Mois : février 2012

Note de lecture : Le management pour les nuls, par Bob Nelson & Peter Economy

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Non, en fait il n’est pas nul du tout !

Une véritable surprise, ce livre. Si un ancien collègue ne me l’avait conseillé, je ne me serai jamais arrêté dessus. Les auteurs sont très aguerris sur le management, et le texte s’attache à ce qui est important, la gestion des hommes, leur motivation, la délégation de travail, le leadership, etc.. Les techniques de suivi en tout genre qui font les choux gras de bien d’autres ouvrages de moindre qualité n’ont pas leur place ici. Outre la remarquable pertinence du propos, le livre recèle deux qualités importantes : le texte est bien écrit, facile à lire, passionnant même. La seconde qualité du livre est de couvrir de façon volontariste les différentes facettes du management, dont le licenciement, les aspects politiques et la budgétisation, entre autre exemple.

Il y a peu de méchantes choses à dire sur cet excellent ouvrage qui permet, outre sa lecture linéaire, une utilisation en ouvrage de référence, eut égard au découpage en nombreux chapitres (23 en tout) et aux nombreuses « check-lists » et autres encadrés. Ah, si ! Une chose tout de même : le texte aurait pu être mieux adapté au contexte français sur certains points ; le chapitre sur le licenciement aurait pu (entre autre) être mieux adapté au contexte français.

Le Management pour les nuls

Référence complète : Le management pour les nuls – Bob Nelson & Peter Economy – First Editions 2004 (V.O. : Management for dummies – Wiley Publishing 2001) – ISBN : 2-87691-952-4

Le Management pour les Nuls


http://www.goodreads.com/book/add_to_books_widget_frame/2876919524?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Publicité

Note de lecture : Lean from the Trenches, managing large-scale projets with Kanban, par Henrik Kniberg

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 10 ; Efficace, pertinent, intelligent !

J’ai acheté ce livre avec de grosses attentes. Non pas sur le contenu, car je ne me suis même pas préoccupé d’en connaître la teneur en l’achetant, mais simplement de par la connaissance des autres écrits d’Henrik Kniberg.

Henrik Kniberg aime faire court. Une tendance qui s’agrave avec l’âge : ce texte fait 150 pages. Et encore la partie principale (celle qui vient des tranchées) n’en compte que 100. A l’arnaque me direz-vous ? Il n’en est rien. L’auteur boucle en 100 pages ce qui en demande 250 à d’autres ! Ca tombe bien : notre temps est précieux, quand l’auteur va droit au but et fait que chaque ligne compte et donne de l’information, cela fait vraiment la différence. A ce jeux, Henrik Kniberg est le meilleur.

A l’image de Scrum from the trenches, l’auteur nous livre un retour d’expérience. Il nous livre ce qu’il a fait, ce qui a marché et ce qui n’a pas marché, comment son équipe en est arrivé là et qu’est-ce qui reste imparfait. Le texte est un modèle de clarté, de pertinence et d’honnêteté. Il est éclairant de par ses bonnes idées, par la démarche et l’analyse fine qui sous-tend cela. Mais que recèle donc ce texte ?

En fait les 16 (oui, 16 chapitres sur 100 pages !) tournent autour du tableau Kanban : la façon dont il est construit, comment a-t-il évolué, quelles sont les dynamiques de travail qui gravitent autour, quelles métriques en sont extraites. Bien sûr le texte est naturellement illustré par des photos (parfois auxquelles des indications sont supperposées) du Kanban ou de l’équipe. L’auteur n’a pas essayé de décrire de manière approfondie la façon de travailler de l’équipe (à la façon de ce qu’il avait fait dans « Scrum from the Trenches »), mais plutôt de se focaliser sur les dynamiques de l’équipe et du projet.

La seconde partie consacre 4 chapitres sur 50 pages pour évoquer certains aspects plus informatifs auxquels le texte principal se rapporte : ce qu’il y a dans XP, Scrum, Lean et Kanban ; l’automatisation des tests ; le planning poker et les diagrammes de cause-effets. Chaque chapitre est un modèle de pertinence et de concision.

