Kanban et Scrum : Tirer le meilleur des deux – la traduction
Scrum et Kanban, Pourquoi ?
Avant toute chose, pourquoi Kanban et Scrum, puisque Scrum tout seul, ca marche ? Quoi, des fois ça marche pas? On m’aurait menti ?
Avant de dire que Scrum ne marche pas, il faut bien entendu se poser quelques questions :
- Est-ce qu’on fait vraiment du Scrum ?
Vous savez, le fameux ScrumBut : “Oui oui, on fait du Scrum, maiiiiis…. Bon, les estimations par l’équipe, on a arrêté parce qu’ils se plantaient tout le temps” Gasp ! La solution : prenez-vous le chou : SHU-HA-RI
- Est-ce qu’on fait du Scrum Agile ?
Vous allez me dire que Scrum est une méthode agile (je préfère le terme framework) donc si on respecte les cérémonies de Scrum, on est forcément agile. Et bien, je ne suis pas complètement d’accord. Scrum étant justement un framework assez peu contraignant, on peut facilement mettre en place les cérémonies sans vraiment en comprendre le sens. J’ai vu des équipes faire des rétrospectives et en sortir sans aucun axe d’amélioration identifié. La solution : s’imprégner du manifeste agile, ses piliers, ses principes. Toujours s’y référer quand on utilise une pratique Scrum. Et vous verrez, ces pratiques Scrum prennent vraiment tout leur sens quand elles sont replacées dans le contexte du manifeste agile.
- Est-ce que la qualité logicielle est au coeur de nos développements ?
Scrum n’impose aucune recommandation en terme de pratiques d’ingénierie logicielle. Le principe est de les faire émerger. Heureusement, nos chers extrêmes et néanmoins amis d’XP se sont penché sur le sujet et ont regroupé un ensemble de pratiques d’ingénierie logicielle : Pair Programming, Conventions de codage, Intégration continue, l’irremplaçable TDD, etc. J’entends déjà les “mais pourquoi faire Scrum+XP alors que XP fait tout ?” Parce que ! Lire la suite…
