Unified Process

Un article de Wikipédia, l'encyclopédie libre.

Sommaire

[masquer]• 1 Abréviations utilisées      :   • 2 Généralités    • 3 Fonctionnement    • 4 PU, méthode agile      ?   

modifier]

Abréviations utilisées :

PU : Processus unifiée, désigne les préceptes généraux de la méthode.

UP : Unified Process, la dénomination anglaise.

RUP : Rational Unified Process, Instanciation par Rational Software (IBM) des préceptes UP.

EUP : Enterprise Unified Process, Instanciation intégrant les phases de postimplantation et décrivant le cycle de vie du logiciel.

XUP : Extreme Unified Process, Instanciation hybride intégrant UP avec Extreme Programming.

AUP : Agile Unified Process, partie des préceptes UP permettant l’agilité du développement, instanciation partielle de la méthode mettant l’accent sur l’optimisation et l’efficience sur le terrain plus que sur le modèle théorique.

2TUP : Two Tracks Unified Process, Instanciation de UP proposé par ValTech prenant en compte les aléas et contraintes liées aux changements perpétuels et rapides des SI des entreprises.

SADT : structured analysis and design technique, équivalent américain de la méthode Merise, méthode séquentielle de développement connue aussi sous le nom de IDEF0 (integration definition for function modeling).

UML : Unified Modeling language, ensemble de diagrammes préconisés dans la modélisation en conception orientée objet.

OMG : Object Management Group, association américaine dont le but est de promouvoir la programmation objet sous toutes ses formes.

DCU : Diagramme de cas d’utilisation, modèle UML considéré comme fondamental dans PU.

AM : Agile Modeling, tentative de formalisation et d’inventaires des préceptes décrivant l’agilité en matière de développement applicatif.

Note : On utilisera les abréviations par commodité. On utilisera de préférence les sigles sous la forme de leur traduction française lorsqu’on parle des concepts génériques ou de méthodes non instanciées. A l’inverse, on gardera la terminologie anglosaxonne pour parler des instances.

[modifier]

Généralités

Processus unifié (PU ou UP en anglais pour unified process) est une méthode de prise en charge du cycle de vie d’un logiciel et donc du développement, pour les logiciels orientés objets. C’est une méthode générique, itérative et incrémentale, contrairement à la méthode séquentielle Merise (ou SADT). PU vient compléter la systémique des modèles UML. Elle est le résultat final d’une évolution de l’approche d’Ericsson qui est au fondement d’une des premières méthodes de développement pour applications orientées objets, la méthode Objectory Process (1987). Objectory Process (version 1 à 3.8 en 1995) a ellemême servie de base à la société Rational pour la création de Rational Objectory Process (1997) (version 4.1), parente direct de RUP en 1998.

RUP est l’une des plus célèbres implémentations de la méthode PU, livrée clés en main, permettant de donner un cadre au développement logiciel, répondant aux exigences fondamentales préconisées par les créateurs d’UML :

• une méthode de développement doit être guidée par les besoins des utilisateurs • elle doit être centrée sur l’architecture logicielle • elle doit être itérative et incrémentale 

UML est souvent qualifié de langage de modélisation et permet en fait de « penser objet » au moment de la conception, de la modélisation, pour permettre un développement objet plus aisé. Mais, et ses créateurs, membres de l’OMG, en étaient tout à fait conscients, le cycle de vie du logiciel, le processus de création et même de la conception des dits modèles n’est pas du tout prise en charge par UML. La raison en est simple : Comment prendre en compte la diversité des projets, des problématique, des équipes et des cultures d’entreprise dans une seule et unique méthode ? C’est à cette question laissée délibérément en suspens par l’OMG que répond PU et ses divers avatars (RUP, XUP, AUP, EUP, 2TUP). C’est pour préserver une nécessaire adaptabilité au contexte d’entreprise que PU est avant tout générique.

Ainsi, une réalisation conforme à PU, pour transformer les besoins des utilisateurs en logiciel, doit nécessairement présenter les caractéristiques suivantes :

• PU est à base de composants • PU utilise UML • PU est piloté par les cas d’utilisation • PU est centré sur l’architecture • PU est itératif et incrémental 

[modifier]

Fonctionnement

Le pilotage par les DCU revêt une signification concrète : des DCU, on doit tirer les modèles d’analyse, de conception, de déploiement. Ce sont eux qui sont implantés et ce sont les cas d’utilisation prévue qui vont présider à l’élaboration des lignes de tests : les cas d’utilisation doivent au final être permis par le nouveau logiciel. Les DCU sont les modèles garantissant la cohérence du processus du développement. Ce sont eux qui unifient. Enfin les DCU sont, de par leur nature, intrinsèquement liés à l’architecture du système.

Celleci est conçue dès le départ de façon très pragmatique : elle est adaptée au contexte de travail, aux besoins de l’utilisateur, aux possibilités de réutilisation (reuse) de bibliothèques ou de « briques » préexistantes.

L’élaboration de l’architecture est d’abord grossière et indépendante des cas d’utilisation (on veillera cependant à ce qu’elle n’empêche pas leur réalisation) puis, un sousensemble des fonctions essentielles est identifié et l’architecture est reprise et détaillée suivant cet ensemble. De la spécification à la précision des cas, l’architecture évolue, incluant finalement de nouveaux cas, ainsi de suite, jusqu’à ce que l’architecture ait atteint un niveau de développement suffisamment conséquent et stable pour donner lieu au développement d’un prototype qui sera présenté au client achevant ainsi une itération.

