Catégorie : publication

What is Scrum ? Par Henrik Kniberg

Le par addinquydans publicationLaisser un commentaire

Une façon classique de présenter le sujet est de commencer par le manifeste, puis d’évoquer le « parapluie agile » et les différentes approches qu’elle abrite : Scrum, XP, Kanban, etc.

Mais c’est surtout : délivrer tôt de la valeur métier et « moins de bureaucratie ». Pour illustrer cela, Kniberg nous trace le Value Stream Map d’une entreprise développant des jeux : un temps de cycle de 25 mois pour 3 mois de travail utile seulement ! La logique de telles entreprises est de minimiser les coûts en maximisant l’utilisation des ressources.

Optimiser l’utilisation des ressources

Il s’agit d’une illusion à plusieur titres. Tout d’abord occuper au mieux l’équipe ne garanti pas une meilleure productivité, au contraire. Preuve nous en est donnée lors des week-end de départ en vacances…

Par ailleurs, notre travail n’est pas de produire du logiciel … mais de résoudre des problèmes. Et si possible en produisant le moins de logiciel possible pour ce faire !

Lire la suite →

Publicité

How do you know that your product works ?

Le par addinquydans publicationLaisser un commentaire

Ai-je vraiment « terminé » ?

C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?

  • Quand le code est commité ?
  • Quand le produit est testé ?
  • Quand il est déployé en production ?

Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.

Où l’on reparle de valeur

La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.

Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.

Lire la suite →

Water – Scrum – Fall … la réalité d’aujourd’hui ?

Le par addinquydans publicationLaisser un commentaire

Le constat

Oui, l’agilité gagne en popularité dans les organisations ! Du moins, apparemment. Les idées qui en sont à la base comme le « people centric » génèrent un réel intérêt. Aujourd’hui plus encore qu’hier, « agile » rime avec « Scrum ». Cet article met en exergue ce qui était déjà un soupçon fort, ce que j’appelle le Scrum « Canada Dry » dans mon article Scrum Shu Ha Ri :

  • La MOA rebaptisée « Product Owner ».
  • L’organisation matricielle, avec les développeurs devant partager leur temps sur plusieurs projets (je l’avait raté celle-ci)
  • Des itérations qui ne couvrent que partiellement le cycle logiciel
  • La « culture projet » où les équipes se font et se défont régulièrement au grée des projets.

Les organisations elle-même créent un carcan dans lequel inscrire un projet agile devient compliqué, à moins d’en pervertir la logique : logique budgétaire, silotage des activités, prédominance de la « logique document » et des releases parcimonieuses pour d’apparentes raisons économiques et culturelles.

Pourquoi ?

Ce constat met en relief un aspect quasi schizophrénique de l’adoption de l’agilité (d’où le titre de l’article). Celui-ci s’explique du fait de l’adoption des processus agiles par les praticiens qui tend à cloisonner l’agilité dans les équipes de développement, les équipes connexes restant attachées à leurs anciens processus. La réalité du « water-scrum-fall » se traduit par :

Lire la suite →

What is an agile tester ?

Le par addinquydans publicationLaisser un commentaire

Rôle, quel rôle ?

Oui, le tester agile n’a plus la même place qu’avant. Tout d’abord, il n’y a plus d’équipe de test, mais un testeur intégré dans une équipe pluridisciplinaire ! Ce qui signifie aussi par voie de conséquence qu’il n’y a plus de phase de test. En fait, pour aller plus loin, il n’y a plus non plus de rôle de testeur !

La qualité est désormais l’affaire de tous, on passe de la notion d’assurance qualité à celle d’assistance qualité. C’est pourquoi ce n’est plus le rôle de testeur qui primer mais la compétence qu’il véhicule et injecte dans l’équipe. Kniberg nous débarque le concept de « T shape compétences », que personnellement je n’aime pas trop.

S’assurer que le produit marche

L’assistance qualité, dans une équipe agile recouvre un certain nombre d’activité que l’auteur nous énumère. Mais surtout, le testeur agile doit travailler en interaction avec les développeurs et les utilisateurs afin de toujours raccourcir la boucle de feedback, une idée qui s’inscrit bien dans la philosophie du « continuous delivery ».

Lire la suite →

Focus

Le par addinquydans publicationLaisser un commentaire

Chap 1 : Où l’on parle de flux

Le focus, au niveau de l’entreprise, qu’est-ce que cela signifie ? En premier lieu, de se concentrer sur la chaine de valeur. Et sur le flux, plutôt que l’utilisation des ressources. Le Value Stream Mapping est un des outils permettant de mettre en évidence les possibilités d’amélioration de ce flux.

Le corollaire est de se concentrer sur un petit nombre de features plutôt que sur des gros batches qui mettent du temps à passer dans le rétroviseur. Donc du Focus !

Chap 2 : Se faciliter la vie

Nous avons vu le problème du « trop de choses à faire ». Et le temps pour le faire est limité. Bien entendu, nous avons moins de temps disponible que de choses à faire. Mais en réalité celles qui sont indispensables n’en sont qu’une fraction. On pourrait appeler le reste des « options » ! Nous sommes maitres de nos choix, n’en devenons pas les esclaves.

Chap 3 : Tel un hamster dans sa roue

Les sollicitations nous viennent de toute part ! Elles créent un bruit qui nous empêche de faire ce qui est important. S’isoler de ces perturbations et se concentrer sur une seule chose jusqu’à ce qu’elle soit terminée, il n’y a rien de nouveau là. Quelques techniques peuvent nous aider comme le « zéro inbox » ou le Pomodoro.

Lire la suite →

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 →

Spotify Engineering Culture

Le par addinquydans publicationLaisser un commentaire

Henrik Kniberg communique beaucoup autour de Spotify qui constitue aujourd’hui le gros de son activité !

Première partie

J’avais partagé précédemment les papiers de Kniberg sur l’agilité à grande échelle et la manière dont Spotify construit ses produits.

Cette vidéo, ou plutôt cette animation nous explique à la fois le cheminement, l’organisation et la dynamique de cette “culture agile”.

Pour résumer plus brièvement cette vidéo, peut-être préfèrerez-vous la fresque ?

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 →

C++ en 1983…

Le par addinquydans publicationLaisser un commentaire

J’ai posté il y a peu une note de lecture sur l’Annotated Reference Manual (l’ARM pour les intimes). Cela m’a incité à aller chercher plus loin. C’est ainsi que j’ai mis la main sur un document dont on devine à sa seule apparence qu’il est plutôt ancien. Je ne peux résister au plaisir, en passant, de vous livrer la photo de famille du premier meeting du groupe de travail sur C++.

Initial meeting Group C++

Bjarne Stroustrup n’a pas tellement changé, vous allez le reconnaitre facilement !

Voici le document en question.

On ne peut pas vraiment parler de norme, ce document décrit le langage C++ d’une manière que l’on dirait aujourd’hui sommaire. Certains éléments du langage sont absent de cette version préhistorique. Les plus remarquables sont l’absence des mots-clé pour les visibilités private et protected !