Je partage ton point vu ! Je dis souvent, Agile est la meilleure approche que moi j’ai trouvée !

Lorsque je fais une intervention en implémentation Agile, je dis toujours qu’elle se résume en trois questions.

1-Qu’est-ce qui fonctionne ?
2-Qu’est-ce qui ne fonctionne pas ?
3-Qu’est-ce qu’on doit adresser ?

J’essaie toujours de donner des réponses à ces questions, oui en m’inspirant des méthodes agiles. Mais, peut importe la solution que j’apporte, elle convenir à l’environnement et surtout adapter par mon client. Sinon, ce n’est pas une bonne solution.

Pour la petite histoire, nous devons cela au “DOD-STD-2167″, un standard militaire du département de la défense américain pour le “développement logiciel de systèmes de défense”. Ce document promouvait un processus séquentiel en cascade à passe unique, partant du principe que tout peut être défini à l’avance et dénaturant ainsi les travaux de Royce sur lesquels il s’appuyait. Ensuite, c’est l’effet boule de neige et la catastrophe que nous connaissons : le standard 2167 influence d’autres ministères américains, d’autres pays, ce qui finit par aboutir à la généralisation de ce Waterfall dénaturé au niveau mondial.

Interviewé par la suite par Craig Larman, l’auteur principal du standard 2167 concéda qu’il regrettait la création de cette approche Waterfall à passe unique. Il déclara qu’il n’était à l’époque pas familier avec les approches itératives et incrémentales et que s’il devait réécrire ce standard aujourd’hui, il recommanderait fortement une approche itérative et incrémentale.

Ceci dit, je ne sais pas si j’irais jusqu’à dire que Royce était initiateur des méthodes agiles; mais du développement itératif et incrémental et d’une approche évolutionniste des besoins, certainement.

Merci pour cet article que j’ai pris beaucoup de plaisir à lire.

Neamoins c’est bien de partager et de comprendre les opinions des gens face aux sites web c’est sur.
J’ai juste ticker un peu trop sur le refonte visuelle…
Les opinions, c’est pour les features, les possibilites.
Prenons l’example d’une compagnie comme nike mettons le departement des t-shirts, les marketeux font un focus group, les teteux disent moi j’aime les gilet qui respire bien, l’autre qui se lave bien, qui seche vite, qui perd pas ses couleurs. Faque les ti marketeux partent avec ca, disent aux concepteur de trouver un tissu qui fait tout ca, et puis y’achete la palette Crayola pis ils en font pour tout les gouts mais avec les meme criteres. Meme principe dans le web dit “grand public”.

PS:
Je pensais jamais que nous renirais si vite, hahaha :

“Ce n’est pas en rassemblant les « meilleurs » qu’on obtient les meilleures solutions!”

Définition de “Risk Management”: http://en.wikipedia.org/wiki/Risk_management

Je comprends aussi que le gouvernement impose une tonne de livrables documentaires…le but du gouvernement n’est pas de faire des profits, ils n’ont de comptes à rendre qu’au public et non à des actionnaires. Les documents word constituent une police d’assurance comme quoi les employés du gouv ont fait ce qu’ils devaient faire en terme de suivi de projet et que les fonds publics n’ont pas été dépensés pour rien…même si on sait bien qu’un logiciel qui ne fonctionne pas avec de la belle documentation ne vaut rien sur le marché

On voit la même chose pour les gros projets de constructions. Le gouvernement va en appel d’offre pour la construction d’une autoroute sur 6 ans et demande aux soumissionnaires de leur fournir un échéancier et un budget alors qu’ils ne connaissent à peu près rien du projet. Le contrat va au plus bas soumissionnaire et ensuite on se scandalise que le projet dépasse budget ET temps.

Cependant je pense qu’une grosse partie de la solution appartient aux entreprises qui gagnent les appels d’offre en ce sens qu’il y a un gros travail d’influence à faire pour qu’un jour les choses changent.

Bien entendu, les fournisseurs qui “bident” sur ces projets ne savent probablement pas dans quoi ils se lancent, ou encore ils se spécialisent dans la réalisation de projets de ce genre (grosses entreprises, avec beaucoup de ressources, qui salivent à l’idée de mettre 10 développeurs pendant 3 ans sur un projet qui a probablement 20% de chances de donner quelque chose d’utilisable, tant que les chèques rentrent…).

Dans la plupart des cas, un client qui demande ce type de projet verra, après l’échec de ce projet, que cette façon de faire ne fonctionne pas. S’ils se font ensuite expliquer les pratiques agiles, il y a des chances qu’ils “comprennent” et qu’ils exigent par la suite des suivis au niveau du fonctionnel, et non des nuages.

TOUTEFOIS, on parle ici du GOUVERNEMENT, et je doute fortement qu’une si grosse structure puisse faire ce virage de 180 degrés et vraiment adopter l’agile à travers tous les ministères et tous les projets. Un jour, peut-être, surement, ça va arriver, mais c’est pas demain la veille…

Atlassian l’ont tellement aimé, qu’ils viennent de l’acheter à Pyxis

http://pyxis-tech.com/press/vente-greenhopper-atlassian/

A+