Une itération est la succession des étapes d’une activité. Un incrément est une avancée dans les stades de développement. A chaque itération on retrouve les phases de spécification des besoins (inception), d’élaboration, jusqu’au prototypage exécutable. Une nouvelle itération, par exemple après démonstration du prototype aux utilisateurs, reprendra la spécification en la précisant ou la corrigeant, puis reprenant l’élaboration, etc.

Les incréments sont définis par le projet, et chaque incrément va ajouter de nouvelles fonctionnalités. Les incréments peuvent suivre les différents cas d’utilisation par exemple. La difficulté résidera dans le fait de combiner au final les sous projets ou incréments ensemble et de respecter leurs interdépendances et la cohérence générale du produit envisagé. C’est donc également un développement sous forme de composants qui est proposé. Il utilisera au mieux les apports des technologies objets.

PU intègre les deux visées dans le but de minimiser les risques de contresens par rapport aux besoins ainsi que le risque de développements infinis, indéfinis, mal définis ou inachevés : Ici l’utilisateur peut corriger luimême, sur les prototypes, la tournure que prend le développement. Dès le début, des résultats tangibles sont obtenus même s’ils ne sont que prototypiques. Certaines implémentations de PU considèrent d’ailleurs les prototypes comme des versions à part entière du système final. Les fonctions subalternes peuvent très bien, dans une telle optique, être abandonnées en cours de route pour des questions de coûts ou de délais par exemple. Enfin, si les besoins utilisateurs changent en cours de développement, cette évolution peut être, dans une certaine mesure, intégrée. Ce n’est pas le cas dans le cadre d’un développement séquentiel.

PU prévoit au global un cycle de vie où les itérations (spécifications + analyse + conception + implémentation + tests) sont regroupées en catégories d’activités. Ces activités sont soit initiales (création), soit intermédiaires (élaboration, construction) soit finales (transition vers l’utilisateur ou mise en production). Ces catégories d’activité découpent la réalisation du produit comme une succession temporelle (séquences) mais comprennent toutes les tâches structurantes du projet (raffinage successifs, itérations) et proposent une organisation matricielle du volume d’activité total fourni : il est évident qu’en phase de création, une plus grande partie du temps sera consacrée à l’analyse des besoins qu’aux tests ; inversement, en phase de transition, les tests sont encore en cours alors que l’analyse des besoin et son raffinage sont théoriquement bouclés depuis la phase de construction :

EUP (Entreprise PU) ajoute des catégories d’activités décrivant la vie du logiciel en production jusqu’à son retrait de la production.

PU, méthode agile ?

Les méthodes dites agiles (AM) décrivent des processus de développement d’application basés sur la modélisation, la conception et la documentation réalisés de façon efficiente. Les pratiques de modélisation agiles sont en fait des améliorations (Best practices) censées pouvoir être appliquées à des méthodes déjà existantes, déjà instanciées. Ainsi AUP (agile modeling unified process) doit être considéré comme un sousensemble de Rational UP. Or l’emboîtement des pratiques agiles avec les concepts UP n’est pas évident :

Souvent l’adoption de PU par une organisation découle en fait de la volonté de discipliner les pratiques de développement à l’utilisation d’outils particuliers et au suivi de règles de conduites établies, homogènes. Ils constituent euxmêmes des traitements dans les directions informatique des entreprises et font l’objet d’ingénierie (BPR : Business Process Re engineering). Le développement agile, au contraire, préconise le choix des outils les plus simples et l’utilisation en douceur ou « sur le mode de la boîte à outils » des modèles du langage ou des phases de la méthode. Il y a donc paradoxe à vouloir rigidifier en les codifiant des pratiques par nature destinées à la souplesse.

Pour autant, la plupart des concepts agiles sont implantés, décrits, dans PU sous la forme de mécanismes de développement :

La participation active telle que promue par AM est facilitée par le développement itératif et incrémental. L’utilisateur peut théoriquement intervenir au bon moment et annihiler toute erreur d’interprétation.

La modélisation en parallèle est préconisée par PU comme par AM : en effet, si la « sérialisation » telle qu’elle peut être induite par le découpage en activité organise la matrice des tâches, il n’en reste pas moins qu’à chaque itération les différents types de modèles peuvent être effectués en même temps.

AM préconise une formalisation des zones de contacts entre le projet et l’existant ou système en place. RUP prévoie l’étude de « classes frontières » servant d’interface avec le SI existant tel qu’il demeurera après l’implantation du projet.

La modélisation dans chaque incrément est conçue par PU comme étant le résultat de raffinages successifs.

