SysML, l’UML de l’analyse système

Voici un court papier écrit en 2005. Les reflexions qu’il soulève restent pertinentes. Je me suis bien éloigné de ces considérations depuis une dizaine d’années. Si les efforts pour structurer les exigences paraissent louables, je ne peux m’empêcher de les trouver vains. Ou tout au moins aurait-il falu les compléter par une structuration des tests (via des stéréotypes ?) à différents niveaux…

Je ferais certainement l’effort d’une note de lecture sur l’ouvrage de Pascal Roques un de ces jours. En attendant : enjoy !

Publicités

The New New Product Development game, par takeuchi et Nonaka

Cette publication est connue pour être la source d’inspiration des créateurs de Scrum. Il fut publié en 1986 dans le Harvard Business Review et Hirotaka Takeuchi et Ikujiro Nonaka en sont les auteurs. Ils viennent du marketing et non du développement logiciel.

Les 6 caractéristiques du “Scrum”

On parle bien déjà de Scrum ! Et l’on prête à ce processus 6 propriétés fondamentales :

  • Une instabilité intrinsèque : le top management ne donne aux équipes qu’une direction générale avec un challenge très élevé à relever. Par ailleurs ce management donne une grande liberté d’action et d’interprétation. Cela crée une tension dans l’équipe à même de favoriser la créativité.
  • Des équipes auto-organisées. Elle apparait quand sont réunies 3 conditions :
  • L’autonomie : peu d’intervention du top management, son rôle est de fournir les ressources adéquates. L’entité fonctionne comme une startup.
  • L’auto-transcendance : L’équipe est dans une quête continuelle pour dépasser ses limites.
  • L’auto-fertilisation : une équipe pluri-disciplinaire renforçant leur connaissances respectives à l’image d’un impact hub.

Des phases de développement en chevauchement : le rythme de développement agit comme le poul de l’équipe. Pour permettre le développement selon ces phases courtes, il faut adopter le “sashimi system”. Le multi-apprentissage : il s’effectue à différents niveaux (individuel, collectif, entreprise) et dans les différents domaines d’expertise de l’équipe.

Lire la suite

The SCRUM Development Process

Cet article est réellement le premier à présenter Scrum, c’était en 1995. Petit détail que j’ignorais, Ken Schwaber l’a mis en oeuvre pour le développement de Delphi ! Déjà l’auteur présente son approche comme étant « boite noire » et empirique, bien adapté au développement de systèmes complexes. Et oui, Scrum est bien en rapport avec le Rugby !
Bien sûr, à cette époque, il n’était pas encore question du mot « agile ». Ken Schwaber situe Scrum comme une évolution des procesus itératifs, non comme une disruption.

Quand il parle du développement logiciel, c’est toujours à la notion de complexité que revient l’auteur. Il la définit comme suit :

Complexité = f(dev. environnement var. + target env. var.)

Toutes ces varaibles changeant par ailleurs au cours du projet.

Lire la suite

Le guide Scrum, millésime 2013

On a pu voir différents retours sur le Scrum Guide 2013

Avant d’aborder le fond, ma première remarque: le document a de toute évidence été écrit avec Word sur Mac. Les auteurs ont utilisé le style par défaut sans rien changer aux styles proposés (Titre, titre 1, titre 2 et normal entre autres). J’aime bien aussi le copyright “1991-2013”, même si le premier article publié date de 1993…

Rentrons dans le fond.

La transparence

C’est un ajout par rapport aux versions précédentes. Bravo. Cela dit, c’est très centré “inspection”. J’aime bien la notion de “done partagée” (pour les items de backlog, car il y a aussi un “done” des tâches qui ne concerne que l’équipe), et pour moi la transparence passe plus par le partage d’information : tableau des tâches, backlog, etc… pas simplement à l’intérieur de l’équipe mais aussi à l’extérieur.

Le Product Owner

Cela n’a pas bougé depuis 2011. Mais je reste assez dubitatif de cette position qui créé un schisme entre l’équipe et le “responsable fonctionnel”. Je m’en étais ouvert dans ma rubrique “en finir avec” dans un post dédié aux Product Owners. Ma position n’a pas changé, et ce partage des eaux ne m’a jamais semblé agile.

La Scrum Team

