Discussion :

[Invité]

Je sais que je vais me faire taper dessus mais tant pis je veux comprendre, j'essaie de comprendre et c'est normal je ne suis qu'un simple débutant.

On (nous les développeurs) râle tous sur le fait que les spécifications (surtout fonctionnelles) ne doivent pas changer mais en lisant cette partie tirée d'un contenu parlant de l'architecture logicielle sur Wikipedia je me suis dis : Bah ! Pourquoi on (j'en fais partie ) se met à râler si cela est normal ? Bizarre aussi que je n'ai pas encore rencontré un développeur admettant que c'est normal que les spécifications changent.
La citation précise le cas des processus itératifs comme UP. Donc peut-être que personne n'utilise un processus itératif. ça j'en doute vu qu'il est rare de voir une offre d'emploi ne stipulant pas la connaissance des méthodes Agile, famille à laquelle appartient UP.

Dans les processus itératifs comme UP (Unified Process), la gestion des changements est primordiale. En effet, il est implicitement considéré que les besoins des utilisateurs du système peuvent changer et que l'environnement du système peut changer. L'architecte a donc la responsabilité de prévoir le pire et de concevoir l'architecture en conséquence; la plus maintenable possible et la plus extensible possible.

[ptah35]

:
Bizarre aussi que je n'ai pas encore rencontré un développeur admettant que c'est normal que les spécifications changent.

Tout dépend du domaine dans lequel on travaille; si un changement de spécification et donc du code implique une montagne de paperasse et de test à refaire, comme c'est le cas dans l’aérospatial par exemple, je peux comprendre.

Mais je dois dire qu'en ce qui me concerne je n'ai jamais rencontré de développeur pensant réellement que ce ne soit pas normal, même s'ils râlent parce que le changement met pile poil en évidence une faiblesse de l'architecture ou simplement parce que ce n'est pas super excitant de revenir sur du code qu'on pensait avoir terminé alors qu'il y a encore tellement à faire.

De plus, c'est souvent super difficile à faire admettre au client que le "petit changement de rien du tout" qu'il demande, n'est pas un "petit changement de rien du tout" simplement parce qu'il en a décidé ainsi et que même si c'est effectivement le cas, il entraînera néanmoins un minuscule surcoût de rien du tout qu'il trouvera presque toujours prohibitif...

[el_slapper]

Le problème n'est pas que le specs bougent. Le problème est que les process de gestion de projet mis en place ne le permettent pas.

En d'autres termes, on fait une belle étude, on en tire un beau chiffrage, et puis tout change, et le chiffrage ne devrait pas bouger.....

J'ai conu des projets "cycle en V" ou, à chaque changement, les gens corrigeaint rapidement la spec, le programme, les cas-tests. Ca marche bien. C'est canulant, mais ça se gère. Si par contre il faut tout reprendre à zéro, c'est la catastrophe. Et c'est souvent le cas; parceque les gens voient un logiciel comme un bâtiment, et que changer la conception d'un bâtiment en cours de construction, ça mérite une paperasse massive. En logiciel, c'est juste un poids inutile(sauf peut-être pour des logiciels vitaux, genre aérospatial ou médical)..

et +1 avec ptah : le changeur de spec n'a généralement pas conscience de ce que le changement représente.

[Logan Mauzaize]

Les spécs bougent nécessairement sinon il n'y aura pas de nouvelles versions de logiciels
Tout changement de spécifications nous donnent du boulot et c'est toujours l'occasion de rattraper le temps/marge perdus.

[Luckyluke34]

La citation précise le cas des processus itératifs comme UP. Donc peut-être que personne n'utilise un processus itératif. ça j'en doute vu qu'il est rare de voir une offre d'emploi ne stipulant pas la connaissance des méthodes Agile, famille à laquelle appartient UP.

Tu mets le doigt sur un truc très juste. Effectivement une des valeurs des méthodes agiles est d'épouser le changement en considérant qu'il est normal et fait partie de la vie d'un projet.

Je ne pense pas qu'on puisse dire que personne n'utilise un processus itératif. Beaucoup d'équipes fonctionnent aujourd'hui sur un mode agile (Scrum, eXtreme programming)... Mais comme tu le soulignes, beaucoup d'offres d'emploi qui mentionnent l'agilité ne l'utilisent pas réellement derrière.

[Invité]

Mais comme tu le soulignes, beaucoup d'offres d'emploi qui mentionnent l'agilité ne l'utilisent pas réellement derrière.

Cool, je ne suis pas le seul à voir ces cas d'offres d'emploi où l'agilité est spécifiée pour faire beau ou pour attirer des gens comme qui dirait chez nous on utilise une méthode alors qu'une fois le projet démarré tu es obligé de courir derrière le chef de projet pour lui tirer les specs du nez et aussi pour l'application d'un plan de test

Les spécs bougent nécessairement sinon il n'y aura pas de nouvelles versions de logiciels
Tout changement de spécifications nous donnent du boulot et c'est toujours l'occasion de rattraper le temps/marge perdus.

Un logiciel n'est jamais fini. Mais une version si et à chaque nouvelle version c'est normal qu'on ait de nouvelles specs.
Mon thread parle plutôt des spécs qui se métamorphosent au cours des devs d'une version d'un logiciel.

[Logan Mauzaize]

Mon thread parle plutôt des spécs qui se métamorphosent au cours des devs d'une version d'un logiciel.

Si la spécification change, sa version change et celle du logiciel aussi
Cependant il n'existe pas nécessairement un programme de chaque version de la spécification.

Pour répondre plus exactement à ta question, tout le peut changer d'avis mais tout le monde doit accepter d'en payer le prix : ceux qui commandent et ceux qui réalisent.

Si contrats/lois/etc. ne changeaient jamais on aurait pas inventé les avenants et les amendements Donc oui c'est "normale".


Ce n'est pas parce qu'on est mécontent de quelque chose, que cette dernière est anormale. Tout comme il est "normal" que les français que nous sommes râlent :p

[gangsoleil]

il est implicitement considéré que les besoins des utilisateurs du système peuvent changer et que l'environnement du système peut changer.
L'architecte a donc la responsabilité de [...] concevoir l'architecture [...] la plus maintenable possible et la plus extensible possible.

Si tu as ca, c'est bon, ton projet ne va pas dans le mur, et pourra evoluer correctement, suivant les evolutions des besoins, pour peu que ceux-ci soient raisonnables.


Le probleme est en fait multiple :
Le client ne sait pas ce qu'il veut, donc demande une machine a cafe.
Le commercial veut le contrat a tout prix, meme si l'entreprise pour laquelle il travaille ne fait pas de machine a cafe, puisqu'elle construit des tables. Donc il fait une proposition pour une table_machine_a_cafe, promettant aux architectes et aux developpeurs du temps pour le faire
L'architecte prevoit un truc super adaptable, qui coute un bras et un oeil, donc le commercial ne peut pas le vendre, donc finalement ils font un truc qui ne coute pas trop cher, mais pas du tout adaptable
Le dev a donc 3 jours pour pondre un truc a moitie pourri, inadapte aux besoins, qui vont forcement changer car le client commence a comprendre ce dont il a envie.
Les specs changent, le dev n'est pas content car il n'a pas de temps supplementaire et que le projet n'est pas concu pour etre evolutif.

PS : Le client voulait en fait un avion.


Dans la theorie Agile, les specs peuvent changer, mais le temps passe a faire les changements est a la charge du client, pas a la charge du developpeur. Mais cette partie est trop souvent oubliee.

[marton92]

Je bosse en méthode "Agile" en ce moment, et je me rends compte que c'est la pire merde qui existe. En fait cette méthode ne peut être appliquée qu'avec un projet assez stable (type contrainte réglementaire) et des développeurs/concepteurs qui maitrisent à fond leur applicatif.

Dans tous les autres cas c'est la réalisation qui se prend toute la casse en amont (y compris les erreurs de modélisation et la non prise en compte des cas particuliers, qui représentent souvent 90% du boulot), et ça finit en guerre de tranchées pour savoir qui est responsable du moindre quart de journée de dépassement.

[Logan Mauzaize]

Dans la theorie Agile, les specs peuvent changer, mais le temps passe a faire les changements est a la charge du client, pas a la charge du developpeur. Mais cette partie est trop souvent oubliee.

Rien à avoir avec les méthodes agiles mais les méthodes contractuelles.
Sinon +1000 pour le reste ;-)