Favoriser la réutilisation de codes, de classes : Plus encore que PU ce sont les langages objets et la conception en classe qui permettent cela. Par contre, selon Scott Ambler (http://www.agilemodeling.com/ ), certains fondements de PU ne peuvent coexister avec les préceptes d’agilité : La prééminence et le rôle moteur des DCU doit être abandonné car s’ils permettent de documenter correctement les comportements du logiciel ils ne pourront pas servir à piloter quelque autre activité du projet que ce soit : les contraintes, les interfaces utilisateurs et leur cinématique, les « business rules » que devront respecter le logiciel ne peuvent être déduite des DCU. PU ajoute d’ailleurs un ensemble de « spécifications supplémentaires » pour pallier ce manque. Ainsi, toujours selon Ambler, si l’analyse des besoins peut conduire le projet, les cas d’utilisations ne le peuvent pas et ne constituent qu’une rhétorique marketing propre aux instanciations telles que RUP ou EUP.

En second lieu, la méthode de développement en incrément et itération, si elle est assimilée par le chef de projet, ne l’est pas forcément des développeurs et encore moins des utilisateurs qui peuvent y être associés. Ces concepts ne sont pas simples à appréhender et à implanter dans une gestion de projet. Cela nécessite une démarche active de la part de celui qui décide de mener le projet selon ces préceptes de façon à ce que la démarche soit effectivement itérative et incrémentale. Autant de temps consacré à la « métaphysique » du projet et de sa gestion qui vont à l’encontre de l’optimisation agile.

2TUP (2 track unified process) est un processus de développement logiciel qui implémente le processus unifié UP.

Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects fonctionnels.

Ce processus en Y s'articule autour de 3 phases :

• une branche technique, • une branche fonctionnelle, • et une phase de réalisation. 

[modifier]

Méthode agile

Un article de Wikipédia, l'encyclopédie libre.

Aller à : navigation, Rechercher

Une méthode agile est une méthode de développement informatique permettant de concevoir des logiciels en impliquant au maximum le demandeur (client), ce qui permet une grande réactivité à ses demandes. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles visent la satisfaction réelle du besoin du client, et non d'un contrat établi préalablement. La notion de méthode agile est née à travers un manifeste signé par 17 personnalités (parmi lesquelles Ward Cunningham, l'inventeur du Wiki), créateurs de méthodes ou dirigeants de sociétés.

Sommaire[masquer]

• 1 Valeurs    • 2 Principes    • 3 Méthodes    • 4 Voir aussi    

• 4.1 Liens internes    • 4.2 Liens externes    

ValeursDans ce but, elles prônent 4 valeurs fondamentales (entre parenthèse, les citations du manifeste) :

• L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile, elle est bien plus importante que les moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale. 

• L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code luimême, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication). 

• La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feedback continu sur l'adaptation du logiciel à ses attentes. 

• L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution. 

PrincipesCes 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :

• « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles ». 

• « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ». 

• « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ». 

• « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ». • « Batissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien 

dont elles ont besoin, et croyez en leur capacité à faire le travail ». • « La méthode la plus efficace de transmettre l'information est une conversation en face à 

face ». • « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ». • « Les processus agiles promeuvent un rythme de développement soutenable. 

Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ». 

• « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité ». 

• « La simplicité  l'art de maximiser la quantité de travail à ne pas faire  est essentielle ». • « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto

organisent ». • « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde 

et ajuste son comportement dans ce sens ». 

Méthodes• Adaptive software development    (ASD) • Crystal clear    • Dynamic software development method    (DSDM) • Extreme programming    (XP) • Feature driven development    • Rapid Application Development    (RAD) • Scrum    

Cycle de développement

Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prendront en compte toutes les étapes de la conception d'un logiciel.

Sommaire

[masquer]

• 1 Les Grandes Familles    • 1.1 Cycle en cascade    • 1.2 Cycle en V    • 1.3 Cycle en spirale    • 1.4 Cycle itératif    

• 2 Comparaison des approches Cascade, V et Itératif    • 3 Quelques méthodologies    • 4 Voir aussi    

Les Grandes Familles

[modifier]

Cycle en cascade

Les phases du cycle en cascade

Ce cycle est hérité du bâtiment. Ce modèle repose sur les hypothèses suivantes;

• on ne peut pas construire la toiture avant les fondations; • les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts 

en aval (on peut imaginer la fabrication d'un moule dans l'industrie du plastique). 

Les phases traditionnelles de développement sont effectuées simplement les unes après les autres, 

avec un retour sur les précédentes, voire au tout début du cycle. Le processus de développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques :

• de produire des livrables définis au préalable; • de se terminer à une date précise; • de ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de 

validationvérification. 

[modifier]

Cycle en V

Les phases du cycle en V

Pour pallier au problème de réactivité du modèle en cascade, le modèle du cycle en V a été imaginé. Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante, doivent renvoyer de l'information sur les phases en visàvis lorsque des défauts sont détectés afin d'améliorer le logiciel.De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes descendantes les " attendus " des futures étapes montantes : ainsi les attendus des tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors de la conception, etc.

Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet depuis les années 1980.

[modifier]

Cycle en spirale

Le développement reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet.

[modifier]

Cycle itératif

Les phases du Cycle itératif

On sépare les activités des artéfacts, un artéfact étant le produit issu d'une activité. Ainsi, on applique un cycle de type roue de Deming sur la production d'une documentation, d'un code, d'un test, etc.

Rapporté à une activité de type gestion de projet, la première phase sera celle de

• la faisabilité : l'acceptation d'un nouveau besoin • l'élaboration  : on imagine comment on va le réaliser • la fabrication : construction • la transition  : tout est mis en œuvre pour livrer au client 

Le cycle itératif n'est pas une bijection avec le cycle en V du type

• faisabilité = spécifications • élaboration = architecture • fabrication = développment prototype • transition = tests 

