Je viens de regarder sur TED une vidéo-conférence de Mihaly Csikszentmihalyi, sur le thème du flow, cet état de grâce dans lequel on bascule lorsque l'on est concentré sur une tâche captivante et où tout va pour le mieux : compréhension, inspiration, et savoir-faire.

J'ai déjà expérimenté cet état parfois, en travaillant sur des projets personnels (articles techniques pour ce blog, préparation de supports de formation, veille technologique...), plus rarement dans le cadre professionnel. Pour moi, la clé du succès est un enviromment calme et sans distractions - pas de bruits, pas de mouvements, pas de mail/téléphone/MSN, et surtout pas d'horaires (repas, réunions...). Cela explique pourquoi je travaille mieux le soir (au travail) ou la nuit (chez moi), comme la plupart des développeurs expérimentés de mon entourage.

Le mercredi 21 janvier, de 19h00 à 21h00, Zenika organise une présentation de la méthodologie de gestion d'entreprise "lean" animée par Pascal Van Cauwenberghe.

L'école de gestion d'entreprise dite lean (littéralement : « maigre », « sans gras », « dégraissé ») s'intéresse à la performance (productivité, qualité). Les tenants du lean recherchent la performance par l'amélioration continue et l'élimination des gaspillages. L'école de gestion lean trouve ses sources au Japon dans le Toyota Production System (TPS). (Wikipedia)

Cette conférence sera l'occasion de découvrir cette méthodologie, de comprendre comment elle peut s'appliquer au secteur du développement informatique, et de bien cerner son positionnement par rapport aux méthodes Scrum et XP.

Les inscriptions sont ouvertes et les places limitées !

Dans un billet récent, Scott Berkun donne 5 astuces pour garder les réunions sous contrôle, quantitativement et qualitativement.
Je vous les résume ici :

1. Se réunir dans une pièce fraîche, pour éviter l'assoupissement (spécialement après manger).
2. Supprimer les chaises : les gens debout sont nettement moins distraits. La méthodologie agile Scrum emploie cette technique.
3. Une alternative consiste à disposer de chaises subtilement inconfortables. Très fourbe, mais ça a l'air marrant.
4. La réunion doit être animée par un homme (ou femme) à poigne, qui saura la remettre sur les rails au moindre écart.
5. Distinguer les réunions utiles (de travail) des réunions inutiles (rapports, annonces, présentations...), et n'y convoquer que les personnes réellement intéressées.

Voici les points de vue de trois personnalités IT influentes sur le métier de consultant :

• Robert Cringely
• Steven Lott
• Scott Berkun

Sans surprise, la conclusion est que la majorité des "consultants" ne sont pas à l'écoute de leurs clients... et la majorité des clients ne savent pas ce qu'ils veulent. Toute ressemblance...

Toute entreprise disposant d'un système d'information informatisé craint par-dessus tout que celui-ci ne soit attaqué et corrompu. Si les motifs (intelligence économique, malveillance ou simple bêtise) et les acteurs (pirate externe ou employé interne) des attaques informatiques peuvent varier, les conséquences en sont en revanche souvent dramatiques.

En entreprise, les développeurs ont rarement le choix de leurs outils de travail.
Il semblerait pourtant naturel de laisser les gens du métier sélectionner les outils dont ils ont besoin pour être efficaces : vous n'iriez pas conseiller votre boulanger sur le choix de son four à pain ?

Reprendre et modifier du code existant fait partie quotidien du développeur. Mais cette activité présente toujours des risques : peut-on garantir que le code "amélioré" fonctionnera au moins aussi bien que l'ancien ?

Bien sûr, des outils comme les tests unitaires, la couverture de code, l'analyse de dépendance permettent de limiter les effets de bord ; mais rien ne remplacera jamais l' instinct du développeur expérimenté, capable de repérer les erreurs au milieu d'un code ayant subi maintes fois les outrages de patches urgents, de stagiaires inexpérimentés et de copier/coller hasardeux.

Certains ont déjà adopté une technique permettant de jauger visuellement la qualité du code : en l'imprimant à 10% de sa taille réelle, les détails d'implémentation disparaissent et sa structure est mise en valeur. Il est également plus facile de comparer le code original au code amélioré et de mesurer la progression. Enfin, il est possible de trier les feuilles en fonction du degré de satisfaction des développeurs sur le code qu'elles représentent, établissant ainsi un planning clair, dynamique et consensuel.

Votre nouveau projet est une catastrophe ?
Vos développeurs grognent et le chef de projet déprime ?
Le planning et le budget ont explosé, et les clients sont mécontents ?

Félicitations ! Vous êtes sans doute l'heureuse victime des pires méthodologies de conduite de projet informatiques !
(je vous recommande également la lecture des commentaires de l'article).

Ce lundi, le Wall Street Journal se fait l'écho du sentiment d'incompréhension qui règne le plus souvent entre le département informatique et le reste de l'entreprise.

Le rôle exact du département IT est généralement méconnu ; tout au plus est-il considéré comme l'obscure entité chargée de donner corps aux décisions des businessmen. Un mal nécessaire en somme, mais qui présente trois inconvénients majeurs :

• Coûter cher, sans preuve immédiate de son ROI (retour sur investissement) ;
• Etre chronophage, et donc allongeant le fameux Time To Market ;
• Jouer les touble-fêtes au sein de l'entreprise, en exposant au grand jour les questions délicates que personne, pour des raisons politiques internes, ne veut évoquer. Car si le management peut se contenter d'estimations, de tendances et de sondages, l'informatique est au contraire une discipline intransigeante faite de règles claires et d'algorithmes précis.

Les deux mondes du business et de l'IT sont-ils réconciliables ?