Dans cette série en trois parties sur le Kanban pour DevOps, Dominica DeGrandis, directrice de la formation et du coaching chez Planview AgilePlace, explique trois raisons essentielles pour lesquelles les équipes d'exploitation informatique et celles qui mettent en œuvre une chaîne de valeur DevOps utilisent une approche en flux tendu pour le développement de produits. Voici la première partie.
Raison #1 : Le travail n'est pas terminé tant qu'il ne fonctionne pas correctement en production.
Il y a une blague dans le développement de logiciels sur le fait d'être "fait" et d'être "fait-fait". Le simple fait est la platitude ; le double fait est la réplique. Les bouchons sautent, les bannières volent, la nouvelle fonctionnalité est "faite" - mais il reste encore du travail réel. Travail nécessitant que quelqu'un des opérations reste derrière pour le faire "faire".
Double-done signifie la véritable ligne d'arrivée, lorsque tout le monde peut se détendre et se réjouir - souvent bien longtemps après que le code soit expédiable ou même livré à la production. Lorsque toutes les tâches opérationnelles sont vraiment terminées, la fête est généralement terminée et il n'y a nulle part où aller si ce n'est à la maison, pour prendre quelques heures de sommeil avant de se lever pour aller travailler à nouveau.
Le flux allégé - également connu sous le nom de Kanban pour le travail de connaissance - sort les opérations de l'embrouillamini du "double-done". En tant qu'approche systémique, elle encourage le développement et les opérations à cartographier l'ensemble du flux de travail et à prendre en compte toutes les tâches pertinentes, y compris celles qui sont habituellement reléguées à la post-production. Ce flux de travail unifié augmente les chances que tout le monde puisse célébrer le franchissement de la ligne d'arrivée ensemble.
Pourquoi les pratiques d'achèvement "doublement" existent-elles ?
Avant d'explorer les raisons pour lesquelles les équipes d'exploitation utilisent une approche en flux tendu, examinons de plus près les raisons commerciales des pratiques courantes d'achèvement "à double" : marketing, maintenance et risque.
Marketing
En général, les clients ne tiennent pas compte de la fanfare de l'unique fait. Ils ne se soucient pas de savoir si le code est dans un état expédiable. Pour les clients, la nouvelle fonctionnalité n'est pas vraiment terminée tant que le code n'est pas livré en production, stabilisé et fonctionne correctement. Dans le contexte du feature marketing, cependant, le single-done donne un signal juste pour obtenir un feedback, pour amplifier le buzz du marché, et pour anticiper le double-done.
Maintenance
Pour rester compétitives, les entreprises ont besoin d'un certain niveau de confiance pour s'assurer que la nouvelle fonctionnalité est résiliente - qu'elle est surveillée et entretenue. Le modèle à double action donne aux entreprises une fenêtre (généralement trop courte) pour acquérir les éléments nécessaires à la résilience, tels qu'une capacité matérielle, un stockage et une sécurité suffisants, à mesure que le volume d'utilisateurs augmente.
Risque
Pour éviter le risque de mises à jour bâclées, plusieurs membres de l'équipe doivent apprendre à dépanner et à résoudre les problèmes liés à la nouvelle fonctionnalité. Pour faciliter la capacité de soutien future, une certaine forme de documentation est nécessaire. Les pratiques de double emploi permettent de vérifier que les systèmes de soutien sont adéquats pour anticiper et réduire les risques.
Si les pratiques d'achèvement à double tour répondent à certains besoins commerciaux, une approche en flux tendu répond à tous les éléments ci-dessus et plus encore, dans le cadre d'un flux de travail totalement transparent.
Kanban pour DevOps : franchir ensemble la ligne d'arrivée
Kanban offre une visibilité de bout en bout de tous les états par lesquels le travail doit passer pour que la fonction soit fiable pour les clients et sûre pour les entreprises.
Les méthodes de flux allégé utilisent des tableaux Kanban pour établir un lien visible entre tous les états de travail du système. Le travail bloqué qui empêche l'achèvement d'autres travaux devient une évidence. Les dépendances entre équipes ou avec des fournisseurs tiers apparaissent comme indiscutables. De plus, comme tous les ensembles de compétences nécessaires à la réalisation d'une fonction ont voix au chapitre, le processus devient une expérience agréable pour les employés.
En résumé
Grâce à l'approche de flux tendu de bout en bout de Kanban, le "fait-fait" peut devenir véritablement fait. Lorsque nous sommes en mesure de visualiser et d'envisager l'ensemble du flux de travail, des goulots d'étranglement auparavant invisibles peuvent être traités, les tâches requises après le déploiement du code en production peuvent devenir courantes, et tout le monde peut se joindre à la fête à la ligne d'arrivée.
Découvrez la deuxième raison pour laquelle IT Ops utilise le lean flow - lisez la deuxième partie de la série Kanban for DevOps.
![Un plan de gestion du travail collaboratif mondial [Vidéo] (en anglais)](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