Sachant que chaque itération ne dépasse jamais huit semaines, cette tactique est donc impossible. En fait, l'idée est de livrer au plus tôt quelque chose qui puisse être testé par le client. On peut en effet réaliser plusieurs itérations sur une documentation telle que l'architecture. De la même manière, si un document n'est qu'un des artéfacts parmi d'autres, il ne faut pas obtenir un document complet. On préférera utiliser la loi de Pareto : ne pas passer 80% de l'effort sur les 20% restant.

La différence entre un PDCA et une itération est la durée : elle doit être courte et régulière alors qu'une roue de Deming appliqué à une organisation de 300 personne prends plusieurs mois, voire plusieurs années.

[modifier]

Comparaison des approches Cascade, V et Itératif

Le cycle en V a pour origine l'Industrie Lourde. La particularité de ce milieu est que la phase qui suit nécessite bien plus de ressources que la précédente.Par exemple, pour fabriquer un objet en Matière plastique,

1. un Bureau d'étude va concevoir le produit, 2. puis des empreintes de moules seront usinées et placées dans des carcasses pour recevoir de 

la matière plastique par injection 3. et une fois que le prototype est correct, on passe à une phase de production. 

Il faut savoir que pour un objet simple tel qu'un gobelet en plastique, la conception est une affaire d'une poignée de semaines (soit quelques milliers d'euros) alors qu'un moule (empreinte + carcasse) nécessite plusieurs mois de fabrication et plusieurs centaines de milliers d'euros.

Par conséquent, dans un tel contexte, pour bien gérer son projet, il est important de ne pas négliger la validation de chaque étape sous peine de le voir déraper.

Ce phénomène intervient sur des chantiers logiciels réunissant des dizaines voire des centaines de personnes. Les décision de l'équipe de direction ou d'architecte de projet impactent tellement d'ingénieurs pour de telles durée qu'il vaut mieux s'assurer de la validité de chaque étape.

Par ailleurs, pour limiter l'entropie du système constitué par l'équipeprojet, il est nécessaire de formaliser par des documents (voire des outils)

• les processus • les besoins • les spécifications logicielles • l'architecture logicielle • les tests 

Dans le cas d'un projet logiciel impliquant une douzaine de personnes pendant une à deux années, la configuration n'est plus la même ; en effet, avec de tels projet on dispose :

• d'une plus grande réactivité due à • une proximité géographique • une facilité (relative) de communication 

• d'un facteur de coût limité entre chaque étape 

Aussi, il est possible de s'orienter vers des méthodes de développement dites agiles en diminuant le formalisme et en multipliant le nombre de cycles (fonctionnement itératif).

[modifier]

Quelques méthodologies

Les phases du Cycle itératif

• eXtreme Programming    • Scrum    • RUP    • 2TUP    • Merise    • SADT    

Extreme programming

Un article de Wikipédia, l'encyclopédie libre.

(Redirigé depuis EXtreme Programming)

Aller à : navigation, Rechercher

Logo XP

L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique, dont l'objectif est de permettre de gérer des projets de manière simple et efficace. Cette méthode a été inventée par Kent Beck et Ward Cunningham. L'Extreme Programming est né officiellement en octobre 2000 avec le livre « Extreme Programming Explained » de Kent Beck.

Sommaire

[masquer]• 1 Le cycle de l'Extreme Programming    • 2 Une méthode XP    • 3 La programmation comme discipline collective    

• 3.1 Valeurs    • 3.2 Pratiques    • 3.3 Autres principes    

• 4 Une méthode qui ne fait pas l'unanimité    • 5 Voir aussi    

• 5.1 Liens internes    • 5.2 Liens externes    • 5.3 Bibliographie    

[modifier]

Le cycle de l'Extreme Programming

Le cycle de développement XP

[modifier]

Une méthode XP

Comme toutes les méthodes de développement, l'Extreme Programming propose un cadre pour l'ensemble des aspects du projet logiciel, depuis l'analyse des besoins jusqu'aux tests, en passant par la conception. Mais à la différence des processus prédictifs, recourant généralement à UML (même si XP utilise aussi parfois UML comme support de communication), XP ne se fonde pas sur la définition exhaustive et précoce des besoins ; elle parie plutôt, à partir d'un ensemble de règles 

strictes, sur la souplesse et la mise en valeur du « capital humain ».

[modifier]

La programmation comme discipline collective

Tout en mettant l'accent sur les bonnes pratiques de programmation, XP préconise un déroulement par itération courte et géré collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur, avec de surprenants résultats en termes de qualité de code, de délais et de satisfaction de la demande du client.

[modifier]

Valeurs

L'Extreme Programming repose sur 4 valeurs fondamentales :

• La communication : c'est le moyen fondamental d'éviter les erreurs. Le moyen à privilégier est la conversation directe, en face à face. Les moyens écrits ne sont que des supports et des moyens de mémorisation ; 

• Le courage : il est nécessaire à tous les niveaux et de la part de tous les intervenants, notamment chez les développeurs (quand des changements surviennent à un stade avancé du projet, ou quand des défauts apparaissent) et chez le client (qui doit pouvoir prioriser ses demandes) ; 

• Le retour d'information (feedback) : les itérations sont basées sur les retours d'informations du client, permettant une adéquation totale entre l'application finale et sa demande ; 

• La simplicité : en Extreme Programming, la façon la plus simple d'arriver à un résultat est la meilleure. Prévoir préalablement des évolutions futures n'a pas de sens. Ce principe est résumé en une phrase : « Tu n'en auras pas besoin. » (en anglais « You ain't gonna need it. »). La meilleure manière de rendre une application extensible est de la rendre aussi simple (et donc simple à comprendre) et aussi bien conçue que possible. 

