Scrum Day 2012, le reportage
Pour ceux et celles qui n’ont pas eu l’opportunité de voir le reportage filmé durant lors du Scrum day 2012, fin mars de cette année.
(Source: https://www.youtube.com/)
Mois : août 2012
Note de lecture : Pattern Language of Program Design, James Coplien & Douglas Schmidt edt
Note : 4 ; Pour les “accros” des patterns, exclusivement.
Le mouvement des “Design Patterns” a donné naissance aux conférences PLOP d’abord (aux Etats-Unis, à l’université d’Urbana Champain, Illinois), puis EuroPLOP (Kloster Irsee, Allemagne). Ce volume regroupe une sélection des papiers soumis par les participants à la première conférence PLOP. C’était alors le début de cette conférence, en conséquence la sélection n’est pas sévère, les patterns soumis peu ou pas “compétitifs”, souvent très généraux, plus centrés sur les concepts (ce que l’on qualifie parfois d’approche Alexandrienne) que sur le design. Enfin, une place importante est prise par les patterns “organisationnels”.
Sans rentrer dans les détails, voici une idée générale de la structure de cette compilation :
La première partie « frameworks et composants » regroupe des patterns et patterns languages de niveau très conceptuels pour architecturer des applications.
La seconde partie « systems and distributed processing » regroupe des patterns à caractères architecturaux. C’est l’une des plus intéressante du livre.
Dans la troisième partie « business objects » on retrouvera des patterns et pattern language liés à des domaines métier.
La quatrième partie « process and organization » regroupe exclusivement des patterns languages. C’est celle qui m’a le moins accroché.
La cinquième partie « design patterns and catalogs » est dédiée aux papiers ayant trait à l’étude des patterns : catégorisation, mise en évidence, documentation. C’est intéressant dans le principe, mais hélas ennuyeux dans les faits.
La sixième partie « architecture and communication » promettait d’être intéressante, mais le traitement des patterns qui y figurent est trop littéraire à mon goût pour présenter un réel intérêt. Le « POSA book » adressera cela beaucoup mieux !
La septième partie « object usage and style » ne donne pas tellement lieu à commentaire, si ce n’est que les patterns qui y figurent ne resteront pas dans les annales.
La dernière partie « events and events handlers » a je pense été créée car plusieurs patterns apparaissaient dans cette catégorie.
Certains patterns se détachent du lot, par exemple :
- Half-object + protocol de Gerard Meszaros
- Master-Slave pattern de Frank Buschmann
- Reactor de Doug Schmidt
- Le CHECKS pattern language de Ward Cunningham qui est l’un des rares pattern language de cette édition à mériter le détour.
- Dans les patterns organisationnels, une petite curiosité : le « Lifecycle and Refactoring Patterns that Support » qui est en fait une prémice du futur « Refactoring » paru en 1999.
Certes la substance utile est plus importante que celle que j’ai cité. Mais beaucoup des patterns et surtout des patterns languages sont plus des essais à l’intérêt académique que de la matière exploitable. Pour qui veut se plonger dans l’étude des Patterns, ce volume a un intérêt ne serait-ce qu’historique. C’est mon cas. Mais pour beaucoup, ce volume sera à la fois trop aride et pas assez pourvu de matière exploitable en regard de ses 550 pages.
En vérifiant sur Amazon, j’ai la surprise de constater que ce livre est toujours disponible 17 après sa parution ! Je ne le recommande toutefois qu’exclusivement aux aficionados des patterns !
Référence complète : Pattern Language of Program Design – James Coplien & Douglas Schmidt edt – Addison Wesley / Software Patterns series 1995 – ISBN: 0-201-60734-4
Une terrasse de neuf étages commence par un tas de terre.
Lao Tseu
Organize for complexity par Niels Pflaeging
Cet article publié sur Betacodex traite de l’adéquation des organisations avec la complexité. En voici la version slideshow
View more presentations from Niels Pflaeging
Niels a également initié une discussion dans le groupe LinkedIn “Stoos” à ce sujet. Il faudra que je vous en dise plus à propos de Stoos un de ces jours …
Note de lecture : C++ Coding Standards, par Herb Sutter & Andrei Alexandrescu
Note : 7 ; N’écrivez plus vos règles de développement sur vos projets C++ !
Quand j’ai besoin de mettre en place des règles de développement en C++, j’ai l’habitude de ressortir mon mètre linéaire d’ouvrages sur le C++, ainsi que mon édition quasi complète de C++ report, et de m’efforcer de dégager nombre de règles impératives, expliquées et détaillées, en fournissant nombre de références bibliographiques. Travail harassant (bien que passionnant), si il en est ! Bien sûr, avec les ans, j’ai amélioré la chose, et je ne repars plus de zéro, mais …. Mais voilà, CE livre est arrivé et a fort heureusement rendu mes efforts obsolètes !
Le livre de Sutter et Alexandrescu couvre plutôt efficacement les grandes lignes des choses à ne pas faire (mais en excluant les choses vraiment trop basiques). 101 règles, c’est plutôt solide, mais on pourrait aussi trouver cela insuffisant. Je pense, moi, que c’est un bon compromis. Si certains aspects doivent être mieux couverts dans votre projet, ou si le niveau de l’équipe nécessite des règles plus basiques pour blinder le développement, ajoutez-les à ce matériel de référence ! Agissez de même pour illustrer les points de l’ouvrage avec des exemples issus de votre domaine de travail. Mais le gros de la matière est là et bien là.
Pour rapport aux ouvrages de Meyers ou de Sutter, celui-ci se positionne différemment : au lieu de développer les items de façon pédagogique, on se contente de développer chaque item sur 1 ou 2 pages (parfois 3), avec des explications claires, mais sans le développement en profondeur de Sutter, ni l’approche pédagogique de Meyers. L’efficacité est privilégiée, et c’est très bien adapté à la finalité de ce livre (manuel devrai-je dire).
Les règles sont rangés sous plusieurs volets qui forment autant de chapitres :
- D’abord des règles organisationnelles : gestion de version, niveau de warnings, etc… Les bases pourrait-on dire.
- Des règles de conception, qui ne sont pas spécifiques au C++. Elles recoupent ce que l’on pourra trouver dans le « Designing Object-Oriented C++ Applications » de Robert Martin.
- Le style de codage : usage des constantes, déclarations des variables, etc..
- L’usage de fonctions et d’opérateurs.
- Les règles d’usage et d’implémentation de l’héritage. Cela paraît curieux mais il y a effectivement beaucoup de subtilités possibles en C++.
- Constructeurs, destructeurs et opérateurs de copie.
- Utilisation des namespaces.
- Utilisation des templates.
- Gestion des exceptions.
- L’utilisation de la STL couvre deux chapitres, pour les conteneurs d’abord puis pour les algorithmes.
- Utilisation des opérateurs de cast modernes.
Si vous avez de la bouteille en C++, vous n’apprendrez rien. En fait, le but n’est pas d’enseigner des choses, mais de poser un socle solide de règles pour construire des développements en C++. Je recommande chaudement, bien entendu.
Référence complète : C++ Coding Standards: 101 rules, guidelines, and best practices – Herb Sutter & Andrei Alexandrescu – Addison Wesley / C++ in depth series 2004 – ISBN: 0-321-11358-6
Quand on ne sait pas où l’on va, tous les chemins mènent nulle part.
Henry Kissinger
Note de lecture : Beginning SQL Server 2005 for Developpers, par Robin Dewson
Note: 7 ; LE livre pour bien débuter avec SQL Server 2005
Attaquer une « grosse » base telle que SQL Server 2005 quand on n’a pas l’expérience de tels environnements n’est pas évident. Paramétrage, gestion des bases, exploitation et administration sont autant de sujets à découvrir autant sous l’aspect du « quoi » que sous l’aspect du « comment ». Ce livre répond parfaitement à cet objectif. En tout cas, il a bien marché pour moi. Il fait un tour d’horizon complet de la base de données en introduisant chacune de ses facettes, en expliquant par l’exemple comment faire, aussi bien avec les outils interactifs qu’avec le T-SQL. Bref, on est mieux armé à la sortie, et l’on sait dans quelle direction aller sur chacun des sujets, prêt à approfondir plus avant chaque sujet dont on a le besoin.
Les deux premiers chapitres présentent l’architecture de la base, ses options d’installation et le « management studio » qui est l’outil interactif permettant d’accéder à la plupart des fonctionnalités de la base.
Le chapitre trois nous guide pour ce qui est de la création des bases, les différentes options possibles et donne des clés pour configurer une base optimale en termes de performances.
Le chapitre 4 est consacré à la sécurité et à la gestion des utilisateurs. Il présente clairement les différents modes d’authentification et donne des conseils pragmatiques quand aux configurations à adopter, surtout pour les bases d’exploitation. Un sujet habituellement aride, traité ici avec pragmatisme et intelligence.
Les chapitres 5 et 6 sont dédiés au design des bases : création de tables et d’index. Là encore, on a une information détaillée et précieuse, même si le chapitre 6 ne s’avère pas si clair que ça.
Le chapitre 7 est consacré à l’administration : les procédures de backup et de maintenance. On y trouve juste ce dont on a besoin : Les clés pour assurer la mise en place de procédure de gestion classiques de sauvegarde et de maintenance. Indispensable !
Avec les chapitres 8 à 13, on aborde le gros de la troupe : travailler avec T-SQL. Même si le langage a été abordé avant pour la mise en œuvre des différentes fonctions dans ce langage, c’est de manipulation de données dont il est question ici ! Le chapitre 8 nous donne le bagage de base pour traiter les données : select, update et delete avec les différentes clauses de base. Le chapitre 9 traite d’un sujet plus pointu : les vues. Hélas ce n’est pas le meilleur chapitre du livre. Les procédures stockées (comment y échapper ?) sont couvertes par le chapitre 10. Même s’il manque pas mal de briques pour faire tout ce que l’on souhaiterait, on a de quoi démarrer. Les chapitres 11 et 12 terminent le tour d’horizon du T-SQL d’abord en le balayant en largeur, puis en abordant les aspects moins usités du langage. J’avoue avoir largement décroché au chapitre 12 (et aussi un peu au chapitre 11). Le chapitre 13 clos l’affaire avec les triggers et des conseils fort pertinents quand à leur usage.
Un peu en décalage, le chapitre 14 aborde Reporting Service. Il nous permet de désirer en savoir plus, car le traitement qui en est fait ici est vraiment superficiel.
Bref, voilà un ouvrage qui, en 400 pages, nous permet d’avoir une vue globale de l’outil, et m’a permis de porter mon attention sur ce qui était mal fait ou pas fait sur la façon dont nous l’utilisions. Sous cet angle, il a déjà dix fois justifié son achat, et je sais qu’il continuera encore à me rendre service.
Le problème inhérent aux livres liés à des technologies particulères est qu’il vieillissent à la vitesse de celles-ci. Cet ouvrage a déjà connu deux mises à jour, pour SQL Server 2008 puis SQL Server 2012 (que je n’utilise pas encore). La troisième édition a d’ailleurs enflé jusqu’à 700 pages ! Cela voudra certainement dire une petite mise à jour dans un avenir certainement pas trop lointain.
Référence complète : Beginning SQL Server 2005 for Developpers, from novice to professional – Robin Dewson – Apress 2006 – ISBN : 1-59059-588-2 ; EAN : 978 1 59059 588 6
En finir avec la roadmap !
Je vous l’avez promis il y a peu, voici le premier opus de mon feuilleton “en finir avec…”. Ma victime du jour est la roadmap.
Avant que vous commenciez cette lecture, un mot d’avertissement. J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.
C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !
La roadmap qu’est-ce que c’est ?
Ce terme est utilisé en informatique de manière assez libérale. Il peut concerne aussi bien un projet, qu’un ensemble de projet, une stratégie business et beaucoup d’autres choses encore. Je vais m’intéresser ici à la roadmap d’une organisation de développement. Elle est souvent relative à un portefeuille de projets, comme on le verra.
Mais au fond, que va-t-on attendre d’une roadmap ? Ou du moins, qu’est-ce que moi, je vais en attendre ?
Principalement une certaine perspective d’avenir, capable de me montrer les orientations des mois à venir. Je suis réaliste, je sais bien que :
- Plus on se projette dans le futur, plus le niveau d’incertitude est élevé. En un an, beaucoup de choses peuvent se passer en terme d’évolution du marché, d’opportunités business, etc… Je considère même que c’est un signe de bonne santé de l’entreprise, du moins tant que l’on ne confond pas évolution de la stratégie et atermoiement.
- Qu’un changement majeur de stratégie (un “pivot” dans le langage Lean Startup) peut totalement remettre en cause cette perspective à un moment donné.
- Qu’il n’est ni utile ni raisonnable de chercher à étoffer cette projection de détails que l’on n’a pas encore et qui seront peut-être obsolètes au moment où l’on traitera le sujet.
Bref, quand on va me parler de roadmap, je vais penser à quelque chose comme cela
En clair : une direction, avec des jalons représentant des niveaux d’accomplissements, mais aussi des dates en dur représentant des contraintes opérationnelles : engagements divers contractualisés, salons, etc…
Le syndrome de la roadmap de projets
Dans les faits, nous allons plutôt devoir composer avec un plan établi sur la base d’une liste de projets priorisés et planifiés en fonction de notre capacité de travail afin d’optimiser celle-ci en l’utilisant au mieux.
Peut-être aurez-vous remarqué le début d’une pointe d’ironie ?
Peut-être aussi, si vous avez suivi des posts et présentations plus anciens que j’ai pu faire, vous dites-vous que j’ai défendu ce même concept de roadmap il n’y a pas si longtemps ? Je l’avoue dès maintenant : mes idées ont sinon changé, du moins pas mal évolué. J’assume.
Le problème avec cette occupation optimisée de la capacité de travail, c’est que la roadmap ressemble désormais à ça:
On peut faire pire. Il y a une variante de la roadmap de projets appelée “roadmap matricielle”. En voici une vue d’artiste (vous remarquerez les “jolies couleurs”, partie intégrante du concept).
La roadmap matricielle présente une certaine élégance et peut donner l’apparence d’une maîtrise plus pointue du sujet. Après tout, il faut être plus intelligent pour appréhender les choses en deux dimensions qu’en une seule, non ? Cela bien établi, on se demande pourquoi personne n’a encore eu l’idée de réaliser des roadmaps tridimensionnelles ! La difficulté de rendre cela sous Powerpoint, j’imagine …
En réalité la roadmap matricielle amplifie les travers de la roadmap de projets :
- Plus d’embouteillage : ce n’est plus une file de projets qui en en attente mais une série de files d’attentes ! L’image du péage de Saint Arnoult s’impose à moi !
- Alignement des ressources avec le plan. Il est bien facile d’ajouter une ligne à une matrice. Mais qu’en est-il des équipes de développement ? La pratique montre qu’elles sont rarement dimensionnées en conséquence. Souvent cela se traduit par du temps partagé de développeurs (un désastre) ou des équipes de développement fractionnées pour atteindre des tailles d’une ou deux personnes pour certaines d’entre-elles…
- Pas de focus stratégique. On attend d’un comité de direction qu’il donne justement une direction ! Que peut-il faire quand il est incapable de mener à bien sa mission première ? Il peut ne pas décider de direction stratégique et clamer que “toutes les directions sont prioritaires”. La roadmap matricielle traduit cela.
Qu’elle soit matricielle ou non, la roadmap a des conséquences dont nous allons nous rendre compte qu’elles sont des effets de bord de son existence même. Ce sont pour la plupart en fait des effets psychologiques.
Conséquences, conséquences
La persistance dans l’action
L’une des vertus de la roadmap est de montrer que derrière le projet en cours, il y a un ou plusieurs projets en attente. En principe c’est un bienfait, ce n’est même pas complètement négatif, même si je vais prétendre l’inverse dans deux secondes.
Mais concentrons-nous sur notre projet en cours.
Etant agile, vous savez que l’intérêt d’un projet ainsi réalisé réside dans le feedback, l’émergence de nouvelles idées porteuses de valeur ou l’abandon d’idées initiales qui finalement n’en ont pas. Dit autrement, on devrait arrêter un projet quand il n’y a plus de valeur business dans les fonctionnalités à venir, par contre on devrait le poursuivre si la valeur de ces fonctionnalités à venir le justifie. Il n’est d’ailleurs pas rare que les fonctionnalités différentiantes arrivent relativement tardivement car on doit au préalable assurer les fonctionnalités de base, comme le montre le modèle de Kano.
Hélas la file d’attente crée une pression psychologique vers l’arrêt du projet, même si les fonctionnalités à venir sont intrinsèquement porteuses de valeur. Il faut certes juger de l’intérêt de poursuivre ou passer à autre chose, mais la roadmap tend à créer un biais dans la décision dans le sens de la tenue du plan.
La rigidification du changement
Une roadmap de projet, c’est un plan. Et créer un plan, ça prend du temps. Combien de temps (en délai) allez-vous prendre pour prioriser avec un comité de direction un portefeuille de 20 ou 30 projets ? Si votre réponse est “1 mois”, je pense que vous vous en tirez bien. Généralement, ce sera plutôt plus.
Maintenant, partons sur l’hypothèse de 2 équipes traitant des projets allant de 6 mois à 1 an, ce qui est compatible avec une roadmap d’une vingtaine de projets soit disons 3 ans de travail. Statistiquement, on va donc se retrouver avec un démarrage de projet tous les 3 à 6 mois. Quelle est la probabilité pour qu’un comité de direction réévalue cette roadmap à chaque début de projet (tous les 3 à 6 mois), avec un délai de réévaluation qui sera de 1 à 2 mois ? En théorie, c’est faisable, dans la pratique c’est au mieux improbable.
On se retrouve ainsi devant l’alternative suivante:
- Pas de réévaluation du portefeuille et on suit le plan sans le remettre en cause, en tout cas pas à chaque début de projet.
- Le bon sens prédomine, et lors du début du projet suivant, on démarre le projet qui parait être le plus important pour la société, qui n’est pas nécessairement celui prévu par la roadmap. Et la roadmap devient gentiment obsolète…
Incapacité à faire face à l’imprévu
L’un des autres effets pervers de la roadmap est l’effet d’encombrement qu’elle donne. En rendant visible (et priorisés) un grand nombre de projets, elle provoque une censure, voir une autocensure par rapport à de nouvelles opportunités business qui demandent un changement radical de direction. La présence même de la roadmap crée un frein psychologique à l’idée d’arrêter là un développement en cours ou de le réorienter.
Une variantes de ceci est la perte d’opportunités pour les équipes de réalisation elles-mêmes : crucifiées à leur roadmap, elles voient les projets d’actualité passer en d’autres mains car “ces pauvres gars sont bien trop occupés, il faut les soulager”. Là encore l’effet d’encombrement se substitue à l’importance business des projets qui émergent.
Quand c’est pas cher, c’est prioritaire
L’analyse et la priorisation d’un portefeuille de projets se font souvent sur la base d’indicateurs associés à ces projets : risque, importance business, coût, etc… En soi cela est une bonne chose même si calibrer l’importance relative de ces indicateurs est à la fois subjectif et délicat. Mais hélas ce processus nous expose lui-même à deux travers:
- Perdre de vue l’axe stratégique que l’on s’est fixé.
- Tomber dans le syndrome de la priorisation par le coût : “ce projet est tout petit, on doit pouvoir le caser avant ce gros”. Une fois tombé dans cette logique, le corollaire est une importance exagérée donnée à la quotation des projets (elle conditionne majoritairement les priorités), donc une logique de coûts préétablis sur les projets fonction des spécifications et par là même une sclérose anticipée du périmètre fonctionnel !
La roadmap de projets, c’est du stock
Quel est l’intérêt avéré d’analyser, évaluer et prioriser une vingtaine de projets lorsqu’au final c’est un et un seul projet qui démarrera au prochain démarrage de projet ?
En fait, il y a bien un intérêt : s’assurer que le bon projet à démarrer est bien celui que l’on a choisi et aucun des 19 autres ! Mais quel est l’intérêt de déterminer que les projets en position 4 et 5 sont correctement priorisés ? Ou même que celui mis en seconde position est le bon ? Le Lean nous apprend deux choses importantes:
- Le stock, c’est du gâchis. Il doit être éliminé.
- Les décisions doivent être différées jusqu’au “dernier moment responsable”. Ce dernier moment responsable, c’est celui où l’on va effectivement démarrer le projet.
Etablir, entretenir, réévaluer de longues listes de projet, c’est indubitablement du stock. Combien de projets de cette liste ne seront même jamais démarrés?
Et la roadmap agile ?
Depuis quelques années est apparu le concept de “roadmap agile”. La littérature sur le sujet n’est pas très abondante non plus, mais elle existe. Vous trouverez d’ailleurs une note de lecture sur un de ces ouvrages sur ce blog.
Quel est le but d’une roadmap agile ? Il reste de gérer et prioriser un portefeuille de projet, mais de manière plus efficace en ne remontant que les informations pertinentes à la priorisation. Donc, on décide plus efficacement sans s’engluer dans une masse d’information et un niveau de détails qui ne sont pas pertinents à ce niveau. On est aussi plus efficace à collecter et analyser l’information en amont. Bref, on se met en condition pour permettre le suivi et l’évolution itérative du portefeuille.
Mais cela reste quand même du stock !
Quelle alternative(s) ?
Analyser un gros portefeuille de projet est-il nécessaire ?
D’un point de vue des équipes de réalisation on a guerre besoin d’avoir une vingtaine de projets priorisés. On a même pas besoin d’avoir une visibilité sur ces vingt projets. On a juste besoin de connaitre le prochain projet. Avoir une idée des un ou deux suivants tels qu’on les imaginent aujourd’hui peut aider à donner de la perspective, pour autant que l’on accepte que la vérité d’aujourd’hui ne sera peut-être pas celle de demain…
D’un point de vue business, c’est un peu différent. Il faut identifier le (ou les quelques) bon(s) projet(s) à réaliser. Mais il n’est pas utile de recenser et surtout analyser tous les projets potentiels de l’entreprise ou du département pour cela. Si la stratégie est clairement identifiée, les quelques projets les plus importants remonteront naturellement. Et il y a de bonnes chances pour que ce soit les bons.
Le problème est la “stratégie clairement identifiée”. Ce n’est pas un boulot si facile que cela, mais c’est celui que l’on attend d’une direction.
Se livrer à une grande foire des projets, pardon à une roadmap des projets est aussi une façon d’abdiquer à l’établissement de cette stratégie.
Alors la roadmap, c’est mal ?
C’est le moment où je ne vais pas répondre à la question. C’est à vous d’y répondre.
La roadmap n’est pas intrinsèquement mauvaise, surtout si on essaie de la mener en agile. La vertu qu’elle doit porter est de donner de la perspective.
On peut aussi avoir une liste des “projets potentiels”, sorte d’aide-mémoire entretenu au fil du temps et de discussions informelles. Je le fais. Et cela m’aide lorsque le sujet et des sujets proches sont évoqués.
Mais les effets néfastes de la roadmap de projets existent et peuvent être plus importants que ses bienfaits. A vous de juger.
Personnellement je pense que la roadmap commence par une stratégie. Elle doit permettre de se focaliser sur un petit nombre de projets.
Les choses qui importent le plus ne doivent pas être à la merci de celles qui importent le moins.
Goethe
Software Freethinker 