Je ne vais pas passer du temps à décrire ce que contient le livre : il vous faut simplement le lire vous-même. Si vous êtes agiliste, débutant ou expert, il n’y a simplement aucune raison, aucune excuse pour ne pas consacrer du temps à vous plonger dedans !

lean-from-trenches-pragprog

Référence complète : Lean from the Trenches, managing large-scale projets with Kanban – Henrik Kniberg – Pragmatic Bookshelf 2011 – ISBN : 978-1-934356-85-2

Lean from the Trenches: Managing Large-Scale Projects with Kanban


http://www.goodreads.com/book/add_to_books_widget_frame/1934356859?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition, par Scott Meyers

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 10 ; Un texte à l’écriture hors pair, remis à jour en prenant en compte la STL, mais toujours irréprochable!

Je sais que vous pouvais être surpris de voir une note de relecture sur un livre dédié à C++ ici ! Sachez deux choses:

  • Ayant pratiqué C++ pendant 12 ans, j’ai un très important fond de commerce de livres, et donc de notes de lectures, sur C++.
  • Discutant l’autre jour avec une de mes collègues, nous parlions de style d’écriture de livres, et de ce à quoi ressemble un très, très bon style d’écriture. De ceux qui vous accrochent, vous passionne, vous font comprendre les choses et vous font rire, quel que soit la complexité ou l’aridité du sujet. L’exemplarité dans le domaine existe, de mon point de vue. Parmi plusieurs centaines de livres, il s’agit de cet auteur là, de ce livre là. Sans aucun doute possible.

Pour ceux qui seraient inquiets quand à cette 3ème édition de l’ouvrage, le style de l’auteur est resté égal à lui-même : un régal ! En fait, l’écriture de Scott Meyers est l’exemple même de ce que devrait être l’écriture d’un texte technique. La première fois que j’ai lu cet auteur, j’ai dû avaler le livre en 2 ou 3 jours. On s’y accroche tel en bon roman, peut-être ai-je surpris des personnes dans le métro en éclatant de rire… Il m’a fallu un moment pour que je prenne conscience, une fois la dernière page tournée, que j’avais lu un texte très technique !

Alors c’est vrai : j’ai sauté la seconde édition ! Je devrais donc me contenter de comparer cette 3ème mouture avec la seconde édition. Dix ans ont passé depuis, et l’auteur a fait bien plus qu’un simple rafraichissement des items présentés, il a effectué un travail d’introspection en réévaluant la pertinence des items (9 ont disparus), en créant de nouveaux (15 items complètement nouveaux), en fusionnant certains et en découpant d’autres. Au-delà de ce remaniement, le texte est complètement revu, eut égard au niveau des compilateurs actuels, de la librairie standard et même du futur standard, et même de la librairie Boost. On trouve aussi des inspirations nouvelles : ainsi le « copy and swap », les 3 types de garanties (basic guarantee, strong guarantee et no-throw guarantee) ainsi que le NVI idiome sont directement inspirés des « exceptional C++ » de Herb Sutter, d’ailleurs largement cité en préface.

Ce volume est plus épais que les précédents, avec ses 280 pages, en impression bicolore, s’il vous plait ! Je vois une double raison pour céder à la lecture de cette seconde édition : se rafraichir la mémoire sur les bonnes pratiques de Meyers, dans le contexte actuel du C++ et découvrir de nouvelles choses non traitées dans les éditions précédentes (dans les nouveaux items comme dans les items existant). Je vous laisse deviner la conclusion qui s’impose…

Pour ceux qui n’ont rien à faire du C++ mais rêvent de devenir auteur, et même auteur hors pair, voici ce à quoi vous pouvez vous mesurer. Je n’ai aucune meilleure référence à vous proposer.

effective-c++-3edt-Meyers

Référence complète : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition – Scott Meyers – Addison Wesley / Professional Computing series 2005 – ISBN: 0-321-33487-6