Comme d’autres, je pense qu’une taille de 9 est le début de la rupture. En fonction de la dynamique de groupe, ça peut tenir ou pas, ou la rupture peut être avant. Quand je dis “rupture”, je veux dire qu’en fait l’équipe se restructurera d’elle-même en sous-groupes de manière informelle. Pas la peine de luter, ça se passera de toute façon.

De toute manière, l’art de fixer une taille est un peu osé. Une équipe de deux, ça peut marcher et avoir un sens pour certains projets, même en Scrum !

Le Sprint

Plus ça va, moins j’aime le mot “sprint” qui a trop une connotation de “rush” à mon goût. Itération me va bien. Bien sûr l’insistance sur les 30 jours (même si l’on précise que cela peut être moins) devient drôle. Plus personne au monde, à part Ken Schwaber et Jef Sutherland, ne parle d’une limite maximum à 30 jours, mais bon…

Planning meeting

Comme mes petits camarades, j’ai noté la présence du “sprint goal”. Voici une évolution que j’accueille à bras ouverts ! Depuis pas mal de temps déjà je commence mes planning meeting ainsi, et note cet objectif sur un A3 qui figure ensuite au-dessus du tableau des tâches. Il est vrai que j’arrive rarement à faire une itération avec un seul objectif, mais je ne dépasse jamais 3.

Quoi qu’il en soit j’ai pu noter une différence extrêmement importante de motivation et de productivité entre des sprints ayant un objectif clair par rapport à la vieille méthode “liste à la Prévert” qui nous transforme plutôt en ouvriers spécialisés ! C’est ce qui aide à créer du plaisir et de la motivation : donner du sens à notre travail. C’est bien plus efficace que de coller des niko-niko au mur…

Bravo pour cette évolution qui va dans le bon sens !

Daily Scrum

De manière concomitante, le Daily Scrum prend une orientation qui est en concordance avec le “sprint goal”. C’est pure logique.

Un effet de bord est que l’on parle moins d’engagement sur la liste des stories (voir plus du tout) mais d’engagement sur le but du sprint, qui donne la souplesse d’adapter le contenu en cours de route pour rester dans la ligne de l’objectif mais éventuellement en déscopant des choses !

C’est encore une évolution que j’apprécie. Je n’ai jamais été à l’aise avec la notion d’engagement telle qu’elle été exprimée. Pour moi, l’engagement est moral. La qualité et la conformité au “done” doivent être maintenus coûte que coûte. L’engagement sur une liste de stories est pour moi une manière de demander à l’équipe de s’enchainer volontairement. Elle est le stigmate d’un manque de confiance et au bout du chemin demande implicitement de renoncer au “rythme soutenable”, ce que je n’accepte pas non plus.

On a ce pour quoi on paie. L’engagement sur un ensemble de stories se paie. Souvent en rush avec à la clé une qualité abdiquée, des heures sup’ avec une conséquence désastreuse sur le moral et la confiance et le plus souvent un cocktail de tout cela. Le tout en parfaite conformité avec les valeurs du management contrôle/commande que l’on prétend avoir abandonné !

Ce qui peut paraitre un petit ajustement est pour moi un gros virage dans le bon sens !

Sprint review

Apparemment il fait toujours 4 heures ! Bon je sais que l’on parle d’itérations d’un mois que personne ne pratique. Mais cette durée est ridiculement longue. Je vise une heure maximum pour une iteration de 2 semaines. Et c’est plus souvent de l’ordre de 30 minutes. Bref, je suis aligné sur Pablo visiblement sur cet aspect.

D’ailleurs la pratique des micro-démo tend à conforter la durée de 30 minutes, voir moins.

Sprint rétrospective

Je me suis fait la même remarque que Pablo: il est curieux qu’elle soit plus courte que la démo. Mes rétrospectives sont à peu près toujours de l’ordre de 2 heures pour 2 semaines. En fonction du contexte, ça peut aller jusqu’à 2h30 ; il est plutôt rare qu’elles soient plus courtes.

Product backlog

On parle d’items qui peuvent être complétés dans un sprint. Certes, mais pour moi cela reste une granularité bien trop élevée ! Difficile d’être adaptable au sein d’un sprint si seule un item ou deux figurent au programme ! Mais bon, ce point n’est pas nouveau… Je dirais que là-dessus je suis clairement d’accord avec ce que Gilles Mantel met au programme de son Scrum Master Academy.

