Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).
Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets
Le manque de transparence cause des malentendus et des conflits.
Cependant, générer de la transparence a un coût.
Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.
Plusieurs des techniques les plus communes pour générer de la transparence
#1 – Le Contrat
Spécifiez ce qui peut et doit être partagé dans le contrat. Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre. Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu). Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.
#2 – Un Plan construit conjointement
Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres. La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur des risques et communiquer les dépendances en temps réel.
Matchware est partenaire de DantotsuPM
#3 – Des Cérémonies communes
Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies). Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives. Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.
#4 – Des Ateliers de mûrissement des exigences et de design
Collecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.
#5 – Des Modèles de design
L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.
Facile ET difficile à la fois
une plus grande transparence comme base de relations et de travail
Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.
partagez ce billet avec vos amis, collègues et relations professionnelles
– Les Scrum Masters avec une formation formelle Scrum et des certifications Agile ont des salaires plus élevés que les autres.
– Les tendances d’adoption montrent que 7 % continuent à utiliser l’approche Waterfall tandis que 11 % sont matures dans leur adoption Agile; les participants restants (donc la très large majorité) commencent ou sont en croissance d’usage.
– Les salaires des femmes Scrum Masters tendent à être plus élevés que ceux de leurs contreparties masculines.
“Le but de ce rapport est defournir de l’information aux Scrum Masters qui les aidera à en apprendre davantage sur le Scrum Master et les tendances des communauté Agiles. Scrum.org s’est associé avec Age of Product dans cette initiative pour fournir à la communauté des Scrum Masters des données pour partager une compréhension qui les aidera à diriger leurs carrières et continuer de s’améliorer.”
Vidéo de 1 heure en anglais qui détaille les résultats de cette enquête.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Maintenant que le mouvement Agile s’est étendu à de plus grandes organisations dans davantage d’industries, nous voyons énormément de variation. Accordé, nous utilisons une grande variété de structures, techniques et méthodes utilisées, de XP à Scrum à Kanban à la Livraison Continue. Cependant, récemment nous entendons de plus en plus parler d’approches « Hybrides ».
Peut-être avez-vous entendu un dirigeant dire : “Nous ne sommes pas encore Agile, mais nous utilisons une approche hybride”.
Ou peut-être vous avez entendu un consultant déclarer fièrement “À moins que vous ne fassiez beaucoup de prototypage, vous êtes seulement Agile Hybride”. Et ensuite, lors d’une rencontre vous entendez une autre personne dire, “Oh, nous ne sommes pas hybrides, nous utilisons une approche mélangée”.
A travers toutes ces discussions, ce que les gens veulent dire en réalité peut devenir assez confus. Ceux parmi nous qui travaillent sur le prochain Guide de Pratique Agile ont aussi entendu ces points de vue et nous ajoutons qu’une section au guide concentrée sur ce sujet. Voici certains des modèles initiaux que nous voyons…
« Itératif » par rapport à « Incrémental » par rapport à « Agile »
Les cycles de vie des projets suivent un continuum, de prévisionnel (« plan driven ») à Agile. Pour nous aider à comprendre ce continuum, considérons deux des aspects clés de l’Agilité que sont “Livrer Tôt et Souvent” et “S’adapter au Changement”. Si nous devions les tracer sur un graphique bidimensionnel, nous obtiendrions quelque chose comme cela …
Sur le continuum d’approches, depuis prédictives (en bas à gauche) à Agiles (en haut à droite), il y a différents degrés de livraison (incrémentale) et degrés de changement (itératif). Les techniques qui réalisent à la fois de forts niveaux de livraison et de hauts degrés d’adaptabilité sont appelées « Agiles ».
« Mélangé » (Blended) versus « Hybride »
Mais c’est juste trop simpliste. Dans le monde réel, nous n’utilisons pas juste une approche. Nous combinons presque toujours plusieurs techniques différentes. Pour nous aider à comprendre les différentes combinaisons, nous avons posé quelques définitions de travail.
Mélangé Agile (« Blended Agile ») est la combinaison de deux ou plus des méthodes établies, techniques, ou structures Agiles.
En ajoutant un peu de Kanban et des limites de travail en cours (« Work In Progress ») à vos Sprints Scrum, vous obtenez une approche « Mélangée ». Ou peut-être voulez-vous « mélanger » un tableau de visualisation (« Information Radiator ») avec votre approche de livraison en continu. Pour beaucoup de praticiens Agiles, c’est facile à comprendre.
Nous combinons des techniques adaptatives-agressives connues pour être meilleurs dans ce que nous faisons :
Mélangé = Agile + Agile = Meilleur Agile
Mais en ce qui concerne le reste d’entre nous simples mortels ?
Et si nous ne sommes pas encore capables d’utiliser ces diverses techniques?
Et s’il y a contraintes ou demandes qui exigent que quelques éléments non-agiles se produisent ?
Et bien, dans ces cas, vous devriez considérer « l’Hybride »
L’Hybride Agile est la combinaison de méthodes Agiles avec d’autres techniques non-agiles.
Par exemple, un effort important pour détailler les exigences, suivi de sprints de livraison progressive serait une “Approche Hybride”. De même, le prototypage itératif fréquent d’un design, suivi d’une mise en œuvre prédictive avec un plan simple serait “une Approche Hybride”.
Ici, l’idée est de prendre une approche non-Agile et d’y injecter quelques techniques Agiles pour aborder une question ou une opportunité spécifique:
L’hybride = non-Agile + Agile = quelque chose entre les 2 qui a du sens
Quand devrions-nous utiliser des approches Hybrides ?
Comme toute autre chose dans le monde, il y a une bonne et une mauvaise raison de faire quelque chose. Pour être clair, la mauvaise raison de mélanger des techniques est de vouloir faire comme les autres. “Utiliser des techniques Agiles” n’est pas le but. Le but est de livrer le bon résultat business en utilisant les bonnes techniques.
Voici deux scénarios :
1. Hybride comme Adéquat en fonction du but
Pour les projets qui ont un profil de risque inférieur, utilise des approches prédictives pour minimiser les dépenses. Pour des projets de risque plus élevés, utilisez des techniques Itératives pour répéter des activités jusqu’à ce que les problèmes se révèlent et soient résolus. Pour des projets ayant besoin de livraisons agressives, des techniques Progressives livreront quelque chose plus tôt et assureront l’engagement du client. Finalement, pour naviguer dans des environnements complexes, des techniques Agiles peuvent avoir un fort coût initial aérien, mais pourraient le valoir pour les résultats d’ensemble. Chacune a sa propre force. Le mélange de celles-ci de la bonne façon peut mieux répondre à votre contexte que l’utilisation de seulement une d’entre elles.
2. Hybride comme Transition-vers-Agile
Beaucoup d’équipes ne sont pas capables de basculer vers les façons de travailler en mode Agile d’un jour à l’autre. Plus l’organisation est grande, plus ses composantes sont en mouvement, plus longtemps il faudra pour changer. Si vous avez vécu dans un monde prédictif depuis de nombreuses années, les méthodes Agiles paraitront très différentes. En conséquence, votre incursion initiale dans le monde Agile sera un amalgame peu ordonné des deux. C’est OK. Vous utilisez des techniques spécifiques pour vous déplacer dans la direction vers laquelle vous voulez aller.
Chaque projet a des besoins différents. Pour ceux qui se trouvent dans un environnement surtout prédictif, une approche hybride peut être une transition vers davantage d’adaptabilité et de livraisons. Pour ceux qui ont déjà adopté la livraison et l’adaptation agressives, incorporer quelques nouvelles techniques peut encore hausser votre challenge.
CertYou est partenaire de DantotsuPM
Ne déclarez pas simplement “Nous sommes Agiles”, la réalité est que vous utilisez déjà presque toujours une combinaison de techniques différentes. Au lieu de cela, une meilleure stratégie serait de vous poser et de réfléchir à quelles approches seraient les meilleures pour ce que vous voulez réaliser en fonction de là où vous êtes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Curieusement, l’auteur reste très dichotomique et ne considère pas dans ce billet une approche hybride entre les deux mondes adaptatif et prédictif mais son retour sur la genèse de la méthode Waterfall me parait intéressant à partager avec vous.
What Does ‘Waterfall’ Really Mean? How Do People Use That Word?
Y avez-vous jamais réfléchi ? Cette expression est souvent utilisée en comparaison de ‘Agile’ mais les gens savent-ils ce qu’ils font quand ils comparent ‘Agile’ à ‘en cascade’ ? Je pense que le mot ‘Waterfall’ est un des mots les plus abusés dans la langue anglaise (et le mot ‘Agile’ n’arrive pas loin derrière).
Quand les gens parlent de ‘Agile’ et ‘en cascade’, il semble qu’ils comparent deux méthodologies très spécifiques et bien définies qui sont les opposés binaires et mutuellement exclusifs l’un de l’autre. Cependant, quand vous fouillez dans ce que signifient vraiment les mots ‘Waterfall’ et ’Agile’, vous découvrez vite que c’est une comparaison très imprécise et prône à erreurs.
Que signifie vraiment ‘en cascade’ dans le management de projet ?
À proprement parler, le mot ‘ Waterfall ‘ a été à l’origine défini en 1970 par docteur Winston Royce dans son papier très célèbre :
Il a décrit un modèle qui consiste en ordonnancer un projet en phases où les livrables d’une phase coulent dans la phase suivante et qui donne quelque chose comme ceci :
Il l’a appelé ‘en cascade’ parce que les résultats d’une phase s’écoulent naturellement dans la phase suivante comme l’eau dans une ‘cascade’.
A quoi ressemblait la Vie avant ‘en cascade’ ?
Pour mieux comprendre, il est utile de voir à quoi ressemblait la vie avant ‘en cascade’ et quels problèmes cette méthode essayait de résoudre. Ce qui a précédé ‘en cascade’ était beaucoup d’efforts de développement mal organisés avec peu ou pas de structure, discipline et planification. Certains des problèmes principaux avec ces approches étaient :
Comme les projets grossissaient en termes de portée et de complexité avec de plus grands nombres de développeurs, il est vite devenu apparent qu’une approche plus planifiée et structurée était essentielle pour coordonner le travail de grosses équipes de développement
L’autre problème principal était une prévisibilité très limitée tant sur les dépenses que les délais des projets de développement informatique. Il y avait de fréquents en très importants dépassements de coûts et de délais et les commanditaires ont exigé un certain niveau de prévisibilité.
Pour ces raisons, quand l’approche ‘en cascade’ a été définie à l’origine, c’était une grande amélioration que de passer de pratiquement aucune méthodologie du tout à un processus très bien défini :
“Un plan d’ensemble” pour coordonner le travail de multiples développeurs ainsi que l’intégration de leur travail avec d’autres ressources essentielles en dehors des immédiates équipes de développement
Un mécanisme pour gagner un certain niveau de contrôle de la portée du logiciel (de son contenu ou périmètre) pour obtenir plus de prévisibilité des dépenses et des délais.
Beaucoup de personnes plus jeunes n’apprécient pas aujourd’hui cette historique et critiquent juste la méthode ‘en cascade’ comme étant mauvaise sans comprendre les problèmes qu’elle a été créée pour adresser.
relisez ce billet sur les bénéfices de ‘en cascade’
Quels étaient certains des problèmes avec l’approche de originale ‘en cascade’ ?
Comme dans beaucoup de choses, il y a un effet de « balancier » et, quand l’approche a été initialement mise en œuvre, il y avait le sorte d’une sur-correction dans de nombreux cas. Le balancier est passé dans beaucoup de projets de presque aucun contrôle ni discipline à un contrôle très rigide et très rigoureux. La pratique commune quand le processus ‘en cascade’ a été défini à l’origine en 1970 était un processus de documentation très intensif et un sur-contrôle où vous ne pouviez pas quitter une phase tant que toute la documentation exigée pour prouver que tout le travail demandé pour cette phase avait été achevé, passé en revue et approuvé.
C’était un processus très pénible et qui avait un certain nombre de problèmes que même le Dr. Royce a reconnus en 1970 quand il a défini le processus. Certains des problèmes les plus sérieux étaient :
L’utilisateur final du logiciel ne voyait pas normalement aucun logiciel avant que tout le développement et les tests ne soient complets et à ce moment-là, il était très difficile, sinon impossible, d’apporter quelques changements significatifs.
L’accent sur le contrôle du contenu rendait le processus très inflexible et résistant aux changements qui pourraient être nécessaires pour répondre aux besoins des utilisateurs et des objectifs business dans un environnement incertain.
En conséquence, il y a eu beaucoup de situations où le projet peut avoir respecté le coût et les délais, mais échoué à fournir un niveau suffisant de valeur business.
Un autre problème principal était que le lourd accent sur la documentation exigée pour les revues et les approbations rendait le processus tout entier bureaucratique et pas très efficace côté coûts.
Comment ‘en cascade’ s’est-elle développée pour Résoudre Ces Problèmes ?
Avant que Agile ne se répande, beaucoup de variations sur le modèle original ‘en cascade’ et d’autres modèles plus itératifs ont été développées et utilisées pour créer une approche plus adaptative et résoudre certains de ces problèmes. Un exemple était le Processus Unifié Rationnel (Rational Unified Process RUP) dont les origines peuvent être retracées jusqu’en 1996 et 1997. RUP a proposé une approche de développement itérative pour résoudre certains des problèmes de l’approche ‘en cascade’. RUP et les variations de RUP comme Enterprise Unified Process (EUP) sont devenus très populaires à la fin des années 1990 et au début d’années 2000.
En conséquence, si vous regardez ce que les gens ont fait en pratique pendant les 15 à 20 dernières années, il y a eu prolifération d’une large gamme de beaucoup de modèles différents (dont certains ont une ressemblance très limitée au modèle original ‘ Waterfall ‘ défini en 1970). Les gens les caractérisent toujours tous de ‘en cascade’ comme si c’était une méthodologie spécifique, unique et bien définie appelée ‘en cascade’ et ce n’est pas vraiment le cas. De la façon dont le mot ‘Waterfall’ est utilisé en pratique, il se réfère en réalité à une large gamme de méthodologies différentes.
Quelle est une façon plus précise de décrire ‘Agile’ versus ‘En cascade’ ?
Le dénominateur commun de toutes les méthodologies que les gens appellent ‘en cascade’ est qu’ils soulignent un certain niveau de planification en amont et de contrôle pour essayer de réaliser la prévisibilité sur le contenu du projet, des dépenses et des échéances. C’est pourquoi, je pense que « dirigé par un plan » est une description plus précise et objective de ce que les gens veulent vraiment dire quand ils disent ‘en cascade’.
Le mot ‘Agile’ est aussi utilisé de manière floue. Nous savons tous que ‘Agile’ n’est pas une méthodologie spécifique bien que beaucoup de personnes assimilent ‘Agile’ avec Scrum :
Scrum n’est pas vraiment une méthodologie spécifique, c’est vraiment une structure destinée à être adaptable à une large gamme de situations
Agile n’est pas vraiment l’équivalent de Scrum. Il y a d’autres méthodologies Agile comme Kanban
Il est assez facile de voir que le mot ‘Agile’ est aussi utilisé très largement pour qualifier une méthodologie spécifique et bien définie quand ce n’est pas le cas. Le dénominateur commun des méthodologies que les gens appellent ‘Agile’ consiste en ce qu’elles sont flexibles et adaptatives et soulignent la créativité et l’innovation dans un environnement incertain plutôt que la planification et le contrôle pour une prévisibilité avec des niveaux moindres de certitude. C’est pourquoi, je préfère utiliser le mot « adaptatif » au lieu du mot ‘Agile’ lors de la comparaison avec ‘en cascade’ (dirigé par un plan).
Pourquoi comparer « Dirigé par un plan » et « Adaptatif » est-il plus précis et objectif ?
Voici pourquoi je préfère utiliser une comparaison entre « Adaptatif » et « Dirigé par un plan » plutôt que ‘Agile’ versus ‘en cascade’ :
C’est plus précis
« Dirigé par un plan » n’implique pas de méthodologie spécifique. C’est une caractéristique d’une large gamme de méthodologies ce qui je pense décrit plus exactement ce dont parlent les gens.
C’est plus objectif
Le mot ‘Waterfall’ associe des tas de connotations très négatives car il ramène au modèle original ‘Waterfall’ défini en 1970 et ce que les gens appellent ‘en cascade’ peut aujourd’hui avoir peu de ressemblance avec l’original de 1970. L’expression « Dirigé par un plan » ne traine aucun de ces bagages négatifs.
Quand les gens dans la communauté Agile comparent ‘Agile’ et ‘en cascade’, c’est d’habitude dans le contexte Agile est bon et ‘en cascade’ mauvais et ce n’est ni vraiment précis ni objectif. Dire « ‘Agile’ est meilleure que ‘en cascade’ » s’apparente à dire “une voiture est meilleure qu’un bateau”.
Les deux ont des avantages et des inconvénients selon l’environnement dans lequel vous évoluez:
Une approche ‘dirigée par un plan‘ donne à son meilleur dans les projets qui ont un faible niveau d’incertitude et exigent un fort niveau de prévisibilité
Une approche adaptative marche mieux dans les projets qui ont un niveau élevé d’incertitude et exigent un focus sur la créativité et l’innovation pour trouver une solution optimum plutôt qu’une orientation sur la planification et le contrôle pour atteindre la prévisibilité
En bref
livre sur Amazon
Je ne pense pas avoir la moindre chance de faire en sorte que les gens cessent d’utiliser la comparaison ‘Agile’ versus ‘en cascade’ qui est trop largement utilisée. Je l’utilise même moi-même parfois parce que c’est une façon commode et simple de décrire quelque chose qui est en réalité beaucoup plus complexe. J’espère juste que les gens comprennent combien c’est une simplification excessive et à quel point ce peut être imprécis et trompeur.
L’auteur de ce billet, Chuck Cobb est l’auteur du livre « The Project Manager’s Guide to Mastering Agile » et il a développé un cours appelé “Learn the Truth About Agile Versus Waterfall” qui fournit plus de détail pour aider les gens à voir ces approches depuis une nouvelle perspective comme complémentaires l’une à l’autre plutôt que en compétition : Free Agile versus Waterfall course
N’hésitez pas à poster vos commentaires sur ce livre, ce cours et/ou ce billet…
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans cet article, l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et Agile.
Serhiy Kharytonov
Selon Serhiy Kharytonov, le choix entre les méthodes « en cascade », RUP (rational unified process) et agile, dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dispersion géographique de l’équipe.
Une combinaison des trois méthodes selon les moments du cycle de développement pourrait être une bonne approche.
Cet article qui date pourtant de presque dix ans reste étonnamment actuel.
Utilisez vous d’autres critères de choix de votre approche de développement?
Waterfall, RUP et Agile : quelle est la bonne méthode de développement logiciel pour vous?
Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mix de stratégies de développement logiciel afin de répondre aux besoins spécifiques de votre projet.
Malgré les signes de reprise dans l’économie, une réalité persiste dans le développement logiciel: La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible.
Pour atteindre ces objectifs apparemment contradictoires, les développeurs cherchent à rationaliser la production avec des processus rapides et efficaces qui peuvent donner au client ce qu’il veut en un laps de temps le plus court possible.
Ces constantes et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel souvent appelées le modèle Waterfall / « en cascade », vers des modèles plus itératifs et progressifs tels que « Rational Unified Process » et « Agile. »
Les partisans d’Agile sont nombreux et il peut parfois sembler que les processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, leurs incovénients et leurs environnements de projet favoris.
Au bout du compte, la meilleure méthode ou le meilleur mix de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, votre culture business et votre propre environnement de développement.
Waterfall / « En cascade »
La programmation « en cascade » est un processus fortement structuré qui compte fortement sur une planification initiale et un ensemble d’étapes séquentielles, prescrites qui découlent l’une de l’autre comme l’eau dans une une cascade. Chaque étape a typiquement sa propre équipe d’experts et jalons soigneusement préparés à l’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète avec des résultats qui sont fortement prévisibles. On appelle aussi souvent cette approche le cycle en « V ».
Typiquement les étapes dans le développement « en cascade » sont :
Recueil des besoins et rédaction du cahier des charges
Analyse fonctionnelle
Développement du code
Intégration
Test et mise au point
Installation
Maintenance
Ceci peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.
Les détracteurs disent que le « Waterfall » demande simplement trop longtemps et manque de la flexibilité, ou de l’agilité, requise pour le marché logiciel actuel avec son environnement de développement en constant mouvement. Les projets qui suivent la méthode « en cascade » prennent typiquement des mois ou des années et quand ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut alors être des corrections onéreuses explosant le budget initial.
RUP (rational unified process)
Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin de répondre au changement et introduit de l’adaptabilité pendant le processus de développement.
Comme la « cascade », RUP a une série de phases et des jalons qui découlent l’un de l’autre :
L’initiation, où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
La construction, où le logiciel est construit et testé et la documentation de support est produite.
La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.
RUP définit en détail les rôles et les activités de membres de l’équipe et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que de grandes quantités de documentations requises pour chaque étape « Waterfall ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de guides, modèles, outils et autres articles pour s’assurer qu’ils partagent les mêmes langages et perspectives sur le projet.
Alors que cela apparaît de prime abord similaire au développement « en cascade », la plus grande différence du RUP est son approche de développement itérative, qui construit le produit en plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin, de l’architecture et l’exploration de différentes idées, alors que les itérations ultérieures essayent d’assembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.
Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours utilisateurs.
RUP adresse bon nombre des critiques du développement « Waterfall » et c’est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » les développements dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.
Les critiques disent que RUP n’est pourtant pas aussi rapide ni adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial et là où l’on s’attend à des mises à jour fréquentes et des compléments rapides de fonctionnalités.
Agile
Tandis que « Waterfall » et RUP penchent vers la prédictibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, dont XP et SCRUM, et tous s’efforcent de mettre une version du produit basique mais fonctionnelle entre les mains du client aussi vite que possible.
Ils font alors suivre cette version par des versions successives qui ajoutent et changent les fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes périodes de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme en « Waterfall » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.
Plutôt que de dépendre d’équipes composées de nombreux experts, le processus de développement Agile est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La constante collaboration en face à face est l’objectif, avec le représentant du client comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à l’approche « Waterfall » et même RUP pour sortir quelque chose aussi rapidement que possible.
Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement des besoins et réponses aux challenges amenés par la compétition, qui sont les raisons de tant de partisans.
Certaines sociétés sont fréquemment citées comme ayant utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont apporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.
Mais même s’il est facile de tomber amoureux d’Agile, l’approche a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rend le processus difficile à adapter à l’externalisation des développements, à des situations où clients et développeurs sont géographiquement éloignés, ou aux clients qui n’ont tout simplement pas les compétences, les ressources ou le focus nécessaires.
Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas aux clients qui veulent des contrats avec des évaluations fermes et définitives et des échéanciers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec de très nombreuses parties prenantes aux besoins différents et néglige de prendre en compte le besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.
De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec le « Waterfall » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.
CertYou est partenaire de DantotsuPM
Le meilleur de chaque monde
Si Agile, RUP et des modèles « en cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret des développements logiciels réussis est de comprendre les trois processus dans le détail et de sélectionner les parties de chacun qui conviennent le mieux à leurs livrables et environnements spécifiques. Donc, être agile dans l’approche même du choix du processus, en regardant sans cesse ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux aux circonstances actuelles.
Par exemple, si vous développez du logiciel « Software as a Service » SaaS dans un marché fortement concurrentiel, vous ferez probablement le meilleur choix en penchant vers des méthodologies Agile. Le SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour y ajouter ou en changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateurs changeants, vous voudrez probablement être capables d’apporter rapidement des changements.
D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou autres systèmes qui exigent un haut degré de design et de certitude, alors il semble logique de commencer par du »Waterfall ».
Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui vont être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière sur le recueil des besoins, la définition du périmètre et du contenu au tout début, ainsi que des standards de parcours et d’interface utilisateur.
Quel est le meilleur de chaque approche que vous puissiez utiliser sur votre projet ?
Les développeurs peuvent tout de même utiliser des techniques Agile pour présenter des prototypes fréquents et des modules successifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de la société (selon que ces équipes soient plus ou moins habituées à une telle collaboration). Quand la distance géographique est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.
Ce même mélange de techniques peut être utilisé dans un environnement d’externalisation du développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contacts de suivi que possible pour votre projet.
Choisir de partir sur des équipes auto-organisées ou une approche plus directive (« top-down ») de management dépend aussi du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leadership qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins lors des itérations suivantes.
Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et tous les environnements, ni même pour un seul.
C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement.
Bref, en choisissant entre Agile, RUP et « Waterfall », adaptez le processus à vos besoins, plutôt que de chercher à adapter votre projet au processus !
partagez ce billet avec vos amis, collègues et relations professionnelles
les articles les plus lus sur DantotsuPM de Juin 2017
Ce mois-ci les billets appréciés des suiveurs du blog et autres visiteurs furent ceux liés à l’agilité, aux soft skills et à la qualité. Bonne relecture ou découverte !
Les personnes non intuitives et de nombreux professionnels techniques disent que maitriser les aspects pas si évidents des interactions avec les personnes (« soft skills » ou compétences relationnelles) est un grand défi et souvent prise de tête.
certaines relations peuvent être particulièrement frustrantes !
Quelles vérités sur les compétences ces personnes doivent-elles apprendre et utiliser ?
L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.
Cet art s’est inspiré de la pratique et de la philosophie de l’aïkido martial, et permet de diriger une agression verbale vers un résultat positif et équilibré. Comme dans l’art martial, l’assaillant et le défenseur sont dits « partenaires » et non « adversaires ». Il n’y a donc pas à proprement parler d’affrontement, ni vainqueur ni vaincu.
PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.
La qualité est mal comprise par trop de personnes qui n’y pensent que quand ils touchent au produit final. En réalité, c’est seulement au travers de processus de qualité centrés sur l’efficacité, l’innovation et l’amélioration continue qu’un produit de qualité est réalisé, et ces processus exigent une culture de management de qualité non seulement dans nos projets, mais aussi dans nos organisations.
Dans le chapitre 2 de son livre de 1986, « Out of the Crisis« , Edward Deming a présenté 14 prinipes dont il pense qu’ils peuvent rendre l’industrie plus compétitive grâce à un accroissement de la qualité.
L’un des 2 sujets 2017 du bac S en philosophie: « Peut-on se libérer de sa culture ? » m’a immédiatement rappelé des discussions avec Claude Emond sur la culture Agile et plusieurs billets que nous avons ensemble publiés sur ce blog.
Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.
Amy Thompson
Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?
J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.
Partenaire de DantotsuPM
Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.
L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)
partagez ce billet avec vos amis, collègues et relations professionnelles
Marc Burlereaux has presented an article written by Christine Rieu, Sylvain Gautier and himself about the pitfalls when introducing Agility at the Project Zone Congress 18,19 March 2013 in Frankfurt.
The Agile approach used for projects, or new product development, ensures a greater flexibility with iterative design, lighter documentation and formalization, more interactivity and efficiency in the conduct of meetings, and especially more customer involvement throughout the project (Pichler, 2010). By coupling a Lean approach to these Agile methods; we remove all unnecessary and ‘non-value added’ steps to minimize waste and to maximize the expected value of the product (Larman & Vodde, 2010). This seems to be the panacea!
But it is not straightforward to implement this type of approach and the Project Manager may be asked many questions:
o How will these approaches be integrated successfully in mature Project Management organizations that are more familiar with traditional software V-Model (software development) or Waterfall Model?
o How will the Release Manager be in a position to facilitate the delivery of products developed with Agile and Lean approaches? This is particularly relevant given his/her role is to keep adherence to rigid processes for minimizing the risks associated with change, which is often seen by the Agile Project Manager as an awful slowdown in the delivery process.
o How will these deliveries fit in the whole Release Management process, including testing procedures (unit, integration and acceptance testing of applications), the production of operating technical documentation, user guides, and the creation of installation and deployment procedures?
o How will you avoid Agile being used as an excuse for lax and ineffective behaviours, such as removing documentation?
The success of such projects imposes a balance between a comprehensive Agile approach and a discipline warranty by the Release Management process. Hence the title of our paper, « An Iron Fist in a Velvet Glove. »
This presentation is based on lessons learned gathered during project experiences combining Agility and Lean Management in various fields of industry and banking organizations. We explain our vision of the prerequisites for a project to be eligible for Agile methods. The thread of the presentation is to then illustrate our experiences with emphasis on Agile best practices that we have identified as key success factors. We have divided these keys points throughout the various phases of project development, with a particular emphasis on the early stages of scoping and preparation, and then the final stages of acceptance (technical and business) and finally the transition to production.
The following anecdote illustrates that sometimes agile’s team are surprisingly facing rigidity:
Jack Duggal, a seasoned Program Manager with over 30 years of experience in project management, said at a conference organized by PMI (Project Management Institute) in Geneva in 2012: « You can sometimes blame rigidity in the application of agility. In a Scrum meeting, which assumes that you are standing, a person a little tired had expressed the need to sit down: this was refused, as matter of principle! »
Whatever method is chosen, we should be able to get inspired by other approaches and benefit from best practices:
As an example, PMI, which is the authority in the management of « traditional » projects, has naturally opened the door to the principles of Agility by recently creating a new credential PMI-ACP (Agile Certified Practitioner) and integrating Agile and Lean Management into traditional project management. For example, the PMBOK 5th edition now takes into account Agile « Adaptive Life Cycles » with section 2.4.2.4 covering iterative and incremental methods. These methods involve short iterations of 2 to 4 weeks with fixed time and resources (i.e. time boxing).An important aspect to add is the risk management: this is an example of good practice derived from traditional methods integrated into agile approaches.
Finally, we conclude by reminding the four principles issued by the Manifesto for Agile software development written by Kent Beck and 16 other signatories (K. Beck et al, 2001) which by the way could be followed regardless of the chosen project management methodology:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we place more value to the items on the left.
The Agile approach should be considered rather as a philosophy of development
In this presentation, we wanted to give very practical advice to implement a successful agile approach, especially in organizations which will combine it with more traditional models. It is inspired by our experiences in various project contexts and emphasizes the importance of deeply understanding the benefits and implementation impacts of this new way (i.e. not just use it as a « tool box with an integrated checklist »). The Agile approach should be considered rather as a philosophy of development, which focuses on employee involvement and commitment. One has to take in each method that is « good for business », knowing that every business is unique and has its own specific operational characteristics. Opposed to traditional methods, Agile methods are a revolution, but they can also bring their share of the burden and stress, depending on the implementation and the use.
The Agility is good but to control it is even better …
– The Scrum approach is not a panacea, especially if it is not understood and supported by the Management and Business Analyst (MOA)
– The Lean Approach coming from the industry may not be implemented in all contexts
– The AGILE mindset is primarily the key success factor that will ensure a smooth Agile implementation
– We must select the right AGILE tools best suited to the company
– A pragmatic coaching is a key success factor
– The dogmatism must be forgotten
– And we must contextualize the process that could not be standard for all areas (from the space industry to Google, through aerospace, automotive, banking …).
Last but not least, misunderstood and badly launched / implemented Agility may cause more damage than traditional methods.
Let’s Be WAGILE! Contraction of WATERFALL (traditional methods of development) and AGILE … hence Agility: An Iron Fist in a Velvet Glove!
Christine RIEU, works as an Associate Professor in the Listic laboratory and has carried out research on Knowledge Management for the past 15 years. Christine teaches Project Management at the IUT of Annecy where she also holds the position of Head of International Relationships. . Christine is also a founding member of “PMI Pôle des Pays de Savoie”, France Chapter.
Marc BURLEREAUX, has more than 27 years of expertise in Project, Program and Portfolio Management with a proven track record in the field of Swiss Private Banking. Marc is a Senior Volunteer at PMI, Director of “Pôle des Pays de Savoie” (part of the France Chapter) and also a member of the PgMP® & PMI-RMP® Credentials PRC (Panel Review Committee). Marc has been applying agile technics for the past 10 years, and more recently has spent two years as Head of European Release Management in a Swiss Private Bank.
Sylvain GAUTIER, has more than 27 years of expertise in IT and started his career working as a consultant, and then as an architect, within the Software Industry (Computer Associates, Sybase). Sylvain focused mainly on data design, DBA, and project management methodologies for major European projects before becoming Head of IT Operations for an important private bank in Geneva. Sylvain is now a freelance consultant applying Agile, ITIL, Archimate and Service Design best practice to companies within the Banking and Insurance sector.
Bonus video : « Agile: An Introduction »
partagez ce billet avec vos amis, collègues et relations professionnelles
La méthodologie « waterfall » a été présente depuis si longtemps que les organisations de développement logiciel qui la pratiquent – et leurs clients – sont complètement en accord avec le processus. Récemment notre gourou résidant Agile l’a indiqué en commentant qu’avec Agile, clients ou propriétaires de produit (« product owners ») ne peuvent pas décharger leurs pensées sur l’engineering. Autrement dit, ils ne peuvent pas donner à l’ingénierie d’un seul coup tous leurs besoins au démarrage, parce que Agile demande une constante collaboration dans laquelle les besoins sont alignés à la fois sur l’équipe et sur le business.
Cela m’a sonné à réfléchir : Intérieurement, dans une organisation de développement de produits qui utilise Agile, coûte que coûte les propriétaires de produit doivent s’aligner. Ils apprendront le concept d’arriéré de produit et de besoins qui s’empilent; ils accepteront les tâches que les experts Agile attendent d’eux. Cependant, dans une organisation pilotée par les projet où les clients sont les gardiens du besoin, est-ce que ces clients sont prêts pour Agile ?
Je me rappelle de plusieurs occasions pendant mes missions de conseil où trois à quatre mois ont été dédiés « à la découverte » des processus clients, l’esquisse des besoins, l’obtention de la signature d’un document de contenu de projet. Le tout avant que nous ne puissions commencer le projet. Les calculs d’allocation de ressources et d’échéanciers, étaient basés sur ces « besoins ». C’est que la communauté informatique communauté a appris à ses clients sur quoi attendre d’un projet.
Aujourd’hui, comme la communauté IT adopte et s’adapte aux pratiques Agile, en faisons-nous assez pour instruire et informer notre écosystème – nos clients ?
Ce qui suit sont mes opinions sur certains des processus ou des engagements auxquels ces clients ont besoin de s’adapter dans le monde Agile.
Vider son esprit par rapport à construire les besoins de manière itérative
Dans la méthodologie « waterfall » les besoins sont le début des projets, avec des clients les exposant et des consultants les documentant. Les besoins n’étaient jamais revisités de nouveau avec le client, puisque le client les avait déjà formellement signés. Les projets commençaient seulement après que la collecte de besoins soit finie.
Dans Agile, cependant, les besoins, depuis le début même, peuvent être définis comme des « épopées » et doivent régulièrement être décomposées en histoires. À chaque planification de sprint, toutes les parties prenantes (incluant le client) conviennent d’histoires (autrement dit de fonctionnalités et de besoins) qui doivent être développées et testées dans le prochain sprint. Cela devrait être utilisé comme un facteur « WOW » par l’équipe projet, pour aider des clients à comprendre qu’ils peuvent être complètement en accord avec ce qui est développé et ils peuvent aussi prioriser les fonctionnalités selon leurs besoins business.
Cependant, là se trouvent les défis :
Participation : les Clients doivent s’engager sur la démonstration et la planification de sprint. Si éviter celles-ci est la norme et les propriétaires de produit deviennent régulièrement des mandataires pour le client, les bénéfices d’Agile ne peuvent jamais être expérimentés ni implémentés.
Alignement des équipes : le fonctionnel, le développement et des équipes QA doivent sortir de leurs mentalités « waterfall » et travailler vraiment en tandem dans chaque sprint, recherchant des démonstrations de sprint réussies sans balayer les problèmes sous le tapis.
Les estimations du management par rapport aux évaluations de point d’histoire d’équipe Scrum
En « waterfall », des échéanciers de projet partent du « go ». On s’attend à quelques semaines de collecte des besoins pour permettre au projet et aux managers de dessiner un parfait plan de projet, avec allocation des ressources, test d’acceptation utilisateur et date de livraison bien définie. Un chef de projet méritant son salaire intégrera toujours une marge de 20 à 30 pour cent.
Agile tourne ce processus sur sa tête. Il implique que l’équipe de Scrum (pas le management) devrait calculer les point d’histoire (« Story Points ») et s’engager à atteindre ces points d’histoire en fonction de la vélocité de l’équipe.
Ici, les défis sont :
Planification de projet : je crois qu’un échéancier est le plus grand défi du projet. L’idée de toujours avoir une date finale de projet (qui, selon diverses études, n’est pas respectée dans 80% des cas en « Waterfall ») sont si innés dans les organisations IT et chez leurs clients qu’atteindre la date finale possible de projet basée sur des points d’histoire va demander beaucoup de désapprentissage avant que cela ne puisse arriver.
Évaluations récurrentes : les propriétaires de produit, ainsi que les clients, doivent participer à la planification de Sprint en aidant ‘équipe, à nettoyer et calculer les points d’histoire de l’arriéré de produit. Ils peuvent alors voir ce qui peut être accompli dans le sprint à venir et ce quels sont les reliquats du sprint précédent.
Vélocité d’équipe : la méthodologie Agile implique que l’équipe soit assez mâture pour connaître sa vélocité, a suffisamment d’expérience pour estimer les besoins et a assez d’autorité pour s’engager sur les échéances.
Fin de développement par rapport à démonstration de sprint
Les démonstrations de sprint exigent que l’équipe Scrum ait un morceau de code qui marche, digne d’être montré, mais elles exigent aussi l’engagement de la partie prenante clé : le client.
Les défis de cette approche :
Revue constante : si l’ingénierie et l’assurance qualité (QA) doivent s’adapter à des cycles de trois à quatre semaines pour créer un morceau de code fonctionnel et digne d’être montré, le client et le propriétaire de produit doivent aussi s’adapter au processus de constante revue. Le succès ou l’échec d’une histoire ramènent finalement à combien l’équipe Scrum a bien compris l’histoire, appelant ainsi à une revue de l’histoire elle-même. Fini sont les jours « Mais je pensais que vous aviez compris ce que je vous avais alors dit ». Si la planification de sprint et même les réunions « stad up » quotidiennes ont abouti à un écart de communication, l’équipe entière doit revisiter beaucoup de terrain, les besoins n’en étant qu’une partie.
Les projets au temps passé et dépenses contre coût fixe
La méthode « waterfall » permet aux organisations de négocier des contrats comme des offres à coût fixe ou bien en fonction du temps passé et des dépenses en matériel. Le type d’offre est dirigé par les offres des concurrents, la longueur possible du projet et le budget et la force de négociation du client.
Cependant, dans le monde Agile, cela n’aurait pas de sens d’avoir des contrats de type temps + coûts en matériels.
article précédent sur assistons-nous à la fin des contrats « classiques »?
Voici Pourquoi:
Des pratiques de sprint itératives donnent à toutes les parties prenantes la capacité d’arrêter le projet après n’importe quel sprint. (Assomption : à la fin de n’importe quel sprint, l’équipe a un code qui marche.)
La planification de sprint permet à toutes les parties prenantes d’avoir accès et d’analyser ce qui peut être réalisé dans des sprints futurs en fonction de la vitesse de l’équipe.
Le soin porté à l’arriéré de produit permet aux besoins d’être alignés sur les besoins business avant chaque sprint, ce qui permet aux clients de prioriser selon ses objectifs business. Par exemple, donner à l’intégration du site Web à PayPal pour les achats en lige la priorité sur un tableau de bord pour les partenaires, atteignant ainsi une présence en ligne avant que la campagne publicitaire « achetez en ligne » ne devienne virale.
Voici quelques-uns des aspects d’Agile auxquels je crois que les organisations doivent s’adapter. Mais un point important est que les clients doivent aussi changer la façon dont ils engagent dans un Monde Agile.
Voici une petite vidéo de Vincent McGevna sur comment « Agiliser » l’approche « Waterfall ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Spécifiez ce qui peut et doit être partagé dans le contrat. Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre. Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu). Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.
Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies). Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives. Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.
Collecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.
DantotsuPM.com 