[modifier]

Pratiques

Ces 4 valeurs se déclinent en 13 pratiques :

• Un représentant du client sur site : afin d'assurer une meilleure réactivité et un retour rapide, un représentant du client doit être présent pendant toute la durée du projet. Ce représentant doit avoir les connaissances d'un utilisateur final, mais en même temps une vision globale du résultat à obtenir ; 

• Planning game : le client crée des scénarios d'utilisation, en les priorisant. Ces scénarios seront ensuite implémentés par l'équipe de développement. Le projet est considéré comme achevé quand le client n'est plus en mesure de trouver de nouveau scénario ; 

• Intégration continue : l'intégralité de ce qui est développé est assemblée à chaque fois qu'une tâche est terminée, ce qui permet d'avoir toujours une version à jour, notamment comme livrable ou pour le démarrage de nouvelles tâches ; 

• Release fréquente : les livraisons doivent être les plus fréquentes possibles, afin d'obtenir un retour le plus rapidement possible, tout en offrant des fonctionnalités complètes. La fréquence de livraison est donc de quelques semaines ; 

• Rythme soutenable : afin d'éviter de surcharger l'équipe, elle ne fait pas d'heures supplémentaires deux semaines de suite. Si le cas se présentait, cela signifierait qu'il faut 

redéfinir l'emploi du temps ; • Tests de recette : à partir de critères définis par le client, on crée des procédures de test, 

souvent automatisées, qui permettent de vérifier fréquemment le bon fonctionnement de l'application ; 

• Tests unitaires    : avant d'implémenter une fonctionnalité, il convient d'écrire un test qui validera l'implémentation. Ces tests sont issus de la traduction à plus bas niveau des Tests de recette. Il est donc normal qu'XP pousse la notion de Tests unitaires (Unit Tests) en imposant leur écriture avant celui du code (firsttest) ; 

• Conception simple : l'objectif est de produire une application qui réponde aux attentes du client. Mieux vaut donc arriver à ce résultat de la manière la plus simple possible, afin de faciliter les évolutions futures en rendant le code simple à comprendre et facile à modifier. De même, la documentation doit être minimale, c'estàdire ce qui est demandé par le client ; 

• Utilisation de métaphores : on utilise des métaphores et des analogies pour décrire le système et son fonctionnement, ce qui permet de le rendre compréhensible par les noninformaticiens, comme les utilisateurs ou les commerciaux ; 

• Refactoring    (ou remaniement en français) du code : amélioration continue de la qualité du code sans en modifier le comportement (commentaire du code, respect des règles de nommage, simplification, etc) ; 

• Convention de nommage : dans l'optique d'appropriation collective du code et de facilitation de la communication, il est indispensable d'établir et de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc. ; 

• Programmation en binôme : la programmation se fait par deux. Le premier, appelé driver, a le clavier. C'est lui qui va travailler sur la portion de code à écrire. Le second, appelé partner, est là pour l'aider, en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Les développeurs changent fréquemment de partenaires, ce qui permet d'améliorer la connaissance collective de l'application et d'améliorer la communication au sein de l'équipe ; 

• Appropriation collective du code : l'équipe est collectivement responsable de l'application et est supposée connaître l'intégralité du code. Chacun peut également faire des modifications dans toutes les portions du code, même celles qu'il n'a pas écrites. 

[modifier]

Autres principes

• Ne pas ajouter de fonctionnalités plus tôt que prévu ; • N'optimiser qu'à la toute fin. 

Cette méthode s'appuie sur :

• une forte réactivité au changement des besoins du client ; • un travail d'équipe ; • la qualité du code ; • la qualité des tests effectués au plus tôt. 

[modifier]

Une méthode qui ne fait pas l'unanimité

• L'Extreme Programming est parfois critiqué pour sa radicalité. En effet, si on en croit les chantres de cette méthode, et notamment ses auteurs, on ne fait de l'Extreme Programming que si l'on met en place toutes les pratiques de la méthode, ce que certains trouvent trop 

contraignant et contraire à l'esprit agile, qui doit justement permettre d'assouplir l'aspect méthodologique des projets informatiques. 

• On reproche aussi parfois à cette méthode d'être mal adaptée à l'environnement économique : comment prévoir la durée et le coût d'un projet ? 

• Enfin, on peut lui reprocher aussi de constituer essentiellement une refonte de méthodes largement utilisées depuis plus de trente ans (voir page de discussion). 

Un article de Wikipédia, l'encyclopédie libre.

Aller à : navigation, Rechercher

Scrum est une méthode de gestion du travail, orientée vers le développement informatique. Celleci fait partie de la famille des méthodes agiles.

Le terme Scrum est emprunté au rugby et signifie « mêlée ». La méthode porte ce nom car chaque jour se tient une réunion informelle où l'équipe de travail se rencontre pour faire un suivi sur le travail quotidien.

Sommaire

[masquer]• 1 Introduction    • 2 Grands principes    

