Raccourcir la queue de release

((/dotclear/public/photos/.jim-highsmith_t.jpg|Jim Highsmith|L|Jim Highsmith))Je rentre de la plage et je tombe sur ce billet de __Jim Highsmith__ : ++[« Shortening the Tail »|http://www.jimhighsmith.com/2011/07/14/shortening-the-tail/|en]++ que j’ai traduit dans la foulée en attendant l’apéritif dînatoire :)%%% > [((/dotclear/public/traductions/.Shortening_Tail_s.jpg|Raccourcir la queue de release|R|Raccourcir la queue de release))|/dotclear/public/traductions/Shortening_Tail.jpg]Dans mon livre ++[Agile Project Management|http://www.amazon.com/Agile-Project-Management-Creating-Innovative/dp/0321658396/ref=ed_oe_p|en]++, j’ai écrit un court chapitre sur un indicateur de performance que j’ai appelé « raccourcir la queue de release ». J’aime utiliser cet indicateur, la longueur de la queue de release, car elle est facile à calculer et en dit beaucoup sur la mise en œuvre de l’Agile dans une organisation. Ce n’est pas un joli indicateur qui ne vous donne aucun élément de décision$$Vanity metric$$, comme par exemple le nombre de développeurs qui participent à un séminaire de refactoring, mais un véritable indicateur qui vous permet d’en apprendre plus et qui se concentre sur un point clé du développement et du test logiciel en Agile. C’est aussi un indicateur qui peut aider une organisation à se rapprocher de la la notion de Livraison Continue$$Continuous Delivery$$.%%% > %%% > La queue de release est la période qui s’étend entre le « la soupe de code »$$code slush$$ (le vrai gel de code$$code freeze$$ reste rare) ou « gel des fonctionnalités »$$feature freeze$$ et le déploiement effectif des fonctionnalités. C’est la période pendant laquelle les entreprises font tout ou partie des activités suivantes : bêta-tests, tests de non régression, intégration de produits, tests d’intégration, documentation, corrections d’anomalies. La pire « queue de release » que j’ai rencontrée était de 18 mois – du gel des fonctionnalités à la livraison du produit – et la plus grande partie du temps était consacrée à la QA. Régulièrement, je rencontre des sociétés de logiciels dont la queue de release est de 4 à 6 mois pour un cycle de version de 12 mois. Après, il y a d’autres sociétés, et un nombre croissant dans le logiciel, qui ont optimisé leurs processus pour obtenir une queue de release de longueur zéro, elles réalisent vraiment une Livraison Continue et un Déploiement Continu$$Continuous Deployment$$. Utiliser l’indicateur longueur de la queue de release, en particulier pour les produits ou les applications qui disposent d’un grand patrimoine de code, peut aider les organisations à mesurer leur progrès vers un Déploiement Continu.%%% > %%% > Il y a plusieurs années, j’ai travaillé avec une organisation qui avait une queue de release de 6 mois dans un cycle de version de 12 mois et la queue devenait progressivement de plus en plus longue à chaque nouvelle version. La queue de release était passée de 4 à 6 mois au cours des 3 derniers cycles de version. La société s’était fixée l’objectif d’atteindre une queue de 1 mois et a travaillé avec assiduité pour atteindre cet objectif au fil du temps.%%% > %%% > Raccourcir la queue de release est un moyen simple, un indicateur puissant pour mesurer les progrès vers l’agilité. L’objectif des équipes agiles est de produire des logiciels déployables à chaque itération, mais la plupart sont loin de cet objectif, surtout si des équipes héritent de patrimoines de code conséquents et anciens. Pensez à tout ce qu’une entreprise peut avoir à faire pour réduire une queue de six à trois mois puis à un mois puis finalement à un jour. Elle devra apprendre à faire de l’intégration continue pour l’ensemble de ses produits. Elle devra améliorer son niveau de tests automatisés pour conduire des tests de non régression et d’intégration dans chaque itération. Elle devra améliorer le niveau de tests unitaires automatisés faits par ses développeurs pour réduire les temps de test à la fin des itérations et des versions. Elle devra impliquer ses clients beaucoup plus tôt dans le processus de développement, en n’attendant pas jusqu’au dernier moment pour les bêta-tests. Elle devra intégrer des spécialistes de la documentation dans l’équipe et produire de la documentation en continu pendant les itérations. Elle devra investir dans le refactoring systématique pour réduire la dette technique et donc réduire le temps consacré aux activités de tests et de corrections d’anomalies.%%% > %%% > Vous pouvez probablement penser à d’autres choses que l’entreprise devra faire. Chacun de ces éléments contribuera d’une certaine façon, grande ou petite, à la réduction de la longueur de la queue de release en nombre de jours ou de semaines. Pour les gros produits, la queue de release ne sera jamais nulle, mais elle pourra être de petite taille. Pensez juste au désavantage concurrentiel dont souffre une entreprise quand sa queue de release est de 18 mois, voire 6 mois. Cela signifie que pendant les 6 ou 18 mois précédant la livraison, aucun changement dans l’environnement concurrentiel ne pourra être incorporé dans ses produits. Si la Livraison Continue semble un trop grand pas en avant, commencez sur cette voie en réduisant d’abord la longueur de la queue des versions de votre produit, petit à petit la Livraison Continue ne vous semblera plus aussi inaccessible.%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Appliquer Kanban aux processus informatiques (5)

J’ai traduit ce cinquième et dernier billet de __Eli Weinstock-Herman__ : ++[Applying Kanban to IT Processes (Part 5)|http://blogs.lessthandot.com/index.php/ITProfessionals/ITProcesses/applying-kanban-to-it-processes-part-5|en]++. Globalement, j’ai pris beaucoup de plaisir à traduire cette série d’articles, que je dédie à Xavier, mon ScrumMaster préféré au boulot et qui souffre en ce moment de Scrumbanite aiguë… y a pas de vaccin :)%%% >  »Cet article est le cinquième et dernier d’une série qui décrit les bases de Kanban et son application dans les processus informatiques : »%%% >  »- La ++[première partie|/dotclear/index.php?post/2011/07/07/Appliquer-Kanban-aux-processus-informatiques-1]++ donnait un aperçu de Kanban et la façon dont il est utilisé dans l’industrie. »%%% >  »- La ++[deuxième partie|/dotclear/index.php?post/2011/07/08/Appliquer-Kanban-aux-processus-informatiques-2]++ donnait un aperçu de Kanban et la façon de l’utiliser dans un service helpdesk (fictif). »%%% >  »- La ++[troisième partie|/dotclear/index.php?post/2011/07/11/Appliquer-Kanban-aux-processus-informatiques-3]++ donnait un aperçu de Kanban et la façon de l’utiliser dans un projet de déploiement de PC (fictif). »%%% >  »- La ++[quatrième partie|/dotclear/index.php?post/2011/07/12/Appliquer-Kanban-aux-processus-informatiques-4]++ donnait un aperçu de Kanban et la façon de l’utiliser dans un projet de développement logiciel (fictif). »%%% > %%% > Dans chacune de ces histoires, la mise en œuvre de Kanban est réussie et il y a des améliorations positives sur une période de temps assez courte. Ce dernier article aborde brièvement certains des défis auxquels il faut faire souvent face et le concept d’amélioration continue. Contrairement aux articles précédents de la série, celui-ci n’a pas d’illustrations, donc je m’excuse d’avance auprès des membres qui préfèrent lire plus d’images que de texte (George * tousse *).%%% > %%% > __Mettre en œuvre Kanban__%%% > %%% > Les histoires fictives narrées dans les articles précédents ont toutes suivi un thème commun, l’amélioration réussie du processus en faisant face à peu voire pas de défis. Toutefois, pour ceux d’entre nous qui travaillent dans le monde réel, nous sommes tous conscients qu’aucun projet ou processus ne peut être lancé sans rencontrer de difficultés. Même si s’attaquer à tous les défis potentiels – que l’on pourrait relever dans l’environnement de chaque lecteur – va bien au-delà de mes compétences et de la portée du présent article, il y a deux défis auxquels la plupart d’entre nous devront faire face dans la mise en œuvre de Kanban dans les environnements informatiques.%%% > %%% >  »Changer les habitudes »%%% > %%% > En plus des défis qui consistent à définir nos processus et à tenter de standardiser des tâches qui sont souvent des exceptions, appliquer un processus Kanban va également nous obliger à remettre en question certaines habitudes bien ancrées. L’idée de limiter la quantité de travail en cours (WIP) dans une étape peut sembler bonne lorsque vous la lisez dans un article, mais en fait se soumettre à des limites est très difficile au début. Les divers styles de management ont tendance à se concentrer sur le temps passé à travailler ou sur le nombre de tâches qu’une personne a terminées et, dans ce cas, s’arrêter de travailler pendant une étape est apparenté à croiser ses pieds sur son bureau et faire une sieste.%%% > %%% > Kanban nous oblige à faire face à ces systèmes de mesure et à corriger certains des défauts auxquels ils mènent dans nos processus. Plutôt que de mesurer à quel point une personne travaille dur pendant une étape, nous allons mesurer la façon dont nous livrons à travers le processus entier. Plutôt que de mesurer le nombre d’heures travaillées par une personne, on peut mesurer le nombre d’heures de travail que nous avons gagnées dans le processus. Là où l’ancien système de mesures se demande pourquoi nous n’empilons pas plus de travail entre les étapes de Développement et de QA, Kanban nous oblige à remettre en question la façon dont nous pouvons améliorer le débit ou diminuer le taux de rework$$NdT : rework = du travail à refaire.$$. Des habitudes bien ancrées sont difficiles à changer. Au lieu de directement remettre en cause ces croyances, nous allons commencer par modéliser le processus et les tâches qui y circulent. Il y a quelques défis à relever dans ce processus de modélisation, mais une fois que la visualisation est en place et que vous commencez à impliquer les autres dans le fait d’améliorer cette visualisation et donc le suivi des tâches, beaucoup de ces défis vont disparaître. La capacité à voir le flux des tâches s’écouler à travers le processus répond au besoin de nombreuses personnes, en offrant une visibilité et un aperçu du processus qui, auparavant, étaient dirigés par l’estimation et des conjectures occasionnelles.%%% > %%% >  »L’informatique ce n’est pas une chaîne de fabrication industrielle »%%% > %%% > Un autre défi fréquent que l’on rencontre avec Kanban c’est que, tirant son origine de l’industrie$$NdT : Kanban a été déployé à la fin des années 50 dans les usines Toyota.$$, on considère du coup qu’il n’est pas approprié pour un environnement informatique. C’est un argument très largement opposé à Kanban (et aux principes du Lean en général), et il a été solidement réfuté dans un grand nombre d’industries. L’idée que des pratiques ou des connaissances d’une industrie ne peuvent pas être utilisées pour améliorer notre compréhension dans d’autres types d’industrie, semble un peu égoïste, surtout lorsqu’on ajoute qu’un domaine est trop spécialisé pour apprendre quelque chose des autres. Si tel était vraiment le cas, les progrès médicaux réalisés grâce au programme spatial n’auraient jamais eu lieu, pas plus que des centaines d’autres concepts et idées qui ont traversé les frontières de l’industrie pour générer de nouvelles idées ou produits dans d’autres types d’industrie.%%% > %%% > Parfois l’argument est formulé de manière plus nuancé, en citant la différence entre les usines de fabrication produisant des pièces identiques et en série et les tâches en constante évolution dans un environnement informatique. Passez quelques minutes sur votre moteur de recherche préféré et vous trouverez des exemples dans un certain nombre d’industries, y compris le développement logiciel, où Kanban a non seulement été mis en œuvre avec succès, mais a montré le chemin vers l’amélioration continue et d’autres pratiques ayant des racines dans les chaînes de fabrication industrielles. Bien que cela ne soit pas une réponse formelle ou philosophique, je ne vois pas pourquoi on passerait du temps à formuler une preuve logique pour quelque chose de si facilement observable.%%% > %%% > Appliquer Kanban n’est pas sorcier, mais il exige de la réflexion et du temps. Heureusement, il y a des communautés entières de gens qui sont prêts à répondre à vos questions, à faire appel à des experts et à proposer de bons livres.%%% > %%% > __Pourquoi Kanban__%%% > %%% > Les articles précédents ont illustré la mise en œuvre de Kanban dans des environnements fictifs, mais nous n’avons pas passé beaucoup de temps à expliquer comment ou pourquoi il fonctionnait comme cela. Les articles n’ont pas donné de détails sur les méthodes utilisées par les équipes pour identifier des zones d’amélioration ou la façon dont ces améliorations ont été traitées. Opérer des changements dans des processus réels peut être aussi simple que nos histoires mais parfois un peu plus difficile. Ce que Kanban nous offre, c’est un outil qui nous aide à localiser les points chauds$$NdT : en Agile on dit « faire émerger les problèmes. »$$ sur lesquels concentrer nos efforts pour obtenir le plus grand effet de levier.%%% > %%% > Au fur et à mesure que nous mettons en œuvre Kanban, nous commençons à réaliser les tâches d’une manière cohérente. Cette cohérence améliore notre vitesse d’exécution parce que nous pouvons faire des hypothèses sur les tâches que nous recevons ; elles répondent à un certain niveau de conformité et partagent un certain ensemble d’exigences et de caractéristiques. Cela réduit le nombre de fois où nous étions amenés à retourner sur les étapes amonts, à router les tâches vers de nouvelles étapes exceptionnelles, ou à inventer des processus à la volée. L’acte en lui-même de créer le tableau Kanban nous aide à trouver ou à construire cette cohérence, et réduit encore davantage le temps perdu à déterminer où les tâches devaient être routées ou à connaître leurs statuts actuels. Le tableau fournit une vue haut niveau des tâches ou des groupes de tâches se déplaçant à travers le processus, faisant clairement apparaître les goulots d’étranglement et les remous dans le flux, ceux-là même qui ne sont pas visibles de l’intérieur du processus. L’analyse des causes racines des goulots d’étranglement nous montre les endroits où mener une amélioration locale sur une étape qui peut directement entraîner une amélioration du processus dans son ensemble.%%% > %%% >  »Amélioration continue »%%% > %%% > Le terme « Amélioration Continue » est apparu dans plusieurs articles et le concept est présent dans chacun d’eux. Le principe de l’amélioration continue est de faire de petites et progressives améliorations à un processus qui, sur le long terme, permettront d’obtenir de grosses économies et des améliorations sur la qualité. Des améliorations individuelles sont obtenues par la recherche et l’analyse d’un gaspillage dans le processus (tels que le gaspillage de matériel, le mouvement et les risques de sécurité) ou de plusieurs gaspillages dans une seule étape du processus (tels que la détection des défauts dans l’article concernant le développement de logiciels). En déterminant la cause racine de ce(s) gaspillage(s), et en effectuant des petits ajustements sur le processus pour réduire ou éliminer ce gaspillage, les objectifs ou les méthodes d’amélioration deviennent utilisables. En éliminant lentement mais sûrement les gaspillages dans nos processus, nous améliorons la qualité, les coûts et le rythme de notre processus.%%% > %%% > Kanban soutient ces efforts d’Amélioration Continue en fournissant un flux cohérent et la visualisation de notre processus. La visualisation et la standardisation du processus permet de rendre davantage visible les exceptions et les goulets d’étranglement, nous donnant des pistes claires d’amélioration. Une fois que les améliorations ont été réalisées, le tableau Kanban peut alors nous montrer la manière dont ces changements ont affecté et amélioré le processus dans son ensemble, si ces améliorations ont permis de découvrir de nouveaux problèmes, ou si elles ont échoué à résoudre le problème à la racine.%%% > %%% >  »Coûts et Qualité »%%% > %%% > Bien que Kanban nous fournisse la capacité à localiser les problèmes et à améliorer le processus, ce qui permet de réduire nos délais de livraison, il ne fournit pas nécessairement des outils pour réduire les coûts ou améliorer la qualité. Bien que nous ayons vu la qualité et les coûts améliorés dans nos articles fictifs, cela a été souvent été une conséquence de l’amélioration du temps de cycle en éliminant un goulot d’étranglement. Cependant, Kanban nous fournit quelques indications qui peuvent être réutilisées. Comme avec le temps de cycle, si nous voulons améliorer la qualité ou les coûts, nous devons utiliser notre processus et localiser où nos problèmes de coûts et de qualité apparaissent et nous concentrer sur ces zones.%%% > %%% > Exemple d’amélioration continue%%% > %%% > Par exemple, si nous souhaitons nous concentrer sur la qualité, nous pouvons créer des standards définissant le niveau de qualité dans notre produit final et commencer à tester leur respect. Pendant les tests, nous pouvons suivre les cartes (ou lots) qui échouent sur le test de qualité et qui génèrent du rework (article 3) ou qui sont abandonnées et ensuite remplacées suite à un travail supplémentaire. En utilisant la fréquence d’apparition des problèmes et les coûts générés pour produire une tâche avant que chaque problème de qualité soit trouvé, nous pouvons créer une répartition des coûts assez simple pour déterminer nos plus grosses opportunités d’amélioration. Dans certains cas, nous pouvons constater les problèmes de qualité en dehors de notre processus, dans d’autres processus, et nous devons donc conduire les tests le plus tôt possible dans notre processus pour réduire les efforts investis avant que les problèmes soient découverts.%%% > %%% > Qualité / Délais / Coûts : le tout ensemble, svp%%% > %%% > En informatique, nous citons souvent le triangle coûts / qualité / délais aux personnes qui s’attendent à avoir les trois ensemble sans aucun travail ou investissement supplémentaire. En utilisant l’exemple ci-dessus, on pourrait facilement remplacer la qualité par les coûts et construire une méthode simple pour trouver les meilleures opportunités de réduction des coûts. Mais étant donné que les gaspillages impactent souvent plus d’un sommet du triangle, on peut choisir d’améliorer nos temps de cycle, la qualité ou les coûts et du coup améliorer les autres.%%% > %%% > Il n’est pas rare dans le monde de l’industrie de diminuer les problèmes de qualité, de délais et de coûts suffisamment pour améliorer la capacité de 25 à 50%, et ceci sans embaucher de nouveaux employés ou acheter de nouveaux équipements. En informatique, on compte souvent sur la technologie pour améliorer les choses, mais la technologie est quelque chose que n’importe lequel de nos concurrents peut acheter et la disponibilité est dictée par le marché, et non par nos besoins. Pour prendre de l’avance sur nos délais et nos concurrents, pour passer des vacances tranquilles ou pour obtenir des augmentations qui soient au-dessus du taux d’inflation annuel, nous devons aller au-delà de ce que les fournisseurs offrent et créer une meilleure qualité de service et un meilleur engagement de l’entreprise. Réduire les coûts, améliorer la qualité et réduire les délais de livraison impactent la dernière ligne du bilan de fin d’année et améliorent l’efficacité du reste de l’entreprise. Et dans le cas où une entreprise est moins intéressée par l’efficacité et plus intéressée par le nombre d’heures sur l’horloge, des améliorations successives peuvent aussi constituer d’excellentes expériences sur les CVs.%%% > %%% > __Plus d’opportunités__%%% > %%% > Il y a beaucoup d’autres possibilités pour Kanban que celles décrites dans mes autres articles, et il existe de nombreux autres articles de fond. Les trois exemples contenus dans les articles précédents ont été choisis pour exposer une grande variété de problèmes :%%% > %%% > – Un helpdesk qui gère un nombre inconnu de tâches à la demande, chacune composée d’un ensemble complètement différent de sous-tâches%%% > – Un processus de déploiement de PC semblable à une chaîne de fabrication, mais nécessitant deux personnes pour s’occuper des multiples étapes d’un processus qui n’est utilisé que tous les 1 ou 2 ans.%%% > – Un processus de développement logiciel qui définit ses propres tâches à partir d’un sous-ensemble de features.%%% > %%% > On peut espérer que ces trois exemples soient assez proches de nos contextes respectifs pour que nous puissions avoir des idées sur la façon d’y appliquer Kanban. Je vous donne d’autres idées :%%% > %%% > – Un concepteur de rapports peut définir un processus commun de conception, développement, modification et déploiement de rapports et commencer à traquer les inefficacités qui enlisent le processus.%%% > – Un administrateur de base de données peut commencer à regarder les mécanismes de file d’attente des transactions et créer une visualisation de type Kanban du processus pour aider à éliminer les goulots d’étranglement en concentrant ses efforts d’amélioration du processus dans son ensemble.%%% > – Un administrateur système peut concevoir un processus de mise à jour de la planification de chacun des domaines fonctionnels et commencer à boucler sur la liste complète des domaines à travers ce processus, chaque fois qu’il réduit le travail ou le temps mis en œuvre dans l’évaluation de nouvelles options technologiques ou dans la mise en œuvre des correctifs et de la maintenance.%%% > %%% > __Remerciements__%%% > %%% > Je tiens à remercier tous ceux qui m’ont aidé à relire et modifier ces articles. Au cours de leur publication, j’ai pris à chaque fois un peu d’avance pour finir la rédaction de l’article avant qu’il soit publié et l’aide de plusieurs membres a été inestimable :%%% > %%% > – Tim (Riverguy) et David (Thirster), qui ont détecté quelques erreurs critiques dans les tout premiers articles%%% > – Erik (Emtucifer), qui a relu de façon très approfondi le premier article%%% > – Fionnuala (Remou) qui a relu les articles suivants, et a sauvé l’un de mes articles de la mort%%% > – Ted (onpnt) pour avoir relu (ou avoir fait semblant de relire) chaque article et avoir régulièrement fourni des retours positifs.%%% > %%% ///html

A propos de l’auteur
Eli Weinstock-Herman Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
/// —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Appliquer Kanban aux processus informatiques (4)

J’ai traduit ce quatrième billet de __Eli Weinstock-Herman__ : ++[Applying Kanban to IT Processes (Part 4)|http://blogs.lessthandot.com/index.php/ITProfessionals/ITProcesses/applying-kanban-to-it-processes-part-4|en]++.%%% >  »Cet article est le quatrième d’un ensemble d’articles qui décrit les bases de Kanban et son application dans les processus informatiques : »%%% >  »- La ++[première partie|/dotclear/index.php?post/2011/07/07/Appliquer-Kanban-aux-processus-informatiques-1]++ donnait un aperçu de Kanban et la façon dont il est utilisé dans l’industrie. »%%% >  »- La ++[deuxième partie|/dotclear/index.php?post/2011/07/08/Appliquer-Kanban-aux-processus-informatiques-2]++ donnait un aperçu de Kanban et la façon de l’utiliser dans un service helpdesk (fictif). »%%% >  »- La ++[troisième partie|/dotclear/index.php?post/2011/07/11/Appliquer-Kanban-aux-processus-informatiques-3]++ donnait un aperçu de Kanban et la façon de l’utiliser dans un projet de déploiement de PC (fictif). »%%% >  »Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte. »%%% > %%% > Dans la quatrième partie de cette série « Appliquer Kanban aux processus informatiques », nous allons suivre une équipe de développement logiciel. Ils appliquent actuellement un processus qui a été baptisé le ++[modèle sashimi|http://en.wikipedia.org/wiki/Waterfall_model|en]++, un modèle en cascade modifié avec recouvrement des phases : exigences, conception, développement et tests. Cet exemple se concentre sur l’utilisation de Kanban pour améliorer et affiner un processus actuellement utilisé plutôt que d’exécuter un processus de conversion complet.%%% > %%% > __Bienvenue à la société GHI__%%% > %%% > GHI est une petite société de développement qui se spécialise dans la construction et l’intégration de systèmes d’inventaire et de valorisation des stocks dans le B2B et le B2C. Un des défis qu’ils ont choisi de relever est le suivi et le reporting d’activités. Étant donné que leurs produits nécessitent de grands développements côté logique métier et administration et très peu côté interface utilisateur, le client ne peut pas voir la façon dont le produit évolue. Améliorer les mécanismes de suivi et de reporting fournira au client de plus amples informations sur la façon dont le projet progresse, augmentant ainsi leur niveau de confiance à la fois dans la solution et dans la société. Cette dernière estime que l’amélioration de cette confiance n’affectera pas seulement la relation avec ce client, mais améliorera également son image sur le marché et avec d’autres clients potentiels.%%% > %%% >  »État courant »%%% > %%% > Le processus actuel de l’équipe commence par le recueil des exigences de haut niveau et la construction de l’architecture générale, sans aborder aucune des règles métier. Une fois le squelette développé, l’équipe se concentre sur le fait de mener de façon itérative le recueil des exigences et la construction des plus petits modules nécessaires pour ajouter la chair au squelette. La conception globale du système suit une approche N-tier, avec des couches définies pour l’accès aux données, la logique métier, la séparation des processus de transaction et de traduction pour chaque système externe et une interface utilisateur limitée. Cette démarche itérative permet de découvrir plus avant la logique métier et les exigences pendant le développement. Cette approche modulaire permet également de développer en pilotant par les tests des parties du système sans disposer des vrais systèmes tiers donc sans exiger que la solution soit complète. Ce pilotage par les tests permet également au personnel technique du client et aux analystes métier d être impliqués et de relever d’éventuelles contradictions au plus tôt.%%% > %%% > On a demandé à l’équipe de fournir une meilleure visibilité et des indicateurs clairs qui puissent être partagés avec le client. Bien que de nombreux membres de l’équipe sont intéressés pour essayer des méthodes Agile, comme Scrum ou XP, l’équipe décide qu’appliquer Kanban à leur processus initial constituera un faible changement du point de vue du client. Une fois que l’équipe disposera d’une meilleure visibilité et de meilleurs indicateurs, elle a bien l’intention de réévaluer le potentiel d’utilisation de Scrum ou de tout autre méthode Agile, mais elle perçoit qu’un changement progressif sera acceptable pour les clients là où un changement de processus complet ne le sera pas.%%% > %%% > Dans le cadre de ses efforts continus, l’équipe est également à la recherche d’un moyen d’améliorer sa vitesse de livraison. La plupart des membres de l’équipe approuvent le fait qu’un développeur supplémentaire permettrait d’accélérer leur processus de livraison d’au moins 15%, mais ils ne seront pas en mesure de défendre le recrutement d’effectifs supplémentaires sans disposer d’indicateurs convaincants permettant de légitimer leurs demandes.%%% > %%% > __Définir le processus__%%% > %%% > Suite à plusieurs longues réunions, l’équipe a élaboré son processus comme une série d’étapes clairement définies qui suivent des cycles, en se concentrant de manière itérative sur de plus petits morceaux.%%% > %%% > ((/dotclear/public/traductions/Pt_4_Sashimi.png|Pt 4 Sashimi||Pt 4 Sashimi))%%% > Processus en cascade itératif (Sashimi)%%% > %%% > Bien que le processus suivi soit presque fractal dans son exécution, chaque passe détaillée de plus en plus finement suit une série d’étapes :%%% > %%% > __Reste à faire__ : travaux non encore bien déterminés qui doivent être conçus et développés%%% > __Exigences__ : recueil d’exigences métier ou système tiers pour une tâche ou un module%%% > __Conception__ : application des standards de conception, de modélisation et d’exigences externes pour concevoir la tâche ou le module%%% > __Développement__ : développement selon la conception et les exigences%%% > __Test__ : test des développements terminés pour détecter les défauts* et valider l’alignement aux exigences%%% > __Revue client et acceptation__ : groupes de revue des tâches avec le personnel technique, les analystes métier ou les services tiers%%% > %%% > L’équipe compte actuellement un chef de projet, cinq développeurs et une personne pour la QA. Une fois défini son processus, l’équipe a décidé que l’un des développeurs serait en charge de l’architecture (exigences et conception), le chef de projet sera responsable des étapes client et de la priorisation du reste à faire (avec l’aide de l’architecte), le reste des développeurs et la personne QA prendront en charge le développement et les tests. L’architecte sera également responsable d’une partie du développement si l’équipe prend de l’avance sur les exigences et la conception.%%% > %%% > * »Les défauts sont des imperfections du produit qui apparaissent en situation de production ou d’exploitation normale. Des exemples de défauts dans l’ingénierie logicielle sont du code mal saisi, un référencement incorrect des variables et d’autres erreurs techniques. Les problèmes au niveau des exigences sont par exemple des options manquantes dans les filtres de recherche, une mise en page incorrecte d’un formulaire et d’autres éléments directement liés au client. »%%% >  »Exemple : le client n’exigera jamais explicitement que la fonction de validation ne bloque pas le serveur, donc une erreur dans une fonction de validation qui bloque le serveur est classée dans la catégorie défaut. »%%% > %%% > __Tableau visuel 1__%%% > %%% > A des fins de visualisation et de suivi, l’équipe découpe plusieurs étapes en sous-étapes. Les étapes d’exigences et de conception ont été définies comme une série de trois sous-étapes, la dernière étape étant une étape « prêt » qui indique que les tâches peuvent être sélectionnées et commencées par les développeurs. Le développement a été découpé en deux sous-étapes, une étape « en cours » et une étape « terminé ». Les éléments de la sous-étape « terminé » » sont mis à disposition pour être sélectionnés et testés par la QA.%%% > %%% > [((/dotclear/public/traductions/KanbanPt4_VisBoard_4a.png|KanbanPt4 VisBoard 4a||KanbanPt4 VisBoard 4a))|/dotclear/public/traductions/KanbanPt4_VisBoard_4a.png]%%% > Le premier tableau visuel%%% > %%% > L’équipe utilise un grand tableau blanc magnétique pour son tableau Kanban. Au lieu d’utiliser des couloirs pour visualiser les travaux en cours, l’équipe a créé des emplacements spécifiques sur le tableau pour les tâches et pour la photo de chaque membre de l’équipe. Par exemple, lorsque l’architecte de l’équipe recueille les exigences pour une tâche, il place sa photo dans la colonne exigences avec la tâche sur laquelle il travaille actuellement. Le chef de projet a donné une série de timbres d’animaux colorés aux membres de l’équipe pour estampiller les tâches qu’ils terminent, permettant au reste de l’équipe de suivre facilement qui a travaillé sur une tâche donnée. Cela permet à la personne de la QA ou à un développeur qui prend la suite de communiquer facilement avec le développeur d’origine sans faire appel à des mécanismes complexes de traçabilité.%%% > %%% > [((/dotclear/public/traductions/KanbanPt4_VisBoard_4b.png|KanbanPt4 VisBoard 4b||KanbanPt4 VisBoard 4b))|/dotclear/public/traductions/KanbanPt4_VisBoard_4b.png]%%% > Limites Kanban%%% > %%% > Les limites Kanban ont été définies en fonction du nombre de personnes affectées à chaque étape et de quelques approximations sur la quantité de travail attendue à chaque étape sans que les étapes avales du processus manquent de travail. Les étapes d’exigences et de conception sont limitées à trois tâches pour trouver un équilibre entre conserver des informations fraîches sur les exigences et fournir suffisamment de travail pour l’étape de développement. La étapes de développement possèdent une limite de cinq tâches pour permettre à l’architecte d’avancer et de développer de petites tâches lorsque la limite est atteinte pour les exigences et la conception. L’étape de QA est limitée à une seule tâche, tirée à partir des tâches de développement terminées. Cela permet à la personne QA de terminer une série de tests sans être perturbée par de nouveaux développements déployés en cours de tests. La file d’attente des éléments en attente de la revue clients n’est pas limitée car le chef de projet a déjà des réunions hebdomadaires avec le client pour discuter des tâches terminées. La file d’attente permet au chef de projet de sélectionner des ensembles de tâches terminées et d’en discuter avec les participants, ou d’envoyer des rappels assez tôt pour s’assurer que les bons participants seront présents à la réunion.%%% > %%% >  »Exécuter le nouveau processus »%%% > %%% > Initialement, le processus est un peu brut puisque l’équipe tente de terminer les tâches qui dépassent les limites à travers le flux. L’architecte commence à s’acclimater à un rôle qui exige de consacrer plus de temps avec des tableaux blancs et moins avec un éditeur de code. Le chef de projet commence à opérer la transition de la gestion des flux de tâches dans le processus vers la gestion des priorités et l’amélioration des communications avec le client.%%% > %%% > Après quelques semaines, le processus est plus fluide. Le chef de projet priorise les tâches dans la file d’attente, parfois en impliquant l’architecte pour s’assurer que les exigences de conception sont prises en compte. L’architecte sélectionne les tâches prioritaires en haut de la pile, recueille des exigences plus détaillées de la part du client, et construit une conception globale qui intègre les exigences et les aligne avec la conception de haut niveau. Lorsque les étapes d’exigences et de conception atteignent la limite Kanban, l’architecte passe à l’étape de développement et soit aide les développeurs soit sélectionne une petite tâche de développement qu’il finira lui-même. Les développeurs sélectionnent des tâches de l’étape d’architecture et les implémentent. Après avoir terminé une tâche, ils la déplacent dans la sous-étape « fini » et soit aident l’un des autres développeurs soit sélectionnent une nouvelle tâche. Lorsque l’étape de développement atteint sa limite Kanban, les développeurs sans tâches attribuées se déplacent en amont du processus pour aider la personne QA à tester afin de supprimer les obstacles. La personne QA teste chaque tâche, à la recherche d’anomalies ainsi que pour vérifier l’alignement avec les exigences clients et la conception interne.%%% > %%% > [((/dotclear/public/traductions/KanbanPt4_VisBoard_4b_QA.png|KanbanPt4 VisBoard 4b QA||KanbanPt4 VisBoard 4b QA))|/dotclear/public/traductions/KanbanPt4_VisBoard_4b_QA.png]%%% > Les tâches de QA retournent au développement ou passent à la suite%%% > %%% > Après avoir testé une tâche, la personne QA soit la renvoie dans la colonne de développement pour être corrigée soit la déplace dans la file d’attente. Renvoyer une tâche aux développeurs causera souvent l’atteinte ou le dépassement de la limite Kanban pour le développement. Le développeur qui prend la suite et qui atteint ce point d’arrêt, soit aide à continuer les tests soit sélectionne la tâche renvoyée pour corriger les problèmes en suspens.%%% > %%% > __Première révision__%%% > %%% > Dans le cadre de la définition du processus initial, l’équipe a convenu d’examiner et de réviser son processus régulièrement. Pendant les premières semaines, le chef de projet a recueilli des statistiques de haut niveau pour mesurer le débit du processus et fournir des informations pour la réévaluation du processus. L’information détaillée comprend des statistiques sur la fréquence des tâches renvoyées par l’étape de test, le nombre de fois où l’architecte ou les développeurs sont amenés à se déplacer en aval du processus pour aider à débloquer les obstacles, et une estimation générale de la façon dont le client réagit lors chaque réunion hebdomadaire.%%% > %%% >  »Évaluation »%%% > %%% > Il y avait un certain nombre de tâches partiellement terminées lorsque l’équipe a commencé et ils attendaient l’étape de QA pour se stabiliser. Malheureusement, cela n’a pas eu lieu, et afin de maintenir un flux régulier de tâches, les développeurs sont souvent aller en aval du processus pour aider la personne de la QA à traiter son backlog. Les quelquefois où les développeurs ont eu des journées exceptionnelles, la QA a presque immédiatement bloquée, nécessitant plusieurs développeurs pour aider à traiter le backlog.%%% > %%% > Le rôle d’architecte requiert moins de temps que prévu, conduisant l’architecte à développer environ 50% de son temps. Cela exige, pour quasiment chaque tâche réalisée par l’architecte, un débogage et une correction par l’un des développeurs et réduit encore un peu plus l’efficacité du processus en forçant quelqu’un, peu familier avec les exigences et le code de la tâche concernée, de dépanner rapidement et d’apporter les corrections.%%% > %%% >  »Changements de processus »%%% > %%% > Initialement l’équipe croit que la plus grande limitation pour accomplir des tâches est la main-d’œuvre et qu’augmenter le nombre de développeurs conduirait à une augmentation directe du nombre de tâches qu’ils réalisent chaque semaine. Toutefois, après avoir travaillé pour obtenir un processus plus raffiné et mesurable, ils ont constaté que l’ajout de développeurs offrirait peu ou pas d’avantages parce que la contrainte actuelle sur leur processus est le goulot d’étranglement sur la QA. S’ils augmentent le débit de cette étape, alors le processus entier sera beaucoup plus fluide et générera un débit plus élevé, puisque la QA sera en mesure de tirer des tâches de la zone de développement plus rapidement.%%% > %%% > L’équipe a pris en compte plusieurs idées pour accroître la main-d’œuvre à l’étape de test, y compris l’embauche d’une personne supplémentaire pour la QA et même utiliser l’architecte à temps partiel sur la QA au lieu de le faire développer. Après avoir discuté de plusieurs options, un membre de l’équipe a suggéré d’utiliser l’architecte et tout développeur disponible pour construire des tests automatisés. La théorie est que l’automatisation de certains des tests ne réduira pas seulement la quantité de travail pour la personne QA, mais réduira aussi le nombre de tâches qui sont renvoyées par la QA au développement pour débogage et correction. L’équipe a décidé d’essayer cette idée parce qu’elle ne nécessite pas de dépenses supplémentaires et qu’il y a peu d’impact négatif d’avoir l’architecte travaillant sur les tests unitaires au lieu d’aider à terminer les travaux de développement en respectant la limite Kanban.%%% > %%% > [((/dotclear/public/traductions/KanbanPt4_VisBoard_4c.png|KanbanPt4 VisBoard 4c||KanbanPt4 VisBoard 4c))|/dotclear/public/traductions/KanbanPt4_VisBoard_4c.png]%%% > Tableau Kanban révisé avec des étapes supplémentaires%%% > %%% > Le tableau Kanban a été modifié pour inclure une sous-étape de création de tests en plus des exigences et de la conception. L’architecte est responsable de la construction d’un certain nombre de cas de test pour chaque tâche à définir. Lorsque les limites de la zone exigences sont atteintes, l’architecte travaille sur la construction. Cela garantit que les tâches en cours ont des tests automatisés et qu’au fur et à mesure que le temps passe, la couverture augmente pour tester l’intégration des modules et tout risque d’effets de bord ou de lacunes lors de l’intégration des modules conçus ensemble.%%% > %%% > La limite pour l’étape de développement sur le tableau est augmentée et une petite zone est créée pour les tâches renvoyées par la QA. Ces tâches sont traitées avec une priorité plus élevée que les tâches de la zone d’exigences pour s’assurer que la plupart des tâches seront corrigées et terminées avant que tout nouveau travail démarre. Pour aider à augmenter l’efficacité des développeurs à corriger ou déboguer le code écrit par d’autres, une nouvelle revue de code est mise en place. Chaque fois qu’une tâche est terminée, le développeur revoit le code avec un ou plusieurs des autres développeurs pour s’assurer qu’il est simple, commenté où il faut et qu’il suit les standards existants. Ce processus est relativement rapide et réduit les coûts et le temps supplémentaire consommé lorsque quelqu’un d’autre dépanne les tâches réalisées initialement par quelqu’un d’autre.%%% > %%% > __Analyse finale__%%% > %%% > Bien que l’équipe continue à réévaluer et réviser son processus selon une fréquence de quelques semaines, elle a déjà réalisé un certain nombre d’améliorations par rapport à son processus original et à la première version des limites de Kanban.%%% > %%% >  »Flux de processus »%%% > %%% > L’équipe n’a pas révisé ses priorités, exigences ou processus de conception, de sorte que ces étapes continuent à travailler de la même manière qu’avant l’application des limites Kanban. Le nouveau processus de création de tests unitaires pour les tâches a été lent pendant la première semaine, mais comme l’architecte a acquis une expérience avec le framework de tests, le processus de construction de tests est devenu plus fluide et a commencé à donner du temps pour construire des tests sur les modules déjà terminés. Au fur et à mesure que les développeurs terminent leurs tâches, ils regardent en premier la file d’attente des « corrections » provenant de la QA pour voir si des tâches sont en attente d’être déboguées ou corrigées. Cela met donc la priorité sur les tâches précédemment commencées et assure que les nouvelles tâches ne sont démarrées que lorsque la zone à corriger est vide. Le nouveau framework de tests unitaires a donné aux développeurs un moyen rapide de tester leur travail avant de déclarer qu’il est terminé et leur a également fourni des informations d’une toute autre dimension sur les exigences métier et de conception. Les tests unitaires ont également réduit le nombre de tâches correctives sur lesquelles les développeurs doivent travailler parce qu’ils signalent la plupart des défauts que la QA avait l’habitude de trouver auparavant.%%% > %%% > L’étape de QA est devenue beaucoup plus rapide et il semble probable que la personne QA aura besoin d’un second boulot bientôt, l’équipe des 4 développeurs a été maintenue mais la QA a subi deux « périodes de sécheresse » la semaine précédente puisqu’elle était en avance sur les développeurs. Le nombre moyen de tâches retournées a été considérablement réduit, avec seulement environ 5% des tâches retournées pour dépannage là où plus de 50% étaient autrefois retournées. L’étape QA évalue et utilise aussi des tests automatisés pour s’assurer qu’aucun défaut n’a été négligé et le gain de temps, lié au fait de ne pas avoir à construire des tests et ne pas avoir à les passer manuellement pour chaque tâche, est énorme.%%% > %%% > Avec l’étape de QA terminant l’évaluation des tâches plus rapidement, la file d’attente des éléments à revoir par le client croît à un rythme beaucoup plus rapide. Le chef de projet commence à avoir des difficultés à couvrir le tout en une seule réunion hebdomadaire, car le nombre d’éléments terminés a augmenté et se révèle un peu compliqué à traiter dans le format de réunion actuel. Des modifications des méthodes de communication sont susceptibles de survenir dans un proche avenir pour aider à gérer le flux croissant des tâches accomplies. Les mesures globales du débit des tâches et l’estimation des dates de fin sont plus cohérentes et ne varient pas énormément par rapport à avant. Alors que les indicateurs ont reflété l’amélioration du processus, la variation ou la plage des valeurs s’est considérablement restreinte.%%% > %%% > __Succès__%%% > %%% > L’équipe a seulement travaillé sur son processus quelques mois, mais elle a déjà commencé à voir des améliorations positives et elle envisage déjà des pistes pour son prochain cycle d’amélioration. Voici quelques-uns des succès qu’elle a déjà obtenus :%%% > %%% > – Augmentation de la productivité : le rythme global de développement a augmenté par rapport au rythme constaté avant mise en œuvre de Kanban%%% > – Augmentation de la confiance : l’amélioration de la vitesse de développement, l’utilisation d’outils automatisés et de nouveaux indicateurs ont tous contribué à l’amélioration de la confiance du client%%% > – Clarté de la vision : la définition du processus et le tableau Kanban ont donné à l’équipe une meilleure vue de leur processus et un moyen de comparer avec d’autres méthodologies%%% > – Estimation de la variabilité réduite : la capacité à mesurer le débit et de meilleures estimations ont permis à l’entreprise de mieux évaluer le moment d’approcher de nouveaux clients potentiels%%% > – Mesurabilité : de bons indicateurs fournissent un outil important pour continuer à améliorer le processus et évaluer si des améliorations potentielles ont amélioré le processus ou non%%% > – Support à la formation : des améliorations dans le processus ont contribué à diminuer les coûts et fournir un argument pour consacrer ce temps à se former, pour aider à conduire de futures améliorations ou empêcher la société de se lancer sur une technologie qui n’offrira pas ce qui est demandé%%% > %%% > Dans le prochain article, nous conclurons cette série en 5 parties, « Appliquer Kanban aux processus informatiques », avec des idées issues d’autres domaines de l’informatique. Nous allons également discuter de certains processus non-humains pour lesquels Kanban peut être appliqué, ainsi que quelques brèves informations sur certains des autres concepts qui ont été abordés dans la série (tels que l’amélioration continue).%%% ///html

A propos de l’auteur
Eli Weinstock-Herman Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
/// —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

La 5ème pratique fondamentale de Kanban

((/dotclear/public/photos/.photo-karl-scotland_sq.jpg|Karl Scotland|L|Karl Scotland))J’ai traduit cet article de __Karl Scotland__ : ++[« The Fifth Primary Practice of Kanban »|http://availagility.co.uk/2009/06/30/the-fifth-primary-practice-of-kanban/|en]++ suite à une réponse de Colin Garriga-Salaün (facilitateur d’équipes agiles chez ++[Yaal|http://yaal.fr/]++) au message ++[Scrumban paru sur le Groupe Yahoo du French SUG|http://fr.groups.yahoo.com/group/frenchsug/message/736|fr]++.%%% > J’ai récemment écrit ce que je considérais comme étant ++[les quatre pratiques fondamentales|http://availagility.co.uk/2009/06/15/how-is-kanban-different-from-other-approaches/|en]++ d’un système Kanban pour le développement de logiciels :%%% > %%% > 1. Cartographiez la chaîne de valeur%%% > 2. Visualisez la chaîne de valeur%%% > 3. Limitez les travaux en cours (WIP) %%% > 4. Établissez une cadence%%% > %%% > Durant les discussions qui ont suivi sur l’amélioration continue dans un système Kanban, j’ai décidé qu’il manquait une cinquième pratique fondamentale :%%% > %%% > 5. Réduisez les éléments dans le Kanban%%% > %%% > J’ai d’abord appelé cette pratique « Éliminez le Kanban », mais j’ai vite été persuadé que c’était probablement trop sensationnel et par conséquent potentiellement source de confusion ou d’erreur. L’intention de cette pratique est qu’une fois qu’un système Kanban est en place, l’équipe devrait constamment chercher à l’améliorer en créant un environnement où le travail s’écoule naturellement. Il y a une citation de ++[Rother et Shook|http://www.amazon.com/Learning-See-Stream-Mapping-Eliminate/dp/0966784308|en]++, je crois, qui dit « laissez le flux s’écouler là où vous pouvez, tirez le travail là où vous devez ». En s’efforçant de réduire le nombre d’éléments dans le système kanban, une équipe évoluera vers un environnement où ses membres seront davantage auto-organisés et où le travail pourra mieux s’écouler. Ceci peut être atteint soit en diminuant les limites de WIP, soit en réduisant fortement le nombre d’étapes distinctes.%%% __Feedback :__%%% * Claude Aubry : ++[La 4ème colonne|http://www.aubryconseil.com/post/La-4eme-colonne]++%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Appliquer Kanban aux processus informatiques (3)

J’ai traduit ce troisième billet de __Eli Weinstock-Herman__ : ++[Applying Kanban to IT Processes (Part 3)|http://blogs.lessthandot.com/index.php/ITProfessionals/ITProcesses/applying-kanban-to-it-processes-part-3|en]++. Le sujet de ce billet m’a clairement rappelé mon année passée au service informatique des pompiers de la Gironde avec la maintenance du parc PC des 80 centres de secours. Ca m’aurait bien aidé à l’époque… :)%%% >  »Cet article est le troisième d’un ensemble d’articles qui décrit les bases de Kanban et son application dans les processus informatiques : »%%% >  »- La ++[première partie|/dotclear/index.php?post/2011/07/07/Appliquer-Kanban-aux-processus-informatiques-1]++ donnait un aperçu de Kanban et la façon dont il est utilisé dans l’industrie. »%%% >  »- La ++[deuxième partie|/dotclear/index.php?post/2011/07/08/Appliquer-Kanban-aux-processus-informatiques-2]++ donnait un aperçu de Kanban et la façon de l’utiliser dans un service helpdesk (fictif). »%%% >  »Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte. »%%% > %%% > Dans la troisième partie de cette série « Appliquer Kanban aux processus informatiques », nous explorons l’utilisation de Kanban pour gérer un projet fonctionnel court terme. Cet exemple se concentre sur l’utilisation de Kanban pour créer un processus transparent pour suivre le flux des équipements à travers un certain nombre d’étapes complexes, sans générer de coûts supplémentaires pour le logiciel de suivi, de processus complexes et de formation, ou même d’efforts en double. Une meilleure uniformité et qualité des processus de déploiement permettront également d’améliorer l’efficacité et les délais de dépannage mais aussi d’assurer un niveau de documentation élevé par rapport aux standards en termes de gestion de logiciels et de licences.%%% > %%% > __Bienvenue sur le projet annuel de déploiement des PC de la société DEF__%%% > %%% > La société DEF est une PME disposant actuellement d’environ 1000 PC et portables déployés. Son service informatique fonctionne comme la plupart des services de cette taille, c’est-à-dire avec un haut niveau de management individuel, des liens solides dans l’équipe et un personnel relativement restreint pour couvrir une grande variété de rôles. Sur les 15 personnes, seulement deux vont travailler sur le déploiement des PC et on leur a donné toute liberté pour s’organiser et effectuer leur travail. L’équipe exige un reporting sur l’état d’avancement qui soit clair et simple afin d’éviter que leur travail acharné devienne ++[un projet invisible|http://blogs.lessthandot.com/index.php/ITProfessionals/ProjectManagement/an-invisible-project-is-a-failed-project|en]++. Par ailleurs, il y a un espace de stockage limité pour les équipements non déployés, l’équipe aura donc besoin de bien gérer le nombre d’équipements non déployés ainsi que les commandes de nouveaux équipements.%%% > %%% >  »L’équipement et les tâches »%%% > %%% > Le déploiement annuel de PC doit tenir compte de l’équipement suivant :%%% > %%% > – 160 nouveaux PC à déployer%%% > – 40 nouveaux portables à déployer%%% > – 120 PC et 10 portables à mettre à jour et à redéployer%%% > %%% > Une image logicielle est disponible pour installer de base un système d’exploitation et un ensemble de pilotes sur chaque PC, en réduisant la variabilité de la procédure d’installation initiale. Des tâches comme l’enregistrement sur le domaine réseau, l’installation de logiciels utilitaires,bureautiques, … doivent devenir le standard d’installation, mais il y aura bien sûr également quelques installations personnalisées de logiciels selon l’utilisateur final ou son rattachement à une entité. Mettre à jour un PC existant passe par les mêmes étapes, avec cependant l’ajout d’une tâche d’audit pour vérifier le passage d’un ancien mode d’utilisation à un nouveau. Si on se base sur l’historique, il est clair que l’un des problèmes les plus perturbants est lorsque l’on doit repasser sur un système (rework*) pour installer un logiciel manquant ou modifier une mauvaise configuration, l’équipe a donc décidé d’ajouter certaines vérifications au processus pour limiter ces risques.%%% > %%% > * »Le rework est le nom du processus qui consiste à terminer un élément et le renvoyer à travers une partie du processus pour corriger une étape de production incomplète ou ratée. Dans le cas du déploiement d’un PC, cela pourrait être un logiciel non installé pendant le processus de configuration, de mauvaises permissions allouées, ou toute une douzaine d’autres éléments qui nécessiteraient qu’un technicien revienne sur un PC déjà déclaré « déployé » afin de finir le travail. Les coûts de rework comprennent les coûts liés au fait d’exécuter une seconde fois une étape, de ré-exécuter les étapes suivantes une seconde fois, de basculer de son travail actuel sur l’élément qui nécessite un rework, et les retards liés au fait de terminer les travaux en cours par rapport à l’estimation initiale ou au délai initial. »%%% > %%% >  »Première version du tableau visuel »%%% > %%% > Après avoir discuté des exigences et des étapes du processus, les techniciens ont créé un processus commun à tous les équipements :%%% > %%% > – Réception : le nouvel équipement et l’équipement à redéployer qui n’ont pas encore été « étiquetés »%%% > – Stock : le nouvel équipement et l’équipement à redéployer qui ont été « étiquetés »%%% > – Image : installer l’OS de base, les pilotes et l’image logicielle%%% > – Analyse personnalisée : construire une liste des logiciels client et/ou des paramètres spécifiques pour l’utilisateur final concerné%%% > – Bureautique : installation et configuration initiale des logiciels bureautiques et installation des templates spécifiques à la société%%% > – Utilitaires : installation d’un ensemble standardisé d’utilitaires pour le dépannage informatique et l’audit%%% > – Installation personnalisée : installation des configurations personnalisées%%% > – Audit : exécution du premier audit du PC et mise à jour des liens d’affectation pour un PC redéployé%%% > – Déploiement : déploiement de l’équipement pour l’utilisateur final%%% > %%% > Pour gérer les PC à travers ce processus, l’équipe a inventé un « système d’étiquetage » de l’équipement. Les techniciens ont conçu un formulaire check-list copié et mis à jour pour chaque PC. Le coin supérieur droit du document devient la carte Kanban, tandis que le reste est une check-list qui sera utilisée pour vérifier l’étape précédente de chaque étape du déploiement au fur et à mesure que l’équipement progresse dans le processus. Par le passé, l’équipe avait déterminé qu’il y avait en moyenne 5% de rework nécessaire pour pallier une configuration ou un logiciel manquant.%%% > %%% > ((/dotclear/public/traductions/Pt_3_Tag.png|Pt 3 Tag||Pt 3 Tag))%%% > Exemple de formulaire avec carte Kanban prête à détacher%%% > %%% > Au lieu d’inclure une étape de QA à la fin de son processus de déploiement, l’équipe a choisi de commencer par vérifier la tâche de chaque étape précédente. En vérifiant le plus tôt possible, l’équipe espère réduire le besoin d’un long processus de QA, réduire la quantité de rework, détecter et corriger le plus tôt possible pour prévenir la répétition tardive des tâches (par exemple exécuter le logiciel d’audit). Des cases à cocher « Fait » et « Vérifié » sont mises à disposition sur chaque ligne du formulaire.%%% > %%% > Maintenant que les tâches ont été définies, l’équipe initialise son premier tableau visuel avec du ruban et des étiquettes sur un tableau de liège. Les punaises seront utilisées pour positionner les cartes Kanban liées à chaque pièce d’équipement dans l’étape appropriée du tableau.%%% > %%% > ((/dotclear/public/traductions/KanbanPt3_VisBoard_1.png|KanbanPt3 VisBoard 1||KanbanPt3 VisBoard 1))%%% > Tableau Kanban avec quelques cartes%%% > %%% > Les limites Kanban à chaque étape sont basées sur l’espace de travail disponible et sur le souhait de conserver un flux lissé de l’équipement dans le processus. L’équipe a décidé que, pour trouver un juste équilibre entre la régularité du flux (petites limites) et l’efficacité des installations menées en parallèle (grandes limites), elle définirait des limites basées sur les temps d’installation des logiciels pour s’assurer que les étapes les plus longues soient correctement dimensionnées et ne génèrent pas de retards pour les étapes ultérieures. Copier l’image, installer les logiciels bureautiques et exécuter l’audit nécessitent peu d’intervention humaine mais beaucoup de temps, tandis que l’Analyse personnalisée, le Déploiement et les deux étapes restantes d’installation des logiciels nécessitent un niveau élevé de participation et d’attention de la part de l’installateur.%%% > %%% >  »Créer un reporting »%%% > %%% > Il y a un certain nombre d’exigences et de facteurs à prendre en compte pour établir le reporting lié à ce processus. En se basant sur les exigences et les souhaits exprimés par le responsable informatique, l’équipe a produit la liste suivante des points devant faire l’objet d’un reporting :%%% > %%% > – Avancement : basé sur le concept d’un ++[burndown (lien mort)|]++, le tableau d’avancement affiche les progrès réels et une date de fin prévisionnelle%%% > – Délai déstocké -> déployé : un graphique simple pour montrer le temps de déploiement réel par rapport à la moyenne et aux années précédentes%%% > – Satisfaction des utilisateurs : un couple de barres horizontales qui affiche le nombre de livraisons réussies à la date prévue et le nombre de déploiements incomplets (rework)%%% > %%% > ((/dotclear/public/traductions/KanbanPt3_Spreadsheet.png|KanbanPt3 Spreadsheet||KanbanPt3 Spreadsheet))%%% > Feuille de calcul et graphiques associés pour le reporting hebdomadaire%%% > %%% > Pour générer ce rapport, il faudra mettre à jour la feuille de calcul chaque fin de semaine avec le nombre de PC réellement terminés, incrémenter (le cas échéant) la quantité totale dans une deuxième cellule et indiquer le nombre de PC qui n’ont pas respecté la date de livraison cible dans une troisième cellule. Les projections sont automatiquement mises à jour sur la base d’une équation définie dans le tableur et l’information réactualisée dans les graphiques. Un simple copier/coller des graphiques dans les documents en fin de semaine permet de produire le nouveau reporting hebdomadaire.%%% > %%% > __Analyse finale__%%% > %%% > Pendant l’exécution du processus de déploiement, l’équipe a légèrement modifié les limites Kanban ainsi que le mécanisme de reporting, mais elle n’a pas eu d’importants changements à apporter à son processus. Compte tenu de la transparence des travaux, elle a pu rester sur la bonne voie et déployer les équipements à un rythme régulier. Au fur et à mesure qu’elle a ajusté le rythme du processus, elle a commencé à planifier les commandes de nouveaux PC pour que cela coïncide mieux avec la consommation des stocks, lui permettant d’augmenter la taille de ses commandes, de bénéficier de meilleurs devis concernant l’achat des équipements, sans pour autant manquer de travail entre les commandes. Un reporting final a été réalisé à partir des graphiques tirés des rapports hebdomadaires et des informations supplémentaires concernant la réduction des dépenses et du travail.%%% > %%% >  »Flux du processus »%%% > %%% > Tout nouvel équipement ou équipement remasterisé était affecté à un utilisateur et étiqueté avant de démarrer quoique ce soit. Ceci a empêché qu’apparaissent les problèmes survenus au cours des années antérieures, tels que les mauvaises affectations, les doubles affectations et les réaffectations avec les mauvais logiciels. Le processus a également fourni un inventaire précis des équipements disponibles à tout moment, permettant ainsi de répondre aux questions immédiatement plutôt que de demander à quelqu’un de se rendre dans l’espace de stockage et d’effectuer un inventaire. Une communication au plus tôt avec l’utilisateur final sur la date à laquelle l’équipement serait disponible, a réduit la difficulté à déployer les PC qui étaient prêts, les utilisateurs finaux étant préalablement avertis, ceux-ci pouvaient aider à mieux définir leur disponibilité, avec comme conséquence de réduire la replanification des installations comparativement aux années antérieures. La vérification immédiate des étapes antérieures et les limites Kanban ont favorisé un flux lissé des équipements dans le processus, en fournissant les bases d’un temps de cycle plus cohérent et reproductible. Une meilleure estimation de la durée du processus de déploiement (disponibilité des stocks) a permis de réaliser des économies budgétaires directes, tout en permettant à l’équipe d’augmenter la taille de ses commandes et de profiter de meilleures économies pour la même quantité d’équipements. Enfin, le mécanisme de reporting créé par l’équipe était assez simple pour que le responsable informatique soit capable de l’utiliser lors de chaque réunion de département, sans devoir passer la nuit précédente dessus pour tout préparer.%%% > %%% >  »Succès »%%% > %%% > Voici quelques-unes des succès de l’équipe :%%% > %%% > – Visibilité 100% : visibilité dans le processus et l’inventaire à tout moment, sans effort supplémentaire consacré au suivi des techniciens ou au comptage à la volée de l’équipement%%% > – Moral amélioré : réduction de la confusion et de la négativité des utilisateurs finaux dans l’attribution des équipements en se basant sur des communications claires et un véritable processus d’affectation%%% > – Gains de temps : aucun rework est synonyme de gain de temps dans le processus de déploiement, ainsi que dans la suppression des interruptions que causaient le rework%%% > – Gains financiers : une meilleure estimation et une meilleure gestion des stocks a permis d’augmenter la taille des commandes sans nuire aux délais de réalisation%%% > – Marketing bon et peu onéreux : le processus simple pour générer les rapports a non seulement apporté un gain de temps, mais a aussi produit des métriques assez simples pour qu’elles soient réutilisées lors des réunions managériales avec une publicité positive sans pour autant exiger plus de temps et d’efforts de la part du responsable informatique%%% > – Productivité accrue : en se fondant sur la cohérence du processus, l’amélioration des estimations, la réduction du niveau d’interruption constatée sur les précédentes années, l’ensemble du processus prenait moins d’heures de travail à dérouler%%% > – Amélioration mesurable : les statistiques identiques sont suivies attentivement pendant l’exécution du processus et permettent de constater en fin d’année les améliorations au niveau de l’équipe et du département.%%% > %%% > Les succès énumérés ici couvrent aussi bien des aspects durs (financier) que mous (moral) et ne couvrent probablement pas l’ensemble des succès qui auraient pu être obtenus dans une version non-fictive de cette histoire. En un mot, le processus a pu s’exécuter de façon plus facile, plus efficace et plus prévisible, ce qui a généré au niveau de l’équipe un certain nombre d’améliorations mesurables par rapport aux années antérieures. Ce même processus sera réutilisable dans les années à venir, et peut désormais être utilisé comme une base pour de nouvelles améliorations ou pour permettre de porter les efforts sur l’amélioration d’autres processus puisque celui-ci se déroule simplement et en douceur. Même si utiliser un système Kanban pour un processus temporaire n’est pas fréquent, il démontre sous un autre angle la façon dont il peut être utilisé pour « apprivoiser » des processus de travail complexes et promouvoir l’amélioration globale du processus.%%% > %%% > Dans le prochain article, nous explorerons l’utilisation de Kanban par une équipe de développement logiciel qui cherche à livrer et maintenir un ensemble de produits. Bien qu’il existe déjà beaucoup de comptes-rendus réels de la part de personnes appliquant Kanban au processus de développement logiciel, le développement est une activité notoire d’un département informatique et je serais négligent si je n’apportais pas ma touche personnelle sur la façon dont Kanban peut être utilisé par une équipe de développement.%%% ///html

A propos de l’auteur
Eli Weinstock-Herman Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
/// —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Appliquer Kanban aux processus informatiques (2)

J’ai traduit ce deuxième billet de __Eli Weinstock-Herman__ : ++[Applying Kanban to IT Processes (Part 2)|http://blogs.lessthandot.com/index.php/ITProfessionals/ITProcesses/applying-kanban-to-it-processes-part-2|en]++.%%% >  »Cet article est le deuxième d’un ensemble d’articles qui décrit les bases de Kanban et son application dans les processus informatiques. La ++[première partie|/dotclear/index.php?post/2011/07/07/Appliquer-Kanban-aux-processus-informatiques-1]++ donnait un aperçu de Kanban et la façon dont il est utilisé dans l’industrie. Les articles qui suivront explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte. »%%% > %%% > Dans cette deuxième partie de cette série « Appliquer Kanban aux processus informatiques », nous explorons un helpdesk et la manière dont Kanban peut aider à améliorer son image, ses métriques, son moral, sa réactivité et ses délais d’exécution. Les exemples de tableaux et de processus donnés dans cet article ne sont pas destinés à être pris tel quel dans vos processus d’entreprise, mais plutôt pour créer un système basé sur Kanban et l’appliquer dans un cadre fictif. Kanban est une philosophie et non pas un ensemble figé de processus, donc s’il vous plaît rappelez-vous que ce n’est qu’un exemple de la façon dont il pourrait être appliqué dans les cas fictifs décrits.%%% > %%% > __Bienvenue au helpdesk de l’entreprise ABC__%%% > %%% > Je raconte l’histoire fictive d’un helpdesk de l’entreprise ABC qui a décidé de mettre en place un système Kanban pour définir et améliorer ses processus. Les détails de leur processus, les décisions qui furent prises au fur et à mesure et les méthodes utilisées pour communiquer et mesurer l’atteinte de leurs objectifs, doivent être considérés comme des exemples et non des règles. Alors que certaines entités peuvent procéder en une seule étape pour passer de leur processus actuel à Kanban, ce type de transformation instantanée est risqué, surtout si l’entité en question ne dispose pas d’un processus réaliste et bien défini.%%% > %%% >  »L’année dernière »%%% > %%% > L’année dernière, le département informatique de l’entreprise ABC a commencé à être en sous-effectif et à prendre du retard dans ses travaux. La pression financière a forcé la société à retarder les nouvelles embauches pendant plusieurs mois. Malgré ses efforts, le helpdesk a accumulé les retards sur les demandes de support. Grâce au travail acharné et aux heures supplémentaires, l’équipe a réussi à maîtriser son travail et a cessé de prendre du retard, mais le délai moyen entre une nouvelle demande et la tâche associée terminée a continué à être mesuré en semaines. L’augmentation du nombre de demandes de statut et des tâches signifiait que les gens étaient souvent en train de travailler sur dix à quinze tâches simultanément, ils jonglaient même avec des tâches basiques comme la connexion de nouveaux téléphones ou la commande de nouveaux équipements si bien que les utilisateurs finaux estimaient que le département informatique ne se souciait tout simplement pas de leurs problèmes.%%% > %%% >  »État courant »%%% > %%% > Quelques mois plus tard, l’entreprise ABC a effectué de bons recrutements et les heures supplémentaires ont commencé à diminuer. Les membres du département informatique font de nouveau des horaires réguliers et ils sont fiers de la façon dont ils ont réussi à résister. Malheureusement, ce sentiment de fierté ne dépasse pas les murs du département informatique, et les utilisateurs ont une vue très différente. Les utilisateurs finaux croient encore que le département informatique prend trop de temps pour traiter les demandes et que « ne pas prendre de retard » est différent de « traiter la demande le jour même » et l’équipe de direction se demande si les nouvelles embauches ont été efficaces ou même nécessaires, car ils ne voient pas d’améliorations dans les délais ou la qualité de résolution. L’entreprise ABC a une bonne équipe, ils vont donc probablement regagner leur réputation, le temps de résolution des demandes va un peu diminuer, les utilisateurs vont commencer à oublier cette mauvaise période et les dirigeants pourraient même considérer que les embauches ont servi la performance de l’équipe. Cependant, puisque nous sommes des « étudiants » de l’amélioration, nous ne pouvons pas permettre à l’équipe de se contenter de penser qu’elle n’est « pas aussi en retard que par le passé » ou « pas aussi mauvaise que par le passé ».%%% > %%% > __Définir l’état courant__%%% > %%% > Avant de tenter d’améliorer le processus, nous devons savoir quel est le processus et déterminer comment il fonctionne. Notre objectif initial sera de définir comment le processus du département informatique fonctionne, y compris les étapes qu’il suit pour terminer le travail et surtout quelle est l’unité de ‘travail’ réelle. A ce stade, nous n’essayons pas de comprendre comment résoudre leurs problèmes ou de déterminer où se situe les goulots d’étranglement, nous essayons simplement de décrire et de définir les processus et les tâches. Dès le départ, nous allons donner aux membres de l’équipe un rôle de supervision, ainsi nous nous ferons sûrement une idée précise du processus.%%% > %%% > Après avoir analyser les processus, nous avons constaté que :%%% > L’entreprise ABC accepte des demandes des clients venant de plusieurs origines différentes, email, téléphone, conversations et une application de gestion de tâches sur le web. Une fois ces demandes reçues, trois choses peuvent arriver : soit la demande est saisie dans l’appli. web, soit la personne qui prend l’appel/l’email/etc. traite immédiatement la demande, soit elle est enregistrée de façon temporaire (post-it, liste de choses à faire dans un email client). Lorsqu’une tâche est terminée, il n’y a pas de processus de suivi afin de s’assurer qu’elle répond aux besoins du demandeur et on ne prend pas le temps de créer la tâche dans l’appli. web si cela n’avait pas été fait préalablement.%%% > %%% >  »Tableau visuel 1 »%%% > %%% > Après avoir défini les processus avec l’équipe, nous avons suffisamment d’informations pour partager notre premier tableau visuel. D’après nos observations ci-dessus, nous savons qu’il y a déjà un certain nombre de processus suivis par les gens, nous voulons donc faire aussi simple que possible pour commencer. Notre objectif initial est d’amener les gens à commencer à utiliser ce nouveau processus et qu’ils soient à l’aise avec. Si nous essayons d’élaborer un nouveau processus qui résout tous les problèmes avec de nombreux niveaux de reporting, nous finirons avec quelque chose qui ressemble au système informatique déjà en place et manifestement pas utilisé de façon cohérente. En démarrant simplement, nous pouvons faire évoluer le tableau et le nouveau processus pour mieux répondre aux besoins de l’équipe, plutôt que d’essayer de créer un processus détaillé et « tordre » l’environnement pourqu’il soit conforme au processus.%%% > %%% > Dans l’esprit de garder les choses simples, nous avons bâti ensemble notre premier tableau Kanban en utilisant un tableau blanc, un peu de ruban et quelques post-its.%%% > %%% > ((/dotclear/public/traductions/KanbanPt2_VisBoard_1.png|KanbanPt2 VisBoard 1||KanbanPt2 VisBoard 1))%%% > Premier tableau visuel de l’entreprise ABC complété avec les post-its des tâches actuelles%%% > %%% >  »Note : un autre choix fréquent est d’utiliser des tableaux magnétiques, expérimentez et ne vous enfermez pas dans une seule idée de solution. »%%% > %%% >  »Créer une demande »%%% > %%% > Lorsqu’un membre de l’équipe reçoit une nouvelle demande, il doit remplir un post-it et le placer dans la file d’attente « Travail en attente ». Un exemple est placé sur le tableau, avec plusieurs piles de post-its vides et des fournitures pour écrire. L’exemple comporte des champs pour le nom du demandeur, la date à laquelle la tâche a été reçue, la personne qui a pris la demande et une brève description de la demande ou de la tâche. Nous avons maintenant suffisamment d’informations pour identifier des tâches distinctes sur le tableau, déterminer combien de temps il a fallu pour les terminer, trouver la bonne personne si nous avons des questions au sujet de la demande initiale et communiquer avec l’utilisateur final à propos de sa demande. Le processus de création de la demande doit prendre moins d’une minute et le point d’entrée (post-it) est assez simple pour être rédigé tout en parlant au demandeur.%%% > %%% >  »Traiter une demande »%%% > %%% > Lorsqu’un membre de l’équipe commence à travailler sur une demande, il déplace le post-it correspondant de la colonne « Travail en attente » vers la colonne « Travail en cours ». Chaque membre de l’équipe a son couloir sur le tableau pour organiser les post-its et montrer clairement qui travaille actuellement sur une tâche donnée. Une fois la tâche terminée, elle est déplacée vers la colonne « En attente retour client » pour indiquer que le membre de l’équipe tente de contacter l’utilisateur final afin de s’assurer que celui-ci est satisfait ou pour lui communiquer de nouvelles modifications ou instructions. Une fois que c’est fait, la tâche est déplacée vers la colonne « Terminé ». Lorsque l’utilisateur final est présent lors du traitement de la demande, par exemple lors de l’installation d’un logiciel ou la mise en place d’un projecteur, la tâche peut passer directement de la colonne « Travail en cours » vers la colonne « Terminé ». Quand un membre de l’équipe termine une tâche, il écrit la date de fin sur le post-it de la tâche.%%% > %%% > A partir de là, nous laissons un peu de temps à l’équipe pour s’habituer à ce nouveau processus. Chaque matin, nous vérifions le tableau et l’après-midi nous observons la manière dont l’équipe procède et si quelqu’un a éventuellement besoin d’aide pour utiliser le tableau (ou de façon moins passive, nous circulons pour rappeler aux gens d’utiliser le tableau). A la fin de la semaine, nous récupérons les tâches dans la colonne « Terminé » et nous saisissons les dates de début et de fin dans un tableur. En nettoyant la colonne « Terminé » à intervalles réguliers, nous donnons également à l’équipe une mesure visuelle et même un objectif pour la semaine à venir.%%% > %%% > Un peu plus tard, on peut proposer d’autres idées concernant le moment opportun pour supprimer des tâches de la dernière colonne. Le but est d’obtenir une vision claire à un niveau élevé de la façon dont les choses fonctionnent correctement ou non. Un autre choix serait donc de supprimer chaque jour les tâches qui datent de plus de sept jours, de sorte que la colonne « Terminé » montre la valeur du travail effectué sur la semaine.%%% > %%% > __Modifications du processus et limites de Kanban__%%% > %%% > Après plusieurs semaines d’utilisation du tableau, l’équipe a pu recueillir les réactions des gens et commencer à travailler sur les prochaines étapes. A présent, l’équipe a pris l’habitude de ce processus et doit normalement l’utiliser de manière cohérente. L’équipe a commencé à utiliser le tableau pour rechercher de nouvelles tâches à traiter, répondre à une question d’un utilisateur final sur le statut d’une demande, et les dates de début et de fin vont commencer à donner une image claire des délais de résolution actuels.%%% > %%% > Jusqu’à maintenant, l’objectif a été que l’équipe utilise le tableau et nous n’avons pas mis de limites sur la façon dont les tâches sont sélectionnées, sur le nombre de tâches parallèles sur lequel travaille quelqu’un, etc. Cela a permis à l’équipe de s’engager et de visualiser sa situation actuelle, même si c’est la pagaïe. C’est le bon moment pour commencer à améliorer le tableau et introduire des améliorations au processus.%%% > %%% >  »Revoir les étapes du processus »%%% > %%% > Après avoir parlé à l’équipe et examiné les post-its sur notre tableau actuel, l’équipe a décidé de modifier le tableau en ajoutant un endroit pour les « Tâches escaladées ». Cette modification a été une idée de l’un des membres de l’équipe pour nous aider à mieux suivre les tâches qui ont été escaladées aux Administrateurs systèmes et au Développement afin qu’ils ne prennent pas de place dans la colonne « Travail en cours », nous ne voulions pas les perdre en les sortant complètement du tableau. Pour l’équipe de l’entreprise ABC, cette demande avait du sens, nous l’avons donc ajouter au tableau.%%% > %%% > ((/dotclear/public/traductions/KanbanPt2_VisBoard_2.png|KanbanPt2 VisBoard 2||KanbanPt2 VisBoard 2))%%% >  »Tableau visuel de l’entreprise ABC avec une nouvelle étape d’escalade des tâches »%%% > %%% > Le helpdesk de l’entreprise ABC utilise un tableau qui définit les processus en termes de statut de la tâche. Bien que ce soit une méthode commune, ce n’est pas le seul moyen de prendre en considération les tâches. Vous pouvez essayer d’autres choses qui peuvent correspondre au cycle de vie des tâches à travers les compétences fonctionnelles (développeur, technicien, administrateurs systèmes), les départements ou les phases (analyse, conception, réalisation, qualification, tests utilisateurs, fin). Il y a toutes sortes de départements informatiques organisés de manière différente et ce qui fonctionne pour l’entreprise ABC peut ne peut être la solution pour vous.%%% > %%% >  »Les limites de Kanban »%%% > %%% > L’une des caractéristiques importantes d’un tableau Kanban, c’est l’idée de limiter la quantité de travail en cours dans le processus. Dans un environnement industriel, nous pourrions utiliser les capacités des équipements pour nous aider à calculer des chiffres pour chaque étape du processus, mais dans notre environnement informatique nous n’avons rien d’aussi évident. Nous pourrions passer des semaines à essayer de trouver des équations ou des chiffres parfaits, mais nous allons simplement choisir arbitrairement quelques chiffres fondés sur le nombre de personnes de l’équipe. Si ces chiffres ne fonctionnent pas parfaitement, alors nous pourrons les ajuster un peu plus tard et expérimenter de nouveau pour trouver notre zone de confort.%%% > %%% > Nous allons également attribuer à chaque membre une colonne « principale » où ils ont l’habitude de travailler. Puisque les limites de Kanban imposent un nombre maximal de tâches autorisées dans chaque étape du processus, il y aura des moments où des pans entiers du tableau seront bloqués. Par exemple, si la personne responsable de la colonne « En attente retour client » est surchargée ou en congé maladie, l’ensemble du département sera bloqué parce que la colonne « En attente retour client » est pleine. Lorsque cela arrive, les gens quitteront leur colonne « principale » pour aider à éliminer les goulots d’étranglement.%%% > %%% > ((/dotclear/public/traductions/KanbanPt2_VisBoard_3.png|KanbanPt2 VisBoard 3||KanbanPt2 VisBoard 3))%%% > Tableau visuel de l’entreprise ABC avec des limites définies%%% > %%% >  »Traitement des tâches »%%% > %%% > Le dernier changement sur notre processus concernera la manière de répartir les tâches et la manière dont elles se déplacent à travers le tableau. Jusqu’à présent, nous n’avons pas contraint la manière ou le moment auquel les gens choisiront de travailler sur certaines tâches plutôt que d’autres, ou comment prioriser les nouvelles tâches. Un des concepts importants de Kanban est de tirer les tâches à travers le processus au lieu de les pousser. A chaque étape, les membres de l’équipe choisissent une tâche de l’étape précédente pour travailler dessus et ceci dans les limites imposées par la colonne concernée. Pour permettre d’identifier les tâches qui sont prêtes à être sélectionnées, nous avons ajouté une sous-colonne ombrée à chaque colonne. Pour la colonne « Travail en attente », la sous-colonne ombrée contient les prochaines tâches prioritaires, et pour les autres colonnes il s’agit plutôt d’une sous-colonne « Terminé ».%%% > %%% > Les tâches terminées comptent systématiquement dans les limites affectées à chaque colonne, donc si le processus se détraque alors le flux de tâches va progressivement se transformer en embouteillage. Au fur et à mesure que les membres de l’équipe vont remplir leurs colonnes amont, ils devront basculer sur les colonnes avales pour aider à résoudre le problème. Ceci garantit que lorsque survient une situation complexe, elle est immédiatement traitée au lieu d’autoriser que tout le monde soit mis sur la touche. Cela garantit également que même les pires situations sont traitées d’une manière opportune et que les délais de résolution sont constamment améliorés.%%% > %%% > __Analyse finale__%%% > %%% > L’équipe a un fait un certain nombre de gains grâce à ce nouveau processus, ce qui a également ouvert la porte à l’amélioration continue et au fait de restaurer une bonne image de l’équipe au sein de l’entreprise.%%% > %%% >  »Flux de processus »%%% > %%% > Initialement, les personnes travaillaient sur plusieurs tâches à la fois, diluant leur concentration et perdant à chaque fois du temps quand ils passaient d’une tâche à l’autre. En l’absence de priorisation, il n’y avait aucune garantie sur l’instant où une tâche serait sélectionnée par un membre de l’équipe, les tâches pouvaient même être égarées ou complètement oubliées. La communication à l’utilisateur final était incohérente et les tâches escaladées étaient rarement communiquées ou suivies, les solutions complexes mises en œuvre n’étaient généralement pas expliquées et généraient des tâches supplémentaires à traiter.%%% > %%% > ((/dotclear/public/traductions/KanbanPt2_VisBoard_4.png|KanbanPt2 VisBoard 4||KanbanPt2 VisBoard 4))%%% > Progression dans le temps du tableau visuel de l’entreprise ABC%%% > %%% > Un membre de l’équipe a été affecté à la gestion de la communication avec les utilisateurs finaux. Ce membre de l’équipe est responsable du suivi des demandes avec les utilisateurs finaux, de vérifier le statut des tâches escaladées, de répondre aux demandes de mise à jour des statuts des tâches en attente et d’accompagner les utilisateurs sur des changements ou des solutions complexes. Les nouvelles tâches sont priorisées en fonction du niveau de gravité et de la durée passée dans la file d’attente, elles sont empilées dans une file d’attente dédiée pour que le prochain technicien disponible les traite. Les membres de l’équipe se concentrent sur l’exécution d’une tâche unique à la fois et lorsqu’elle est terminée, ils la transmettent immédiatement à des fins de reporting et sélectionnent la prochaine tâche de plus haute priorité dans la file d’attente. Un calcul statistique de distribution est réalisé chaque semaine pour obtenir le nombre de jours écoulés entre la réception et la résolution des tâches, ce résultat est utilisé comme une métrique par l’équipe et pour les objectifs hebdomadaires.%%% > %%% > L’équipe a réalisé des gains sur leurs tâches en attente avec moins d’interruptions, moins d’allers-retours coûteux entre les tâches, et en étant capable de dédier un membre de l’équipe pour la communication avec les utilisateurs finaux. Les utilisateurs finaux reçoivent des communications plus régulières et les estimations de délais sont à la fois plus constantes et plus précises. Le reporting à la direction indique que le nombre total de tâches en suspens diminue alors que le délai total entre la réception et la résolution des tâches a été réduit en termes de variabilité et de durée.%%% > %%% > __Succès__%%% > %%% > Voici quelques-uns de nos succès :%%% > %%% > – Résultats mesurables : nous avons réduit le délai entre la réception et la résolution des tâches, et pour les prochains mois ce délai va continuer à se raccourcir jusqu’à ce que le backlog ait été traité et que nous ayons trouvons notre nouveau rythme.%%% > – Améliorations mesurables : nous avons non seulement mesuré les résultats, mais nous avons pris une photo avant de changer le processus, ce qui signifie que nous avons maintenant des chiffres précis sur la façon dont nous avons amélioré les choses jusqu’ici.%%% > – Statut en un coup d’œil : le tableau visuel permet d’évaluer rapidement l’état d’avancement du département, les problèmes potentiels, l’ensemble du flux de travail ou le rythme.%%% > – Objectifs du département : des mesures précises sur les délais de résolution servent de bon indicateur clé sur la performance du département et fournissent une excellente mesure pour les objectifs annuels.%%% > – Estimations rigoureuses : davantage de données et un processus lissé ont permis de réduire la variation dans les temps de résolution et d’estimer les tâches de façon beaucoup plus précise.%%% > – Moral : faire participer les membres de l’équipe dans la définition de leur propre processus, essayer des idées qu’ils proposent, leur permettre d’expérimenter participent à l’augmentation du moral et du respect, ce qui augmente à terme la productivité, réduit le turnover et rend l’environnement de travail beaucoup plus agréable.%%% > – Productivité accrue : le travail est maintenant exécuté plus efficacement en raison de la réduction des allers-retours entre les tâches, des recherches d’information, des interruptions pour mise à jour du statut et du manque de priorisation.%%% > %%% > Les avantages décrits ci-dessus sont directement liés à l’application de Kanban dans un environnement général. Dans le cas de l’entreprise ABC, nous pourrions probablement ajouter d’autres gains plus spécifiques à leur environnement, si ce n’était pas une société fictive. Peut-être le plus gros gain est-il que le département fonctionne maintenant à partir d’un tableau blanc. Quelqu’un a récemment déclaré que les tableaux blancs, de par leur nature, invitaient les gens à écrire dessus ou à modifier leur contenu, tandis qu’un papier imprimé invite plutôt à la lecture seule. En quoi est-ce pertinent ? Aucun processus n’est parfait et un processus figé dans la marbre est un processus qui ne se développe pas pour répondre au mieux aux besoins de leur entreprise. En engageant les membres de l’équipe, en expérimentant et en définissant le processus sur un support modifiable, on encourage l’équipe à continuer de faire des suggestions et à continuer à essayer d’améliorer le processus et le département.%%% > %%% > Dans le prochain article, nous explorerons l’utilisation d’un processus Kanban temporaire pour gérer un projet fonctionnel court terme. Alors que Kanban est souvent appliquée aux grands processus comme une ligne de fabrication ou un département entier, il y a des avantages à également l’utiliser pour des projets de petites tailles voire jetables. Dans cette prochaine histoire, nous examinerons l’utilisation d’un tableau kanban pour aider à gérer un projet annuel de réapprovisionnement de PC.%%% ///html

A propos de l’auteur
Eli Weinstock-Herman Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
/// —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Appliquer Kanban aux processus informatiques (1)

J’ai traduit ce billet de __Eli Weinstock-Herman__ : ++[Applying Kanban to IT Processes (Part 1)|http://blogs.lessthandot.com/index.php/ITProfessionals/ITProcesses/applying-kanban-to-it-processes-part-1|en]++.%%% >  »Cet article est le premier d’une suite décrivant les fondamentaux du Kanban et son application dans les processus informatiques. Ici, on donne un aperçu de Kanban et la façon dont il est utilisé dans l’industrie. Les articles qui suivront explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte. »%%% > %%% > Récemment, j’ai vu une augmentation du nombre d’articles dans les communautés de développement et de gestion de projet Agile et qui vantent les mérites de Kanban, en montrant la valeur que Kanban a permis d’apporter lorsqu’il est utilisé avec des méthodes Agile. La plupart de ces articles se concentrent fortement sur l’aspect visualisation (++[Visualiser des projets agile en utilisant des tableaux Kanban|http://www.infoq.com/articles/agile-kanban-boards|en]++ par exemple), certains font même ressortir quelques autres avantages de Kanban, ou se contentent simplement de revendiquer que Kanban est un « marteau d’argent à la recherche d’un clou ». Dans la communauté informatique, il semble que cela soit fortement orienté gestion de projets logiciels et développement, mais Kanban est applicable à de nombreux autres domaines de l’informatique.%%% > %%% > __Qu’est-ce-que Kanban ?__%%% > %%% > Kanban est un terme japonais signifiant « tableau visuel » ou « enseigne » et est un outil pour réduire le temps de cycle$$Temps de cycle : le temps que cela prend de traiter une commande de sa réception à sa livraison$$ d’un processus, permettant d’accroître la visibilité dans le flux des processus et de réduire la quantité de travail en cours$$[Travail] En cours : produits incomplets actuellement en cours de traitement dans le processus ou attendant de (ré-)entrer dans le processus pour être terminé. Travail non fini.$$. En tirant le meilleur parti de cette visibilité, nous pouvons voir où le flux de travail stagne, se bloque en créant des goulots d’étranglement ou en réduisant l’efficacité des étapes amonts. Kanban est utilisé dans le Lean Manufacturing pour disposer d’une meilleure visibilité du processus et de son état d’avancement, pour réduire les gaspillages (et les coûts), et pour aider à atteindre une capacité de production ++[juste-à-temps|http://en.wikipedia.org/wiki/Just-in-time_%28business%29|en]++$$NdT : JIT = Just In Time$$.%%% > %%% > __Le signal Kanban__%%% > %%% > À son stade basique, Kanban est un système de signalisation qui indique aux étapes amonts d’un processus de production qu’il y a une exigence ou une demande client pour faire X.%%% > %%% > ((/dotclear/public/traductions/KanbanSimplePic.png|Kanban Simple Picture||Kanban Simple Picture))%%% > %%% > Dans un processus de fabrication, la commande client est convertie en une ou plusieurs cartes qui représentent les exigences de production permettant de satisfaire la commande. Chaque carte ou symbole définit le produit à fabriquer et la quantité nécessaire. La carte est communiquée au responsable de l’entité concernée qui va répondre à la demande de production. Si ce responsable a un tableau visuel pour afficher la file d’attente des commandes ou la capacité disponible, il placera la carte reçue dans l’emplacement vide suivant, sinon il met à jour le tableau. Selon la complexité du processus, la réception ou l’exécution du signal Kanban pourra déclencher des signaux supplémentaires dans les étapes amonts du processus ou vers le personnel chargé d’amener le matériel nécessaire à la réalisation de l’étape de production. Chaque étape a un nombre limité d’emplacements sur le tableau qui définit le nombre maximum de cartes qui peuvent cohabiter à un point du processus à un instant donné. Cette limite Kanban contraint la quantité de travail et le nombre d’éléments en cours de travail et empêche que le travail non fini ou les demandes s’accumulent.%%% > %%% > ((/dotclear/public/traductions/KanbanCards.png|Kanban Cards||Kanban Cards))%%% > %%% > Limiter la quantité de travail en cours dans le processus à une petite valeur maîtrisable, nous permet de continuer à utiliser pleinement nos ressources (dans ce cas, les machines et les opérateurs), tout en réduisant la quantité de travail partiellement terminé et en attente d’être terminé. L’application de limites Kanban à un processus nous aide à commencer à réduire la variabilité du temps de production d’un produit, ainsi qu’à supprimer la nécessité (et la tentation) de différer la priorité du travail lors de chaque étape. Bien que cela puisse sembler ralentir les temps de réponse lorsqu’une commande prioritaire arrive, cela accélère en réalité son traitement parce que nous n’avons pas besoin de réorganiser nos ressources pour abandonner 47 tâches en suspens partiellement démarrées. Nous positionnons tout simplement la commande prioritaire dans la file d’attente de la dernière étape (si un emplacement est disponible) et nous laissons le signal remonter à travers les étapes précédentes de manière classique. Puisque nous avons déjà une quantité limitée de travail en cours, nous sommes en mesure de traiter de nouvelles demandes rapidement, sans interrompre les items sur lesquels nous nous sommes déjà engagés.%%% > %%% > En supprimant les files d’attente de travaux non terminés et la repriorisation entre chaque étape, nous avons réduit la quantité de non-valeur générée par les opérateurs et amélioré à la fois la précision et (généralement) le délai estimé et communiqué au client. Nous avons également réduit le nombre des changements de priorité parce que nous terminons chaque tâche avant de passer à la suivante, au lieu d’aller et venir entre plusieurs commandes en suspens. La suppression des changements de priorité inutiles constitue une économie immédiate, car ils n’apportent aucune valeur directe au client, la diminution des délais de livraison$$NdT : lead times$$ améliore notre réactivité pour le client final et la diminution des changements de priorité ainsi que du temps consacré au fait de recommencer à travailler sur une tâche$$NdT : rework$$ augmente notre capacité sans coûts additionnels.%%% > %%% > __Visualisation et Métriques__%%% > %%% > Visualiser les demandes à chaque ‘poste de travail’ en utilisant un tableau réel est un bon moyen de communiquer à travers le groupe et de gérer votre Kanban. Si votre tableau n’a que 3 emplacements pour les ‘cartes’ alors vous ne pourrez pas prendre plus de 3 demandes. Les personnes situées aux étapes amonts et avales, peuvent voir les progrès réalisés ainsi que la potentielle capacité excédentaire (rien à faire) à votre étape. Le tableau n’est pas seulement une méthode pour gérer vos tâches, mais aussi un outil de communication instantanée, vous permettant de vous concentrer davantage sur le fait de réaliser votre travail plutôt que de faire du reporting et de mettre à jour les métriques des tableaux de bord.%%% > %%% > ((/dotclear/public/traductions/InitialExampleBoard.png|Initial Example Board||Initial Example Board))%%% > On finit 2 unités/jour, soit environ 14 jours pour traiter une nouvelle commande%%% > %%% > Un autre avantage majeur des méthodes Kanban apparaîtra avec la création initiale du tableau visuel. Outre le fait de définir clairement les opérations ou les étapes de production, les tâches actuelles sur le tableau, les demandes actuelles et les travaux en cours vont commencer à mettre en évidence les goulots d’étranglement. Au fur et à mesure que le temps passe et que le système kanban vous oblige à réduire ce backlog, les goulots d’étranglement vont continuer à devenir de plus en plus évidents, montrant les étapes où des améliorations directes auront un impact sur le délai de livraison pour l’ensemble du processus. Dans de nombreux systèmes, lorsqu’une étape n’a plus rien à traiter dans un système Kanban, les personnes affectées à cette étape remontent à l’étape précédente pour aider à terminer les tâches en suspens. Des règles simples ou une réorganisation de l’équipe actuelle peuvent continuer à donner des gains de performance au fur et à mesure que le tableau nous permet de visualiser et détecter les problèmes de ralentissements, les hoquets de production ainsi que les étapes potentiellement sans travail en cours.%%% > %%% > ((/dotclear/public/traductions/KanbanExampleBoard.png|Kanban Example Board||Kanban Example Board))%%% > On finit 2 unités/jour, soit environ 5 jours pour traiter une nouvelle commande%%% > %%% > La communauté du lean manufacturing a des centaines d’exemples de tableaux visuels, mais j’en profite plutôt pour vous donner ici quelques liens sur des articles concernant le développement logiciel Agile. Les tableaux Kanban ne sont pas coûteux et, à mon avis, devraient toujours commencer par un tableau réel avant d’être enfoui dans une solution logicielle (si vous le faites).%%% > %%% > – Article ++ »Lean Software Development in Small Teams (lien mort) »++ – Tableau blanc et aimants%%% > – Article ++[« Evolution of a Kanban Board »|http://weblogs.asp.net/wallen/archive/2008/10/30/evolution-of-a-kanban-board.aspx|en]++ – Tableau blanc et post-its%%% > – Article ++[« Visualizing Agile Projects with Kanban Boards »|http://drdobbs.com/architecture-and-design/201807863|en]++ – Copieusement illustré et beaucoup d’informations%%% > – Article ++[« The Kanban Story – Kanban Board »|http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html|en]++ – Résultat final (et simple !) pour un exemple concernant le développement logiciel%%% > %%% > Une recherche sur Internet vous donnera de nombreux exemples supplémentaires dans une variété d’environnements.%%% > %%% > __Appliquer Kanban dans un département informatique__%%% > %%% > Maintenant que nous avons une idée sur la manière dont fonctionne Kanban, nous pouvons commencer à explorer comment l’appliquer à des processus informatiques, que ce soit dans des environnements administratif, support et développement logiciel. Initialement l’idée d’appliquer Kanban dans un environnement non industriel peut sembler difficile… les exemples couvriront donc un large éventail de situations possibles. En explorant plusieurs exemples de réalisations, nous pourrons avoir un aperçu ou de nouvelles idées sur la façon d’appliquer ces concepts (et voir les avantages qui en résultent) dans nos environnements informatiques respectifs.%%% ///html

A propos de l’auteur
Eli Weinstock-Herman Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
/// —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Scrum, la 2ème édition du livre de Claude Aubry

La seconde édition du livre « Scrum : Le guide pratique de la méthode agile la plus populaire » de Claude Aubry est annoncée sur ++[Amazon|http://www.amazon.fr/Scrum-pratique-m%C3%A9thode-populaire-%C3%A9dition/dp/2100563203/ref=sr_1_2?ie=UTF8&qid=1309981625&sr=8-2]++ pour __début Septembre 2011__ ! J’ai déjà passé commande, ce sera mon roman de la rentrée :)%%% Pendant ce temps-là, Claude fait des ++[pomodori|http://www.aubryconseil.com/post/Un-pomodoro%2C-des-pomodori]++ en relisant le deuxième jeu d’épreuves ((/dotclear/public/pomodoro.gif|Pomodoro||Pomodoro))%%% %%% Petit montage pour le fun :%%% [((/dotclear/public/lectures/.scrum-claude-aubry-2e-edition_m.jpg|Scrum, la 2e édition – fausse couverture||Scrum, la 2e édition – fausse couverture))|/dotclear/public/lectures/scrum-claude-aubry-2e-edition.jpg]

Kanban pour maîtriser le développement incrémental

((/dotclear/public/photos/.jeff_patton_sq.jpg|Jeff Patton|L|Jeff Patton))J’ai traduit cette présentation de __Jeff Patton__ : ++[Using Kanban Techniques to Control Incremental Development|http://www.agileproductdesign.com/downloads/patton_kanban.ppt|en]++. J’ai ajouté le slide #5 après avoir trouvé et visionné les vidéos du jeu de construction d’avions en papier.%%% %%% Lien : ++[Utilisation des techniques Kanban pour maîtriser le développement incrémental|/dotclear/public/traductions/patton_kanban_FR_anime.pdf]++%%% %%% [((/dotclear/public/traductions/.patton_kanban_FR_couverture_m.jpg|Kanban pour maîtriser le développement incrémental||Kanban pour maîtriser le développement incrémental))|/dotclear/public/traductions/patton_kanban_FR_anime.pdf]%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.