Nb : La première édition de ce livre était mon “book of the year” 1994.

Effective C++: 55 Specific Ways to Improve Your Programs and Designs


http://www.goodreads.com/book/add_to_books_widget_frame/0321334876?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Software Project Manager’s Bridge to Agility, par Michele Sliger & Stacia Broderick

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Du PMI à l’agilité par des auteurs qui savent de quoi ils parlent !

Franchir le pas entre les approches classiques et l’agilité est un thème désormais classique. Mais la littérature traitant sérieusement de cette transition est plutôt rare. Les auteurs de ce livre ont un passé (ou un passif) lié au PMBOK plutôt sérieux, elles ont donc largement la crédibilité nécessaire pour attaquer le sujet sous cet angle.

L’agiliste accompli apprendra peu de choses à la lecture de cet ouvrage. Cela ne signifie pas pour autant que la lecture ne puisse en être profitable : si votre besoin est de pouvoir expliquer ou argumenter le passage à l’agilité aux managers classiques, voici un texte sérieux sur lequel s’appuyer !

Cela dit, la cible privilégiée du livre n’est pas celle-ci. Le texte s’adresse directement aux managers et aux « middle managers » issus de la culture de la gestion de projet en cascade. Il s’adresse directement à eux pour expliquer comment passer à l’agilité, quels en sont les bénéfices, la façon de changer les différentes pratiques et la nouvelle posture qu’ils doivent prendre dans cet environnement changé.

Sur le fond, nous avons un matériel assez dense accusant 330 pages, donc une taille de livre moyenne, mais malgré une bonne illustration du propos, cela reste du tassé du point de vue texte. Fort heureusement, les 300 pages du texte principal sont très bien découpés en 17 chapitres d’une part, eux même regroupés en 3 parties formant une progression logique. Chaque chapitre est élégamment introduit avec de surcroit une ou deux citations toujours fort bien choisies. Pour clore les chapitres, nous avons aussi chaque fois un résumé reprenant sous forme de liste à points les éléments passés en revue et une liste des références présentes dans le texte. Un travail de très bonne facture, le découpage en chapitres de moins de 20 pages en rend la lecture plaisante.

La première partie « an agile overview » consacre 3 chapitres à la présentation du monde agile au manager PMI. On commence pour les principes de l’agilité, le manifeste, etc… Bref, les grands classiques. La suite est plus originale, car on passe vers un « mapping » des principes PMI vers les principes agiles. Pour finir on fait un tour du propriétaire du projet agile (itération planning meeting, stand-up, etc…) en le comparant à son pendant PMI.

La seconde partie est la plus conséquente du livre, elle compte 9 chapitres sur 160 pages. Elle aborde les différentes facettes d’un projet en se calquant sur l’approche PMI des différents domaines à couvrir : intégration, cadrage, gestion du temps, gestion des coûts, qualité, ressources humaines, communication, gestion du risque, sous-traitance. Malgré cet angle d’attaque, jamais les auteurs n’abdiquent sur l’approche agile et ils présentent l’alternative agile avec beaucoup d’à propos et de pertinence. J’ai peu à dire là dessus, car si j’ai peu appris, le tout est fort bien ficelé.

La 3ème partie évoque la problématique de la transition. 80 pages sur 5 chapitres y sont consacré. Cela va du changement dans le type de management, à la façon de vendre l’agilité jusqu’aux écueils dans lesquels ne pas tomber. Personnellement, c’est la partie qui m’a le plus apporté.

Au final, un livre qui n’apprendra probablement rien à l’agiliste confirmé, mais pourra aider un coach à faire changer un manager classique vers une approche agile. Mais surtout, c’est probablement la meilleure lecture que l’on puisse proposer à ce dernier pour réussir son changement. Bien entendu, cela nécessite au préalable le bon état d’esprit !

soft-PM-bridge-agility

