Devops for Growth

Kanban Boards

Boards with workflows

• Buying a House/Moving House
• Engineering & Manufacturing at LeanKit: Boards for Aerospace Producibility, Facility and Production Issues Improvement, Automotive New Product Introduction Program
• IT Operations at LeanKit:  Boards for Platform Ops, Application Automation Operations, Database and Security Operations

Boards with static information

• Curriculum maps
• Engineering Operations Management at LeanKit: Supplier Scorecard

Please Note:  All submissions will be attributed to the submitter. Please include any restrictions on re-use so they can be publicly posted alongside your submission.

LeanKit.com board examples:

• 10 board examples for development and operations
• Engineering & Manufacturing Board Examples
• ITSM Kanban Templates
• SAFe Kanban Templates

La principale différence est que seules les US transitent du début à la fin du board, et on ne rend pas visible leurs check lists de tâches internes. L’intérêt est de ne pas ajouter des détails spécifiques à l’US qui nuiraient à la clarté nécessaire pour que l’équipe prenne des décisions efficaces au quotidien.

1. La première conséquence est de suivre un état par US. Donc au lieu de se dire “J’ai effectué 70% de l’US” ou “j’ai fait 7 taches sur 10”, on ne s’attarde que sur la colonne dans laquelle il est, ou s’il présente des points de blocage. L’équipe a ainsi une vision plus synthétique de l’évolution de la fonctionnalité.
2. La deuxième conséquence est que les estimations – en temps, en taille de t-shirt ou en point de complexité – sont définies à un niveau de granularité “US” et non pas par tâches.
3. Enfin, les développeurs sont responsabilisés sur l’ensemble du périmètre fonctionnel de l’US et pas uniquement sur l’un de ses aspects techniques. (Ex: IHM uniquement, Back uniquement …)

Dès lors, le process de l’équipe est modélisé de façon générale – et non spécifique par ticket – en définissant chaque colonne par laquelle l’US devra transiter obligatoirement.

Ajouter des colonnes dans le board visuel c’est formaliser visuellement les étapes réelles du processus par lesquelles les user stories passent.

Une colonne correspond idéalement à un type d’activité qu’un collaborateur peut effectuer seul ; le passage d’une colonne à une autre formalise le fait que l’US passe à un autre état et est prise en charge par une autre personne. Cette transition répond à une règle, un contrat formalisé et accepté par l’équipe, appelée “Definition of Done” (ou DoD).

Tous les projets sont différents, et à fortiori le process et donc les colonnes du board sont généralement spécifique à chaque équipe projet. Néanmoins, voici les colonnes qu’on a l’habitude de voir lorsque l’équipe étend le traditionnel “Todo – Doing – Done”