• 2.1 Isolement de l'équipe    • 2.2 Développement progressif    • 2.3 Pouvoir à l'équipe    • 2.4 Contrôle du travail    

• 3 Cycle de développement    • 3.1 La phase d'initiation (de démarrage)    • 3.2 Les sprints    • 3.3 Phase de clôture    

• 4 Gestion d'un sprint    • 4.1 Ecarter les embûches    • 4.2 Gestion des tâches    • 4.3 Saborder le sprint    

• 5 Critique    • 6 Termes Scrum    • 7 Voir aussi    

• 7.1 Liens internes    • 7.2 Liens externes    

[modifier]

Introduction

Scrum est le fruit de l'effort entre Ken Schwaber et Jeff Sutherland, qui au début des années 1990 ont commencé à mettre en place les grands principes de Scrum, mais ce n'est qu'en 1996, que Scrum est né officiellement avec la publication du premier article traitant de cette méthodologie.

Le principe de base de Scrum est d'isoler l'équipe de développement durant une période de 30 jours (appelée « Sprint »), afin que celleci réalise un maximum de fonctionnalités. C'est le leader de l'équipe (Scrum Master) qui a la charge de réduire au maximum les distractions extérieures qui pourraient nuire à l'atteinte de l'objectif de l'équipe. Pour faire une analogie, celuici joue un rôle de parefeu entre l'équipe et le monde extérieur.

[modifier]

Grands principes

À la fin des années 1980, Ken Schwaber et Jeff Sutherland participent à plusieurs projets qui sont en état de stagnation et ont des difficultés à livrer des solutions logicielles. Ils mettent en place quelques principes simples afin d'aider les acteurs de ces groupes de travail à travailler de façon plus performante. Ils tirent les grands principes de Scrum de ces expériences.

[modifier]

Isolement de l'équipe

Tout d'abord l'équipe de développement est isolée de toute influence extérieure qui pourrait lui nuire. Seule l'information et les tâches reliées au projet lui parviennent.

[modifier]

Développement progressif

Afin de forcer l'équipe à progresser, ils imposent qu'elle livre une solution tous les 30 jours. Durant cette période de développement l'équipe se doit de livrer une série de fonctionnalités qui devront être opérationnelles à la fin des 30 jours.

[modifier]

Pouvoir à l'équipe

L'équipe reçoit les pleins pouvoirs pour réaliser les fonctionnalités. C'est elle qui détient la responsabilité de décider comment atteindre ses objectifs. Sa seule contrainte est de livrer une solution qui convient au client dans un délai de 30 jours.

[modifier]

Contrôle du travail

Le travail est contrôlé quotidiennement pour savoir si tout va bien pour les membres de l'équipe et à la fin des 30 jours de développement pour savoir si la solution répond au besoin du client.

[modifier]

Cycle de développement : Le cycle de développement Scrum peut être divisé en trois parties :

Démonstration du cycle de développement de Scrum[modifier]

La phase d'initiation (de démarrage)

Celleci a pour but la définition du « product backlog », qui contient la liste des fonctionnalités du système demandé par le client. Cette étape permet d'établir une idée générale de l'effort nécessaire pour la construction du système. Le « product backlog » sera construit par le « product owner », avec l'aide du client et de l'équipe de développement, afin de classer les fonctionnalités par ordre de priorité et d'effort.

[modifier]

Les sprints

Au début du sprint l'équipe choisit parmi les fonctionnalités du « product backlog » celles qu'elle désire réaliser. Elle prendra autant de fonctionnalités qu'elle pense pouvoir faire durant le prochain sprint. Ces fonctionnalités seront traduites dans le « sprint backlog » en petites tâches (entre 4 et 16 heures) à accomplir pour les réaliser.

Durant le sprint, les membres de l'équipe iront se choisir une tâche à faire parmi celles qui sont disponibles dans le « sprint backlog ». Ils auront la charge de mettre à jour le « sprint backlog » en indiquant le nombre d'heures restant avant de terminer celleci. Lorsque toutes les tâches sont à zéro, le sprint est terminé.

Tous les jours les membres de l'équipe vont se réunir pour faire un Scrum. Durant cette rencontre, ils feront part de ce qu'ils ont accompli depuis le dernier Scrum, ce qu'ils pensent faire jusqu'au prochain et quels empêchements ils ont rencontrés durant leur travail.

[modifier]

Phase de clôture

La phase de clôture est une phase linéaire : elle a lieu quand l'équipe de management estime que les variables de temps, exigences, coût et qualité concordent. Cette phase de clôture prépare le produit pour une livraison : intégration, test systèmes, documentation utilisateur, préparation de supports de formation, etc.

[modifier]

Gestion d'un sprint

Malgré le fait que toute l'équipe soit responsable du travail à faire durant un sprint, la charge de faire la gestion du sprint revient au « Scrum Master ».

[modifier]

Ecarter les embûches

Une partie importante de la gestion d'un sprint consiste à s'occuper des embûches que peut rencontrer l'équipe durant son travail. Pour toutes les embûches que l'équipe ne peut résoudre ellemême, le « Scrum Master » a la charge d'y apporter une solution.

[modifier]

Gestion des tâches

Durant un sprint il est important de s'assurer que toute les tâches du « Sprint backlog » qui sont à compléter, puissent être terminées avant la fin du sprint.

