L’deadlock entre les processus Agile et Waterfall a persisté dans gestion de projet discours depuis des décennies. Les équipes de développement de logiciels prospèrent dans les environnements Agile, mais le manque de soutien de la path est l’un des obstacles majeurs à la transformation Agile. Un chef de projet travaillant dans l’industrie du logiciel depuis un sure temps a probablement rencontré une suite C qui veut qu’ils « font Waterfall ». Mais qu’est-ce que cela signifie exactement dans la pratique ?
Pendant des années, des études ont montré une relation constructive entre l’utilisation de Cadres agiles et succès du projet, et il peut être tentant pour un chef de projet de croire qu’il n’a qu’à vendre les résultats d’Agile à ses mandataires sociaux. Mais il est tout aussi essential de comprendre ce que la haute path aime dans le Méthodologie en cascade. Si vous comprenez les garanties financières que Waterfall offre à la suite C, vous pouvez créer un cadre hybride qui comblera le fossé entre Pratiques agiles et entreprise Waterfall une fois pour toutes. Le début de cette compréhension réside dans l’histoire d’origine pour la plupart inédite de Waterfall.
Les origines troubles de la méthodologie Waterfall
La plupart des gens dans la gestion organisationnelle associent le terme « Cascade » au tableau ci-dessous, qui vient de « Gestion du développement de grands systèmes logiciels», un article académique influent écrit par Winston W. Royce, PhD, en 1970. L’illustration de Royce est largement considérée comme la première expression du développement de Waterfall.
L’attribution du développement de Waterfall aux recherches de Royce est l’une des étranges ironies de l’industrie du logiciel. Dans son article, Royce n’utilise jamais le mot « cascade » ni ne le préconise comme un système efficace ; il présente en fait ce qui deviendrait connu sous le nom de Waterfall comme un récit édifiant – un exemple d’un processus qui est « risqué et invite à l’échec » automotive il ne tient pas compte de l’itération nécessaire entre les étapes de développement logiciel.
Royce n’était pas seul : 18 ans plus tard, Barry W. Boehm, PhD (qui deviendra bientôt directeur de DARPA), utilisé un très illustration similaireencore une fois comme exemple d’une problématique cycle de vie du développement logiciel, et a proposé le développement itératif comme different favorable. En 1996, la quasi-totalité de l’industrie du logiciel a adopté un cycle de développement itératif appelé processus unifié rationnel (RUP), qui était lui-même une synthèse des meilleures pratiques universellement reconnues par les ingénieurs logiciels.
Cela soulève une grande query : pourquoi quelqu’un dans la path s’opposerait-il à l’utilisation d’Agile plutôt que de Waterfall, un cadre qui, depuis sa création, a été considéré par les specialists et les professionnels de l’industrie comme étant en contradiction avec des pratiques de développement efficaces ?
OpEx vs CapEx : le cas financier de Waterfall
La raison pour laquelle Waterfall reste en faveur nécessite un peu de connaissances sur une fonction métier à laquelle les équipes de développement pensent rarement : la comptabilité.
Dans la comptabilité en partie double, il existe deux sorts de dépenses : dépenses de fonctionnement et dépenses en capital (aussi communément appelé OpEx et CapEx). Toute dépense réduit les bénéfices nets d’une entreprise, mais une dépense opérationnelle, comme le loyer, la masse salariale ou l’assurance, le réduit plus. L’argent est dépensé, et n’est donc plus dans les livres. Une dépense en capital, telle que l’immobilier, l’équipement d’usine ou le mobilier de bureau, réduit moins les bénéfices en raison d’une method comptable appelée amortissement, qui répartit la dépense sur plusieurs années. De plus, une fois qu’un actif a été acheté, il est considéré comme faisant partie de la valeur nette de l’entreprise.
Entre 2000 et 2002, alors même que le Manifeste Agile se développait – le monde de l’entreprise a été secoué par une paire de scandales comptables majeurs, à commencer par la société énergétique américaine Enron. En termes simples, Enron (avec la complicité présumée du cupboard comptable Arthur Andersen) a dissimulé des pertes importantes aux investisseurs en gérant intentionnellement mal les dépenses d’exploitation et les dépenses en capital. Cela faisait partie d’un stratagème plus vaste visant à gonfler frauduleusement ses bénéfices, et donc à augmenter sa valeur boursière, de milliards de {dollars}.
Peu de temps après, un scandale similaire s’est produit au sein de la société de télécommunications américaine WorldCom. WorldCom a également caché des pertes en catégorisant délibérément à tort les dépenses d’exploitation en tant que dépenses en capital, et la session 2002 du Congrès a réagi en adoptant la Loi Sarbanes-Oxley. Les tendencies de ce projet de loi comprenaient de nouvelles règles qui rendaient les dirigeants de l’entreprise, tels que le PDG et le directeur financier, personnellement responsables des pertes d’actionnaires survenues en raison d’un manque de diligence raisonnable.
En ce qui concerne le développement de logiciels, CapEx contre OpEx est une query particulièrement complexe : les dépenses d’investissement semblent bonnes sur un bilan, ce qui permet aux entreprises de déclarer un meilleur résultat d’exploitation et d’emprunter des montants plus importants. L’inconvénient, cependant, est que les critères de capitalisation ont évolué et nécessitent de la documentation, des examens et des approbations, ce qui peut grandement entraver le processus de développement logiciel.
C’est ici que gestion de projet joue un rôle central. Dans le sillage de cette législation, les directeurs financiers avaient besoin d’un mécanisme de sécurité sur lequel ils pourraient se référer : un type de gestion qui pourrait prouver qu’ils avaient satisfait aux exigences de la loi Sarbanes-Oxley. L’Institut de gestion de projet avait une answer: le processus phase-gate (également appelé stage-gate). Cette method en cascade utilise une série de « portes » – des pauses où l’approbation de la path serait nécessaire pour que le développement progresse. En définissant une étape qui ne contenait que des activités éligibles au CapEx et en l’isolant de toutes les autres étapes, les directeurs financiers pouvaient prouver qu’ils avaient fait preuve de diligence raisonnable lors de l’inscription d’une dépense en tant que dépense en capital.
Avance rapide jusqu’à nos jours, et la gestion par phases est la norme de facto pour les projets de développement dans les entreprises publiques depuis 20 ans – Stage-Gate Worldwide estime que 80% du Fortune 1000 utilise une certaine variation de ce cadre. Pour un développeur Agile ou un chef de projet, cela peut sembler déconcertant. Votre directeur financier ne connaît-il pas les avantages d’Agile ? Ils peuvent ou non, mais dans tous les cas, la selected la plus importante à retenir pour un chef de projet est : ils s’en fichent.
Lorsque le directeur financier veut que vous « fassiez Waterfall », il n’est pas basé sur la conviction que Waterfall est le moyen le plus efficace de fournir des logiciels. Peu leur importe que les programmeurs utilisent RUP, MêléeXP, Cristal, FDD, DSDM, Tableaux Kanban, ou toute autre method de développement ou cadre de gestion ; ce qui les intéresse, c’est de capitaliser le projet sans violer les termes de la loi Sarbanes-Oxley.
La bonne nouvelle est que tout ce que vous devez faire pour garantir au directeur financier que le projet passera un audit se déroule en dehors du processus de développement proprement dit. Si vous pouvez garantir à la suite C que ses besoins seront satisfaits, elle doit se prêter à une méthodologie hybride dans laquelle les préoccupations financières sont gérées by way of Waterfall au stade de la planification et le développement se fait dans un cadre Agile :
Naviguer dans les chutes
Si un chef de projet comprend ce que veut son directeur financier et peut l’assurer de la supervision opérationnelle fournie par un cadre de phase-gate, il n’y a aucune raison d’utiliser Waterfall over Agile dans le développement. Approchez-vous simplement des exigences de la gestion par étapes en sachant que son objectif est financier et juridique et qu’il n’a pas d’affect sur le travail de développement de votre équipe. Voici remark commencer :
Traitez la budgétisation comme itérative… jusqu’à ce qu’elle ne le soit plus
Chaque année, le finances de l’entreprise alloue un montant fixe aux dépenses en immobilisations. Une petite partie de cette somme est allouée aux projets de développement de logiciels, et les cooks d’entreprise négocient pour la plus grande tranche attainable pour leurs projets. Ce processus de négociation se poursuit généralement pendant les deux ou trois premiers mois de l’exercice.
La négociation est extrêmement itératif, donc finances du projet fluctuent constamment tout au lengthy de ce processus. Autonomisez votre sponsor industrial en lui fournissant des estimations ajustables. L’objectif ici est d’établir une enveloppe budgétaire, donc des choices larges pour plusieurs éventualités seront extrêmement utiles. Par exemple, en plus d’une estimation de base, vous pouvez proposer une possibility moins chère qui serait réalisable si les circumstances d’économie sont remplies, comme la migration des données by way of une saisie manuelle, ou une possibility plus chère si des fonctionnalités supplémentaires sont incluses, comme une software cellular. Cela aidera votre sponsor industrial à ajuster sa demande de finances au fur et à mesure que les négociations du comité de trésorerie sont en cours.
Ces estimations doivent être fournies avant les négociations budgétaires, automotive une fois que le comité du Trésor a approuvé les projets pour l’année, il n’y a plus de retour en arrière. Dans le système de porte de part, la porte 3 est l’endroit où le projet reçoit l’approbation du Trésor. La flexibilité dans la budgétisation existe, mais seulement au début du processus, avant que cette porte ne se produise.
Comprendre la matérialité
Votre bureau de contrôle de projet (ou, si vous n’en avez pas, votre contrôleur financier) peut vous aider à comprendre les seuils de l’entreprise pour matérialité— le second où la variation financière est suffisamment importante pour être enregistrée : L’achat d’une boîte de stylos peut être considéré comme immatériel, mais l’achat de nouveaux ordinateurs pour l’équipe ne l’est pas. La ligne où l’immatériel devient matériel varie selon l’entreprise. Comprendre le seuil de votre entreprise et documenter en conséquence vous fera aimer de quiconque prend des décisions comptables.
Partagez vos connaissances du domaine avec votre homologue en finance ; par exemple, comprendre le idea de échanger des histoires d’utilisateurs et parvenir à un consensus sur la façon de gérer la pratique évitera l’apparence d’irrégularité. Assurez-leur que si une dépense supplémentaire résultant d’un échange menace de dépasser le seuil de matérialité, vous l’augmenterez afin qu’elle puisse être correctement documentée.
Parler le langage de la finance
Si vous n’êtes pas déjà familier avec rapports d’état hebdomadaires et les journaux des risques, familiarisez-vous. Lis-les. Les aime. Remplissez-les régulièrement et avec précision. Donnez-les à votre bureau de gestion de projet et ils vous aimeront à leur tour.
Plus essential encore, si vous fournissez des rapports ou des mises à jour sur le finances du projet, assurez-vous que les titres et les descriptions de vos éléments de campagne correspondent exactement à ceux que vous avez utilisés lors de la première approbation du finances. Si le finances approuvé fait référence à « Epic : Authentication UI », c’est ce que vous devez mettre sur votre rapport, et non « Epic Login Display screen » ou toute autre variante. Ignorez ce conseil et vous êtes assuré de créer des frictions et de la frustration dans l’ensemble de la branche financière de l’organisation.
Valeur livrée
Si vous remplissez les circumstances financières ci-dessus, félicitations ! Vous répondez au besoin de la suite C de « faire Waterfall ». Les dépenses en capital sont correctement enregistrées et aucune partie du processus n’a nécessité de changement dans la manière dont le code est réellement écrit ou dont les mises à jour sont livrées. Tous les compromis que vous avez dû faire dans la planification vous ont valu des alliés dans d’autres départements et dans la suite C. Le processus vous a également permis de mieux comprendre remark votre équipe peut travailler avec d’autres events de l’organisation, plutôt que de travailler isolément ou, pire, de travailler en opposition à ceux qui sont censés être de votre côté.
Un Puriste agile pourrait considérer ces préoccupations financières comme des « négociations de contrat ». Cependant, il est tout aussi valable de considérer vos collègues financiers comme des purchasers commerciaux internes. Répondre à leurs besoins en matière de funds n’est qu’une autre forme de collaboration avec les purchasers. Et en Agile, la notion de la valeur délivrée par le consumer l’emporte toujours.
