Discussion :

[Community Management]

Salut, l'idée est de mettre en place une FAQ collaborative sur les méthodes agiles telles que Scrum, XP et RAD.

Si vous avez des propositions de questions et/ou de réponses, n'hésitez pas à les proposer sur cette discussion. Toute sorte de proposition est la bienvenue. Vous avez rencontré un problème, ou vous avez des questions qui reviennent souvent ou encore des éléments de réponses à des questions récurrentes, alors postez les à la suite de ce topic. Nous allons ensemble mettre en place la foire des questions relatives aux méthodes agiles.

Pour commencer, on aura quatre sections:

• Section Scrum
• Section RAD
• Section XP
• Section Kanban

[Francis Walter]

Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion de projets informatiques. Elles reposent sur des cycles de développement itératifs et adaptatifs en fonction des besoins évolutifs du client. Elles permettent notamment d'impliquer l'ensemble des collaborateurs ainsi que le client dans le développement du projet.

Ces méthodes permettent généralement de mieux répondre aux attentes du client en un temps limité (en partie grâce à l'implication de celui-ci) tout en faisant monter les collaborateurs en compétences. Ces méthodes constituent donc un gain en productivité ainsi qu'un avantage compétitif tant du côté client que du côté du fournisseur.

Le manifeste Agile (ou « agile manifesto » ) est un texte apparu en 2001 et rédigé par 17 experts du développement logiciel. Ce texte reprend les 4 valeurs communes des méthodes agiles et les dérive en 12 principes précisés ci-dessous.

Nous découvrons de meilleures approches pour faire du développement logiciel, en en faisant nous même et en aidant les autres à en faire. Grâce à ce travail nous en sommes arrivés à préférer et favoriser :

• L'équipe et la communication avant les outils et processus : dans la vision agile, l'équipe est bien plus importante que les outils ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et dont les membres communiquent entre eux, composée de développeurs de niveaux différents, plutôt qu'une équipe composée d'experts qui travaillent de manière isolée. La communication est donc une notion fondamentale dans un contexte de développement agile.
  
• L'application avant la documentation : il est primordial que le projet fonctionne, c'est la priorité avant toute chose. La documentation technique et les autres outils (de tests, de reporting) constituent une aide précieuse, mais ne sont pas une fin en soi. Une documentation précise est utile comme moyen de communication. Il est parfois préférable de simplement commenter abondamment le code lui-même, et surtout de transférer la totalité des compétences et connaissances du métier à l'ensemble des collaborateurs de l'équipe.
  
• La collaboration avant la négociation : le client doit être impliqué dans le développement. Le fournisseur ne doit pas se contenter de négocier un contrat au début du projet, puis de refuser l'évolution des besoins du client. Le client doit collaborer avec l'équipe et fournir des comptes rendus réguliers sur l'adaptation du logiciel à ses attentes.
  
• L'acceptation du changement et la flexibilité avant la planification : la planification initiale et la structure du projet doivent être flexibles afin de permettre les évolutions attendues par le client. En effet, les premières livraisons du projet donnent très souvent suite à des demandes d'évolution.

1. La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
2. Accueiller positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent les changements pour donner un avantage compétitif au client.
3. Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
5. Réaliser les projets avec des personnes motivées. Fournisser-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
6. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
7. Un logiciel opérationnel est la principale mesure d’avancement.
8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
9. Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.
10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto organisées.
12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

[Francis Walter]

Il y existe plusieurs méthodes basées sur les 12 principes agiles :

• Scrum
• eXtreme Programing
• Kanban
• RAD
• DSDM

Scrum est une pratique ou méthodologie d'organisation et de conception de projets informatiques basée sur les 12 principes et 5 valeurs des méthodes agiles. Elle consiste à découper le projet en des itérations nommées sprints avec une durée de réalisation courte de 2 à 4 semaines. De façon concrète, Scrum vous demande de diviser un travail en de petits travaux réalisables par de petites équipes en une courte durée.

La méthode Scrum est caractérisé par 3 rôles que les membres de l'équipe de conception du projet doivent jouer durant la durée de réalisation, 5 réunions et 4 artefacts. Le nom Scrum vient du football américain Rugby qui veut dire la mêlée. D'ailleurs, cette pratique exige de faire des mêlées quotidiennes appelées Stand-up qui constitue l'une des 5 réunions le caractérisants.

Scrum définit trois rôles dans une équipe de développement qui sont :

• Le Product Owner (PO ou Propriétaire du produit)
• Le Scrum Master (SM ou Maître Scrum)
• Les développeurs

Le Product Owner (PO) qui veut dire le propriétaire du produit représente généralement le client à qui l'on veut réaliser le projet. Il est le maître du projet car c'est lui qui connait les règles métiers et de gestion du projet à développer. Il définit la chronologie dans laquelle les fonctionnalités du projets doivent être développées. Il s'assure que tous les participants du projet comprennent et respectent ce qui est écrit dans le carnet du projet ou le cahier de charges.

Il doit être généralement disponible durant toute la durée du développement pour répondre aux questions ou besoins des développeurs lors des réunions. Il doivent suivre de façon très assidue le développement du projet et la valider à chaque itération. En général un bon PO implique une bonne réalisation. Si nécessaire, il a la possibilité de stopper une itération et passé à une autre

Le Maître Scrum s'assure de la bonne pratique du Scrum durant le développement à travers les différentes itérations et réunions. Il définit par exemple la durée de chaque itération et les sujets à traiter lors des réunions. Il aide à déterminer et éradiquer les éventuels obstacles aux développement du projet. Un rôle de Scrum Master bien joué permet d'optimiser le développement du projet.

L'équipe de développement, généralement constituée de 3 à 9 personnes, représentent les personnes qui doivent réaliser le projet. Elle peut être constituée de graphistes, analystes, concepteurs de base de données ou testeurs. Durant le développement, ils sont tenus de respecter et de produire ce qui est écrit dans le carnet de produit ou le cahier de charges.

[Francis Walter]

Cinq activités sont décrites :

• Sprint
• Planning Poker ou Sprint Planning Meeting (Réunion de planification)
• Daily Scrum (Mêlée quotidienne)
• Revue de sprint
• Rétrospective du sprint

Le sprint est une période de deux à quatre semaines au cours de laquelle l'équipe de développement doit livrer une ou plusieurs fonctionnalités définies dans le carnet de produit. La durée d'un sprint est limitée à 4 semaines afin de réduire sa complexité. Les objectifs définis pour un sprint ne peuvent pas être modifiés durant le sprint et seul le Product Owner (Propriétaire du produit) a la possibilité d'annulé un sprint en cas d'obsolescence.

[tikomoon]

La planification Agile (avec la question du bon niveau pour la user story, backlog produit, backlog de sprint)

Les tests et au delà la qualité.

L'infrastructure pour supporter l'agilité (du plus simple tableau vers les outils collaboratifs)

Comparatif des Cadres Agiles (Kanban, Scrum, Xp, DSDM, RAD) ils sont très souvent complémentaires