Surveiller les progrès vers un but

Ce point devrait être en principe en concordance avec ce qui est dit sur le sprint planning et le Daily meeting. Il ne semble pas, car on parle de monitorer à la fin de chaque sprint ! De plus je trouve que ce point n’est pas très clair…

La transparence, encore et toujours…

J’aime bien ce nouveau focus. Toutefois je le trouve incomplet. Tout d’abord il ne concerne que le “done” et la liste des items pris dans le sprint, alors que je pense qu’il doit s’étendre à l’ensemble des artefacts de l’équipe, notamment le suivi des tâches.

Ensuite pour moi la définition de terminé ne doit pas seulement venir de l’équipe, mais de l’ensemble des parties concernées par le produit : product owner, opérations, hot line s’il y a lieu, etc…

En conclusion

Globalement, ce Scrum guide n’est pas une révolution. Ce n’est pas non plus ce que l’on attendait. J’aimerai bien que les auteurs abandonnent une fois pour toute leur notion de sprint d’un mois qui était déjà ridicule il y a 10 ans et est maintenant franchement embarrassante.

Mais de manière générale, je trouve que ce Scrum guide va dans le bon sens. Les auteurs ont résisté à la tentation d’alourdir Scrum. En fait ils l’ont même allégé de notions pas indispensables, comme celle de release. D’un autre côté, je suis un grand fan de cette notion de “sprint goal” qui nous éloigne d’idées précédentes pas franchement agiles.

Bon boulot, donc !

Scrum Shu Ha Ri : l’article

Après vous avoir infligé le support de la présentation que j’avais faite lors du Printemps Agile à Caen, voici le contenu de la présentation elle-même. Peaufiné, retravaillé, il ne correspond peut-être pas (certainement pas, en fait) à la transcription de ma présentation, mais en révèle le contenu de manière plus approfondie.

En effet, ce ne sont pas moins de 93 renvois et 80 références bibliographiques (sans compter les 27 illustrations) qui émaillent les 29 pages du texte.

Bonne lecture !

La facilitation en kit

Ce “falititator toolkit” donne de nombreuses clés pour appréhender et focaliser la dynamique des groupes. Plus qu’un simple article, il s’agit-là d’un mini-book regroupant le “best of” des auteurs en matière de facilitation. J’ai apprécié la concision et l’efficacité du propos dans chacune des parties abordées:

Le rôle du facilitateur : en une seule page, les responsabilités et ses challenges !

La dynamique de groupe : elle s’articule autour du modèle de Tuckman, reprends la liste des bons et des mauvais comportements et les schémas d’intervention.Le tout en moins de 5 pages.

Idéation et consensus : on aborde ici le coeur de l’ouvrage et les outils qui le constitue : l’art de l’écoute, le “focused conversation”, “appreciative inquiry”, Le brainstorm, le consensus, le processus d’affinité. On a du mal à se rendre compte que l’on a couvert tout ça en 11 pages !

Les réunions efficaces : On balaye les états d’esprit, la check-list (avant, pendant et après), les rôles et règles et les comportements. J’aurais cru cette partie plus riche, mais là encore ce chapitre ne fait que 6 pages.
Gestion de projet: Une page … dont je ne comprend pas ce qu’elle fait là !
Stakeholders input tools : Elles tournent beaucoup autour du Focus group et un peu autour du Web Survey (plus pour faire la pub d’un outil dirait-on). En 6 pages, c’est quand même bien.

Outils pour collecter et analyser les données : quelques outils sont proposés, ils sont bons à rappeler même s’ils sont assez classiques : check sheet, importance / satisfaction diagrams, analyse causale, diagrammes d’interrelation, analyse SWOT.
Flowcharting: Il est assez curieux de trouver ici ces 3 pages sur les flow charts diagrams ici. Cela a bien peu à voir avec la facilitation proprement dite…

Outils de prise de décision : Sans être mortel, ce chapitre nous donne ou rappelle quelques outils : matrice de critères, analyse “force field”, Notation 0 à 10, matrice impact / effort.