Référence complète : Software Project Manager’s Bridge to Agility – Michele Sliger & Stacia Broderick – Addison Wesley ASD series 2008 – ISBN : 978 0 321 50275 9

The Software Project Manager's Bridge to Agility


http://www.goodreads.com/book/add_to_books_widget_frame/0321502752?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Maintenance des logiciels: Java, le nouveau Cobol ?

Le par addinquydans ArticlesLaisser un commentaire

Un post de Nicolas Martignoles a récemment attiré mon attention sur un article comparant les coûts de maintenance des logiciels en fonction des langages

L’article évoque en substance des coûts élevés pour les applications Java (un facteur 4,3) par rapport aux applications Cobol. Le tout basé sur une étude de 745 applications. C# semble nager dans les mêmes eaux que Java (cela semble logique). Pire: C++ semble mieux loti que Java ! J’aime bien le C++, mais cela devient franchement troublant.

En réalité l’étude fait état d’une réalité sous-jacente bien différente.

La maturité d’une application est un facteur important !

Eh oui, une application “neuve” n’est pas forcément la meilleure sous seul prétexte qu’elle a été écrite à partir d’une feuille blanche ! Cette application est surtout plus “verte”. Je pense qu’il y a différents facteurs jouant sur l’aspect maturité:

  • Une application mature est souvent plus stable. On passe au bout d’un certain temps de demandes de changements de type évolutif à des correctifs ou de ajustements liés à des conditions d’utilisation métier qui ont évolué. Ce facteur va dans le sens d’une maintenance moins chère. Hélas ce facteur de stabilité est aussi souvent le signe d’une transition de l’application vers une phase de fin de vie.
  • Un refactoring applicatif intégrant une flexibilité liée aux évolution. Au delà du design initial d’une application parfois liminaire, les changements demandés sur une application peuvent amener les développeurs à raffiner la conception pour en rendre les changements moins douloureux. Cette approche va souvent de pair avec une amélioration de la couverture de tests. Cela ne concerne hélas qu’une minorité d’application car elle nécessite des développeurs chevronnés sensibles à ce facteur. La majorité des applications se trouve plutôt dans la seconde catégorie.
  • Une entropie des applications suite à des modifications / corrections successives. les applications qui ne sont pas vraiment sous contrôle en terme de tests ont tendance à faire l’objet de “patch”, de correctifs dits chirurgicaux sans en raffiner la conception. Au contraire cela augmente la fameuse “entropie du logiciel”, c’est à dire une dégradation de son design qui augmente la crainte des développeurs d’y toucher, augmentant à son tour les pratiques accélérant l’entropie du logiciel ! Cette spirale se termine finalement par une sclérose totale du code conduisant à la réécriture complète de celui-ci.

L’expérience des développeurs

L’article insiste à juste titre sur les pratiques managériales privilégiant une équation économique court terme. En clair: on embauche des développeurs inexpérimentés à bas salaires pour réduire les coûts. Advienne que pourra de la maintenance ultérieure !

Effectivement les équipes de développement Java sont des équipes jeunes. Il est rare d’y croiser des développeurs de plus de 10 ans d’expérience. On parle déjà de développeur sénior pour des jeunes ayant 5 ans de pratique professionnelles dans les pattes. Il est vrai que le développeur armé de 15 ans d’expérience est d’une part plus cher que son homologue Coboliste et d’autre part qu’il cherchera plutôt une position d’architecte, de team leader ou d’expert technique. Nous avons là deux cultures différentes.

En contrepartie, il n’existe probablement plus de développeur Cobol débutant. Il ne faut pas se leurre, Cobol n’est probablement pas le language le plus sexy, mais la communauté des développeurs n’est pas nécessairement formée d’idiots (en fait, il y a probablement la même proportion d’idiots chez les Cobolistes que chez les Javanais) et les 20 ou 30 ans d’expérience de ces développeurs s’ils ne sont pas un facteur linéaire de compétence les aident produire du logiciel de qualité.

java le nouveau  Cobol ?

