Méthologie : Agile or not

Personnellement j'ai un peu de mal avec cette méthode, parce que...trop vieux et trop attaché à la gestion par processus, mais il ne faut pas être têtu. je vais donc essayé de présenter quelques notions d'agile extrait du site : https://fr.wikipedia.org/wiki/M%C3%A9thode_agile

Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles, impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles reposent sur un cycle de développement itératif, incrémental et adaptatif et doivent respecter quatre valeurs fondamentales déclinées en douze principes desquels découlent une base de pratiques, soit communes, soit complémentaires.

Quatre valeurs fondamentales

Les méthodes agiles prônent 4 valeurs fondamentales :

• Individus et interactions plutôt que processus et outils
• Fonctionnalités opérationnelles plutôt que documentation exhaustive
• Collaboration avec le client plutôt que contractualisation des relations
• Acceptation du changement plutôt que conformité aux plans

Douze principes généraux

1. Satisfaire le client en priorité
2. Accueillir favorablement les demandes de changement
3. Livrer le plus souvent possible des versions opérationnelles de l’application
4. Assurer une coopération permanente entre le client et l’équipe projet
5. Construire des projets autour d’individus motivés
6. Privilégier la conversation en face à face
7. Mesurer l’avancement du projet en termes de fonctionnalités de l’application
8. Faire avancer le projet à un rythme soutenable et constant
9. Porter une attention continue à l’excellence technique et à la conception
10. Faire simple
11. Responsabiliser les équipes
12. Ajuster à intervalles réguliers son comportement et ses processus pour être plus efficace

Le planning POKER

source : https://fr.wikipedia.org/wiki/Planning_poker

Le planning poker est une façon ludique de produire des estimations sur la complexité de fonctionnalités à développer . Cette pratique est surtout utilisée en informatique, en Scrum et dans les méthodes agiles en général pour évaluer les scénarios utilisateurs (user stories) du carnet de produit (product backlog).

ouais ouais...tu bluffes !

Comment faire court ?

source : https://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement_(logiciel)

Le modèle en cascade

Le modèle en cascade1 est hérité de l'industrie du BTP. 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 validation-vérification

Le cycle en V

Le modèle du cycle en V2 a été imaginé pour pallier le problème de réactivité du modèle en cascade. 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.

Comparaison des approches Cascade, V et Itératif

Le cycle en cascade 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écisions de l'équipe de direction ou de l'architecte projet impactent tellement d'ingénieurs pour de telles durées qu'il vaut mieux s'assurer de la validité de chaque étape.

Par ailleurs, pour limiter l'entropie (désordre) du système constitué par l'équipe-projet, 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 projets 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).

Un phasage classique

Définition : Expression de besoin ou ce que l'on veut faire

Conception : Conception générale et détaillée - Comment faire ?

Réalisation  : Mise en place de l'infrastructure et le développement

Test : Vérifier que ça fonctionnement conformément aux besoins

Deploy : Mise en production, ouverture du service etc..