Étiquette : publication

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

Le par addinquydans ArticlesLaisser un commentaire

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 !

The New New Product Development game, par takeuchi et Nonaka

Le par addinquydans publicationLaisser un commentaire

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

Le par addinquydans publicationLaisser un commentaire

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

Le par addinquydans PresentationLaisser un commentaire

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.

Lire la suite →

Scrum Shu Ha Ri : l’article

Le par addinquydans Articles1 commentaire

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 !

 
scrum-shuhari-article-1Download

La facilitation en kit

Le par addinquydans PresentationLaisser un commentaire

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

Le par addinquydans PresentationLaisser un commentaire

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

Le par addinquydans PresentationLaisser un commentaire

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.