Mesurer les impacts : On est plus ici dans la déclaration d’intention. Ou plus exactement, il s’agit d’introduire le matériel fourni en annexe qui d’ailleurs vaut aussi bien le coup !

Bref un papier remarquable qu’il serait dommage de négliger, même si 2 ou 3 parties sont un peu plus faibles ou n’ont simplement pas leur place.

La plupart des outils sont décrits de manière introductive, voir un peu plus. En fait, ce qui est fourni ici est largement suffisant pour démarrer, mais les auteurs donnent aussi les pointeurs pour aller plus loin !

Bonne lecture !

Molecular Structure of Nucleic Acids

Un article qui marque l’histoire des sciences n’est pas nécessairement un monument. L’article original de Watson et Crick décrivant la structure de l’ADN, la fameuse double hélice tient en un peu moins de deux pages de l’édition de Nature datant du 25 Avril 1953. Il vaudra aux deux auteurs associés à Wilkins, le prix Nobel de médecine en 1962.

Pour l’anecdote, le dessin de la double hélice est dû à Odile Crick, la femme de l’un des auteurs, peintre de profession. Ce dessin est par ailleurs la seule oeuvre pour laquelle elle est connue.

Moins drôle : le point de départ de l’article de Watson et Crick est une photographie, connue sous le nom de “photo 51”, prise par Rosalyn Franklin, que Wilkins a montré aux deux auteurs sans en informer sa collègue ! Voici la photo en question

image

Rosalyn Franklin apparait uniquement dans les remerciements de l’article, une bien piètre reconnaissance de sa contribution par ailleurs involontaire !

How Spotify Builds Products

J’avais posté il y a quelques temps un lien vers l’article d’Henrik Kniberg à propos du scaling chez Spotify. Cet article expose la manière “lean startup” dont les produits sont pensés et évoluent :

  • Think it : on a une idée !
  • Build it : on construit un MVP.
  • Ship it : On le met en production.
  • Tweak it : Puis on l’améliore continuellement.

C’est même un Kanban au niveau de la société qui permet de visualiser la totalité des projets et leur état d’avancement.

Think it

Lorsque quelqu’un arrive avec une nouvelle idée, il peut former une petite “squad” (typiquement 3 personnes) s’il a le feu vert de la direction afin de développer celle-ci, typiquement sous forme de prototype. Il s’agit de répondre aux questions : pourquoi devons-nous construire ce produit et pour qui ? Quel va être la mesure du succès ? Bref, une vraie démarche Lean Startup dans l’esprit !

La partie la plus importante est un narratif qui est développé avant que le produit soit développé. De nombreuses maquettes (papier ou non) sont souvent élaborés en parallèle.

Le “done” est accompli lorsque le management décide que le produit vaut le coup. Cela est fait de manière subjective, sans épauler cela de chiffres ou d’études de marché. Cela viendra plus tard, dans le “ship it” !

Build it !

C’est la construction du produit, conduit en agile (Scrum, XP, Kanban) avec un squad plus étoffé. Parfois même plusieurs squad. L’objectif est la création du MVP.

Le MVP est un équilibre délicat entre un proto qualifié d’embarrassant, en tout cas pas assez abouti pour être mis dans les mains des utilisateurs et un produit standard, bien trop coûteux pour un premier jet. Pour Spotify, MVP signifie Minimum Loveable Product, qui soit “narrative complete”, plutôt que “feature complete”.

Le “done” est atteint quand le squad et le management pensent que le produit est assez bon pour passer en production.

Ship it

Il s’agit de déployer progressivement le produit vers 100% des utilisateurs. On commence par le déployer vers un petit échantillon d’utilisateurs, et c’est là que l’on commence à vérifier nos hypothèses initiales. Le processus standard est d’effectuer des itérations pour opérer des ajustements.

Le “done” est atteint lorsque le produit est déployé vers 100% des utilisateurs.

Tweak it

C’est la phase la plus importante. Le produit peut être amélioré de nombreuses façon. Le squad opère des évolutions via de l’A/B testing et le suivi des métriques d’utilisation. A un certain point le produit atteint un optimum local et les nouvelles fonctionnalités n’ajoutent guère de valeur au produit. Soit le squad passe progressivement vers un nouveau projet, soit l’on rentre dans une phase de “re-think” pour changer dramatiquement le produit.