Le département de la défense américain adopte agile et la méthode Scrum

Le département américain de la défense adopte agile et la méthode Scrum
Sous les conseils de Jeff Sutherland inventeur de Scrum

Agile séduit de plus en plus de professionnels de l’IT, après son adoption par Microsoft c’est au tour du puissant département américain de la défense (DoD), qui passera d’un modèle en cascade à un modèle agile basé sur la méthode Scrum, sous les conseils avisés du docteur Jeff Sutherland, inventeur de la méthode et actuel PDG de Scrum Inc.

A l’origine de cette initiative, le nouveau projet de modernisation de l’infrastructure IT du DoD qui définit les caractéristiques des futures acquisitions logicielles :

• participation précoce et continue de l’utilisateur ;
• innovation et évolution rapide à travers des incrémentations successives et la livraison de nouvelles fonctionnalités ;
• prototypage précoce pour supporter une approche évolutive ;
• système modulaire et ouvert.

Ces caractéristiques cadrent bien avec l’esprit agile, c’est ce qui a poussé le DoD à entreprendre cette démarche et à faire appel aux conseils de Sutherland. Ce dernier a alors proposé deux modèles différents, le premier comprend certains principes hérités du développement en cascade et pourrait être résumé par le déploiement du logiciel prend place après plusieurs builds, alors que le second évoque la nécessité de livrer fréquemment une nouvelle version du logiciel, ce qui cadre mieux avec la seconde valeur du manifeste agile : des logiciels opérationnels, plutôt qu’une documentation exhaustive.

Tout ceci semble de bon augure pour le DoD, encore faut-il que cela corresponde à leurs besoins et attentes. D’ailleurs, à ce sujet il, est important de noter que contrairement au développement agile traditionnel, les itérations seront beaucoup plus longues et espacées, de l’ordre de 12 à 18 mois, ce qui peut s’expliquer par la spécificité et l’unicité des logiciels utilisés au sein du DoD.

« Scrum est une lecture obligatoire pour tout leader, qu'il mène des troupes sur le champ de bataille ou sur le marché des affaires. Les défis du monde d'aujourd'hui ne permettent pas le luxe d'un travail lent et inefficace. Le succès exige vitesse, énorme productivité et un engagement indéfectible pour atteindre des résultats escomptés. En d'autres termes, le succès exige Scrum », a commenté le général à la retraite Mc Caffrey, à l’annonce de cette nouvelle .

Source : Jeffsutherland.com

Et vous ?

:fleche: Qu’en pensez-vous ?

Citation:

---

Le succès exige vitesse, énorme productivité et un engagement indéfectible pour atteindre des résultats escomptés. En d'autres termes, le succès exige Scrum

---

Cela me fait penser à une mauvaise publicité...

Quelque soit la méthode ou la pratique employée, Agile, CMMI, DevOps, au final derrière, c'est toujours le même que l'on retrouve: l'humain.

Et c'est surtout de lui dont dépendra l'échec ou la réussite du projet.

Mais ce n'est que mon avis.

Je ne sais plus ou j'avais lu que le DoD était parfaitement rationel : chacun y faisait non ce qui était bon pour le projet, mais ce qui était bon pour sa carrière. Suivant cette simple grille de lecture, vous pouviez facilement interpréter tout ce qui s'y passait.

Je ne sais pas si c'était vrai(même si j'ai tendance à y croire), en tous cas, les gens qui font du "SCRUM avec des itérations de 12 à 18 mois", eux, rentrent parfaitement dans le schéma. Parceque bon, une itération de 15 jours, si on part de traviole, on a perdu 15 jours. Une itération de 18 mois..... Il va y avoir du cacheton de consultant incapable et surpayé, moi je vous le dis.

Un des points exprimés est

Code:

---

participation précoce et continue de l’utilisateur

---

Déjà là, qu'on fasse du vrai agile ou à moitié ou aux trois quarts, si ce point n'est pas appliqué,
autant partir à la pêche... ce qui m'arrive souvent .... :-) Non, c'est faux !

Bonjour,

Au fait, c'est quoi un utilisateur ? oups .... :mrgreen:

Olivier

Citation:

---

Envoyé par Arsene Newman