En effet, normalement durant un sprint, le nombre de tâches à achever fluctue de jour en jour. Dans les meilleurs cas c'est que les tâches sont réalisées une à une à un rythme qui permet de réaliser toutes les fonctionnalités avant les 30 jours du sprint. Malheureusement, dans bien des cas c'est tout le contraire qui arrive. Certaines tâches demandent plus d'heures pour être réalisées, d'autres sont ajoutées ou encore la progression ne se fait pas au rythme prévu.

Il arrive donc un moment (ou des moments) où il y a plus de travail à faire que de temps restant avant la fin d'un sprint. Dans ces cas, l'équipe doit apporter des changements aux tâches à accomplir pour qu'elle puisse livrer un produit à la fin du sprint.

En se penchant sur les besoins minimaux du client, il peut s'avérer que certaines tâches ne soient pas nécessaires afin de réaliser les objectifs du sprint, dans ce cas, les tâches en question peuvent être enlevées du « Sprint backlog ». Même choses pour les heures, certaines tâches peuvent s'avérer avoir été mal estimées, l'équipe doit donc apporter les correctifs nécessaires.

Malgré tout il peut s'avérer que le nombre d'heures disponibles soit toujours plus important que le nombre restant avant la fin du Sprint. Dans ses cas il est judicieux que l'équipe discute avec le client et la direction pour réduire l'étendue des fonctionnalités à réaliser. Par exemple si deux besoins usagers devaient être réalisés, le plus important des deux pourraient être conservé, ou encore une certaine fonctionnalité pourrait n'être réalisée qu'à moitié. Le plus important est que les trois parties soient en accord.

[modifier]

Saborder le sprint

Si durant le cours d'un sprint, l'équipe découvre qu'elle n'a pas toute l'autorité ou l'information nécessaire pour atteindre les objectifs visés, elle peut décider elle même de saborder le sprint. Dans ce cas le sprint est annulé et un nouveau sera établi après avoir clarifié les zones d'ombres.

[modifier]

Critique

La pratique qui consiste à isoler l'équipe de l'extérieur pendant les sprints permet aux développeurs de se concentrer complètement sur les fonctionnalités déclarées prioritaires par le client sans être perturbé par des besoins nouveaux dictés par ce même client.

Afin de déterminer la durée idéale des sprints, il faut donc peser la fréquence des demandes de changement, leur urgence (temps jusqu'à implémentation), la capacité de concentration de l'équipe et la tolérance (surtout en coût) par rapport aux développements finalement jugés inutiles.

La durée de base d'un Sprint, 30 jours calendrier (y inclus 1 jour pour le Sprint Review / Sprint Planning meeting), est une valeur empirique; il est déconseillé de descendre audessous de 15 jours. (Les sprints trop courts permettent certes de s'adapter plus rapidement à des besoins changeants, mais incluent plus de temps non productif, pour le client et pour l'équipe.) En cas de changement radical nécessitant une réaction très rapide, un Sprint peut à tout moment être terminé de manière anormale ("aborted"  pas d'obligation de livraison pour l'équipe).

Ce point particulier mérite d'être examiné attentivement avant de mettre en place cette méthode.

[modifier]

Termes Scrum

Burndown Chart  Graphique qui montre pour chaque jour du sprint le nombre d'heure restant à être travaillé. 

Product Backlog  Liste de toutes les fonctionnalités qui devront être réalisées pour un logiciel. 

Product Owner  Personne chargée de mettre à jour le « Product backlog ». 

Scrum  Réunion quotidien de 15 minutes, qui a pour but de faire le point sur ce qui a été fait depuis le dernier Scrum, ce qui est prévue de faire jusqu'au prochain et que sont les embûches rencontrées durant le travail. 

Scrum Master  Personne faisant office d'ambassadeur entre l'équipe de développement et les intervenant extérieur, il a pour but d'isoler l'équipe des influences extérieures durant un sprint. 

Sprint  Période de 30 jours durant laquelle l'équipe de développement travail à la réalisation de fonctionnalités. 

Sprint Backlog  Listes de taches détaillées que doivent accomplir l'équipe de développement afin de réaliser les fonctionnalités choisies pour un sprint. 

Rapid Application Development

Acronyme informatique signifiant Rapid Application Development (RAD).RAD est une méthode de développement de logiciels où le cycle de développement est court. Cette méthode fut initialement dévelopée par James Martin pendant les années 1980's.

Cette méthode inclut la réalisation, et les tests d'une application par morceaux à intervalles réguliers. La méthode repose notamment sur l'utilisation d'outils de programmation à interface graphique (CASE), qui permettent d'obtenir rapidement des prototypes.

Méthode agile

Un article de Wikipédia, l'encyclopédie libre.

Aller à : navigation, Rechercher

Une méthode agile est une méthode de développement informatique permettant de concevoir des logiciels en impliquant au maximum le demandeur (client), ce qui permet une grande réactivité à ses demandes. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles visent la satisfaction réelle du besoin du client, et non d'un contrat établi préalablement. La notion de méthode agile est née à travers un manifeste signé par 17 personnalités (parmi lesquelles Ward Cunningham, l'inventeur du Wiki), créateurs de méthodes ou dirigeants de sociétés.

Sommaire

[masquer]• 1 Valeurs    • 2 Principes    • 3 Méthodes    • 4 Voir aussi    

• 4.1 Liens internes    • 4.2 Liens externes    

Valeurs