Cependant les méthodes agiles visent à anticiper les changements. En ne prenant les entrées n'ont pas comme un ensemble documentaire cohérent (une pièce de granit) mais comme un ensemble de "point"/"ticket".
La réalisation du logiciel est alors découpé en petites unités (itération/version/RC) auxquels on affecte les points (on parle alors de "scoper"/"unscoper"). A la fin de chaque itération, l'équipe et le client peuvent revoir les priorités et donc réaffecter les "points".
Le soucis c'est de bien maîtriser les indépendances et inter-dépendances des différents points. Et les clients, comme les développeurs, ont tendance à voir les entrées comme un bloc, et donc utiliser le découpage pour arriver aux "points"/"tâches". Et je pense que c'est cette approche tout en début de projet (recueil de besoin, rédaction de cahier des charges et/ou spécifications) qui mène à de mauvaises pratiques agiles.
Le même principe devrait être appliqué à l'autre bon de la chaîne concernant les releases. A la fin de chaque cycle, on devrait avoir une nouvelle version. Bye-bye les 1.2, 1.3, 1.3.1, 1.2.1 (ou pire 1.2 RC1, 1.2 RC2), mais uniquement un seul numéro séquentiel 1,2,3...20 !. Exactement comme Chrome et comme cela a été adopté pour FireFox.
On acceptera tout de même des X.Y pour les correctifs s'il n'est pas possible de migrer à la dernière version.

Dans une méthode non-agile, on voit donc les entrées (spécifications, annexes, etc.) comme un ensemble cohérent ; et il en va de même pour les modifications de ces entrées : elles forment un tout.
Et quand l'équipe reçoit les entrées, elle doit tout accepter ou tout refuser jusqu'à ce que tout soit acceptable. Dans les faits le client ne veut pas revoir sa copie pendant X jours/semaines/mois/années avant que sa demande soit prise en compte et exiges à ce qu'on prenne les modifications en l'état avant d'avoir les détails (qui tuent ... le projet) ; et je ne parle même pas des incohérences que l'équipe de développement ne peuvent même pas trancher.


Pour en revenir aux méthodes agiles et les problèmes de responsabilité, il convient dans ce cas d'appliquer/utiliser des méthodes qualité.
Encore un autre aspect du projet.
Elles ne sont pas incompatibles avec les méthodes "agiles" même si il est généralement conseiller d'avoir des "process" "lightweight".
Toutefois le minimum est d'avoir des unités d'exigence identifiées ; et de les couvrir par des unités de test également identifiées.
L'existence/rédaction de ces tests impliquent généralement que l'exigence est correcte (en termes de contenu et de cohérence). Ensuite il est facile de vérifier si l'exigence est correctement implémentée (sauf si le test est pourri mais c'est une autre histoire), et donc si l'équipe est en défaut.
Par faciliter l'écriture des tests, XP utilise les "User stories" qui sont plutôt une bonne idée pour définir les scénarios (UP utilise également un principe très similaire).
Par ailleurs, le client devrait être capable de valider la cohérence des grandes lignes du test par rapport aux exigences qu'ils couvrent. En gros le scénario doit être correcte.
Souvent un problème d'exigence signifie qu'il est difficile/problématique/impossible d'écrire un ou plusieurs scénarios la vérifiant.


