Article très intéressant de Jeff sur son blog: « The First Scrum: Was it Scrum or Lean?« , mais comme il est assez long, profitez d’un moment de calme pour le lire.
Jeff nous fait un historique de la création de Scrum afin de nous montrer que Lean et Scrum ont les mêmes origines: la théorie des systèmes adaptatifs complexes. Mais Jeff positionne clairement Lean et Scrum sur 2 plans différents. Scrum intrduit le chaos dans le processus de développement et utilise un système de contrôle empirique pour rapidement inspecter et adapter ce système qui évolue rapidement. En ce sens, Scrum est un moyen d’implémenter Lean au niveau du développement de logiciels. Lean de son coté est un bon outil de communication à destination des managers, et permet à des équipes Scrum de comprendre pourquoi elle ne réussissent pas avec Scrum, en implémentant du Kaizen et/ou des principes de’arrêt de production au moindre défaut (Stop-the-line).
Jeff rappelle également quelques principes de Scrum dont je retiendrais ceux-ci:
- Le nombre de testeurs et de documentalistes doit être supérieur au nombre de développeur afin d’éviter qu’ils produisent trop de code trop vite
- Rien n’est plus convaincant pour le management que de voir régulièrement (démo) du code qui marche
- Il est impossible pour les développeurs de développer du code de qualité sans avoir un environnement d’intégration continue en place
salut Alex
Merci pour ton blog et ses posts bien intéressants ! 🙂
Par contre, serait il possible d’avoir des éléments pour nouveaux venus aux méthodes Agile ?
J’en fait parti et je recherche un peu les « meilleurs » pointeurs pour débuter, sachant que pour l’instant j’ai surtout flashé sur Scrum and Xp from the trenches, ebook disponible sur infoq.com
merci d’avance
++
joseph
Salut Alex, et merci pour le lien et ton résumé. L’un des points qui me parle le plus dans cet article est
« 3. Lean is a good teaching tool to show Scrum teams why their implementations are broken. For example, if you do not have fully tested code and cannot create potentially shippable code in a Sprint, you have 100% work in progress going into the next Sprint. This would be viewed as a horrible and intolerable blunder in a Lean operation, yet software development teams and management seem to have difficulty understanding why this doubles your defects and cuts your velocity in half. »
A relier d’ailleurs avec un commentaire assez sévère que Sutherland fait plus haut
« However, it [Scrum] is hard to implement. Less than 10% of the Scrum teams worldwide can pass the Nokia test, primarily because they cannot deliver potentially shippable (fully tested) software at the end of a Sprint. »
Il me semble que la conclusion est qu’il absolument faut avoir du code complètement testé et potentiellement shippable à la fin de chaque sprint. Mais c’est à fois difficile d’un point de vue technique et aussi humain (il faut adopter et respecter des règles très strictes sur ce qui est démontrable).
Alors est-ce que tu as vu du nouveau sur ces questions récemment ? Que font les gens pour avoir du code « fully tested » ?
Bruno
@Bruno: Alors est-ce que tu as vu du nouveau sur ces questions récemment ? Que font les gens pour avoir du code “fully tested” ?
C’est pourquoi les approches TDD et BDD sont essentielles. De même l’utilisation des user stories fournit aussi un cadre pour écrire les tests. Par contre la ‘simple’ métrique de couverture de code ne suffit pas et la couverture fonctionnelle n’est pas toujours au rendez-vous d’où l’importance de ‘vrais’ testeurs dans l’équipe.
Pour moi la difficulté vient de la notion de ‘shippable’ dans des sprints courts à la XP (c’est peut être d’ailleurs pour ça que Scrum est sur un sprint d’environ 1 mois).
Emmanuel