Java est le langage majeur des nouvelles applications de gestion. Il absorbe une quantité très importante de la profession avec une disparité de qualification très importante et globalement une population peu expérimentée. A ce titre, il ressemble à ce qu’était Cobol dans les années 80. Il est d’ailleurs devenu un lieu commun de dire que Java est le Cobol des années 2000 (ou 2010 maintenant). L’article avance sans doute avec raison l’existence d’une population importante de développeur Java sans formation solide. C’est aussi ce que j’ai pu voir en entretien de recrutement.

Et C++ ?

Je persiste à dire que C++ a un coût de développement, donc de maintenance potentiellement plus élevé que Java:

  • Le langage est difficile, beaucoup plus difficile et piégeux.
  • Le langage est de bas niveau et ne possède pas l’écosystème de librairies et frameworks s’assemblant rapidement pour adresser certaines problématiques. Pour ne pas parler des outillages et de la communauté open-source…

Mais voilà, beaucoup de développeurs “moyen” ont déserté C++ dans les années 2000, la population C++ est essentiellement constituée de développeurs aguerris, expérimentés sur le langage, voir d’amoureux de ce langage ! Bref la communauté s’est professionnalisée ! Il n’est pas étonnant de constater que la qualité des conceptions et du code produit en C++ soit supérieure, moins sujette au bugs. Cela n’a rien à voir directement avec le langage, mais avec la communauté.

Un jour peut-être…

L’article est trompeur sur son affirmation, mais pas sur son contenu. Les deux facteurs premiers avancés sont réels:

  • Réécrire sans cesse les applications n’est pas une solution. Une application “verte” est toujours plus baguée. De bonne pratiques de maintenance incluant une couverte de tests unitaires et une utilisation agressive du refactoring étendent de manière très importante la durée de vie des applications jusqu’à leur réelle obsolescence technologique (au lieu de la limite de sclérose).
  • L’expérience et la compétence sont des facteurs clé. Ils prédominent largement les aspects de contexte technologiques. On le sait depuis longtemps, mais le management classique reste imperméable à ces assertions.

Ma conclusion n’est pas que Java est un mauvais langage. Sans doute en existe-t-il de meilleurs et je sais qu’il il y en a de moins bon. En fait, peu importe. Je conclue surtout que les valeurs agiles et le Software Craftmanship vont dans la bonne direction: du logiciel de qualité développé avec rigueur et compétence.

Qui a peur du Lightning Talk ?

Le par addinquydans ArticlesLaisser un commentaire

Le Scrum Day 2012 propose, parmi ses formats de soumissions, le “lightning talk”. C’est une nouveauté et un principe simple : vous avez 5 à 10 minutes pour présenter votre sujet.

Je trouve le format attractif, aussi vais-je moi-même proposer un sujet selon ce format.

Plus simple ?

D’abord le format est attractif car il vous permet de ne préparer un sujet que pour 5 à 10 minutes. C’est en principe moins stressant que faire cet exercice pour 45 minutes ! On verra plus loin que ce n’est pas entièrement vrai.

Focus, focus …

Dans une session de 45 minutes, on a tendance à cibler un sujet, puis à explorer différentes facettes de celui-ci. Certes, on a ainsi la sensation d’avoir traité le sujet, mais n’il y a-t-il pas un aspect prédominant par rapport à un autre ? Si c’est le cas (et c’est souvent le cas) celui-ci sera finalement perdu au sein d’une présentation assez longue. Dommage !

ma proposition et mon challenge sont ainsi celui-ci: ne choisir qu’un aspect et un seul. N’aborder que celui-ci, être direct, pertinent et percutant sur ce sujet ciblé ! C’est ce que je vais essayer de faire !

Le sens de l’info

Cette idée du lightning talk (je dois l’avouer, j’ai posé à ce que ce format soit proposé) m’est venue en écoutant une émission de France Info: le sens de l’info, avec Michel Serre. Dans cette émission, Michel Serre évoque un sujet durant 6 minutes environ. Je ne cesse d’être surpris par la masse de réflexions et d’informations que Michel Serre parvient à délivrer dans un temps si court !