Bref, le développement ce n'est pas le seul aspect d'un projet. Et que tout développeur est confronté à ces aspects. Et ces derniers affectent nécessairement l'impact "direct" des changements mais également la manière dont ils sont perçus par les intervenants (client, CdP, architecte, concepteur, développeurs, etc.)

[souviron34]

.....

Je bosse en méthode "Agile" en ce moment, et je me rends compte que c'est la pire merde qui existe. En fait cette méthode ne peut être appliquée qu'avec un projet assez stable (type contrainte réglementaire) et des développeurs/concepteurs qui maitrisent à fond leur applicatif.

Dans tous les autres cas c'est la réalisation qui se prend toute la casse en amont (y compris les erreurs de modélisation et la non prise en compte des cas particuliers, qui représentent souvent 90% du boulot), et ça finit en guerre de tranchées pour savoir qui est responsable du moindre quart de journée de dépassement.

Comme tout le thread en parle, et que c'est un peu mon dada (et depuis plus de 20 ans), je souhaiterais apporter une nuance que j'ai déjà nommée plusieurs fois :

Le malheur de l'informatique (et de nos sociétés fin XX début XXIième) est de vouloir tout codifier et couler dans du "marbre" / papier....

L'Agilité n'est pas une METHODE, ni une METHODOLOGIE, c'est un ETAT D'ESPRIT et une forme d'équipe/gestion, qui, justement, NE DEVRAIT PAS être encadrée....

