Gérer le développement Lean des logiciels avec les diagrammes de flux cumulé
Auteur : David J. Anderson
Source : Managing Lean Software Development with Cumulative Flow Diagrams
Traducteur : Fabrice Aimetti
Date : 17/10/2010
Traduction :
Résumé
Les Diagrammes de Flux Cumulé (CFD) fournissent une méthode pour suivre les progrès des projets agiles, un peu comme les burnups. Parce qu’ils illustrent à la fois le périmètre total et le progrès des Features / Stories / Tâches / Fonctions / Cas d’utilisation, ils communiquent à la fois sur l’état d’avancement total et sur le ratio de complétude totale. Les CFD nous offrent également une méthode simple de suivi du travail en cours (WIP) et illustre visuellement la tendance du Lead Time pour livrer un code opérationnel. Ils fournissent une mesure de premier plan qui permet aux équipes et aux managers de réagir plus tôt aux problèmes croissants qui pourraient apparaître dans le flux entre les exigences et la livraison d’un code opérationnel. Les CFD fournissent une grande transparence sur le cycle de vie complet. Suivre un projet avec un CFD est un élément clé pour évoluer vers un système Lean de développement logiciel.
Introduction
Les méthodes agiles de développement de logiciels tels que Scrum et Feature Driven Development gèrent et mesurent l’avancement du projet d’une manière très différente des chemins critiques en gestion de projet traditionnelle. Scrum a commencé avec l’utilisation d’un burndown qui illustre le nombre estimé d’heures restant pour terminer le backlog du sprint. Plus récemment, les burnups ont gagné en popularité. Ils suivent le nombre de Stories, Tâches ou Features terminées sur le projet par rapport à un objectif de fin prévisionnelle. Il est possible d’extrapoler la courbe avec une ligne de tendance pour estimer la date de fin du projet.
Le concept du burnup a été utilisé en Feature Driven Development depuis sa création dans les années 1990. Cela s’appelle le Graphe des Features Finies, comme le montre la Figure 1.
Figure 1. FDD – Graphe des Features Finies
Toutefois, les burnups ne sont pas vraiment suffisants pour gérer un projet. Ils n’ont aucune notion du travail en cours (WIP) et simuler la date prévisionnelle de fin est problématique. Dans mon livre "Agile Management" (Anderson 2003), j’ai présenté les Diagrammes de Flux Cumulé (CFD) comme de meilleurs outils de visualisation. Cet article explique pourquoi et montre comment utiliser les CFD pour mieux apprécier l’état de santé d’un projet et prévoir ses résultats.
La Courbe en S
L’achèvement des Features tend à suivre un modèle de Courbe en S, comme le montre la Figure 2. L’effet de courbe en S rend difficile la prédiction de la date de fin d’un projet à partir d’un tracé de fonctionnalités terminées.
Figure 2. Courbe en S pour les Features terminées
Bas de la Courbe en S
Il est très difficile de sprinter dès le départ. Il est probablement impossible d’atteindre une production optimale dans le développement logiciel au début d’un projet. Il y a plusieurs raisons à cela : le stock des Features est bloqué en raison d’exigences ambiguës, la formation du personnel, le manque de compréhension du domaine du projet, le travail insuffisant en équipe, les changements de conception, la disponibilité des outils, la disponibilité des environnements, les équipements, le manque d’infrastructures techniques, l’insuffisance d’outils spécifiques au domaine et le niveau de recrutement. Certaines raisons peuvent être éliminées grâce à une meilleure planification, d’autres semblent être endémiques. Elles représentent la spécificité du développement de logiciels.
Formation de l’équipe
Lorsqu’une nouvelle équipe est formée pour un projet, il y a un impact sur la vélocité. C’est propre au métier. L’équipe doit travailler en traversant les phases de forming et storming (Tuckman 1965, Weaver 1997) avant de s’installer dans ses nouvelles habitudes. Au fur et à mesure que les membres l’équipe apprennent à connaître les forces et les faiblesses de chacun d’entre eux, des frictions apparaîtront. Ces frictions auront pour effet de réduire le rendement de l’équipe.
Dysfonctionnement de l’équipe
De temps en temps, une équipe fait preuve de dysfonctionnements. Cela se manifeste par un faible rendement et une courbe plate. Le dysfonctionnement peut entraîner une mauvaise conception ou de mauvaises revues par les pairs, ou même de petites disputes qui vont bloquer le développement. La maîtrise des Diagrammes de Flux Cumulé fournit au manager des informations pouvant montrer les dysfonctionnements d’une équipe, mais seul le manager peut réellement enquêter et découvrir un mauvais comportement. Il est important de comprendre qu’un différend entre deux individus peut pénaliser les performances de l’équipe entière.
Partage des connaissances
Le partage des connaissances est important pour la performance. Une équipe qui fonctionne bien ensemble, partage ses connaissances. Une équipe qui ne fonctionne pas bien et qui ne partage pas beaucoup ne sera pas performante. Il est important de créer un environnement qui encourage les individus à ne pas cacher les informations et à ne pas mesurer et récompenser les individus plutôt que les équipes. Toutefois, je ne traiterai pas ce sujet plus avant dans le présent document. Encourager l’ouverture et le partage des connaissances et mettre en oeuvre des moyens de communiquer la connaissance, comme un serveur de news, ou une base de connaissances sur intranet, permettra d’améliorer la performance de l’équipe.
Outils & Environnements
Si une équipe de développement est prête à démarrer un projet, mais qu’elle n’a pas tous les outils et environnements nécessaires pour progresser alors le rendement en souffrira gravement. Les limites de capacité des ressources de développement doivent être pleinement exploitées. Elles ne doivent pas être ralenties parce que les outils ou les environnements ne sont pas disponibles. Par conséquent, il est important que le manager s’assure que les outils et les environnements soient en place dès le début. Une ligne plate au début d’un projet peut être une forte indication que l’équipe ne dispose pas des outils ou environnements dont elle a besoin.
Ambiguïté dans les Exigences
Les modifications de conception nuiront à tout moment du projet. Quand quelqu’un découvre une exigence qui nécessite la modification d’une interface largement utilisée, l’effet de toute régression dans le système peut causer une chute dramatique de la vélocité. Ce problème est endémique. Il y aura toujours un peu d’incertitude liée à l’analyse et la conception.
Haut de la Courbe en S
Il y a quatre raisons pour lesquelles le rendement a tendance à s’écrouler dans les projets quel que soit la méthode de développement logiciel utilisée : l’augmentation de l’effort d’intégration, la correction des bugs, le stock des besoins bloqué en raison de problèmes non résolus et le refactoring.
Intégration
L’augmentation de l’effort d’intégration est presque inévitable. Au fur et à mesure que le projet grandit, le code d’une nouvelle itération doit être intégré à la grosse base de code existante. Le nombre de problèmes rencontrés pendant le build et les tests d’intégration est susceptible d’augmenter. La seule façon d’éviter cela est de ne jamais travailler sur un gros projet ou un système, même si les effets peuvent être atténués par une bonne architecture à couplage faible. Ainsi, les grands projets, même ceux construits en plus petites itérations, doivent anticiper cet effet et en tenir compte dans la planification du projet.
L’effet de l’augmentation des problèmes dus au build peut être mesuré depuis le début du build jusqu’à ce que le build soit déclaré réussi. C’est le lead time spécifique aux test d’intégration. Le manager peut alors évaluer ce que pourrait être le temps d’arrêt global de l’équipe de développement. Dans les cas extrêmes, tout développement s’arrête jusqu’à ce que la compilation soit déclarée réussie. L’effet sur le rendement de l’équipe peut être calculé. L’évolution du temps de build peut être utilisée pour prédire l’impact futur du build sur la vélocité de l’équipe. Par conséquent, la contribution du build peut être prédite sur le Diagramme de Flux Cumulé.
Il devrait également être possible d’utiliser un outil, tel que Borland Together, pour calculer le degré de couplage dans l’architecture. L’évolution de ce paramètre pourrait être utilisé pour prédire l’augmentation du temps d’intégration.
Bugs
Au fur et à mesure que le projet mûrit et que davantage de code est disponible pour les tests système et produit, le nombre de bugs signalés peut augmenter. Alors que la base de bugs augmente, il y a une tendance à mélanger la correction des bugs avec le codage en cours de nouvelles fonctionnalités pour les clients. Le résultat est que la vitesse globale de l’équipe est maintenue, mais une part croissante de l’effort est consacré à la correction des bugs. Ces corrections de bugs sont liés aux Features déjà en stock et complètement codées, donc il n’y a pas de valeur supplémentaire gagnée sur le Diagramme de Flux Cumulé lorsqu’on travaille dessus.
Pour minimiser l’effet des bugs sur la courbe du code terminé et afin de maintenir la vélocité, il est essentiel de maintenir des standards de haute qualité. Moins de bugs ont un effet positif direct sur le taux de production du système. La courbe en S montre clairement comment et pourquoi des standards de haute qualité peuvent faire qu’un projet aille plus vite.
Problèmes non résolus
Lorsqu’un projet approche de sa fin, le stock des besoins qui a été bloqué en raison de questions en suspens soulevées lors de l’analyse ou de conception, revient dans le chemin critique. Finalement, toutes les fonctionnalités à valeur ajoutée pour le client seront codées, ou alors le client doit accepter de les déclarer hors-périmètre. Si elles sont maintenues dans le périmètre, les problèmes doivent être résolus. Les questions qui restent encore ouvertes à la fin d’un projet, ont pour effet de réduire le nombre de fonctionnalités à valeur ajoutée qui peuvent être terminées. Le résultat est donc que la vitesse de l’équipe ralentit. Certains développeurs peuvent devenir inoccupés, ou de plus en plus d’efforts sont consacrés aux corrections de bugs, puisque le stock des besoins est bloqué.
Pour éviter une baisse de vélocité, il est essentiel de résoudre les problèmes avant que les fonctionnalités à valeur ajoutée pour le client soient sur le chemin critique. Par conséquent, le manager devrait se concentrer sur la résolution rapide et efficace des problèmes. Cela permet de maintenir le débit global du système. Un aplatissement de la courbe est un bon indicateur visuel qui signale que le manager doit redoubler d’efforts pour résoudre les questions en suspens.
Refactoring
Le refactoring aura également un impact sur la vélocité, s’il concerne des Features déjà terminées. Lorsque du code opérationnel fini doit être remanié alors ce n’est pas une nouvelle production. Pour toute fonctionnalité à valeur ajoutée pour le client qui doit être remaniée, le système perd la possibilité d’une nouvelle unité de production. Pour cette raison, je préfère tracer le refactoring comme étant de nouvelles Features baptisées "Matière Noire" qu’on ajoute au stock total sur le Diagramme de Flux Cumulé.
Lorsque le remaniement du code est inévitable en raison d’un changement des conditions du marché qui impose de nouvelles contraintes sur l’architecture du système ou sur du code bâclé qui a limité la capacité de l’équipe à aller jusqu’au bout de l’itération, il est vital de transmettre à la haute direction, le coût réel du refactoring. Le coût réel peut être calculé à partir de la baisse du rendement, l’augmentation du lead time, l’augmentation du WIP sur le stock et l’occasion perdue d’augmenter le débit. Si le bénéfice tiré du refactoring l’emporte financièrement sur le coût, il devrait être réalisé.
Pour avoir un aperçu supplémentaire sur la courbe en S, vous aimerez peut-être aussi lire le livre Tracking Software Process de Betsy Clark (Yourdon 2002). Elle baptise les petits morceaux de fonctionnalités à valeur ajoutée pour le client, des unités de travail et observe qu’elles dessinent une courbe en S.
Ratio de complétude
Pour communiquer une image plus complète de la santé d’un projet, j’ai trouvé nécessaire de compléter le Graphe des Features Finies avec un ratio de complétude et un diagramme. Une courbe de l’évolution du ratio de complétude en FDD donne du crédit aux Features qui sont en cours. Chacune des six étapes pour une Feature est créditée d’un pourcentage de la valeur acquise, comme le montre la Figure 3.
Figure 3. Jalons des Features et pourcentage de valeur acquise
Les graphes de Features Finies ne parviennent pas à communiquer sur le travail en cours, mais le Ratio de complétude et le graphique génèrent un faux reporting. Pourquoi ? Parce que tout développeur agile vous dira qu’ils ne valorisent qu’un logiciel fini. Il n’y a donc pas de valeur pour du code partiellement terminé. Ce résultat est compatible avec le livre "Theory of Constraints management accounting method, Throughput Accounting" (Corbett, 1997). La valeur doit être uniquement reconnue à la livraison.
Par conséquent, il était nécessaire d’arrêter de suivre le ratio de complétude. Suivre uniquement la seule valeur acquise avec des Features terminées ou trouver une meilleure façon de communiquer sur le travail en cours, c’est à dire une méthode qui ne suit pas la valeur du WIP, mais qui communique sur le fait que le travail progresse, même lorsque des Features ne sont pas terminées tous les jours.
Travail en cours
S’il est mauvais de communiquer sur la valeur acquise à partir d’un WIP partiellement terminé, alors devrions-nous ignorer le WIP ? Non, je ne crois pas ! Nous devrions plutôt nous inquiéter plus avant de ce sujet. Pourquoi ?
Le travail en cours peut être considéré comme du stock. Dans ce cas, ce stock est capturé à un certain moment dans un processus de transformations telles que l’analyse, la conception, le plan de test, le code, les tests unitaires et la revue de code (en fonction de la méthode que vous utilisez). En suivant le WIP par une série de transformations, nous pouvons mieux comprendre la santé d’un projet et prévoir son résultat. Ces idées sont développées à partir des travaux de Donald Reinertsen, mais pour le comprendre, nous devons d’abord comprendre la contribution de Marvin Patterson.
Modèle de conception de Patterson
Avec son livre "Accelerating Innovation" (1993), Marvin Patterson a présenté un concept pour la modélisation des processus de conception. Il nous a demandé d’envisager que la conception soit un processus de découverte de l’information. Avant qu’une conception commence, il y a peu ou pas d’information, peut-être même uniquement une vague idée. Au fur et à mesure que la conception émerge peu à peu, il y a de plus en plus d’informations et de moins en moins d’incertitude jusqu’à ce que la conception soit terminée.
Mary Poppendieck (2003) a suggéré que le développement de logiciels puisse être appréhendé avec le même modèle. En d’autres termes, tout développement de logiciel est un problème de conception. Cela nous permettrait de modéliser les flux de valeur grâce à un système de génie logiciel comme la réduction progressive de l’incertitude et la découverte de l’information de plus en plus détaillée jusqu’à ce que soit produit un code opérationnel qui passe des tests de contrôle de qualité appropriés.
La conception est périssable
Dans son livre "Managing the Design Factory" (1997), Donald Reinertsen a développé les idées de Patterson en allant un peu plus loin et en introduisant deux concepts. La première observation est que le stock en cours de conception peut être suivi à l’aide de Diagrammes de Flux Cumulé, comme illustré à la Figure 4. Les CFD étaient déjà en usage dans la Production Lean pour suivre le flux de valeur dans une usine. La seconde et peut-être la plus précieuse vision, c’est que la valeur des informations de conception se déprécie au fil du temps. Il y a plusieurs raisons à cela. La principale est que l’information ne doit être créée qu’une seule fois, que le coût de reproduction est proche de zéro. Si la conception est de l’information, alors le temps qu’il faut à un concurrent pour dupliquer la conception, c’est le délai pendant lequel la conception (et les informations associées) a une valeur de différenciation. L’information sur la conception est également périssable en raison des changements de mode possibles sur le marché, comme les lois, les règlements, les matériaux, les composants fournis, les réseaux de distribution et les modèles métiers. Pour avoir une réelle valeur, une conception doit être appropriée en termes de durée et doit arriver sur le marché dans cette fenêtre d’opportunité. Si le logiciel c’est la conception, alors cela doit également s’appliquer. Les exigences pour un logiciel doivent être périssables. Ainsi, plus les exigences peuvent être rapidement réalisées sous forme d’un code opérationnel mis sur le marché, plus une grande quantité de valeur sera livrée. Les observations de Reinertsen et de Poppendieck ancrent solidement le génie logiciel aux principes du Lean et le lead time permettant de transformer une idée en un logiciel opérationnel doit être essentiel à la réussite financière de toute activité de production logicielle.
Figure 4. Un Diagramme de Flux Cumulé dans le cadre d’un projet FDD
Loi de Little
La Loi de Little stipule qu’une file d’attente de matériaux peut être analysée de deux manières : selon le stock, ou selon le lead time. Il suffit de considérer que la taille du stock est directement proportionnelle au lead time de traitement du stock. Ainsi, la taille du stock en cours de traitement est problématique parce que dans le développement agile nous voulons terminer le logiciel selon des cycles courts et livrer de la valeur aussi souvent que possible. La Figure 5 montre comment lire le stock en cours de traitement (WIP) et les Lead Time à partir d’un CFD.
Figure 5. Lecture du WIP et du Lead Time à partir du CFD à J40 d’un projet
Taille du lot
La Figure 5 montre également comment la taille des lots et les transferts de lots affectent le Diagramme de Flux Cumulé. Les transferts de lots peuvent être clairement vue par la forme hâchée de la courbe. Avec des tailles de lots plus importants, il y a plus de WIP et les lead times sont plus longs. Avec des tailles de lots plus petits comme dans la Figure 6, le WIP est réduit et le lead time tombe en conséquence. Notez le lissage de la courbe sur la Figure 6. Il s’agit d’un véritable projet FDD avec des paquets (petits lots de Features) terminés en moins de 2 semaines. Les lead times peuvent être clairement lus à partir du diagramme.
Il est facile de voir que les CFD peuvent être utilisés pour indiquer en un coup d’œil, la taille des itérations et le type de méthode utilisés pour le développement.
Figure 6. CFD montrant que le lead time baisse suite à la réduction du WIP
Le WIP est une mesure importante
Reinertsen décrit le WIP comme une métrique de premier plan. Ce qu’il veut dire, c’est que le WIP peut prédire à l’avance le lead time et la date de livraison. Il peut donc être utilisé pour corriger les problèmes avant qu’ils ne deviennent trop graves. Si nous attendons trop pour mesurer le lead time ou la date de livraison, nous aurons plus de difficultés à traiter les nombreux problèmes. Une fois, j’ai eu un projet dont l’état d’avancement a été estimé à 53% après 8 semaines, mais seulement 4 Features étaient terminées. Un CFD de ce projet aurait attiré mon attention, en tant que manager, beaucoup plus tôt. Non seulement le CFD m’aurait averti, mais cela m’aurait également orienté vers la cause du problème. Le reste de cet article explique comment utiliser les CFD, pour diagnostiquer les problèmes de santé d’un projet.
Dérive du Périmètre et Matière Noire
J’aime faire la distinction entre deux types de changements dans la globalité du stock de Features pour un projet. La première représente l’évolution des besoins ou de nouvelles demandes de la part du client. Ceci est souvent appelé la dérive du périmètre. Ce sont de nouvelles Features qui n’étaient pas dans le périmètre lorsque le projet a démarré. Cependant, il y a un deuxième type de nouvelle Feature qui doit être connu. Ce sont des Features qui émergent au cours du projet, au fur et à mesure que l’analyse gagne en profondeur et que la conception avance et que l’équipe obtient une image plus complète du travail à réaliser. J’appelle ces Features émergentes, la matière noire, parce qu’elles ont toujours été là, mais jusqu’à ce moment-là, l’équipe ne pouvait pas les voir. Ainsi, la matière noire est une réflexion sur l’incertitude dans la phase d’analyse initiale. Plus un domaine est inconnu de l’équipe impliquée, plus il est probable qu’ils ont manqué quelque chose. Par conséquent, il y aura plus de matière noire sur des projets avec une plus grande incertitude en raison du manque de connaissance du domaine. Lorsque vos experts ne sont pas aussi experts que vous souhaitiez qu’ils soient, la matière noire sera plus importante. La Figure 7 montre comment tracer le périmètre initial, la matière noire et les nouvelles Features. Ces données sont tirées du même projet FDD que la Figure 6.
Figure 7. Périmètre avec matière noire et nouvelles fonctionnalités
Incertitude sur le Périmètre
Pour comprendre la valeur de ce graphique, nous devons d’abord comprendre la notion d’incertitude sur le périmètre. Lorsque la liste des features est établie au début du projet, l’équipe est invitée à deviner si elle est bien certaine d’avoir identifiée toutes les Features. Dans le cas particulier illustré, l’équipe a utilisé une technique baptisée "Yesterday’s Weather" et avec laquelle elle a réfléchi sur la matière noire qui a émergé lors de l’itération précédente. Cela a été utilisé en s’appuyant sur l’expérience et l’équipe est tombée d’accord sur le fait que le périmètre total était maintenant probablement de 220 Features alors que le périmètre initial était de 185 Features. Par conséquent, l’équipe s’attendait à une matière noire de 35 Features. L’incertitude sur le périmètre était donc de 35. Le calendrier du projet a alors été refait en se basant sur un échantillonnage de la vélocité et multiplié par 220. Cela a donné une date de fin au 22 Mars.
Graphique de Suivi du Périmètre
Pour suivre le périmètre quotidiennement, un graphique de suivi du périmètre peut être créé comme illustré à la Figure 8. L’idée est que si le périmètre tombe en-dessous de 170 alors l’équipe tolère une évolution du périmètre dans la release. Toutefois, si le périmètre dépasse 220, il est probable que le projet sera en retard, à moins que la vélocité devienne plus grande que prévu. La vélocité peut être lu sur la CFD et la limite de suivi peut donc être réajusté si nécessaire.
Figure 8. Graphique de Suivi du Périmètre
Maintenant, considérons ce qui s’est réellement passé sur le projet. Initialement, la portée totale tombe. Cela est dû à des Features reportées à une version ultérieure lorsqu’il est apparu que le client n’en avait pas vraiment besoin. Ensuite, l’effet matière noire commence à entrer en action et le stock augmente un peu. Ensuite, quelques features sont reportées à une version ultérieure, car une fois de plus, le client n’en a pas vraiment besoin. Vers le 8 Mars, le client soumet une demande d’évolution. Cela provoque une augmentation du stock, mais l’équipe l’accepte parce qu’elle croit qu’elle est en voie d’atteindre la date de livraison. Toutefois, la matière noire continue de croître jusqu’à la mi-Mars et le 16 Mars le périmètre total passe à travers la limite de contrôle. Le projet va être en retard. À ce stade, le manager doit intervenir.
Il s’avère que la demande d’évolution n’est pas requise pour la livraison du 22 Mars mais pour celle du 14 avril (et même plus tard, elle a été repoussée à la mi-été). Donc, la demande d’évolution est sortie du périmètre et le projet revient sur les rails. Un accord a été trouvé pour réaliser la demande d’évolution et la livrer spécifiquement avant le 14 avril. En fait, ça n’est jamais arrivé. Cela souligne clairement la valeur de l’approche agile et la visibilité apportée par cette approche, facilitée par l’utilisation de CFD.
Incertitude sur les Exigences
Comme illustré à la figure 9, où il y a un écart croissant entre les Features commencées mais pas entrées en conception, cela indique une incertitude dans les exigences. Cela devrait normalement ressortir par de nombreuses questions demandant des éclaircissements sur les exigences. Avec des Features bloquées en raison d’informations insuffisantes ou ambiguës, ou un manque de cohérence interne dans les exigences, l’équipe de développement va commencer davantage de Features avec l’espoir de réaliser des progrès avec ces dernières tandis que les autres sont bloquées. Le WIP total va donc augmenter.
Sans un expert compétent sur le site du client, il peut ne pas être possible d’obtenir des réponses instantanées. Le client peut même ne pas connaître la réponse correcte ou l’analyste métier ou le chef produit ne sont peut être pas habilités à fournir une réponse complète. Malgré tout, le Diagramme de Flux Cumulé révèle le symptôme et la cause racine doit être cachée dans la liste des problèmes.
Figure 9. Écart croissant entre le Début et la Conception
Problèmes de conception ou d’architecture
La figure 10 montre un écart croissant entre la conception et le codage. La cause de cela ne peut être déterminée à partir de la courbe seule, mais elle fournit un avertissement qui devrait inciter le manager à enquêter.
Mauvaise conception
La première possibilité est la mauvaise qualité de la conception ou un conception impossible à réaliser. L’équipe déclare la conception terminée et la courbe est mise à jour, mais quand l’équipe commence à coder la conception, elle découvre qu’elle n’y a pas suffisamment bien réfléchi. Cela signifie que le travail de conception réelle va se faire pendant le codage. Ainsi, la courbe est fausse et ne reflète pas l’état réel d’avancement. Un manager pourrait choisir de résoudre ce problème de deux façons : envoyer l’équipe en formation pour une meilleure conception Orientée Objet, ou tout simplement changer la méthode de reporting afin de ne pas tenir compte de la conception. Ma préférence personnelle va à la première. Je crois qu’une bonne conception améliore la productivité.
Figure 10. Écart croissant entre la Conception et le Codage
Problèmes de développement Une autre raison qui expliquerait l’écart entre la conception et le codage est le manque de connaissance du langage de développement ou des APIs utilisées. Si une nouvelle technologie est utilisée pour la première fois, l’équipe a peut être du mal à l’apprendre.
Sinon, il pourrait aussi y avoir des problèmes d’environnement ou d’outils. Il n est pas rare de commencer un projet avec une licence temporaire pour un outil, une plateforme ou un environnement en attendant que les achats passent l’ordre d’achat de la licence complète. J’ai aussi vu des cas où un nouveau projet poussait à bout l’environnement de gestion de configuration et exigeait un nouveau matériel ou un rebuild ou une reconfiguration. Cela prend aux outils ou à l’équipe de support un certain temps et peut entraver le gros de l’effort de développement.
Refactoring
La présence officieuse de refactoring peut être une autre raison pour expliquer un écart de plus en plus grand entre la conception et le codage. Il peut s’avérer que les dernières conceptions nécessitent des changements dans le code écrit plus tôt dans le projet. Ce remaniement du code ne serait pas considéré comme de la matière noire, sauf si l’équipe est très honnête à ce sujet. Dans un cas extrême, il se pourrait que l’architecture du système soit invalidée par la dernière conception des Features et que tout le système soit en cours de réécriture. Cela s’illustrerait par un grand écart ou une sévère descente de la courbe de codage sur le CFD.
Références
- Blog de David J. Anderson
- (Anderson 2003) Anderson, David J., "Agile Management for Software Engineering Applying the Theory of Constraints for Business Results", Prentice Hall, Upper Saddle River, NJ 2003
- (Corbett 1997) Corbett, Thomas, "Throughput Accounting", North River Press, Great Barrington, MA 1997
- (Patterson 1993) Patterson, Marvin, "Accelerating Innovation", Van Nostrand Reinhold, New York, NY 1993
- (Poppendieck 2003) Poppendieck, Mary and Tom Poppendieck, "Lean Software Development, an agile toolkit", Addison Wesley, New York, NY 2003
- (Reinertsen 1997) Reinertsen, Donald G., "Managing the Design Factory, A Product Developers Toolkit", Free Press, New York, NY 1997
- (Tuckman 1965) Tuckman, Bruce W., "Development Sequence in Small Groups", Psychological Bulletin, 63(6)
- (Weaver 1997) Weaver, Richard G. and John D. Farrell, "Managers as Facilitators, a Practical Guide to Getting Work Done in a Changing Workplace", Berrett & Koehler, San Francisco, CA, 1997
- (Yourdon 2002) International Function Point User Group, "IT Measurement Practical Advice from the Experts", Foreword by Ed Yourdon, Addison Wesley, New York, NY, 2002