Dans ce but, elles prônent 4 valeurs fondamentales (entre parenthèse, les citations du manifeste) :

• L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile, elle est bien plus importante que les moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale. 

• L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code luimême, et surtout de transférer les compétences au sein de l'équipe (on en revient à 

l'importance de la communication). 

• La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feedback continu sur l'adaptation du logiciel à ses attentes. 

• L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution. 

[modifier]

Principes

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :

• « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles ». 

• « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ». 

• « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ». 

• « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ». • « Batissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien 

dont elles ont besoin, et croyez en leur capacité à faire le travail ». • « La méthode la plus efficace de transmettre l'information est une conversation en face à 

face ». • « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ». • « Les processus agiles promeuvent un rythme de développement soutenable. 

Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ». 

• « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité ». 

• « La simplicité  l'art de maximiser la quantité de travail à ne pas faire  est essentielle ». • « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto

organisent ». • « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde 

et ajuste son comportement dans ce sens ». 

[modifier]

Méthodes

• Adaptive software development    (ASD) • Crystal clear    • Dynamic software development method    (DSDM) • Extreme programming    (XP) • Feature driven development    • Rapid Application Development    (RAD) • Scrum    

Processus en cascade

Propose de dérouler les phases projet de façon séquentielle

Cité pour des raisons historiques

Points forts

Distingue clairement les phases projet

Points faibles

Non itératif

Ne propose pas de modèles de documents

Analyse

ConceptionProgrammation

TestMaintenance

RUP

Promu par Rational

Le RUP est à la fois une méthodologie et un outil prêt à l’emploi (documents types partagés dans un référentiel Web)

Cible des projets de plus de 10 personnes 

RUP

Promu par Rational

Le RUP est à la fois une méthodologie et un outil prêt à l’emploi (documents types partagés dans un référentiel Web)

Cible des projets de plus de 10 personnes 

Points forts

Itératif

Spécifie le dialogue entre les différents intervenants du projet : les livrables, les plannings, les prototypes…

Propose des modèles de documents, et des canevas pour des projets types 

Points faibles

Coûteux à personnaliser : batterie de consultants

Très axé processus, au détriment du développement : peu de place pour le code et la technologie 

XP

Ensemble de « Bests Practices » de développement (travail en équipes, transfert de compétences…)

Cible des projets de moins de 10 personnes 

XPEnsemble de « Bests Practices » de développement (travail en équipes, transfert de 

compétences…)

Cible des projets de moins de 10 personnes 

Points fortsItératif

Simple à mettre en œuvre

Fait une large place aux aspects techniques : prototypes,  règles de développement,  tests…

Innovant:  programmation en duo,  kickoff matinal debout … 

Points faiblesNe couvre pas les phases en amont et en aval au développement : capture des besoins, 

support, maintenance,  tests d’intégration…

Élude la phase d’analyse, si bien qu’on peut dépenser son énergie à faire et défaire

Assez flou dans sa mise en œuvre: quels intervenants, quels livrables ? 

2TUPS’articule autour de l’architecture

Propose un cycle de développement en Y

Détaillé dans  « UML en action »

Cible des projets de toutes tailles

2TUP

S’articule autour de l’architecture

Propose un cycle de développement en Y

Détaillé dans  « UML en action »

Cible des projets de toutes tailles

Points forts

Itératif

Fait une large place à la technologie et à la gestion du risque

Définit les profils des intervenants, les livrables, les plannings, les prototypes

Points faibles

Plutôt superficiel sur les phases situées en amont et en aval du développement : capture des besoins, support, maintenance, gestion du changement…

Ne propose pas de documents types 

Projection de XP et 2TUP sur la matrice du RUP 

  Description Points forts Points faibles

RUP

Rational Unified Process

Promu par Rational. 

Le RUP est à la fois une méthodologie et un outil prêt à l’emploi (documents types partagés dans un référentiel Web)

Cible des projets de plus de 10 personnes

Itératif 

Spécifie le dialogue entre les différents intervenants du projet : les livrables, les plannings, les prototypes… 

Propose des modèles de documents, et des canevas pour des projets 

Coûteux à personnaliser : batterie de consultants

Très axé processus, au détriment du développement : peu de place pour le code et la technologie

 

types

2TUP

Two Track

Unified

Process

 

S’articule autour de l’architecture

Propose un cycle de développement en Y 

Détaillé dans " UML en action " (voir références)

Cible des projets de toutes tailles

Itératif 

Fait une large place à la technologie et à la gestion du risque 

Définit les profils des intervenants, les livrables, les plannings, les prototypes

 

Plutôt superficiel sur les phases situées en amont et en aval du développement : capture des besoins, support, maintenance, gestion du changement…

Ne propose pas de documents types

XP

eXtreme

Programming

Ensemble de " Bests Practices " de développement (travail en équipes, transfert de compétences…)

Cible des projets de moins de 10 personnes

 

Itératif 

Simple à mettre en oeuvre 

Fait une large place aux aspects techniques : prototypes, règles de développement, tests… 

Innovant: programmation en duo, kickoff matinal debout …

Ne couvre pas les phases en amont et en aval au développement : capture des besoins, support, maintenance, tests d’intégration… 

Elude la phase d’analyse, si bien qu’on peut dépenser son énergie à faire et défaire 

Assez flou dans sa mise en oeuvre: quels intervenants, quels livrables ?