Que ce soit UP, RUP, XP, Scrum, ou autre, le "métier" (et la Fance est particulièrement forte sur ce point, à cause de l'importance des titres et des grades) a crée des "normes", mais ce ne sont que des visions "normatives" d'une conduite qui ne l'est pas, bien au contraire...

Relisez le Manifeste agile

La "mise en dur" de ce Manifeste et son application par des gens non conscients (sans doute par inexpérience) de ce que cela implique, conduit forcément à des échecs..

Tant que les gens qui veulent l'appliquer n'auront pas compris que justement cela implique de ne PAS avoir de norme , il y aura ces visions négatives et ces expériences de b.rdel..

[el_slapper]

+1000 avec Souviron sur ce sujet. Mais j'aimerais reformuler à ma sauce :

Le problème, ce sont les gens qui suivent le petit manuel aveuglément. Ca peut marcher pour une production industrielle répétitive(et encore, l'industrie automobile en est partiellement revenue). Dans un domaine un peu moins prévisible, ça se plante systématiquement.

La solution, c'est de se dire : on va essayer les idées du petit manuel, on va garder ce qui marche, et remplacer ce qui ne marche pas, par des idées de notre cru - ou d'un autre petit manuel, peu importe. Et ce, de manière itérative. Ce que les "démarches qualité" appellent "l'amélioration continue". Peu importe que ce soit formalisé ou non. L'important est que ça soit fait.

Par exemple, Scrum exige une réunion matinale "stand-up". Si tout le monde n'est pas sur le même site, ou si certains arrivent à 7 heures et d'autres à 11, ça peut poser des problèmes. L'important, c'est d'avoir un mécanisme de feed-back rapide(c'est ça la raison du stand-up), pas d'avoir un stand-up. Ca peut être un "management par la promenade", ou le chef est tout le temps en train de se balader et de transférer les informations et les ressentis. Ou un stand-up "militarisé", avec tout le monde au garde-à-vous dans la cour, parceque les développeurs Chinois avaient tendance à regarder leur mobile plutôt que d'écouter ce qui se passer dans un stand-up plus informel(ça ne marcherait jamais en France, ça, mais l'équipe chinoise est devenue très, très efficace après ça, et 2-3 autres ajustements culturels).

Pareil pour le contenu des "sprints". Si on essaye de signer un contrat complet de type forfait à chaque sprint de 2-3 semaines, on passe plus de temps à négocier(et à mentir) qu'à travailler à faire avancer le projet.

Suivant les cultures locales(qui varient d'un pays à l'autre, mais aussi d'un coté de la rue à l'autre, à coté de la BNP à Montreuil y'a Ubi Soft, et la culture y est certainement très différente), plus ou moins de formalisation sera nécéssaire. En d'autres termes, appliquer le petit manuel est la garantie de se retrouver dans un cul-de-sac.

[Logan Mauzaize]

L'Agilité n'est pas une METHODE, ni une METHODOLOGIE, c'est un ETAT D'ESPRIT et une forme d'équipe/gestion, qui, justement, NE DEVRAIT PAS être encadrée....

J'ai envie de dire : "Et alors ?"
Une méthode agile c'est simplement une méthode qui a l'état d'esprit de l'agilité.

Que ce soit UP, RUP, XP, Scrum, ou autre, le "métier" (et la Fance est particulièrement forte sur ce point, à cause de l'importance des titres et des grades) a crée des "normes", mais ce ne sont que des visions "normatives" d'une conduite qui ne l'est pas, bien au contraire...

Je me trompes peut-être mais il me semble que tous les noms que tu cites sont plutôt anglosaxons ?

Tant que les gens qui veulent l'appliquer n'auront pas compris que justement cela implique de ne PAS avoir de norme , il y aura ces visions négatives et ces expériences de b.rdel..

Mettre des mots sur une démarche relativement précise ("Scrum" par exemple) permet de mettre tout le monde d'accord et que chacun se comprenne.
Toujours l'exemple de "Scrum", quand on parle de "Sprint" ou "Backlog" tout le monde comprend ce que cela signifie et implique.

Tu as le même problème avec CMMi qui n'est qu'un amas de principe et dont chacun doit trouver des implémentations/solutions. Dans la vie de tous les jours, la théorie n'a pas beaucoup d'écho et le pragmatisme s'en donne à coeur joie. Dès qu'un gars dit, on fait comme ci-comme ca, on passe vraiment des "ténèbres" à la "lumière" (ou du "chaos" à "l'ordre").
Et comme dans la vie de tous les jours tu n'as pas des gars attitrés à cela et que chacun voit les choses un peu différemment si on peut trouver une sorte de consensus externe, tout le monde se met d'accord plus facilement. Parce que l'idée est externe, que ses auteurs sont "reconnus", qu'ils ont déjà vécus des "exceptions" à la théorie.

Pareil pour le contenu des "sprints". Si on essaye de signer un contrat complet de type forfait à chaque sprint de 2-3 semaines, on passe plus de temps à négocier(et à mentir) qu'à travailler à faire avancer le projet.

Sauf que dans un monde B2B (Business To Business), tout est régi par des contrats ; et donc des négociations/batailles incessantes.


On digresse légèrement et je verrai très bien cette discussion continué sur le sujet concernant les méthodes agiles ;-)

[souviron34]

J'ai envie de dire : "Et alors ?"
Une méthode agile c'est simplement une méthode qui a l'état d'esprit de l'agilité.

Le mauvais terme ici est méthode ..

Quand je (et le Manifeste) dis que c'est un état d'esprit, c'est que justement il n'y a pas une "méthode" associée..

La défintiion de rôles, d'étapes, d'éléments précis, est justement antinomique...

C'est purement un état d'esprit dans lequel, avec l'équipe que l'on a , on gère le temps / les specs / le projet / les finances suivant simplement un plan souple...

Je me trompes peut-être mais il me semble que tous les noms que tu cites sont plutôt anglosaxons ?

Je n'ai pas dit le contraire, je dis que c'est encore plus voué à l'échec en France à cause de l'influence des titres et des grades (la référence que j'ai pointée dans l'autre discusssion sur un site de recherche de jobs aux US montre que chercher "scrum master" ne donne rien, contrairement à une recherche similaire en France).

La mentalité française fige dans des rôles , parce que ce sont des titres et non des fonctions volatiles et changeantes pour une personne..

Mettre des mots sur une démarche relativement précise ("Scrum" par exemple) permet de mettre tout le monde d'accord et que chacun se comprenne.

Sauf que cette démarche est déjà en elle-même porteuse du biais, en identifiant des rôles et des étapes qui en fait dépendent des projets et des équipes, et non de la "méthodologie" suivie..

Toujours l'exemple de "Scrum", quand on parle de "Sprint" ou "Backlog" tout le monde comprend ce que cela signifie et implique.

Non, pas sur le "sprint"... Déjà le terme en lui-même indique une précipitation...

Tu as le même problème avec CMMi qui n'est qu'un amas de principe et dont chacun doit trouver des implémentations/solutions. Dans la vie de tous les jours, la théorie n'a pas beaucoup d'écho et le pragmatisme s'en donne à coeur joie. Dès qu'un gars dit, on fait comme ci-comme ca, on passe vraiment des "ténèbres" à la "lumière" (ou du "chaos" à "l'ordre").

Sauf que justement, l'esprit agile n'est PAS une théorie, mais un pragmatisme, et que les "méthodlogies" le transforme en théorie...

Sauf que dans un monde B2B (Business To Business), tout est régi par des contrats ; et donc des négociations/batailles incessantes.

Non, en général en informatique le B2B est régi par "j'ai besoin de ça" et "voilà".

Considérer des négociations comme des "batailles" implique déjà d'être passé à côté de l'essentiel de l'agilité..

On digresse légèrement et je verrai très bien cette discussion continué sur le sujet concernant les méthodes agiles ;-)

Pas vraiment, non.. Le PO dit :

On (nous les développeurs) râle tous sur le fait que les spécifications (surtout fonctionnelles) ne doivent pas changer
...
La citation précise le cas des processus itératifs comme UP. Donc peut-être que personne n'utilise un processus itératif. ça j'en doute vu qu'il est rare de voir une offre d'emploi ne stipulant pas la connaissance des méthodes Agile, famille à laquelle appartient UP.

[Luckyluke34]

L'Agilité n'est pas une METHODE, ni une METHODOLOGIE, c'est un ETAT D'ESPRIT et une forme d'équipe/gestion, qui, justement, NE DEVRAIT PAS être encadrée....

Je suis à la fois d'accord et pas d'accord.

Il y a pour moi trois niveaux dans l'agilité.

• Valeurs

• Principes

• Pratiques

Les valeurs et les principes sont tous deux définis dans le manifeste agile. La différence entre les deux c'est qu'une valeur est "tout le temps vraie", dans le sens où toute action entreprise s'inscrit dans une ou plusieurs des valeurs de l'agilité. Les valeurs sont des références vers lesquelles on peut se tourner lorsqu'on s'interroge sur la pertinence d'une pratique. On peut dire avec pas mal de certitude qu'une organisation qui va à l'encontre d'une des valeurs n'est pas agile.
Les principes sont une application un peu plus concrète, un peu plus situationnelle des valeurs. Certains principes sont plus valables que d'autres suivant le contexte. On peut les adopter en totalité ou en partie.

Les pratiques agiles quant à elles ne sont pas définies dans le manifeste lui-même. C'est à chaque équipe de définir ses propres pratiques en fonction de son contexte, en respect des valeurs et des principes qu'elle a choisis. Les pratiques ne sont pas universellement transplantables, une pratique agile qui marche bien dans une équipe peut être catastrophique dans une autre.

La notion de méthode agile existe aussi bel et bien. Il s'agit de Scrum, XP, Crystal... Elles "implémentent" le manifeste en proposant un jeu de pratiques, voire en "surchargeant" certains principes.

En conclusion, une équipe qui aspire à être agile peut créer ses propres pratiques, adopter celles d'une méthode ou de plusieurs méthodes voire les transformer, du moment que les valeurs agiles sont le point de mire.

(PS : je décris juste la représentation que se sont faite les auteurs du manifeste et de méthodes comme XP de ce que devait être un cadre de développement logiciel, je ne dis pas que cette représentation est la meilleure).

[Logan Mauzaize]

Le mauvais terme ici est méthode ..

Quand je (et le Manifeste) dis que c'est un état d'esprit, c'est que justement il n'y a pas une "méthode" associée..

De ce que j'ai compris le "Manifeste Agile" est simplement née de l'abstraction des méthodes des auteurs à savoir celles justement citées.

La défintiion de rôles, d'étapes, d'éléments précis, est justement antinomique...

Si je prend (encore et toujours) l'exemple de SCRUM (désolé les deux seuls articles que j'ai lu traitait quasi-uniquement de cette méthode), il s'agit à peu de chose près d'avoir associé un "mot" à chacun des principes.
On pourrait tout aussi bien traduire :
"Product Owner" "Client"
"Sprint" "Itération"
"Backlog" "Périmètre"

Je n'ai pas dit le contraire, je dis que c'est encore plus voué à l'échec en France à cause de l'influence des titres et des grades (la référence que j'ai pointée dans l'autre discusssion sur un site de recherche de jobs aux US montre que chercher "scrum master" ne donne rien, contrairement à une recherche similaire en France).

La mentalité française fige dans des rôles , parce que ce sont des titres et non des fonctions volatiles et changeantes pour une personne..

Elever à la méthode franco-française, je n'irai pas te contredire.

Cependant il faut avouer qu'il est plus facile de décrire (un "poste" ou toutes autres choses) en utilisant quelques mots clés. Toutefois il faut reconnaître que les annonces sur les sites d'emploi sont souvent fumeuses. Je ne sais pas ce trop ce qu'il en ait sur les sites étrangers ?

Sauf que cette démarche est déjà en elle-même porteuse du biais, en identifiant des rôles et des étapes qui en fait dépendent des projets et des équipes, et non de la "méthodologie" suivie..

Je pense que c'est surtout pour avoir de bonnes idées et une ligne de conduite de base, la définition d'une méthode quoi .
Après dans les faits chacun le fait à sa sauce, c'est comme tout. Chacun a ses propres rituels.

Non, pas sur le "sprint"... Déjà le terme en lui-même indique une précipitation...

Il est vrai que le terme a cette connotation, mais c'est bien pour souligner le caractère court et "ligne droite".
Je ne sais pas s'il s'agit d'une bonne traduction "litteral" mais le terme "foulée" me semble bien retranscrire l'idée.

Sauf que justement, l'esprit agile n'est PAS une théorie, mais un pragmatisme, et que les "méthodlogies" le transforme en théorie...

S'agissant du résultat de l'abstraction des méthodes des différents auteurs, le manifeste agile est quoiqu'il arrive plus théorique que les méthodes en question.

Non, en général en informatique le B2B est régi par "j'ai besoin de ça" et "voilà".
Considérer des négociations comme des "batailles" implique déjà d'être passé à côté de l'essentiel de l'agilité..

La notion d' "Entreprise" (en tout cas en France) implique nécessairement cette dualité entre les intervenants. Chacun veut que ça lui coûte un minimum et lui rapporte un maximum.
Même si je comprends bien que c'est contraire aux méthodes agile.

Pas vraiment, non.. Le PO dit :

Disons que le problème devient de plus en plus orienté sur l'agilité et non sur la gestion du changement. Même si sur ce point l'agilité apporte beaucoup de réponse.

[marton92]

Comme tout le thread en parle, et que c'est un peu mon dada (et depuis plus de 20 ans), je souhaiterais apporter une nuance que j'ai déjà nommée plusieurs fois :

Le malheur de l'informatique (et de nos sociétés fin XX début XXIième) est de vouloir tout codifier et couler dans du "marbre" / papier....

L'Agilité n'est pas une METHODE, ni une METHODOLOGIE, c'est un ETAT D'ESPRIT et une forme d'équipe/gestion, qui, justement, NE DEVRAIT PAS être encadrée....

Que ce soit UP, RUP, XP, Scrum, ou autre, le "métier" (et la Fance est particulièrement forte sur ce point, à cause de l'importance des titres et des grades) a crée des "normes", mais ce ne sont que des visions "normatives" d'une conduite qui ne l'est pas, bien au contraire...

Relisez le Manifeste agile

La "mise en dur" de ce Manifeste et son application par des gens non conscients (sans doute par inexpérience) de ce que cela implique, conduit forcément à des échecs..

Tant que les gens qui veulent l'appliquer n'auront pas compris que justement cela implique de ne PAS avoir de norme , il y aura ces visions négatives et ces expériences de b.rdel..

Voilà c'est exactement ça, la méthode Agile c'est un état d'esprit. Malheureusement les donneurs d'ordre veulent de l'Agile quand ça les arrange, mais dès qu'on parle des choses qui fâchent (au hasard les dépassements de charge) on revient aux bonnes vieilles méthodes où il faut tout justifier à postériori, refaire de la paperasse, des réunions managers, et on passe 3 jours à justifier le moindre dépassement d'une demi-journée. Bref ce n'est jamais gérable avec certains clients, et encore plus ceux qui ont sous-chiffré sans comprendre qu'avec cette méthode le développement avait au contraire bien plus de contraintes à gérer que s'ils avaient un cahier des charges et des specs propres et (surtout) stables et exhaustives.

[souviron34]

De ce que j'ai compris le "Manifeste Agile" est simplement née de l'abstraction des méthodes des auteurs à savoir celles justement citées.

Tu es passé complètement à côté de l'origine...

C'est le contraire...

Dixit le Manifeste :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers

C'est au contraire par le fait de s'être frottés (comme moi) à la pratique de cycles en V dans de multiiples (et souvent gros) environnements que naît la détection des problèmes inhérents, et qu'ils ont pondu ce Manifeste.. (voir la première partie du premier point : "les individus et leurs interactions" est priviliégié par rapport à "les processus et les outils")

C'est au contraire à l'opposé de l'abstraction !!!! Il n'y a rien de plus terre à terre...

D'où la défiance prononcée vis-à-vis de toute norme, même si celle-ci se qualifie "d'agile"..

Si je prend (encore et toujours) l'exemple de SCRUM (désolé les deux seuls articles que j'ai lu traitait quasi-uniquement de cette méthode), il s'agit à peu de chose près d'avoir associé un "mot" à chacun des principes.
On pourrait tout aussi bien traduire :
"Product Owner" "Client"
"Sprint" "Itération"
"Backlog" "Périmètre"

Eh bien tu vois, comme nous en avons discuté de l'autre côté, c'est assez antinomique de l'esprit initial :

• "Product Owner" est d'une part idientifié comme une personne (à mon sens 2 : un utilisateur expert et un techicien généraliste CP), d'autre part n'est pas spécifié "pour ce projet-là et pas un autre".... et enfin c'est toute l'équipe qui est Product Owner dans l'esprit du Manifeste
  
  
• "Sprint" possède d'une part une notion de vitesse, et donc de "bâclage", d'autre part une fréquence associée, qui est absurde : si on a besoin, cela doit être fait tous les jours, voire 2 fois par jour, ou pour d'autres éléments une fois tous les 2 mois... Justement l'agilité doit être sur des parties du logiciel autant que sur le tout : il est donc assez stupide de proposer des fréquences pour l'ensemble.... C'est pourquoi je prône (et le Manifeste également) la présence d'utilisateurs experts de manière quasi-permanente..
  
  
• "Backlog" signifie "retard accumulé".. Pour moi un backlog c'est l'accumulaton de ce qui aurait dû être fait et n'a pas été fait... Je ne vois pas de notion de périmètre là-dedans (ou alors c'est que justement on n'a pas correctement défini le périmètre en amont)

Il est vrai que le terme a cette connotation, mais c'est bien pour souligner le caractère court et "ligne droite".
Je ne sais pas s'il s'agit d'une bonne traduction "litteral" mais le terme "foulée" me semble bien retranscrire l'idée.

Non, la bonne traduction serait "étape" ou "bouclage provisoire", mais comme dit plus haut c'est un non-sens..

Cependant il faut avouer qu'il est plus facile de décrire (un "poste" ou toutes autres choses) en utilisant quelques mots clés. Toutefois il faut reconnaître que les annonces sur les sites d'emploi sont souvent fumeuses. Je ne sais pas ce trop ce qu'il en ait sur les sites étrangers ?

Comme j'ai cité, va regarder par exemple Dice.com et cherche "scrum master"...

Non... Ce ne sont pas quelques mots-clés qui donneront ça.. C'est à l'entretien et à l'expérience : quelqu'un qui en a, par exemple, mais qui est souple (a fait plusieurs projets, dans plusieurs environnements). Et à l'entretien c'est quelq'un qui n'est pas "droit comme un I" sur la théorie, les langages ou les outils ou les méthodes, mais qui a des (assez larges) connaissances...

C'est pour ça que la notion de RH est fondamentale dans l'agilité : tout est dans les hommes (ou femmes), alors qu'en "traditionnel" tout le monde est remplaçable, les chiffrages se font en nombre de lignes de code ou points de fonctions, et la charge (et le coût) se fait(font) en homme/jour...

En agilité (suivant le Manifeste) le chiffrage se fait en jours. (compte-tenu de l'équipe que tu as ou peut assembler..)

Je pense que c'est surtout pour avoir de bonnes idées et une ligne de conduite de base, la définition d'une méthode quoi .
Après dans les faits chacun le fait à sa sauce, c'est comme tout. Chacun a ses propres rituels.

Alors la base est le cycle en V...

Il est absurde de prétendre autre chose...

C'est juste que les étapes, la gestion, les documents, et l'ordre sont mélangés...

Mais il n'y a aucun besoin de savoir plus que le cycle en V..

S'agissant du résultat de l'abstraction des méthodes des différents auteurs, le manifeste agile est quoiqu'il arrive plus théorique que les méthodes en question.

Voir plus haut c'est le contraire...

Le Manifeste est au contraire un outil pratique : il vaut mieux une équipe ne suivant aucune norme et qui s'entend, composée de gens complémentaires et bons, qu'une équipe formattée, divisée en entités qui ont de la difficulté à communiquer, et suivant des règles..

La notion d' "Entreprise" (en tout cas en France) implique nécessairement cette dualité entre les intervenants. Chacun veut que ça lui coûte un minimum et lui rapporte un maximum.
Même si je comprends bien que c'est contraire aux méthodes agile.

Non, ce n'est pas du tout contraire...

C'est la manière de le voir : il est parfaitement normal que pour les 2 parties il faut que ça coûte un minimum et que ça rapporte un maximum..

C'est juste que ce ne doit pas être vu comme une "bataille" mais une "collaboration" , un échange de bons procédés : l'objectif de l'un est atteint lorsque l'objectif de l'autre est atteint, et réciproquement..

Il n'y a d'aucune manière opposition de demandes, d"exigences, ou de buts..

Chacun a le même but : avoir le meilleur produit qui soit au meilleur coût...

Et meilleur ne veut pas dire "qui rapporte le plus d'argent", mais "qui rapporte le plus" : notoriété, satisfaction, et, éventuellement (en conséquence) argent : si tu es réputé avoir le meilleur soft, les clients vont se l'arracher et tu vas faire des sous.. si tu es réputé avoir fait le meilleur soft, les boîtes vont se battre pour t'avoir, et donc tu vas faire des sous....

[el_slapper]

Dans cet article de Martin Fowler, remis à jour hier, un détail intéréssant, qui à mon sens se rapporte à cette discussion :

One of Kent's suggested names for 'Agile' was conversational software development - the point being that it's a two way communication. This isn't something like a telecoms protocol that you can define, but the back and forth discussions about how software can enhance the business are where the real value lives. Much of this conversation is of half-baked ideas, some of which grow into valuable features - often ones that aren't things that the customer originally thought of.

En Français(traduction par ma pomme, si vous faites mieux, je prends) : Un des noms suggérés par Kent Beck pour "Agile" etait "développement logiciel conversationel" - avec l'idée que c'est une communication dans les deux sens. Ce n'est pas comme un protocole de télécommunications que vous pourriez définir, mais que des discussions aller-et-retour sur comment le logiciel peut améliorer le business sont la ou la valeur réelle se trouve. L'essentiel de cette conversation est constituée d'idées incomplètes, dont certaines grandiront en des fonctionalités de valeur - souvent des choses auquel le client n'avait pas initialement pensé.

Ce qui va dans le sens de Souviron34 : l'interaction prime sur la méthode - la discussion à bâtons rompus prime sur le protocole de conversation. Et on parle de 2 des principaux auteurs du manifeste.

[Logan Mauzaize]

Tu es passé complètement à côté de l'origine...

Je quote le lien Wikipedia que tu as donné :

Le Manifeste Agile est considéré comme l'acte généralisateur des méthodes agiles sous la dénomination initiale de Agile Manifesto

Ces 17 experts venant tous d'horizons différents réussirent à extraire de leur concepts respectifs des critères pour définir une nouvelle façon de développer des logiciels

Dixit le Manifeste :

Rien que les termes "Principes" et "Valeurs" n'ont rien de pragmatiques ... Et qu'une méthode d'application de tout ceci me paraît pas aberrant.
J'en reviens à CMMi qui te dit qu'il faut "quantifier" le travail (indicateur), tu peux le faire de XXXX manières qui soit, ben pareil pour "Les individus et leurs interactions plus que les processus et les outils", ça implique beaucoup de choses.

C'est au contraire par le fait de s'être frottés (comme moi) à la pratique de cycles en V dans de multiiples (et souvent gros) environnements que naît la détection des problèmes inhérents, et qu'ils ont pondu ce Manifeste.. (voir la première partie du premier point : "les individus et leurs interactions" est priviliégié par rapport à "les processus et les outils")

C'est au contraire à l'opposé de l'abstraction !!!! Il n'y a rien de plus terre à terre...

D'où la défiance prononcée vis-à-vis de toute norme, même si celle-ci se qualifie "d'agile"..

Déjà il ne s'agit pas de norme. Ce qui imposerait quelque chose de contraignant et notamment des "audit". Dans ce cas, on serait comme tu le dis à l'opposé de l'agilité.
Et il s'agit bien de ce que j'évoquai : "une ligne de conduite" ou "guide line". Ca permet quand tu doutes que ca dérive, d'en revenir à quelque chose de "sain".

"Product Owner" est d'une part idientifié comme une personne (à mon sens 2 : un utilisateur expert et un techicien généraliste CP), d'autre part n'est pas spécifié "pour ce projet-là et pas un autre".... et enfin c'est toute l'équipe qui est Product Owner dans l'esprit du Manifeste

C'est rarement à l'équipe de réalisation de décider. Ils peuvent "peser" mais ça doit se limiter à ça.
Et l'oligarchie n'a fonctionné chez les Hommes, il faut toujours un juge/décideur/directeur/donneur d'ordre. Et celui qui paye me semble le plus approprié.

"Sprint" possède d'une part une notion de vitesse, et donc de "bâclage", d'autre part une fréquence associée, qui est absurde : si on a besoin, cela doit être fait tous les jours, voire 2 fois par jour, ou pour d'autres éléments une fois tous les 2 mois... Justement l'agilité doit être sur des parties du logiciel autant que sur le tout : il est donc assez stupide de proposer des fréquences pour l'ensemble.... C'est pourquoi je prône (et le Manifeste également) la présence d'utilisateurs experts de manière quasi-permanente..

Pour commencer les "Sprint" ne sont pas nécessairement de longueur égales et vont de quelques heures à plusieurs mois. Mais idéalement deux semaines, ce qui me semble correcte pour bien implémenter/tester quelques fonctionnalités avant d'envoyer au client.

Ensuite si on peut avoir constamment sous la main quelqu'un s'est bien. Mais la réalité est que ce n'est pas trop possible. Et ce n'est pas parce qu'on fait sans qu'on n'est pas "agile" sinon ce serait contraignant et donc tu l'admettras à l'opposé de ce que prône "Le Manifeste Agile".

"Backlog" signifie "retard accumulé".. Pour moi un backlog c'est l'accumulaton de ce qui aurait dû être fait et n'a pas été fait... Je ne vois pas de notion de périmètre là-dedans (ou alors c'est que justement on n'a pas correctement défini le périmètre en amont)

T'es sérieux ?

Le périmètre c'est un ensemble de fonctionnalité, tout comme le produit ou les backlogs. Il y a les fonctionnalités qu'on a déjà traitées, celles qu'on va traiter et celles qu'on a pas encore traitées.
Si tu ne traites pas le produit comme un ensemble de fonctionnalité indique moi ta démarche, et je réviserai éventuellement mes idées préconçues du génie logiciel.
Autrement, soit tu fais tout d'un bloc, ce qui n'est pas du tout agile, soit tu le fais par "morceaux" et peu importe que tu appelles ça "itération", "version" ou autre ca reste ni plus ni moins que la définition de "sprint backlog".

Comme j'ai cité, va regarder par exemple Dice.com et cherche "scrum master"...

Non... Ce ne sont pas quelques mots-clés qui donneront ça.. C'est à l'entretien et à l'expérience : quelqu'un qui en a, par exemple, mais qui est souple (a fait plusieurs projets, dans plusieurs environnements). Et à l'entretien c'est quelq'un qui n'est pas "droit comme un I" sur la théorie, les langages ou les outils ou les méthodes, mais qui a des (assez larges) connaissances...

En fait je parlais des emplois en général et non ceux qui tournent exclusivement autour de l'agilité.
Si je suis sur un secteur/contrat/plateau/équipe sur du Java, je pense qu'il est normale de mettre "Java" comme mot clé. Ensuite ça dérive parfois largement, par exemple j'ai travaillé sur un projet Java classique et on vendait ça comme du J2EE ...
Ou encore les annonces qui recherchent un débutant expert en 18 trucs totalement différents.

C'est pour ça que la notion de RH est fondamentale dans l'agilité : tout est dans les hommes (ou femmes), alors qu'en "traditionnel" tout le monde est remplaçable, les chiffrages se font en nombre de lignes de code ou points de fonctions, et la charge (et le coût) se fait(font) en homme/jour...

En agilité (suivant le Manifeste) le chiffrage se fait en jours. (compte-tenu de l'équipe que tu as ou peut assembler..)

Ca revient à peu de chose près à la même chose ... Dans la mesure où chaque chiffrage est pondéré par son auteur.
Cependant dans la méthode "traditionnel", on vend un coût et un délai.

L'avantage du "tout le monde est remplaçable" permet de tenir de compte des choses qui arrivent : les absences sur le projet (accident, maladie, naissance, décès, mariage, démission, besoin sur un autre projet, etc.) ou des réaffectations (retard, blocage, conseil/expertise/aide, etc.)

Le Manifeste est au contraire un outil pratique : il vaut mieux une équipe ne suivant aucune norme et qui s'entend, composée de gens complémentaires et bons, qu'une équipe formattée, divisée en entités qui ont de la difficulté à communiquer, et suivant des règles..

Il vaut mieux un minimum d'organisation que l'anarchie. Tout "stage"/"court"/"TP" sur la gestion de projet en fait généralement la démonstration : on scinde les intervenants en équipe, on extrait une tête de chaque et on leur donne comme consigne de plus ou moins intervenir avec quelques règles (genre ne pas parler, parler uniquement en beuglant, etc.) ; ensuite tu balances un petit projet genre réaliser des ponts en papier.
Généralement c'est l'équipe la mieux organisée qui réalise le meilleur projet.

C'est la manière de le voir : il est parfaitement normal que pour les 2 parties il faut que ça coûte un minimum et que ça rapporte un maximum..

C'est juste que ce ne doit pas être vu comme une "bataille" mais une "collaboration" , un échange de bons procédés : l'objectif de l'un est atteint lorsque l'objectif de l'autre est atteint, et réciproquement..

Il n'y a d'aucune manière opposition de demandes, d"exigences, ou de buts..

Chacun a le même but : avoir le meilleur produit qui soit au meilleur coût...

Et meilleur ne veut pas dire "qui rapporte le plus d'argent", mais "qui rapporte le plus" : notoriété, satisfaction, et, éventuellement (en conséquence) argent : si tu es réputé avoir le meilleur soft, les clients vont se l'arracher et tu vas faire des sous.. si tu es réputé avoir fait le meilleur soft, les boîtes vont se battre pour t'avoir, et donc tu vas faire des sous....

Déjà que je trouvais que l'agilité avait un côté "communiste" mais l'a tu m'as définitivement convaincu !
Tout cela suppose l'absence de rapport qualité/coût ou bien l'infinité des ressources (... sans parler de l'effacement des individualités).
Je me demande bien pourquoi il y a plus de gens qui achètent des Dacia que des Mercedes, pourtant cette dernière est bien meilleur.