Certes je ne suis pas Michel Serre, mais pourquoi donc aurais-je besoin de 45 minutes pour délivrer un message moitié moins consistant. “less is more” disait Ludwig Mies (et Steve Jobs après lui). Il est temps pour moi de montrer que j’y croie

Aller à l’essentiel

J’ai un constat un peu amère à faire: j’ai assisté à de nombreuses présentations et pour une grande proportion d’entre elles j’en suis arrivé à la conclusion que le message ou l’information délivrée aurait pu l’être dans un format bien plus court !

C’est ici que l’apparente simplicité du format se transforme en réelle difficulté: comment éliminer le superflu ? Que faut-il couper pour ne pas diluer le sujet initial ?

L’exercice n’est pas facile, il sera (presque) nouveau pour moi.

Et vous, pourquoi ne présenteriez-vous pas un “lightning talk” au Scrum Day ?

Pour en savoir plus sur les Lightning Talks

  • L’article de Wikipedia dédié au sujet
  • Les Pecha Kucha sont un format très particulier de Lightning Talks en 20 minutes et 20 slides.
  • La conférence Ignite vous donnera aussi de nombreux exemples de Lightning Talks en format court (5 mn).

Note de lecture : Ship it ! A practical Guide to Successful Software Projects, par Jared Richardson & William Gwaltney Jr

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Dans la continuité des « pragmatic programmers », mais en manque d’originalité.

Qu’est-ce qui fait que certaines équipes s’enlisent, tandis que d’autres parviennent à délivrer ? Cette question est le point récurent des méthodes agiles, c’est le fer de lance de cet ouvrage qui n’a donc pas grand-chose d’original à cet égard. Le texte reprend les bonnes pratiques du « pragmatic programmers », en les unissant dans un processus agile découpé en 3 sous-ensembles (formant autant de chapitres du livre :

Techniques ; Cette partie regroupe 5 pratiques : Technical Lead (en fait le chef de projet), The List (la « feature list » de Scrum), Daily Meeting (le daily meeting d’XP), Code Reviews et Code Change Notifier. Il y a peu d’originalité dans ces pratiques communes à la plupart des méthodes agiles. Toutefois la description du « Technical Lead », à la fois gourou technique et gestionnaire des hommes et des plannings me laisse perplexe, tandis que le manager est vu comme un espèce de VRP…

Infrastructure ; Cette partie regroupe 6 pratiques dont 4 sont liées à l’automatisation : Version Control, Script Builds, Write and Run Tests et Continuous Builds. On remarquera que « continuous build » et « script builds » sont sinon liés, au moins dans la continuité l’un de l’autre. Les deux dernières pratiques sont Track Features et Track Issues, là encore 2 pratiques très liées et intimement liées à « The List », mais vu sous la facette Infrastructure !

La partie Process regroupe 5 pratique liées au développement de l’architecture : Propose System Objects, Propose Interfaces, Connect Interfaces, Add Functions et Refactor Refine Repeat. Le but de cette approche est de définir une architecture par découpage n composants majeurs, puis de définir ces composants par leurs interfaces que l’on connecte ensuite, pour finalement les « étoffer » avec la mécanique. Le réfactoring ajoute la touche finale de raffinement de l’architecture.

Comme je l’ai dit au début, il y a peu d’originalité dans ce livre, même si en soi il constitue un texte valable, il a du mal à sortir du lot. Parmi les particularités, je note toutefois les itérations de longueur variable, mais de contenu fixe. Un point de vue qui, hélas, me laisse également perplexe…

ship-it-pragprog

Référence complète : Ship it ! A practical Guide to Successful Software Projects – Jared R. Richardson & William A. Gwaltney Jr – The Pragmatic Bookshelf 2005 – ISBN : 0-9745140-4-7

Ship It!: A Practical Guide to Successful Software Projects


http://www.goodreads.com/book/add_to_books_widget_frame/0974514047?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on