Phases et Jalons Agile UP

Hier, j’ai eu une discussion passionnante avec un architecte logiciel qui travaille sur le même projet que moi. Le sujet était de savoir si l’architecture devait être définie et ++stable++ avant de lancer les premiers sprints de développement, disons lors du sprint zéro (selon moi) ou si l’architecture pouvait ++fortement évoluée++ en parallèle des sprints et en y faisant éventuellement participer une partie de l’équipe au travers de technical stories ou de spikes (selon lui). J’ai eu affaire à forte partie (non j’ai pas dit une tête de mule) et il a même réussi à me faire douter en invoquant ++[UP|http://sabricole.developpez.com/uml/tutoriel/unifiedProcess/]++.%%% %%% ((/dotclear/public/photos/.Scott-Ambler_t.jpg|Scott W. Ambler|L|Scott W. Ambler))Ni une, ni deux, j’ai fait quelques recherches sur le sujet et je vous propose ici la traduction des deux articles de __Scott W. Ambler__ :%%% – ++[Agile UP Phases|http://www.ambysoft.com/unifiedprocess/aup11/html/phases.html|en]++%%% – ++[Agile UP Milestones|http://www.ambysoft.com/unifiedprocess/aup11/html/milestones.html|en]++%%% %%% Pour ceux qui souhaiteraient réagir, je vous invite à me laisser un commentaire.%%% %%% —- ((/dotclear/public/logos/logoAgileUP.gif|Agile UP||Agile UP))%%% L’Agile UP peut être considéré à travers ses quatre phases, au travers desquels vous allez vous déplacez. La fin d’une phase est marquée par un jalon et la « revue de jalon » vérifie que votre équipe a bien réussi à remplir les critères du jalon concerné.%%% %%% [((/dotclear/public/traductions/.phasesAndMilestones_m.jpg|Phases et Jalons UP||Phases et Jalons UP))|/dotclear/public/traductions/phasesAndMilestones.gif]%%% %%% ///html

Phase Objectifs Jalon
1. Inception Pour identifier le périmètre initial du projet, une architecture potentielle de votre système, et obtenir un financement initial du projet et la validation des parties prenantes. Objectif défini (LCO)
2. Elaboration Pour valider l’architecture du système. Architecture définie (LCA)
3. Construction Pour construire un logiciel opérationnel sur une base itérative, incrémentale qui répond aux besoins les plus prioritaires des parties prenantes du projet. Première version exploitable (IOC)
4. Transition Pour valider et déployer votre système dans votre environnement de production. Livraison finale (PR)

/// !!1. Phase « Inception » – Jalon « Objectif défini » (LCO$$LCO : Lifecycle Objectives$$)%%% Pour ce jalon, les parties prenantes évaluent l’état du projet. Elles doivent se mettre d’accord sur les points suivants :%%% * __Validation du périmètre.__ Les parties prenantes parviennent à un accord sur le périmètre du projet.%%% * __Validation des besoins initiaux.__ Il y accord sur le fait que l’ensemble des besoins de haut niveau a été recueilli et que tout le monde partage la même compréhension des besoins.%%% * __Validation du planning.__ Les parties prenantes sont d’accord sur les estimations initiales du coût et du calendrier.%%% * __Validation du risque.__ Les risques ont été identifiés, évalués et des stratégies acceptables ont été identifiées pour y remédier.%%% * __Validation du processus.__ L’Agile UP a été initialement adapté et accepté par toutes les parties.%%% * __Faisabilité.__ Le projet a un sens du point de vue métier, technique et opérationnel.%%% * __Planning du projet.__ Un planning adéquat a été défini pour la prochaine phase (Elaboration).%%% * __Respect du portefeuille projets.__ Le périmètre du projet s’inscrit-il bien dans le portefeuille des projets de votre organisation ?%%% !!2. Phase « Elaboration » – Jalon « Architecture définie » (LCA$$LCA : Lifecycle Architecture$$)%%% Pour ce jalon, les parties prenantes évaluent l’état du projet. Ils doivent s’entendre sur les points suivants :%%% * __ Stabilité de la vision.__ La vision du projet est devenue stable et réaliste.%%% * __Stabilité de l’architecture.__ Vous validez le fait que l’architecture est stable et suffisante pour satisfaire les besoins. L’architecture a été prototypée pour faire face aux principaux risques.%%% * __Validation du risque.__ Les risques ont été évalués afin de s’assurer qu’ils ont bien été compris et documentés et qu’une stratégie acceptable a été mise en place pour les traiter.%%% * __Faisabilité.__ Le projet a toujours un sens du point de vue métier, technique et opérationnel.%%% * __Planning du projet.__ Un planning détaillé des itérations à venir lors de la phase de Construction ainsi qu’un planning global du projet ont été élaborés.%%% * __Respect de l’architecture d’entreprise.__ Est-ce que l’architecture du système respecte les règles de l’architecture d’entreprise ?%%% !!3. Phase « Construction » – Jalon « Première version exploitable » (IOC$$IOC : Initial Operating Capacity$$)%%% Pour ce jalon, les parties prenantes doivent s’entendre sur ce qui suit :%%% * __Stabilité du système.__ Le logiciel et la documentation sont validées (stables et mûrs) pour déployer le systèmes aux utilisateurs.%%% * __ Parties prenantes prêtes.__ Les parties prenantes (et le métier) sont prêtes pour que le système soit déployé (à la formation près).%%% * __Validation du risque.__ Les risques ont été évalués afin de s’assurer qu’ils ont bien été compris et documentés et qu’une stratégie acceptable a été mise en place pour les traiter.%%% * __Validation de l’estimation et du coût.__ Le budget consommé à ce jour est acceptable et des estimations raisonnables ont été fournies pour le calendrier et les coûts futurs.%%% * __Planning du projet.__ Un planning détaillé des itérations à venir lors de la phase de Transition ainsi qu’un planning global du projet ont été élaborés.%%% * __Respect de l’architecture d’entreprise.__ Est-ce que le produit développé par l’équipe respecte les standards de l’entreprise ?%%% !!4. Phase « Transition » – Jalon « Livraison finale » (PR$$PR : Product Release$$)%%% Pour ce jalon, les parties prenantes doivent s’entendre sur ce qui suit :%%% * __Validation par les parties prenantes métier.__ Les parties prenantes métier sont satisfaites et valident le système.%%% * __Validation par les opérations.__ Les personnes responsables de l’exploitation du système une fois en production sont satisfaites de la documentation et des procédures d’exploitation.%%% * __Validation par le support.__ Les personnes responsables du support du système une fois en production sont satisfaites de la documentation et des procédures de support.%%% * __Validation de l’estimation et du coût.__ Le budget consommé à ce jour est acceptable et des estimations raisonnables ont été fournies pour les coûts de production futurs.%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *