KANBAN ET LE DÉVELOPPEMENT LOGICIEL AGILE

Le magazine consacrée aux thèmes informatiques
KANBAN ET LE DÉVELOPPEMENT
LOGICIEL AGILE
KANBAN et / ou SCRUM ?
Kanban et le développement logiciel agile
04/2011
Depuis un certain temps, on entend dans le contexte de développement logiciel agile et de
processus agile de plus en plus souvent la notion de « Kanban » ou de « Kanban logiciel ».
Mais que recouvre au juste cette notion? Est-ce un phénomène nouveau ou veut-on nous faire
prendre du vieux pour du neuf? Le présent document se propose de répondre à cette question.
L
a notion de « Kanban » vient du
japonais et signifie carte de
signal ( « kan » = signal, « ban » =
carte ).
À l’origine, Kanban est un élément de
la lean production [flux tendu], qui
trouve ses racines dans le système de
production de Toyota. La lean production ou le système des « flux tendus » a
pour objectif d’optimiser la productivité, la qualité et la flexibilité des outils
de production.
Un des moyens pour y parvenir
consiste à éviter le gaspillage et les
erreurs. Par gaspillage, on entend:
• un travail qui n’ajoute aucune valeur
au produit (muda)
• une surcharge des salariés et des
machines (muri)
• une irrégularité des processus
(mura)
La surproduction est également
con­
sidérée comme du gaspillage, et
doit à ce titre également être évitée
afin de réduire les stocks qui nécessitent de la place, drainent des capitaux, et qui par conséquent coûtent
chers. On entend obtenir ce résultat,
entre autres, en mettant en place un
flux de processus tant que possible
continu. C’est ici qu’intervient le principe de Kanban.
Une étape de la production se
procure les matériels requis dans la
zone de stockage tampon des étapes
de production précédentes respectives (principe de pull). Pour cette
raison, Kanban s’appuie sur le plan de
production de la dernière étape de
fabrication.
Si l’on passe en dessous d’un stock
minimal défini de matériels, on
transmet une information indiquant
qu’il faut produire le ravitaillement
requis. Dans le cadre du système de
Kanban classique, cette information
est transmise par les cartes de signal
(cartes Kanban). Dès l’obtention de la
carte Kanban, l’entité productrice
lance la production du type et de la
quantité de matériels définis sur la
carte.
Dès que la quantité exigée est
produite, le matériel est transporté
conjointement avec la carte Kanban
dans la zone de stockage tampon à
partir de laquelle l’étape de production
suivante se ravitaille elle-même.
Kanban en informatique
(Kanban logiciel)
C’est David Anderson qui en 2007 a
développé le principe de Kanban dans
le secteur de l’informatique. Dans le
cadre de cette démarche, il n’a pas
emprunté directement les techniques
émanant de la production mais il a
conjugué des principes fondamentaux
provenant de la lean production et du
lean development avec la théorie des
contraintes – i. e. des goulets d’étranglement) – (cf « the theory of
constraints »).
Contrairement à d’autres méthodologies agiles, le Kanban ne connaît pas
d’itérations. Ainsi obtient-on un « flux »
continu dans le cadre du traitement.
Kanban s’articule autour des deux
principes fondamentaux suivants:
• la visualisation de la chaîne de
création de valeur et
• la limitation du « work in progress »
(WiP).
© 2012 PENTASYS AG
1
Le magazine consacrée aux thèmes informatiques
Visualisation de la chaîne de création de valeur
Pour toutes les personnes concernées, la chaîne de création de valeur du développement est rendue visible par un tableau, celui-ci étant dans la plupart des
cas un grand tableau blanc. Sur ce tableau figurent les différentes étapes du
processus, par exemple, la définition des besoins, la conception, la mise en
œuvre, les tests, la représentation prenant la forme de colonnes. Les différentes
demandes sont notées sur des fiches ou des post-its, ceux-ci étant collés sur le
tableau. Les demandes peuvent être formulées sous forme d’histoires utilisateur
(user stories), de fonctionnalités (features), cas d’usage (use case), etc. Au cours
du traitement, les demandes se déplacent ensuite de la gauche vers la droite.
L’opérateur se procure pour chaque étape de traitement relative qui suit les
tâches finalisées de l’étape précédente. Cela correspond au principe de pull
appliqué dans le cadre de la lean production.
La visualisation montre quelles activités se trouvent dans quel stade de réalisation. Il n’existe pas de contraintes pour l’aménagement du tableau, celui-ci
pouvant donc être conçu selon ses besoins propres.
Fig. 1:
La visualisation sur un tableau
démarrage
Définition du besoin
En cours
Lore ipsum
Lore ipsum
Fini
Lore
ipsum
Conception
Mise en œvre
En cours
Fini
En cours
Fini
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Test
Realisé
Lore
ipsum
Lore
ipsum
Lore
ipsum
Lore
ipsum
Comme le montre la représentation ci-contre, la transparence obtenue l’affichage au tableau permet d’identifier très rapidement des goulets d’étranglement
survenant au cours du traitement.
Cet exemple contient de nombreuses tâches se trouvant au stade de la
conception et un très petit nombre au stade de la réalisation. C’est là qu’apparaît
un goulet d’étranglement, puisqu’un grand nombre de tâches sont finalisées au
niveau de la conception mais qu’elles ne peuvent pas être mises en œuvre à la
même vitesse. Cela empêche d’obtenir un flux régulier.
Le principe de la limitation du work in progress (WiP) permet de remédier à
cette situation. On limite le nombre de tâches ayant simultanément le même
statut; ainsi on garantit que le nombre de résultats obtenus dans le cadre d’une
étape de traitement ne dépasse pas le nombre de résultats pouvant être traités
lors de l’étape de traitement suivante. Ceci génère un flux constant, tout en
garantissant une utilisation régulière. On peut par exemple limiter l’étape
« conception » à 2, c’est-à-dire que l’on a uniquement le droit d’accrocher deux
post-it au niveau de cette étape.
2
© 2012 PENTASYS AG
Dans ce qui suite, on fait une comparaison entre Kaban et scrum. Pour cette
comparaison, on a choisi scrum car cette méthode connaît un très haut niveau
de notoriété.
Points communs entre Kanban et scrum
• Processus agile
• Basé sur des équipes auto-organisées
• Livraison fréquente d’incréments logiciels commercialisables
• Contrainte de décomposition des besoins en en petites unités
• Utilisation d’un système de pull
• Limitation du traitement simultané maximal de tâches (WiP: work in progress)
Différences entre Kanban et de scrum
• Chez Kanban, les itérations sont en option
• Chez Kanban, les engagements de l’équipe sont en option
• Chez Kanban, les équipes interdisciplinaires sont en option
mais les équipes d’experts sont autorisées
• Chez Kanban, de nouvelles demandes peuvent à tout moment
être communiquées à l’équipe tant qu’il existe des capacités disponibles
• Kanban ne définit pas de rôles
• Le tableau Kanban fait l’objet d’un suivi permanent
• Chez Kanban la priorisation des demandes est en option
Lore
ipsum
Lore
ipsum
Limitation du « work in progress » (WiP)
COMPARAISON DE KANBAN ET DE SCRUM
EXPÉRIENCES FAITES AVEC KANBAN DANS LA PRATIQUE
Jusqu’en 2009, le département BI d’une entreprise très connue développait ses
systèmes selon le modèle classique de la cascade. Au début de l’année 2010, on
a mis en place la méthode agile scrum. Les avantages de l’agile ont pu être rapidement concrétisés. Ainsi a-t-il par exemple été possible d’améliorer considérablement la productivité, les points bloquants (« impediments ») étant identifiés et
éliminés plus rapidement.
On a cependant également été amené à constater qu’il existait encore d’autres
gisements d’amélioration. Ainsi existait-il pour chaque sprint de nombreux
« sprinters ». C’est ainsi que l’on appelle des demandes auxquelles on peut
répondre rapidement, en général des adaptations à des tableaux de bord existants ou de nouvelles mais petites évaluations. Pourquoi faire attendre le demandeur de ces sujets de faible envergure la durée intégrale d’un sprint? D’un autre
côté, il existait des demandes dont la complexité et par conséquent l’effort de
réalisation associé ne pouvaient tenir dans le cadre du planning du sprint.
À cette fin, il a d’abord fallu procéder à une analyse au sein d’un sprint afin de
pouvoir évaluer le travail requis. Cela a eu pour conséquence que certaines fonctions ont pu être mises en place plus tard que prévu. On était dans une situation
de maintenance et on a en permanence amélioré et élargi un système existant.
Pour ces raisons, on a commencé à mettre en place cette approche, avec l’utilisation de tableaux, assortis des différentes étapes de traitement. On a fait l’économie de sprints ou d’itérations ainsi que de meetings de planification. Après
environ quatre mois d’utilisation de Kanban, on a pu tirer le bilan intermédiaire
suivant:
• La transparence du tableau a permis de rapidement identifier les goulets
d’étranglement dans le processus, leur élimination par la limitation du WIP
exigeant cependant des opérations de réglage fin. À cet égard, les goulets
d’étranglement survenant au niveau de dépendances externes, par exemple la
révision des résultats par le client, posaient cependant problème. On a entretemps mis en place un flux continu et on est en mesure de fournir en permanence de nouvelles fonctionnalités
• Le client apprécie beaucoup la transparence au niveau du développement. Il
peut en un seul clin d’œil voir le statut respectivement actuel des demandes
© 2012 PENTASYS AG
3
Kanban et le développement logiciel agile
04/2011
blickpunkte – Le magazine consacrée aux
thèmes informatiques est une newsletter gratuite de la PENTASYS AG
Le magazine consacrée aux thèmes informatiques
• Mais en raison de l’absence de sprints et de meetings de
planification, on peut cependant difficilement prévoir quand
une exigence sera effectivement mise en œuvre.
Pour y parvenir, et afin de développer un « modèle prévisionnel », on analyse actuellement la durée d’exécution des
tâches déjà réalisées.
BILAN
Kanban représente un cadre de gestion agile très allégé, imposant moins de contraintes à la mise en œuvre que scrum par
exemple.
Ne prévoyant aucune itération, il se prête à une utilisation dans
des situations dans lesquelles un traitement fluide d’une certaine
ampleur est difficile à réaliser. Ceci est par exemple le cas pour
des applications en cours de maintenance et /ou de service,
puisque le travail est souvent perturbé par des situations d’urgence et des interruptions.
Kanban se prête également à des situations caractérisées par
une forte spécialisation et une forte division du travail. Contrairement à d’autres méthodologies agiles, qui elles prévoient une
« équipe de généralistes », des équipes d’experts sont admises
ici. D’un autre côté, Kanban constitue un moyen souple pour
mettre en place des processus agiles dans des entreprises organisées de manière « classique ». Lors de la mise en place de ce
système, on peut procéder à un grand nombre de petites modifications, par exemple, créer de la transparence grâce au tableau
Kanban, sans devoir déclencher pour autant une « révolution
agile ».
SUR L’ AUTEUR
PENTASYS AG fait partie des intégrateurs de
systèmes informatiques qui connaissent la
croissance la plus rapide. Fondée en 1995
avec uniquement trois employés, l’entreprise
a depuis créé plus de 200 nouveaux emplois
qualifiés en Allemagne. La stratégie de l’entreprise se concentre sur une qualité sans
compromis et s’oriente strictement selon la
valeur ajoutée générée pour les clients. Des
collaborateurs hautement qualifiés et très
motivés ainsi qu’un modèle de processus projet, certifié selon la norme ISO-9001/2008 en
créent les conditions.
La palette des prestations englobe le conseil,
la gestion de projet, l’analyse de la faisabilité,
la conception d’architecture, la réalisation
et le test de systèmes IT, le tout proposé par
un interlocuteur unique. Parmi les clients
de référence, on peut citer ADAC e.V., Arval
(une BNP Paribas Company), CACEIS Bank,
Deutsche Bahn AG, DekaBank Deutsche
Girozentrale, Deutsche Post AG, Deutsche
Telekom, BMW AG, Direkt Anlage Bank,
Bristol-Myers Squibb, MAN Truck & Bus AG,
Telefónica o2 Germany, RTL II, TÜV süd AG,
Yves Rocher, Volvo Financial Services, l’institut ifo pour la recherche économique et l’Office européen des brevets.
COPYRIGHT:
Tous les contenus, ainsi que les concepts et
la conception de la newsletter sont protégés
par les droits d’auteur. Le copyright/le droit
de la propriété intellectuelle sont détenus par
PENTASYS AG.
En appliquant les règles et les remarques habituelles, il est possible de faire des citations.
La copie ou la reproduction, même par extraits ainsi que la restitution photomécanique
ou la saisie sur des supports de données sont
uniquement autorisés avec le consentement
écrit de PENTASYS AG.
Manfred Schlaucher travaille comme chef
de projet chez PENTASYS.
Ses activités portent principalement sur
l’architecture, les processus et méthodologies projet et la gestion de projets.
En tant que scrum master certifié et Project
Management Professional (PMP), il maîtrise
aussi bien les méthodologies projet classiques que les projets en mode agile.
Si dans les contenus présents on utilise des
marques et des relations commerciales, et
même si celles-ci ne sont pas marquées comme telles, il convient d’appliquer les dispositions de protection correspondantes.
CONTACT:
PENTASYS AG
Rüdesheimer Straße 9
D-80686 Munich
Tél. : +49 (0) 89 5 79 52-0
PENTASYS AG
Bureau de Paris
1, passage du Génie
F-75012 Paris
Tél. : +33 (0)1 76 36 02 90
Internet: www.pentasys.de
www.pentasys-consulting.de
4
© 2012 PENTASYS AG