Get Started for FREE
Sign up with Facebook Sign up with Twitter
I don't have a Facebook or a Twitter account
Tag |
---|
|
Scooped by
Mickael Ruau
onto Devops for Growth |
![]() ![]()
![]()
From
inspearit
Le CMMI permet d'adapter et améliorer ses pratiques pour créer plus de valeur en ligne avec ses objectifs stratégiques et garantir la Qualité
Mickael Ruau's insight:
e modèle CMMI dont les origines datent du milieu des années 1980 a été complètement refondé en 2017 pour mettre l’accent sur la performance des entreprises. Il impose en particulier d’analyser les activités mises en place -et les activités permettant de garantir la qualité comme les autres – à l’aune de la valeur qu’elles créent. Cette création de valeur n’est pas immédiate et absolue. En se basant sur le concept de niveau de maturité, le modèle CMMI organise dans chaque domaine, les pratiques en groupes permettant d’améliorer progressivement la valeur créée. Nous avons illustré dans un précédent article comment s’organise cette création progressive de la valeur. Trois groupes de niveau sont fondamentaux
![]()
From
inspearit
Pour en finir avec le "command and control", le Management 3.0 est un bon outil pour aider les équipes à s'auto-organiser.
Mickael Ruau's insight:
Un exemple d’application Il y a quelque temps, j’ai accompagné des équipes opérationnelles dans l’adoption d’une approche agile et avec leur responsable. Elle est en charge de ces équipes depuis environ six mois, nous avons convenu de travailler de manière ciblée sur la délégation afin que les deux équipes deviennent plus autonomes et qu’elle puisse par conséquent diminuer ses interventions qui, dans certains cas, faisaient d’elle un véritable « goulot d’étranglement ».
Nous avons organisé un atelier par équipe, dans le but de créer pour chacune d’entre elles une première version du tableau de délégation à utiliser ultérieurement pour planifier et réaliser de manière structurée les actions visant à améliorer les niveaux de délégation. J’ai d’abord eu une séance individuelle avec la manager, au cours de laquelle je lui ai demandé de créer et d’alimenter des tableaux de délégation par elle-même, en dressant la carte de ce qu’elle pensait être la situation actuelle de sa délégation aux équipes. Ce tableau de délégation n’a pas été directement proposé aux équipes afin d’évaluer la différence entre sa perception et celle des collaborateurs.
Les deux ateliers ont débuté par une introduction de la manager sur les raisons pour lesquelles elle considérait ce travail important, suivie d’une explication des sept niveaux de délégation et du tableau de délégation. Ensuite, j’ai animé une discussion ouverte sur les niveaux de délégation dans les différents domaines de décision proposés par elle et éventuellement intégrés ou modifiés par les équipes. Dans ces cas, il est possible d’utiliser un jeu appelé « delegation poker », créé par l’équipe de Management 3.0, qui est engageant et amusant, mais dans ce contexte, j’ai considéré qu’une méthode moins structurée était plus efficace.
Pour chaque équipe, nous avons consacré environ deux heures de temps et le résultat a été que, dans les deux cas, le tableau de délégation précédemment compilé par la manager présentait des niveaux de délégation inférieurs à ce que les membres de l’équipe percevaient en réalité. Elle a elle-même admis que la comparaison avait rendu beaucoup plus claires certaines dynamiques de prise de décision dans des domaines opérationnels sur lesquels elle avait une connaissance moins approfondie.
L’activité a permis à chacun de partager sa vision sur la manière dont les responsabilités décisionnelles étaient réparties dans les équipes et de commencer à planifier certains changements en vue d’améliorer la satisfaction client, en éliminant certaines étapes jugées superflues et en prévoyant un soutien pour aider certains des collaborateurs à accroître leur confiance pour intervenir de manière indépendante dans certains domaines. ConclusionLes sept niveaux de délégation, le tableau de délégation et le « délégation poker » ne sont que quelques exemples de la façon dont, avec quelques outils de soutien et peut-être l’aide d’un coach agile, vous pouvez intervenir rapidement pour créer de l’implication sur ces sujets. Dans ce cas nous avons travaillé autour de la délégation. Mais la même méthode pourrait être utilisée sur la motivation, la façon de mener un meeting, le tout avec une forte orientation vers l’action concrète et immédiate.
![]()
From
inspearit
Agilité à l'échelle - Retour d’expérience de la mise en œuvre dans le groupe Orange de mécanismes de type large solution SAFe. ![]()
From
medium
Need this in German? Lesen Sie diesen Artikel auf Deutsch! Need this in French? Lisez cet article en Français! Organization design is hard. Whether you’re the CEO of a global corporation, the founder…
Via Oliver Durrer swissleap.com
![]()
From
inspearit
Vous êtes acteur(trice) du changement au sein de votre organisation, RTE ou coach interne et vous devez organiser votre premier PI planning
![]()
From
www
Dans un tel cas, les conditions techniques et financières associées à chaque nouvelle itération serait fixée par voie contractuelle dans le cadre d’accords opérationnels de type contrats d’application.
Mickael Ruau's insight:
La faculté de sortir du projet de manière anticipée est un des traits distinctifs de la démarche Agile. Le client doit, en effet, pouvoir arrêter le projet quand il le souhaite sans contrainte autre que de rémunérer le prestataire pour les prestations déjà effectuées. Les divers « sprint backlogs » étant envisagés comme des modules fonctionnels autonomes, le client doit en effet pouvoir en conserver l’usage sans qu’il soit nécessaire de repartir de zéro comme c’est souvent le cas dans un projet de type « cascade ». A l’inverse d’un contrat au forfait classique, la faculté de sortie de projet ne sera normalement pas subordonnée au versement d’une indemnité compensatrice par le client. Le risque de non-poursuite du projet aura en effet été appréhendé par le prestataire Agile comme une composante de son offre et intégrée dans sa grille de risque. Ce risque est le corollaire nécessaire de l’absence d’engagement global, en termes de forfait et de délais notamment, sans lequel l’économie d’un contrat Agile pencherait trop fortement en faveur du prestataire [15]. Il importe toutefois de veiller à ce que cette faculté de sortie sans contrepartie ne soit pas requalifiée en condition purement potestative rendant nulle la clause de dénonciation ou de résiliation insérée dans le contrat (article 1174 du Code civil). Ainsi toute clause faisant dépendre de la simple manifestation de volonté du client la poursuite ou non des prestations prévues au projet pourrait encourir un tel grief particulièrement en l’absence de mécanisme de compensation financière au profit du prestataire. Afin de conjurer ce risque, deux méthodes nous paraissent envisageables : (i) faire dépendre la mise en œuvre chaque nouveau « sprint » d’un accord de volonté préalable entre les parties sur le périmètre, les délais ou le prix Dans un tel cas, les conditions techniques et financières associées à chaque nouvelle itération serait fixée par voie contractuelle dans le cadre d’accords opérationnels de type contrats d’application. Le contrat conclu à l’origine se rapprocherait alors fortement d’un contrat cadre renfermant les conditions générales ayant vocation à régir l’ensemble des contrats d’application qui seraient signés dans le cadre du projet.
![]() Le Monde du Droit est le magazine des professions juridiques, toute l\'actualité des professionnels du droit, legalnews, avocats d\'affaires, directeurs juridiques, responsables juridiques, juristes d\'entreprises
Mickael Ruau's insight:
Le projet Agile s’analyse moins en une course de fond épuisante qu’en une succession et la qualité du code de la solution qui deviennent l’étalon-mesure du projet, plutôt que la conformité à un cahier des charges initial vieux de plusieurs mois. Les Méthodes Agiles sont donc pragmatiques, mais elles impliquent une évolution des mentalités et de l’économie du contrat. Cet aggiornamento ne doit donc pas s’arrêter aux seules équipes techniques : le juriste qui encadre le projet, tout comme la Direction Générale qui en décide, doivent être sensibilisés aux Méthodes Agiles, et comprendre que les objectifs (couverture fonctionnelle, sécurité juridique, efficacité économique) peuvent être atteints autrement, à condition de renoncer à certains réflexes. L’aspect protéiforme des Méthodes Agiles permet également aux prestataires informatiques de proposer leur propre « offre Agile » et d’y puiser des avantages concurrentiels. A l’instar des logiciels libres, les Méthodes Agiles sont issues de la pratique, et permettent manifestement de tels gains de valeur qu’elles impliquent désormais une révolution culturelle au sein de l’entreprise. La protection frileuse du code source ou la relation classique « client-prestataire » sont parfois des freins à l’efficacité des projets IT. On constate au contraire que l’innovation, loin d’être menacée par ces nouvelles propositions, est en fait décuplée. Quant au juriste, il relève précisément de son office de s’approprier ces nouveaux concepts pour leur apporter une traduction juridique et contractuelle pertinente. Le contrat ne peut être un monolithe intangible, théâtre du rapport de forces entre le client et son prestataire et checklist des engagements réciproques : il doit aussi s’adapter aux évolutions opérationnelles et accompagner l’émergence de nouveaux concepts pour en assurer l’efficacité. A leur arrivée en France, les licences Open Source avaient défrayé la chronique. On les disait intransposables en droit français, anti-économiques, voire utopistes… On constate aujourd’hui qu’elles se sont multipliées au point d’innerver la plupart des projets informatiques. Plus aucun juriste français ne songe à les combattre, et elles témoignent de ce qu’une autre conception du droit d’auteur est possible et souhaitable. Si le contrat IT leur permet de s’épanouir, peut-être en ira-t-il de même des Méthodes Agiles ?
![]() Ces cinq dernières années ont vu l’inéluctable progression des méthodes Agile au sein des SSII, au prix d’un nouveau chamboulement des modèles de production, pourtant eux-mêmes mis en place avec force et rigueur durant une décennie d’industrialisation de l’ingénierie logicielle. Cette période tendait en effet à apporter la fiabilité, la sureté et la maturité promise par l’industrie logicielle. Par Sébastien Lachèvre, Directeur de projet Banque & Assurance chez Gfi Informatique.
Mickael Ruau's insight:
Ces propriétés de la matière Agile permettent d’élaborer un certain nombre d’outils qui serviront à la construction d’offres de service adaptées aux contextes les plus variés. Nous pouvons présenter quelques-uns de ces outils en les scindant en deux catégories : les outils de forfaitisation et les outils d’engagement. Les outils de forfaitisation • Prix fixé. C’est la clause qui rassurera tous les acheteurs. L’engagement, au travers de l’évaluation de la backlog, est ferme en termes de nombre de points de complexité et donc, par transitivité, en terme de coût ! • Délai fixé. Dans la mesure où le dispositif mis en place est évalué pour permettre de produire un ensemble de points déterminés et que les sprints respectent les boîtes de temps, le délai peut être considéré comme fixe. • Le bonus/malus. Il s’agit d’un système d’évaluation du niveau de la qualité. En évaluant un certain nombre d’indicateurs de qualité, on construit une part de variable sur le coût de développement initial. Les formules et indicateurs pris en compte peuvent varier en fonction des clients et de leur niveau de maturité à les mesurer. Les outils d’engagement sur la valeur produite • Engagement sur la production de 80 % du nombre de points de complexité initialement évalué lors de la constitution de la backlog. L’objectif de la règle est d’induire un certain niveau de variabilité sur le contenu fonctionnel en acceptant que le changement puisse provoquer un écart de plus ou moins 20% par rapport à l’évaluation de départ. En somme il s’agit de partager le risque inhérent à la gestion de spécifications émergentes. • Clause de changement gratuit. C’est le pendant de la règle précédente, l’intégrateur accepte les demandes de changement, propres à la construction de spécifications émergentes. Evidemment ces changements sont conditionnés d’une équivalence de points de complexité entre les demandes sortantes et les demandes entrantes. Mais la variabilité de 20 % induite par la règle précédente permet de s’assurer du risque. • Partage des gains et des pertes. Cette règle, couplée à la première, est attachée à la notion de facturation de la valeur et non de la dépense. Elle se propose de reporter, sur le coût global du projet, l’écart entre la valeur évaluée dans la backlog de départ et la valeur réellement produite. Cela peut être assimilé à la notion de bonus/malus appliqué au périmètre fonctionnel. • Clause Gagnant-Gagnant. Cet outil permet au client d’arrêter le projet après la production d’un sprint, considérant que le logiciel lui suffit en l’état, ou que finalement il n’a plus d’intérêt au regard de l’enjeu de départ. Le fournisseur se trouve dédommagé en touchant 20 % du montant restant à produire. L’objectif est de limiter les risques pour le client, notamment dans le cadre d’une innovation, et de lui permettre de garder la main sur la continuité du dispositif mis en place. Une stratégie portée sur la valeur A partir de ces éléments il est possible de définir un mode de contractualisation prenant en compte le niveau de maturité des acteurs et les risques associés. On le voit, les possibilités sont nombreuses et n’ont pour seule limite que l’imagination des acheteurs et contractants.
![]() Le Tribunal de commerce de Paris a commencé par noter que « les erreurs relevées, les réponses quelquefois tardives, la difficulté de s’accorder sur des prestations qui apparaissent entre les cocontractants ne dérogent pas à la norme de ce type de construction en l’absence de cahier des charges et ne présentent pas de caractère anormal ».
![]() Une discussion récente avec un acheteur d’une grande administration m’a conforté dans l’idée que le contrat au forfait n’est pas un obstacle à l’introduction de l’agilité. Au contraire, l’agilité apparaît comme une voie à suivre pour éviter les difficultés rencontrées dans les contrats actuels.
Mickael Ruau's insight:
Partant de ce principe qu’il est impossible de définir le périmètre fonctionnel à l’avance, le client fournit simplement sa vision du projet dans l’AOA. Le périmètre deviendra la variable d’ajustement. Sélection sur les compétencesLa sélection du fournisseur est faite sur la qualité de la réponse, la pertinence du processus (agile) proposé et sur les compétences de l’équipe pressentie. Le changement par rapport à la pratique d’évaluation actuelle des réponses à appel d’offres est que le prix n’est pas considéré, puisque c’est le client qui le fixe. Le contrat avec le fournisseur est toujours un contrat au forfait, avec prix et date fixés. Mais c’est un contrat au forfait agile (CFA) qui se différencie du contrat classique parce qu’il impose une livraison à la fin de chaque itération et parce que le périmètre fonctionnel, défini initialement dans la vision, est ajustable. Avec un CFA, l’objectif du client n’est plus de reporter les risques sur le fournisseur, il devient de collaborer avec lui pour obtenir le meilleur produit dans le délai défini. Point de vue du clientLes clauses du contrat sont adaptées à l’agilité. Voici quelques exemples de ce qu’il est possible d’y introduire, pour le bénéfice du client :
Point de vue du fournisseurDu point de vue du prestataire titulaire d’un contrat avec un client qui a remporté l’appel d’offres :
Le fait de montrer rapidement au client le résultat des itérations et de l’impliquer dans les réunions de planification favorise sa confiance et le met ainsi dans de meilleures dispositions, l’incitant à s’impliquer davantage.
![]() Table Ronde : Contrat et Agile – De sa rédaction aux contentieuxAnimée par Elisabeth Ducarre, Coach international en organisation Agile & Lean, cette table ronde fera le point sur les Contrats Agiles. Nous accueillerons à cette occasion différents acteurs importants de l’Agile dont 2 avocats spécialisés dans le droit des affaires et ayant rencontré des projets agiles face à la justice. L’idée sera d’en apprendre un peu plus sur les manières d’établir des contrats agiles. Une table ronde terminera la matinée.
“La contractualisation agile, à la Poste, c’est possible ! Saison II – Le contrat en action”, Michel LEJEUNEPetit rappel de la saison I “le contrat type”, avec les mécanismes clefs du contrat open source : http://www.contrat-agile.org/ Pitch : La saison 2 : Il s’agit maintenant d’apprendre à utiliser le « Contrat agile type », beaucoup de Seigneurs du SI sont intéressés, mais ont du mal à accepter leurs nouveaux engagements, ils somment les Agilistes et de leur faire un « modèle de Cahier des charge agile ». Du côté des Fournisseurs, c’est aussi la peur de l’inconnu qui domine et puis finalement… Biographie :
Mickael Ruau's insight:
Contractualisation Agile, contentieux et médiation, Sylvia Israel et Thomas BeaugrandNotre intervention vise à rendre compte de l’expérience d’avocats quant à la contractualisation Agile et aux relations avec les expertises et les contentieux autour de projets informatiques. Elle portera également sur l’intérêt d’intégrer la médiation à la démarche Agile en cas de dérive du projet ou préventivement, l’agilité étant peu adaptée aux règles du contentieux judiciaire classique. Biographie : Thomas Beaugrand est Avocat au Barreau de Paris, associé du Cabinet Staub & Associes. Son activité porte principalement sur le droit de l’informatique et de la communication électronique, le droit de la propriété intellectuelle, la protection des données à caractère personnel, et de manière générale sur le droit des contrats et le contentieux commercial. Il est l’auteur de plusieurs articles juridiques sur l’agilité.
![]() L’externalisation agile s’est fourvoyée dans un type de contrat qui privilégie la posture de contrôle du client lors de l’introduction des rituels Scrum de codage, jusqu’à en perdre l’esprit. Voyons quels sont les freins à desserrer et les idées anciennes auxquelles il convient de renoncer pour réunir les conditions d’une contractualisation agile, collaborative et donc partenariale. Regardons pour cela les liens entre les méthodes de développement et les principales modalités d'externalisation. |
![]()
From
scrumlife
Découvrez les résultats de notre étude 2021 sur les salaires du secteur agile. Êtes-vous payé à votre juste valeur ?
![]()
From
inspearit
On connaît les vertus du management visuel pour les équipes projet. On doit également s'intéresser à son apport pour le top management.
![]()
From
inspearit
La méthode Kanban est formidable car elle est simple à comprendre et à mettre en place. Elle s’adapte à votre contexte.
![]()
From
inspearit
Gouvernance : comment ancrer les pratiques dans une organisation. Le cycle de mise en place de nouvelles pratiques au sein d’une organisation est bien connu ![]()
So, I recently came across an old tweet of Jurgen Appelo, in which he asks: "Apart from Holacracy, the "Spotify model" and Liquid Organization, what other frameworks/models do you know for adaptable org structures?" It made me reflect on all the different "adaptable organizational structures" we've come across over the last years. Here is the (not so exhaustive) list I managed to come up with.... for now.
Via Oliver Durrer swissleap.com
![]() Découvrez comment transformer vos contrats informatiques en contrat agile basé sur la valeur pour favoriser la collaboration avec vos fournisseurs.
Mickael Ruau's insight:
La contractualisation sur la valeurSi agilité et contractualisation ne vont pas naturellement de pair, le contrat demeure l’instrument indispensable de la sécurité juridique des projets.
![]()
From
www
Le développement Agile avec un contrat validé par des avocats paraît impossible. La nature des processus d'achat et de contractualisation s'oppose aux principes Agiles. Voici un retour d'expérience d'un fournisseur coopérant avec un client pour développer un projet ambitieux de façon Agile, en le découpant en petits bouts tout en préparant un contrat basé sur la confiance mutuelle.
Mickael Ruau's insight:
D'après la description de ce projet, nous concluons qu'il est possible de développer un énorme projet en Agile en le découpant en petits morceaux. Cela prend du temps de le définir et de préparer le contrat, mais l'effort est récompensé. En passant beaucoup de temps ensemble au début du projet, nous avons compris nos désirs et besoins réciproques. Cette compréhension mutuelle forgea une confiance partagée avec le bon niveau de coopération, et ceci grâce au temps investi en amont.
![]()
From
www
Comment concilier un développement itératif avec le contrat au forfait ? C'est tout l'enjeu de la formulation contractuelle des méthodes agiles qui repose sur une séparation du cahier des charges et des modalités du contrat. Un tour de force nécessaire pour passer à l'agilité. Et s'accorder entre donneur d'ordre et prestataire sur la facture qui en découle.
![]() Aujourd'hui, presque 20 ans après l’écriture du manifeste agile, 90% des sociétés disent avoir lancé des projets informatiques utilisant les techniques agiles. Les projets agiles sont bâtis sur un paradigme : gérer un périmètre non spécifié au début du projet dans un détail défini et permettre changement et priorisation en cours de projet. Si cette ouverture ravit le métier qui ne sait en général pas tout ce dont il aura finalement besoin, cela semble contraire à l'esprit d'une contractualisatio
Mickael Ruau's insight:
La contractualisation agile doit créer une situation Win-Win Une étude du Standish Group sur la fréquence d'utilisation des fonctions des logiciels met en évidence que seulement 21% des fonctionnalités développées sont vraiment utilisées. Ca vous parait aberrant? Et bien, posez-vous la question de combien de fonctionnalités vous utilisez usuellement dans Excel - Sachant que ce tableur a une profusion de possibilités et d'automatisations possibles... Partant de ce constat, on intègre généralement dans le contrat agile une incitation à finir plus tôt. C'est la notion du "Money for Nothing" qui conduit à l'arrêt des développements dès que le ROI (return on investment - logique de coût/bénéfice) n'est plus suffisant. En bref, en application du principe MoSCoW (Must-Have/Should-Have/Could-Have/Would-Have), dès que les fonctionnalités Must & Shoud Have sont développées, Product-Owner et Stakeholders doivent se demander pragmatiquement ce qui mérite encore que l'on dépense de l'argent dessus. Pour que ce soit incitatif, 20% (classiquement) du budget économisé revient alors au fournisseur en tant que prime de performance. En conclusionVous le voyez, contractualiser l'agile est possible. Le meilleur conseil que l'on puisse vous donner, c'est de ne surtout pas partir sur un contrat "au forfait" et de faire de l'agile en interne.
![]()
From
www
Toute l'info Droit de l'informatique IP/IT/TELECOM avec LexGo en collaboration avec Mr. Alexandre Cruquenaire Avocat
Mickael Ruau's insight:
Comment formaliser la collaboration du client dans un contrat Agile ? La nécessaire collaboration du client doit être effective dès le début du processus Agile. Pour cela, la méthode de pilotage doit être contraignante. Elle doit intégrer des modalités d’exécution du projet spécifiques dans le champ contractuel. Cette formalisation des processus de gestion du projet va permettre de conscientiser le client sur son nécessaire apport à la réussite du projet. Une implication accrue du client est donc requise dans la phase de développement, essentiellement lors des réunions avec l’équipe du prestataire où les décisions seront prises :
Le client doit alors veiller à mettre à disposition du projet suffisamment de ressources. Les clauses fixant des obligations de disponibilités, délais de réaction, etc. sont donc courantes dans la pratique des contrats Agile. Quelles sont les conséquences de l’obligation de collaboration ? Dans cette même optique de responsabiliser les parties sur leur nécessaire implication dans le processus Agile, des clauses de limitation de la responsabilité du prestataire en cas d’absence de collaboration du client nous paraissent essentielles. Si elles sont parfois jugées sévères, elles se justifient totalement. En effet, la commune intention des parties est bien de conduire le projet sur la base d’une méthode collaborative. On ajoutera que la collaboration insuffisante du client peut sans doute être qualifiée de manquement fautif aux obligations contractuelles dans le cadre d’un projet Agile dont ladite collaboration est une pierre angulaire. De son côté, le prestataire sera attentif au fait que l’intensification du devoir de collaboration du client a pour conséquence un alourdissement proportionnel de son devoir de conseil. En effet, plus le client doit s’impliquer et prendre des décisions, plus il doit pouvoir se reposer sur les connaissances et conseils du prestataire pour le faire. On insistera donc sur la nécessité de documenter d’une manière suffisante :
afin de couper court à toute discussion ou contestation sur ces éléments en cas de problème ultérieur. Que faire en l’absence de collaboration du client lors d’un projet Agile ? Pour éviter un blocage lié à un manque de réactivité du client, il peut être tentant de prévoir des mécanismes d’acceptation tacite. Toutefois, une telle solution ne fait que reporter le problème. Le client risque de contester plus tard une décision qu’il n’aurait pas prise. De plus, cela ne correspond pas à l’esprit d’un processus collaboratif. Cependant, des clauses de gouvernance peuvent permettre de clarifier les rôles et les procédures de décision. Elles ménagent des mécanismes qui évitent les blocages tout en stimulant l’implication des parties dans la prise de décision.
![]()
From
www
La notion d’obligation de résultat est incompatible avec l’application des méthodes Agiles : c’est faux !
![]()
From
saat-network
As a customer or supplier of software services at the beginning of an Agile software development project, you know that there is too much at stake […]
Mickael Ruau's insight:
Ten contracts for your next Agile project, by Peter Stevens |
|
Scooped by Mickael Ruau |
La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations. Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système Kanban à produire des métriques permettant une visibilité forte sur la capacité…
La mesure de la prédictibilité par le débit nous offre également une indication assez fiable de la date prévisionnelle d’atterrissage de notre Release.
Le calcul de base est simple et tient compte des éléments suivants :
La formule appliquée est la suivante :
Nous divisons simplement le nombre de Stories restant à réaliser, ainsi que le nombre d’anomalies à corriger, avec une estimation du nombre d’anomalies prévisionnelles que nous serions amenés à avoir et tenant compte du ratio d’anomalies/story terminée.
Le débit est calculé sur une semaine (5 jours ouvrés) et nous fournit donc le nombre de semaines nécessaires afin de réaliser l’ensemble de notre Backlog de Produit.
Jusque là rien de compliqué, sauf que le débit est mesuré sur la capacité d’une équipe sur une période. Qu’en est-il de la fiabilité du débit lorsque cette capacité vient à baisser ou augmenter ?
Afin de pallier ce risque, la charge de l’équipe ayant permis de mesurer le débit, ainsi que la charge de l’équipe sur laquelle doit se baser la prédictibilité doit être prise en compte, ce qui nous donne la formule suivante :
Ou :