Agile séduit de plus en plus de professionnels de l’IT, après son adoption par Microsoft c’est au tour du puissant département américain de la défense (DoD), qui passera d’un modèle en cascade à un modèle agile basé sur la méthode Scrum

---

C'est la 2e fois que je lis dans un article ici comme quoi le contraire d'agile c'est le cascade, je ne dis pas le DoD ne faisait pas du cascade et que maintenant passe à l'agile. Mais on doit faire un peu attention sur la définition des méthodes agiles. Il n y a pas que le cascade qui est le contraire de l'agile, il y a bien des méthodes itératives et incrémentales non agiles comme les Processus Unifiés :2TUP, RUP.. même si la démarche avec RUP peut le rendre facilement agile. Seulement quand on ajoute le concept d'adaptative en plus de l'itérative incrémentale, et on intègre le client au sein du processus qu'on parle de méthode agile, comme les méthode Scrum, XP.... Mais, il y a aussi l'UP agile, ils ont essayés d'unifier les processus agiles.

On utilise plutôt le terme de méthodes traditionnels comme contraires des méthodes agiles, et non pas le modèle en cascade.

Des iterations de 12 a 18 mois... Si ce n'est pas du cascade, cela doit être du cycle en V.

L’agilité ce sont des itérations courtes, ou bien cela n'a pas de sens.

Citation:

---

Envoyé par iolco51

Des iterations de 12 a 18 mois... Si ce n'est pas du cascade, cela doit être du cycle en V.

L’agilité ce sont des itérations courtes, ou bien cela n'a pas de sens.

---

Oui dans l'agilité les itérations doivent être courtes, mais cela ne veut pas dire que dans les méthodes traditionnelles on a pas des itérations courtes, mais dans les processus unifiés(UP) les itérations sont aussi courtes, dans le moment où ils sont pilotés par les cas d'utilisation, les itérations sont d'une semaine et au maximum 2 semaines, je me demande un cas d'utilisation qui prendra plus de deux semaines, c'est plutôt plusieurs cas d'utilisation groupé en un seul, alors il faut découper.

Le délais court est très important aussi, et les méthodes recommandent fortement que dans le cas où les objectifs visés ne sont pas atteint dans le délais court fixé pour une itération, il faut reporter les objectifs non atteints à la prochaine itération. La chose qu'il n y a pas dans les UP non agiles c'est qu'on code pas quelque chose adaptative ou du faire du RAD, mais on code quelque totalement conçu, documenté et bien maîtrisé avant codage pas de possibilité de changer en court de route selon le besoin du client, exactement tel quel le texte du cas d'utilisation décrit dans une phase d'analyse de l'itération avant même de passer à la conception les composants à développer au court de l'itération. Parfois certains cas d'utilisations sont développés dans une phase d'analyse avant d’entamer le cycle itérative incrémental.

La 2e chose qui n'existe pas dans les UP non agile on ne fait pas intervenir le client dans le processus, même si RUP recommande une élaboration d'un business model: qui est une représentation synthétique censée décrire les principaux aspects de l'activité de l'organisation avec le systèmes à développer, une sorte d'étude du processus métier de l'organisation où le système à développé sera déployé. Il y a des stéréotypes spécifiques pour ça pour élaborer des cas d'utilisation métier et diagrammes de collaboration.... La démarche commence par là.

Je note que j'ai dis qu'on ne fait pas du RAD dans UP, mais cela ne veut pas dire qu'il ne peut pas y avoir si on veut une phase de prototypage.

Je tiens à noter que quand j'ai dis qu'avec les méthodes non agiles on code quelque chose de bien conçu, je ne voulais pas dire que dans l'agile on ne code pas quelque chose de bien conçu si tout est bien conçu dans l'agile, mais je voulais dire que pour les méthodes traditionnelles itératives et incrémentales dans une seule itération la paperasse revient, tout doit être 100% conçu et documenté, totalement bien analysé et conçu avant codage, avec l'agile on est souple et on peut changer des choses selon le besoin du client, c'est pour cela qu'on parle d'adaptative,

Dans l'agile on privilégie l'histoire, que l'analyse et la conception rigoureuse de tout ce qu'il faut coder.