Article basé sur le chapitre "contrats" du livre de Craig Larman et Bas Vodde:
Traduction de Nicolas Mereaux, Pierre Fauvel et moi même.
La version française est disponible ici, l'original étant là.
Affichage des articles dont le libellé est Lean. Afficher tous les articles
Affichage des articles dont le libellé est Lean. Afficher tous les articles
Primer Agile Contracts en Français
Agile Contracts Primer de Tom Arbogast, Craig Larman et Bas Vodde.
Traduction de Nicolas Mereaux, Pierre Fauvel et moi même.
La version française est disponible ici, l'original étant là.
Traduction de Nicolas Mereaux, Pierre Fauvel et moi même.
La version française est disponible ici, l'original étant là.
Agile Toulouse - Atelier Lean Startup
A ne surtout pas manquer pour bien démarrer l'année.
Message d'Agile Toulouse:
"Bonjour à tous,
Je vous annonce l'atelier Lean Startup animé par Oana Juncu le mardi 22 janvier 2013 de 14 heures à 18 heures à la maison des associations.
Inscription sur http://atelier1301-agiletoulouse.eventbrite.fr
Bonnes fêtes à tous"
Lean Primer
Lean Primer de Craig Larman et Bas Vodde.
Traduction de Fabrice Aimetti et moi même.
Disponible ici ou sur le wiki de Fabrice.
Traduction de Fabrice Aimetti et moi même.
Disponible ici ou sur le wiki de Fabrice.
Are you ready-ready to be done-done
Jeff-Sutherland, continuant l’agilisation de Systematic, présente une évolution du concept de done/done : le ready/ready
Ou plus exactement la Feature ready/ready checklist.
A partir de la notion de done/done, normalement, une équipe construit une liste de typologie de tâche ayant pour objectif l’atteinte du done. Cette checklist se place au niveau Scrum Team, côté développement donc.
La checklist ready/ready reprend ce concept et le remonte d’un cran, côté demandeur (Product Owner, Architecte, et lead developper).
En clair, quelles sont les tâches de préparation nécessaires au passage d'une feature dans l'état "Not Started" de ces user stories dans le task board (repris du Kanban Lean) :
• Preparation de la feature pour l’engagement : préparation à l’acceptation
• Clarification de la feature pour l’équipe : prise en compte des contraintes de l’équipe de développement en amont
• Préparation de la feature pour implémentation : passage de la feature aux stories pour préparation aux sprints.
Tous ces points sont fortement conditionnés par la mise en place du pilotage par les tests d’acceptance (ATDD)
Deux métriques sont utilisées :
• Le Process Efficiency
S’il faut une journée idéale pour produire une user story mais qu’en fait elle est produite en 5 jours, alors l’efficacité est de 20%. Le but étant d’augmenter cette efficacité en préparant au mieux l’implémentation, la checklist ready/ready est construite en ce sens.
• Fix time after failed builds
De la même manière, quelle est l’efficacité du processus concernant la correction d’une erreur de build. Ici, les pratiques ATDD permettent la réduction de temps.
Plus que le nombre de bugs, c’est bien le temps de correction qui importe.
Ou plus exactement la Feature ready/ready checklist.
A partir de la notion de done/done, normalement, une équipe construit une liste de typologie de tâche ayant pour objectif l’atteinte du done. Cette checklist se place au niveau Scrum Team, côté développement donc.
La checklist ready/ready reprend ce concept et le remonte d’un cran, côté demandeur (Product Owner, Architecte, et lead developper).
En clair, quelles sont les tâches de préparation nécessaires au passage d'une feature dans l'état "Not Started" de ces user stories dans le task board (repris du Kanban Lean) :
• Preparation de la feature pour l’engagement : préparation à l’acceptation
• Clarification de la feature pour l’équipe : prise en compte des contraintes de l’équipe de développement en amont
• Préparation de la feature pour implémentation : passage de la feature aux stories pour préparation aux sprints.
Tous ces points sont fortement conditionnés par la mise en place du pilotage par les tests d’acceptance (ATDD)
Deux métriques sont utilisées :
• Le Process Efficiency
S’il faut une journée idéale pour produire une user story mais qu’en fait elle est produite en 5 jours, alors l’efficacité est de 20%. Le but étant d’augmenter cette efficacité en préparant au mieux l’implémentation, la checklist ready/ready est construite en ce sens.
• Fix time after failed builds
De la même manière, quelle est l’efficacité du processus concernant la correction d’une erreur de build. Ici, les pratiques ATDD permettent la réduction de temps.
Plus que le nombre de bugs, c’est bien le temps de correction qui importe.
Scrum et CMMI Niveau 5 : Potion magique pour les guerriers du code
Je viens de lire le papier de Jeff Sutherland, Carsten Ruseng Jakobsen et Kent Johnson sur Scrum and CMMI Level 5 : The Magic Potion for Code Warriors
Bon, ça date un peu (Mai 2007), mais que voulez-vous, je ne suis pas à jour, c'est tout.
Ce que j'en retire, il faut y voir :
- Agile comme une boite à outil répondant aux besoins d'institutionnalisation (différent d'industrialisation)
- Lean comme une étude d'opportunités
- CMMI comme support à la conduite de changement et la propagation des bonnes pratiques au reste de l'entreprise.
Et tout ça pour avec chiffres à la clé démontrant le bien fondé de la démarche.
Côté productivité, mais éminents collègues du SigmaT me font remarquer qu'il serait plus judicieux de parler d'efficacité. Effectivement si l'on regarde le mode de calcul de la productivité utilisé, c'est le rapport du nombre total de lignes de code produites pour la totalité des heures comptées sur un projet. Donc toutes activités confondues. Hors l'amélioration par l'élimination du gaspillage fait que mathématiquement le nombre d'heure total diminue. Le ratio de LOC/h diminue donc mécaniquement. On peut effectivement plutôt parler d'efficacité. Le résultat est là : réduction des coûts.
En tout cas, bonne expérience montrant que la combinaison du mieux de chaque améliore le tout.
Pour ceux comme moi qui ne sont pas à jour, je vous engage à lire ce papier et vous en faire votre propre opinion!
Diagramme de flux cumulé
Suite à la lecture de Kaban & Scrum- making the most of both (version française),
j'aime bien le principe du diagramme de flux cumulé.
Cela ressemble au burn-up de produit. Appliqué au sprint, ça permet de faire la corrélation entre la vélocité et le temps de cycle.
Il devient très utile d'avoir cette information au niveau des sprints pour évaluer si la durée des sprints est efficace.
La plupart du temps, on définit la durée des sprints de manière très arbitraire en début de projet.
L'information de temps de cycle permettra d'ajuster au mieux cette durée au fil du temps.
A expérimenter !
j'aime bien le principe du diagramme de flux cumulé.
Cela ressemble au burn-up de produit. Appliqué au sprint, ça permet de faire la corrélation entre la vélocité et le temps de cycle.
Il devient très utile d'avoir cette information au niveau des sprints pour évaluer si la durée des sprints est efficace.
La plupart du temps, on définit la durée des sprints de manière très arbitraire en début de projet.
L'information de temps de cycle permettra d'ajuster au mieux cette durée au fil du temps.
A expérimenter !
Kanban and Scrum - making the most of both
Dans la suite de "Scrum and XP from the Trenches", aujourd'hui, InfoQ met à la disposition "gratuite" le guide écrit par Henrik Kniberg et Mattias Skarin : Kanban and Scrum - making the most of both
Version originale (.pdf)
Et préfacé par Mary Poppendieck & David Anderson.
Et pour nos amis Francophones, la version traduite par Claude Aubry, Frédéric Faure, Antoine Vernois & Fabrice Aimetti :
Version FR (.pdf)
Et au cas où vous voudriez quand même payer (pour l'imprimer):
En voici 2 extraits évocateurs:"Kanban ou Scrum n'est pas l'objectif final, c'est l'apprentissage continu
qui l'est."
"Le seul véritable échec est de ne pas réussir à apprendre de ses échecs."
J'en profite pour rappeler un excelent article sur le même théme, avec un cas pratique dans l'utilisation du développement logiciel de jeu:
Beyond Scrum: Lean and Kanban for Game Developers écrit par Clinton Keith, paru en nov 2008 et qui ne fait que 11 pages!
Retour SigmaT9
J’étais hier au dernier SigmaT9. Si vous vouliez être convaincu de l’intérêt de Lean, c’était hier.
Alexandre Boutin nous a fait un superbe show à l’américaine version grenobloise.
Que de concepts communs avec les principes Agiles, cela devrait arrêter le débat sur « Lean est il agile ou pas ? ». La question n’étant pas là.
On ne parle ici que de bon sens. J’allais dire de pragmatisme, mais étant basé sur nos références propres, encore faut-il avoir les mêmes. Et c’est ce que j’ai retrouvé dans le discours d’Alexandre.
J’ai relevé trois points :
Alexandre Boutin nous a fait un superbe show à l’américaine version grenobloise.
Que de concepts communs avec les principes Agiles, cela devrait arrêter le débat sur « Lean est il agile ou pas ? ». La question n’étant pas là.
On ne parle ici que de bon sens. J’allais dire de pragmatisme, mais étant basé sur nos références propres, encore faut-il avoir les mêmes. Et c’est ce que j’ai retrouvé dans le discours d’Alexandre.
J’ai relevé trois points :
- L’analyse systémique des problèmes est une approche plus que cohérente et efficace. Cela risque d’avoir des impacts majeurs sur la structuration et l’organisation des entreprises. Leur faculté d’adaptation au changement sera un gage de réussite. Toyota a bien réussi à le faire.
- Réduction du gaspillage. Les gaspillages coutent chers par définition, pas besoin de savoir pourquoi ou combien, passons à l’action...
- La qualité intrinsèque au process. Sans doute eXtreme Programming apporte une réponse à cela en support de Scrum.
S’en suit présentation du JUG Toulouse. Belles promesses de corrélation entre la méthode et la pratique !
Et pour conclure le standard, la marque de fabrique du SigmaT : Le retour d’expérience toujours aussi enrichissant.
PS : Merci à Alexandre pour sa courte mais efficace leçon de blogger !
Inscription à :
Articles (Atom)
