Discussion :

[theMonz31]

je sais bien que dans tous les métiers il faut des méthode...

je dis juste qu'imposer des méthodes, comme celà a déjà été dit, ne garantit en rien la réussite du projet...

Moi, j'aime bien créer quelque chose de différents à chaque fois en développement, sinon, je prends des patterns tout fait, des MVVM tout fait et mon métier devient
de l'assemblage, de la recopie, etc.. bref, plus il y a de méthodes en place, et moins, en général, il faut réfléchir... et se contenter d'appliquer des méthodes... et ça, mais
je suis peut-être atypique, ça me saoule !!!

[Traroth2]

Ben, quand tu as un projet d'ordre réglementaire(notre quotidien, dans le médical, sur la partie comptable), c'est inévitable. Si le jour J on est pas prêt, on a plus qu'à mettre la clef sous la porte. Et le délai est imposé par des gens dans des bureaux du ministère, encore plus loin de moi que ta personne du marketing.

Et sinon, pour du fonctionnel, on peut choisir une date, et accepter de perdre des fonctionnalités en cours de route. Ça peut être parfaitement rationnel de dire que le 1 Janvier, la nouvelle version doit être prête, avec toutes les évolutions réglementaires pour 2016... et on essayera d'y mettre un maximum de vraies évolution aussi, mais ça, ça dépendra de ce qui est possible. Nous, en tous cas, on marche comme ça, et on a des fonctionnalités qui trainent dans les cartons depuis des années, que les clients réclament, mais avec nos faibles moyens et l'épée de Damoclès du réglementaire, ça doit attendre. C'est triste, mais nos concurrents ont les mêmes soucis.

Typiquement un faux problème. Les délais pour changer le taux de TVA sont toujours largement suffisants. Sauf si l'équipe technique doit absolument faire un truc "super important" dans l'intervalle. Je ne connais pas de cas où un changement réglementaire a créé une tension dans un planning sans intervention d'abrutis bien maison qui du haut de leur ignorance ont considéré que ça pouvait attendre.

[Traroth2]

La définition d'un planning se fait dans un échange entre le marketing et la technique.
Il y a un besoin business que le projet soit délivré à telle date.
La technique doit être en mesure de dire au marketing, pour telle date, je suis en mesure de délivrer tel périmètre sous telles conditions (jalons de spec, équipes, etc).
Et y a échange jusqu'au compromis mutuellement acceptable.

La technique seule ne peut pas définir un planning.
De même, je suis de ton avis, que le marketing ne peut pas le faire seul non plus.

Le délai nécessaire serait une négociation ? Je te conseille d'essayer ça avec la durée de gestation d'une femme enceinte, pour voir ce que ça donne...

Ce n'est clairement pas la bonne manière de penser. Parce que justement, la partie non-technique n'a rien d'autre à indiquer que la pensée magique que j'évoquais plus haut. La seule circonstance où ce que tu dis s'applique, c'est si on peut négocier sur les moyens qu'on peut attribuer au projet. Mais le plus souvent, ça ne change pas grand-chose (lire "The mythical man-month")

Et les résultats de la politique actuelle sont là, sous forme d'innombrables projets dans le fossé. De nos jours, les projets qui atteignent tous leurs objectifs dans les délais et dans le budget, c'est l'exception. C'est dire à quel point on est dans une fiction d'efficacité. Il faudrait déjà réaliser que la situation actuelle n'est pas satisfaisante avant de vouloir justifier les pratiques actuelles.

[theMonz31]

Et les résultats de la politique actuelle sont là, sous forme d'innombrables projets dans le fossé. De nos jours, les projets qui atteignent tous leurs objectifs dans les délais et dans le budget, c'est l'exception. C'est dire à quel point on est dans une fiction d'efficacité. Il faudrait déjà réaliser que la situation actuelle n'est pas satisfaisante avant de vouloir justifier les pratiques actuelles.

Excellente analyse

Ce qui tend à "prouver" que les différentes méthodologies, méthodes et autres process ne sont pas un garde fou pour la réussite d'un projet.

Je pense que, la réussite d'un projet est VRAIMENT et presque UNIQUEMENT lié à la qualité de l'équipe et à la qualité du management à tirer partie du meilleur de chacun, quelque soit les compétences de l'équipe (évidemment, si il n'y a que des novices pour un problème complexe, ça risque de créer du retard, délai...)

[Saverok]

Le délai nécessaire serait une négociation ? Je te conseille d'essayer ça avec la durée de gestation d'une femme enceinte, pour voir ce que ça donne...

Si la mère accepte que son enfant n'est ni bras ni jambe, je suis sûr qu'on peut gagner quelques semaines

Blague à part, l'analogie avec le biologique n'a pas de sens.
Un projet info a un périmètre et il est possible de jouer avec ce périmètre pour trouver un compromis.

Le post de Bono_Mx illustre parfaitement mon propos :

Petit retour d'expérience qui s'est bien passé : pour faire face à des délais très court, nous étions arrivé à un compromis avec les équipes de production sur le fait qu'ils auraient bien les fonctionnalités demandées à temps, mais au lieu d'avoir une interface ce seraient de bonnes vieilles lignes de commande, et au lieu d'un beau reporting, un vieux csv tout basique.
Et ça a marché, nous avons pu leur implémenter "le sucre" plus tard, et tout le monde était content (happy ending).

Ce n'est clairement pas la bonne manière de penser. Parce que justement, la partie non-technique n'a rien d'autre à indiquer que la pensée magique que j'évoquais plus haut.

Le besoin métier est justement l'origine du projet.
S'il n'y a pas de besoin métier, il n'y a pas de projet donc pas de développeur

Par exemple, le métier souhaite mettre en place un service d'emballage cadeau pour les fêtes de fin d'année.
Il serait totalement absurde de la part des équipes de dev de dire "on vous fait ce dev pour février car impossible pour fin novembre..."

On ne fait pas de l'informatique pour le plaisir de faire du dev logiciel.
On est là pour répondre à un besoin métier et ce besoin inclut un planning car cela a un impact business et organisationnel fort.

Maintenant, il s'agit de bien comprendre le "besoin" au delà de la demande.
Quel est l'action réellement demandée ?
Une fois que l'on a compris cela, on peut proposer des modes d'implémentations minimalistes mais qui permettent de répondre au besoin (pas d'interface graphique ou minimaliste, un reporting texte, pas de temps réel mais 1x/h, etc.).

[Logan Mauzaize]

Le délai nécessaire serait une négociation ? Je te conseille d'essayer ça avec la durée de gestation d'une femme enceinte, pour voir ce que ça donne...

Tu te méprends complétement entre contrainte et variable. C'est bien le principe de la négociation et de la planification. Chaque élément à sa part de variabilité : la taille de l'équipe, sa force de travail, sa productivité, etc.

Prenons spécifiquement ton exemple. On ne construit pas "un enfant", ce n'est donc pas le projet. "Faire du enfant" c'est un projet. Est-ce que l'accouchement est l'aboutissement du projet ? Non. Même en admettant qu'il soit confié à quelqu'un d'autres, il y a forte probabilité non négligeable qu'il te revienne dans la tronche au bout de quelques années .. ca marche aussi avec les projets informatiques !

Bref, ce n'est ni butoir, ni figé. Admettons que nous ayons atteint le jalon "Tomber enceinte", la variabilité s'étend de 0 à 398 jours. Bon admettons que ce délai est fixé à 273 jours. Il est toujours possible de finir les peintures, acheter la chambre, coudre soi-même l'édredon après !

Mais on peut négocier ce qu'on fera avant de ce qui sera fait après. Et même renégocier selon l'avancement de chaque élément (puisque tout variable), y compris le terme de la grossesse.

La seule circonstance où ce que tu dis s'applique, c'est si on peut négocier sur les moyens qu'on peut attribuer au projet. Mais le plus souvent, ça ne change pas grand-chose (lire "The mythical man-month")

Dans le vie tout se négocie En supposant justement une force de travail et une productivité constante, c'est bien là que toute la négociation va se faire.

Premièrement, il convient de prioriser. Ce qui permet justement en cas d'aléa de savoir rapidement ce qui sera sacrifié. Pour cela l'implication de l'ensemble des acteurs est importante pour bien comprendre toutes les contraintes et la variabilité (que ce réglementaire, commercial ou logiciel). Ex : Un salon prévu en septembre pour montrer l'application des nouvelles mesures réglemtnaires applicables en janvier. On prévoit la partie IHM pour septembre et la gestion des données et des règles à minima pour janvier. Les statistiques et la génération des graphiques, etc. pour plus tard.

Et les résultats de la politique actuelle sont là, sous forme d'innombrables projets dans le fossé. De nos jours, les projets qui atteignent tous leurs objectifs dans les délais et dans le budget, c'est l'exception. C'est dire à quel point on est dans une fiction d'efficacité. Il faudrait déjà réaliser que la situation actuelle n'est pas satisfaisante avant de vouloir justifier les pratiques actuelles.

En sus de ce que je viens d'expliquer j'en reviens à l'article et aux premiers commentaires. L'agilité repose sur une gouvernance mutualiste de l'ensemble des acteurs (ou tout du moins des différentes parties). Et c'est également de ce que j'ai décrit ci-dessus. Or dans les faits cette gouvernance n'est pas partagée. C'est donc de l'eau que tu retires de ton moulin

Je voudrais introduire une autre notion que je n'ai pas évoqué au sujet de la planification : la gestion du risque. Il ne faut pas non plus s'étonner que des projets sont dans le fossé, si les risques ne sont pas pris en compte. L'abolissement de l'effet tunnel est une action de gestion du risque qui illustre parfaitement une cause d'échec des projets.

Je l'ai déjà dit nous jouons avec des paramètres variables. J'ai évoqué uniquement l'amplitude comme attribut de la variabilité mais il y en a d'autres comme la distribution de la probabilité, mais il faut aussi évoqué les coûts, les délais, etc. Ne pas en tenir c'est justement prendre le risque de voir tout simplement son projet échoué.


Concernant purement l'article, les gens vendent des méthodes avec le "nom" mais pas les valeurs. Je pense qu'il est plus intéressant de vendre : la libération des échanges (idées, conversation, travail) entre les acteurs, l'implication de l'ensemble des acteurs et l'amélioration continue.

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

En effet, si les décisions techniques sont pilotées par la direction, on corrompe ce principe de l'Agilité.
L'auto-organisation est un élément très important dans l'agilité.

Je pense que le sujet ici n'est pas l'auto-organisation mais surtout un libre échange d'idées sans intermédiaire pour les temporiser, les modifier ou les bloquer. Mieux l'idée circule plus elle est critiquée et meilleure elle est. En revanche pour cela il faut que l'ensemble des acteurs se sentent impliqués et sur un pied d'égalité. Par exemple qu'un "débutant" ne se sente pas "trop nul" et s'interdise de faire une remarque qui pourrait être extrêment pertinente. Ou à contratio un "expert" qui se sentant blasé sur une question, n'aurait pas le courage d'aller au bout de son idée.

[ZenZiTone]

Le hic c'est que c'est un peu une obligation.
Dire au client "ça sera livré quand ça sera terminé" n'est tout simplement pas possible.

N'oublions pas qu'un projet peut se résumer en trois mots :

• Coût
• Délais
• Qualité

Ces trois éléments sont dépendants les uns des autres. Réduire le délais en conservant un même niveau de qualité implique d'augmenter les coûts (ajout de ressources), réduire le coût en conservant le délais implique de réduire la qualité, etc...

Donc non, on ne peut pas promettre de livrer un produit fini de bonne qualité en moins de temps que l'équipe ne peut lui accorder. Et cela est vrais en Agile, en Waterfall ou tout autre méthode de gestion de projet.

De plus, en Agile, il existe ce que l'on appelle le planning poker. On attribut un certain nombre de "points" à une certaine fonctionnalité. Ces points correspondent à un niveau de difficulté traduisible en temps de développement. Donc si ton équipe estime qu'il faudra x jours pour réaliser x fonctionnalités, il n'y a pas de raison de vendre un délais plus court. Le problème ici n'est donc pas la gestion de projet utilisé.

[Laurent 1973]

N'oublions pas qu'un projet peut se résumer en trois mots :

• Coût
• Délais
• Qualité

Moi, j'en rajouterais un quatrième: périmètre.
En effet, suit à un problème technique, pour respecter les même délais, le même coût sans baisser la qualité on peux faire le choix de réduire le paramètre fonctionnel de ce qui sera livré.

C'est ce que nous a relaté Bono_BX:

Je suis tout à fait d'accord. Petit retour d'expérience qui s'est bien passé : pour faire face à des délais très court, nous étions arrivé à un compromis avec les équipes de production sur le fait qu'ils auraient bien les fonctionnalités demandées à temps, mais au lieu d'avoir une interface ce seraient de bonnes vieilles lignes de commande, et au lieu d'un beau reporting, un vieux csv tout basique.
Et ça a marché, nous avons pu leur implémenter "le sucre" plus tard, et tout le monde était content (happy ending).

[el_slapper]

Typiquement un faux problème. Les délais pour changer le taux de TVA sont toujours largement suffisants. Sauf si l'équipe technique doit absolument faire un truc "super important" dans l'intervalle. Je ne connais pas de cas où un changement réglementaire a créé une tension dans un planning sans intervention d'abrutis bien maison qui du haut de leur ignorance ont considéré que ça pouvait attendre.

Euh, permets-moi d'être en désaccord. Une nouvelle norme comptable pour les fichiers à transmettre à la sécu, c'est très vite très compliqué. Pareil quand j'étais dans le bancaire(les normes Bale 2 et 3, tout un poème). Il ne s'agit pas juste de changer un taux dans une case, mais bel et bien de repenser la manière de comptabiliser un certain nombre d'actes médicaux. Ça a tout un tas d'effets fonctionnels assez vicieux. Et là, on en a une pour laquelle on a été prévenu à moins de 3 mois.

Je veux bien que quand tu fais un site web marchand standard, dédié à la vente au particuliers, ton réglementaire ne change pas souvent(même si il peut être compliqué). Quand tu t'adresse à des professionnels, qui ont un ministère à eux tous seuls pour leur pondre sans cesse de nouvelles normes(même hors compta, on a le Circuit de Bon Usage du Médicament qui arrive, et c'est un bouleversement des paramétrages qu'on a fait dans les hôpitaux - on a peu de code, mais énormément de travail d'adaptation sur site); c'est très différent. Et non, ce n'est pas un faux problème. Ça occupe souvent la moitié du temps de développement et de tests. Parfois plus, rarement moins. D'ailleurs, ma boite, comme certains de nos concurrents, sont des gens qui vendent un logiciel médical, et qui ont racheté un opérateur français pour la partie comptable, ce n'est pas un hasard. Ils savent qu'ils ne peuvent pas suivre sans partir sur un existant fiable(et nous, au moins, on a une intégration entre les deux qui marche, nyark nyark nyark.)

"Je ne connais pas", ça ne veux pas dire "ça n'existe pas". Joel Spolsky découpe le monde du software en 5 mondes, et je suis sur qu'il en oublie. Les gens du jeu vidéo ont assez peu de contraintes réglementaires(PEGI, peut-être?), mais des contraintes de délai souvent imposées(il faut sortir avant Noël, sinon on vendra moitié moins). Je retrouve des similitudes entre le médical et le bancaire(beaucoup de réglementaire et de compta), mais aussi des différences majeures(les banquiers ont des moyens colossaux, les hôpitaux des dettes colossales). Et ton domaine est certainement encore très différent, puisque le réglementaire y est semble-t-il limité. Donc on peut tirer des conclusions, mais gare aux généralisations trop hâtives. Moi, dans mon monde, j'ai des contraintes réglementaires fortes qui ont un impact fort sur le contenu des versions et leur date butoir de livraison. Nous ne sommes pas parvenus à passer en agile(ils ont essayé juste avant ma venue), et je ne pense pas que ça soit un hasard. Alors même qu'on a des gens de très haute qualité et très indépendants. Agile quand 50% du contenu à 6 mois est absolument figé, c'est tout de suite moins intéressant. Sans cette contrainte, ça aurait sans doute réussi.

[ZenZiTone]

Moi, j'en rajouterais un quatrième: périmètre.
En effet, suit à un problème technique, pour respecter les même délais, le même coût sans baisser la qualité on peux faire le choix de réduire le paramètre fonctionnel de ce qui sera livré.

Pour ma part, réduire le périmètre fonctionnel c'est réduire la qualité : qualité n'étant pas seulement rattaché à la qualité technique de la solution, mais aussi au nombre de fonctionnalités proposées dans la solution. La nuance que tu soulignes est néanmoins intéressantes car on parle bien de deux choses différentes.

[Matthieu Vergne]

Peut-être que parler de quantité plutôt que de périmètre serait plus clair (le compromis avec qualité est naturel).

[Traroth2]

Tu te méprends complétement entre contrainte et variable. C'est bien le principe de la négociation et de la planification. Chaque élément à sa part de variabilité : la taille de l'équipe, sa force de travail, sa productivité, etc.

Prenons spécifiquement ton exemple. On ne construit pas "un enfant", ce n'est donc pas le projet. "Faire du enfant" c'est un projet. Est-ce que l'accouchement est l'aboutissement du projet ? Non. Même en admettant qu'il soit confié à quelqu'un d'autres, il y a forte probabilité non négligeable qu'il te revienne dans la tronche au bout de quelques années .. ca marche aussi avec les projets informatiques !

Bref, ce n'est ni butoir, ni figé. Admettons que nous ayons atteint le jalon "Tomber enceinte", la variabilité s'étend de 0 à 398 jours. Bon admettons que ce délai est fixé à 273 jours. Il est toujours possible de finir les peintures, acheter la chambre, coudre soi-même l'édredon après !

Mais on peut négocier ce qu'on fera avant de ce qui sera fait après. Et même renégocier selon l'avancement de chaque élément (puisque tout variable), y compris le terme de la grossesse.

Délimiter un projet a forcément une part d'arbitraire. Je ne vois pas ce que tu démontres en changeant le périmètre. Le fait qu'on ne peut pas négocier la durée d'une grossesse. Mais étrangement, on imagine pouvoir négocier la productivité des développeurs.

Dans le vie tout se négocie En supposant justement une force de travail et une productivité constante, c'est bien là que toute la négociation va se faire.

A force de travail et productivité constante, il n'y a justement rien à négocier !

Premièrement, il convient de prioriser. Ce qui permet justement en cas d'aléa de savoir rapidement ce qui sera sacrifié. Pour cela l'implication de l'ensemble des acteurs est importante pour bien comprendre toutes les contraintes et la variabilité (que ce réglementaire, commercial ou logiciel). Ex : Un salon prévu en septembre pour montrer l'application des nouvelles mesures réglemtnaires applicables en janvier. On prévoit la partie IHM pour septembre et la gestion des données et des règles à minima pour janvier. Les statistiques et la génération des graphiques, etc. pour plus tard.

Voila revers de la médaille des délais au doigt mouillé décidé "en haut lieu" (c'est à dire par des gens qui n'y comprennent rien) : le cahier des charges - lettre au père Noël. Voila encore un domaine où l'agilité a complètement raté sa cible. Je ne vois pas en quoi moi, développeur, je devrais avoir mon mot à dire concernant le contenu du cahier des charges. Les gens du métier doivent savoir ce dont ils ont besoin. Ils sont là pour ça ! Je ne vois en quoi il y a là quelque chose à négocier. On est entre professionnels, pas sur un champs de course ! Le type qui dit "bon, pour raccourcir le délai, finalement ce bidule, on n'en aura pas besoin", pour moi, il a déjà complètement raté, professionnellement. Pourquoi demander qu'on développe un truc dont il n'a pas besoin ? Un cahier des charges doit toujours contenir le minimum nécessaire pour obtenir une application utilisable. Et là, on a un délai minimal. Ensuite, en se basant sur le retour des utilisateurs et sur un calcul de rentabilité, on peut enrichir. Supprimer l'effet tunnel ne devrait pas être seulement l'affaire de la DSI. Dans la vraie vie, la MOA demande tout ce qui lui passe par la tête. C'est lamentable.

En sus de ce que je viens d'expliquer j'en reviens à l'article et aux premiers commentaires. L'agilité repose sur une gouvernance mutualiste de l'ensemble des acteurs (ou tout du moins des différentes parties). Et c'est également de ce que j'ai décrit ci-dessus. Or dans les faits cette gouvernance n'est pas partagée. C'est donc de l'eau que tu retires de ton moulin

Cette gouvernance mutualiste, tu la voies où, dans le manifeste agile ? Chacun son métier. Or, j'ai souvent l'impression que les développeurs sont les seuls dont on exige du professionnalisme.

Je voudrais introduire une autre notion que je n'ai pas évoqué au sujet de la planification : la gestion du risque. Il ne faut pas non plus s'étonner que des projets sont dans le fossé, si les risques ne sont pas pris en compte. L'abolissement de l'effet tunnel est une action de gestion du risque qui illustre parfaitement une cause d'échec des projets.

Je l'ai déjà dit nous jouons avec des paramètres variables. J'ai évoqué uniquement l'amplitude comme attribut de la variabilité mais il y en a d'autres comme la distribution de la probabilité, mais il faut aussi évoqué les coûts, les délais, etc. Ne pas en tenir c'est justement prendre le risque de voir tout simplement son projet échoué.


Concernant purement l'article, les gens vendent des méthodes avec le "nom" mais pas les valeurs. Je pense qu'il est plus intéressant de vendre : la libération des échanges (idées, conversation, travail) entre les acteurs, l'implication de l'ensemble des acteurs et l'amélioration continue.

Les gens achètent ce qu'ils veulent acheter. Et ce qu'ils achètent souvent, c'est le droit de changer d'avis comme de chemise, la disparition d'un cahier des charges figé (mais souvent, il n'y a plus de specs du tout. La partie où la MOA maintient un backlog des fonctionnalités à développer passe facilement à la trappe) et la communication informelle qui permet de facilement prétendre qu'on n'a jamais dit ça. Bref, tout le poids du projet se retrouve exclusivement sur l'équipe technique. Forcément, ça finit par agacer.

[ZenZiTone]

le cahier des charges - lettre au père Noël. Voila encore un domaine où l'agilité a complètement raté sa cible. Je ne vois pas en quoi moi, développeur, je devrais avoir mon mot à dire concernant le contenu du cahier des charges. Les gens du métier doivent savoir ce dont ils ont besoin. Ils sont là pour ça ! Je ne vois en quoi il y a là quelque chose à négocier.

Le développeur a pour rôle d'apporter son regard technique à un problème, d'expliquer et pourquoi pas proposer des solutions techniques pour répondre à un besoin fonctionnel, quantifier le travail a réaliser afin de permettre au client de prioriser les fonctionnalités souhaitées, etc.. Sans parler du fait que la présence des professionnels technique est plus rassurante pour un client qu'un "simple" commercial qui ne sais pas ce qu'il vend.

[Matthieu Vergne]

Voila revers de la médaille des délais au doigt mouillé décidé "en haut lieu" (c'est à dire par des gens qui n'y comprennent rien) : le cahier des charges - lettre au père Noël. Voila encore un domaine où l'agilité a complètement raté sa cible. Je ne vois pas en quoi moi, développeur, je devrais avoir mon mot à dire concernant le contenu du cahier des charges. Les gens du métier doivent savoir ce dont ils ont besoin. Ils sont là pour ça ! Je ne vois en quoi il y a là quelque chose à négocier. On est entre professionnels, pas sur un champs de course ! Le type qui dit "bon, pour raccourcir le délai, finalement ce bidule, on n'en aura pas besoin", pour moi, il a déjà complètement raté, professionnellement. Pourquoi demander qu'on développe un truc dont il n'a pas besoin ? Un cahier des charges doit toujours contenir le minimum nécessaire pour obtenir une application utilisable. Et là, on a un délai minimal. Ensuite, en se basant sur le retour des utilisateurs et sur un calcul de rentabilité, on peut enrichir. Supprimer l'effet tunnel ne devrait pas être seulement l'affaire de la DSI. Dans la vraie vie, la MOA demande tout ce qui lui passe par la tête. C'est lamentable.

Désolé pour toi, mais la réalité est toute autre : un cahier des charges vise effectivement à expliciter les besoins, mais hélas on ne vit pas dans un monde formel où les règles sont connues à l'avance, et donc complètement prédictible ou tout au moins complètement formalisable. Pour établir un cahier des charges, il faut savoir de quoi le client a besoin, mais le client lui-même ne sait pas forcément ce dont il a besoin. Il a éventuellement un (souvent plusieurs) problème(s) bien cerné(s), mais n'a justement pas la compétence pour savoir ce qui résoudrait ce(s) problème(s), autrement il le réglerait lui même. De l'autre côté, il y a le dév, qu'on estimera être super compétent parce que c'est un pro, qui connaît donc son domaine sur le bout des doigts mais n'a jamais fait face aux problèmes que connaît le client, puisque ce sont des problèmes spécifiques au domaine du client et non à celui du dév. Et comme on ne trouve ni baguette magique en supermarché ni expert extrasensoriel sur le marché de l'emploi, pour établir le cahier des charges il faut que le client et le dév se mettent ensemble autour de la table et discute des problèmes du premier et des solutions que le second peut apporter. À cela, il faut ajouter qu'expliciter ce qu'on sait n'a rien de trivial, on fait d'ailleurs la différence entre :
- ce qu'on sait savoir (known knowns)
- ce qu'on sait ne pas savoir (known unknowns)
- ce qu'on ne sait pas savoir (unknown knowns)
- ce qu'on ne sait pas ne pas savoir (unknown unknowns)

Le cahier des charges s'établit sur la base de ce qu'on sait, c'est à dire les deux premiers points : le premier permettra d'identifier les besoins déjà connus, le second identifiera les travaux de veille techno à effectuer. Cependant, il reste les deux derniers points. Et notamment le 3e, qui est au sujet de ce dont on ne se rend pas compte qu'on le sait. Cette partie là concerne notamment toutes les connaissances qu'on a fini par automatiser, à tel point qu'on l'a oublié et que ça nous paraît évident. C'est notamment ce qui est à la source des biais de raisonnement, mais aussi un des principaux problèmes en ingénierie des exigences : le client ne dit pas tout, pas forcément parce qu'il veut cacher des choses, mais simplement parce qu'il ne voit pas l'intérêt de le dire, tellement ça lui paraît évident (le dév est donc censé déjà le savoir, inutile donc de l'écrire). En fait, c'est même plus vicieux que ça, car on ne parle pas là de quelque chose qui viendrait à l'esprit du client et qu'il se dirait "oh, il doit être au courant, je passe", mais bien de quelque chose qui ne passe même plus par la case conscience. De la même manière que quand on marche, on ne se rend même plus compte qu'on met un pied devant l'autre, ça vient juste "comme ça" (alors qu'on est bien passé par une phase d'apprentissage où il fallait faire attention à bien s'appuyer sur un pied avant de bouger l'autre et de faire suivre le corps).

Bien entendu, le 4e point (unknown unknowns) n'est pas en reste non plus : souvent, le client viendra avec une idée préconçue de ce qu'il lui faut, alors qu'il n'a pas les compétences pour ça. Mais de par les connaissances qu'il a lui, il pense que telle ou telle chose pourra résoudre son problème. Et c'est de là que démarre le cahier des charges : pas du problème à résoudre, mais de l'idée préconçue que le client a de la solution. Or, souvent le client n'a tout simplement pas idée de ce qui se fait de mieux, voire il ne connaît pas suffisamment la solution qu'il a en tête pour se rendre compte qu'en fait il est à côté de la plaque. Le cahier des charges pourra être rédigé de la meilleure des façons, si la solution proposée ne résout pas le problème, le projet échouera lamentablement (et le dév dira que c'est la faute du client de ne pas savoir et le client la faute du dév de ne pas comprendre).

Avec ça, on comprend aisément pourquoi il vaut mieux avoir un contact entre client et dév qui soit direct, ce que prônent les méthodes agiles. Seulement, le dév ne connaît/comprends pas (en général) l'intégralité du problème du client (après tout c'est pas son domaine), et le cahier des charges se focalisant sur la solution à implémenter on fait face à une situation où les deux parties ont une connaissance incomplète et doive donc s'aligner. Le dév doit essayer d'identifier le problème du client en fonction de la solution qu'il demande, ce qui n'a rien d'évident vu que ça peut être une solution foireuse, et demander des précisions sur pourquoi le client veut telle ou telle fonctionnalité. En face, le client n'est pas forcément capable de dire tous les tenants et aboutissant (on n'est pas tous pédagogues), on n'est donc jamais sûr d'avoir la meilleure vision du problème, et donc jamais sûr de la pertinence de la solution proposée. C'est une des raisons principales pourquoi des projets en Waterfall peuvent foirer et qu'on prône l'agile quand c'est possible : la solution établie dans le cahier des charges peut ne pas être la bonne, et donc on privilégie les remises en question pour éviter l'échec final.

Donc non, personne n'est "censé savoir". Chacun sait des choses, et c'est en combinant et discutant qu'on établit les besoins et priorités. C'est pas comme à l'école où les questions sont bien choisies et ne reste alors qu'à choisir la bonne réponse. En dehors de l'école, il faut aussi savoir chercher les bonnes questions, et c'est tout un art.

[Logan Mauzaize]

Délimiter un projet a forcément une part d'arbitraire. Je ne vois pas ce que tu démontres en changeant le périmètre. Le fait qu'on ne peut pas négocier la durée d'une grossesse. Mais étrangement, on imagine pouvoir négocier la productivité des développeurs.

Je ne change pas le périmètre, je cherche à te faire comprendre que :

• les jalons sont aussi des aléas d'un projet
• même si une date butoire est donnée on peut prioriser le travail pour réaliser ce qui est non essentiel plus tard

Et que ce dernier point peut faire l'objet d'une négociation.

Il existe des leviers pour faire varier la productivité mais traitons plutôt de la force de travail d'une équipe. Elle est négociable, passer une personne à plein temps sur le projet alors qu'elle est à mi-temps ou le contraire, "réglementer" la pose de congés sur certaines périodes, etc. ne sont que quelques exemples.

A force de travail et productivité constante, il n'y a justement rien à négocier !

Tu te trompes. Si l'on considère que la force de travail n'est pas un paramètre variable, c'est qu'il faudra négocier ailleurs ! Notemment en réduisant le nombre d'exigences implémentées à une date donnée. Cela peut amener à reporter des fonctionnalités entières ou bien des parties.
Et c'est dans ce cadre que l'avis de la partie fonctionnelle (qui connait les dépendances fonctionnelles et métiers) et de celui de la partie technique (qui connait les dépendances techniques) sera nécessaire pour bien négocier. Si la "direction" et l'AMOA décide de sacrifier certaines exigences dont la réalisation technique est liée, ce sera un de ces projets qui vont dans le fossé.

Voila revers de la médaille des délais au doigt mouillé décidé "en haut lieu" (c'est à dire par des gens qui n'y comprennent rien) : le cahier des charges - lettre au père Noël. Voila encore un domaine où l'agilité a complètement raté sa cible. Je ne vois pas en quoi moi, développeur, je devrais avoir mon mot à dire concernant le contenu du cahier des charges. Les gens du métier doivent savoir ce dont ils ont besoin. Ils sont là pour ça ! Je ne vois en quoi il y a là quelque chose à négocier. On est entre professionnels, pas sur un champs de course ! Le type qui dit "bon, pour raccourcir le délai, finalement ce bidule, on n'en aura pas besoin", pour moi, il a déjà complètement raté, professionnellement. Pourquoi demander qu'on développe un truc dont il n'a pas besoin ? Un cahier des charges doit toujours contenir le minimum nécessaire pour obtenir une application utilisable. Et là, on a un délai minimal. Ensuite, en se basant sur le retour des utilisateurs et sur un calcul de rentabilité, on peut enrichir. Supprimer l'effet tunnel ne devrait pas être seulement l'affaire de la DSI. Dans la vraie vie, la MOA demande tout ce qui lui passe par la tête. C'est lamentable.

Assez perturbant de critiquer à la fois les décisions en "haut lieu", celles faites par les développeurs et la négociation entre les parties ...

Tu confonds la fin et les étapes. D'un point de vue pragmatique, le cahier des charges ne sera effectivement et probablement jamais rempli. Il reste un objectif flou qu'on réajuste au fur et à mesure. Mais il est l'objectif lointain nécessaire pour ne pas rater l'objectif de chaque étape. Enfin ceci est mon expérience des projets à long/infini termes.

Ils savent ce qu'ils veulent de manière vague. Ils ont des objectifs à remplir et attendent des solutions technico-fonctionnels. Pour des aspects comme les interfaces utilisateurs, ils vont émettre des idées. Mais il ne serait pas professionel de ne pas les alerter ou de proposer des alternatives. Il n'est pas rare non plus qu'ils s'avancent sur des solutions techniques (qui peuvent être impossibles ou non optimales). Si ni en "haut lieu", ni les développeurs n'ont les moyens pas les moyens de décider, c'est qu'il s'agit bien d'une décision collégiale et qu'une négociation sera obligatoire.

Cette gouvernance mutualiste, tu la voies où, dans le manifeste agile ? Chacun son métier. Or, j'ai souvent l'impression que les développeurs sont les seuls dont on exige du professionnalisme.

"équipe auto-organisée". Cela signifie clairement qu'il n'y a pas de hiérachie (au moins à la base). Si une hiérarchie se forme et prenons le postulat que cela ne viole aucune règle du manifeste, alors c'est simplement que des personnes ont délégués leur "pouvoir" à des représentants.

Ensuite je pense que c'est contraire aux idées "travailler ensemble" (pas de subordination), de "personnes motivées" (impliquées), de "faire confiance" et enfin "réflection et d'ajustement de l'équipe".

Attention non plus de ne pas confondre les mauvaises (fausses) pratiques que tu constates et ce qu'on t'explique ... Comme je le disais, ce n'est pas parce qu'une organisation portant un "nom" fonctionne mal que le "principe" est en défaut. On pourrait prendre l'exemple du communisme. Qui par ailleurs a des ressemblances avec les principes de l'agilité. Par ailleurs ce que je t'explique ne se rapporte en rien avec l'agilité mais simplement la gestion de projet puisque mes propos sont principalement issus de processus itératifs comme RUP.

Les gens achètent ce qu'ils veulent acheter. Et ce qu'ils achètent souvent, c'est le droit de changer d'avis comme de chemise, la disparition d'un cahier des charges figé (mais souvent, il n'y a plus de specs du tout. La partie où la MOA maintient un backlog des fonctionnalités à développer passe facilement à la trappe) et la communication informelle qui permet de facilement prétendre qu'on n'a jamais dit ça. Bref, tout le poids du projet se retrouve exclusivement sur l'équipe technique. Forcément, ça finit par agacer.

Encore une fois, la mauvaise pratique ne prouve en rien que ce nous préconisons est mauvais. C'est sur que le chou cuit c'est pas bon, mais je t'explique qu'en vinaigrette c'est mieux

[zulu1]

Tu prends un bon développeur RUP à l'ancienne, tu le mets avec des geeks agiles... 2 options, le dev deviens mauvais de caractère ou il fait un burn out.

[ZenZiTone]

Tu prends un bon développeur RUP à l'ancienne, tu le mets avec des geeks agiles... 2 options, le dev deviens mauvais de caractère ou il fait un burn out.

La capacité d'adaptation et de travail en équipe sont des qualités que tu sembles négliger

[mchoucroun]

Pour moi:
Pour avoir fait beaucoup de forfaits et un peu d'agile:
* Le forfait c'est 30% moins cher
* Un coté tunnel...

* Agile: le resultat est plus lent, mais visuel
* La communication est meilleure.

C'est un peu à chacun sa religion....
Mais je trouve beaucoup de gens faisant de l'agile sont méprisantes pour les autres.
Ce n'est pas parce que l'on est chretien/juif/musulman que les autres religions sont méprisables.
C'est ce qui m'ennuie dans l'agile.


Maxime Choucroun

[Eric80]

il y a peut être un aspect culturel ou esprit d entreprise pour que Agile prenne ou pas.
J ai pas d expérience en France donc ne peut me prononcer, mais les projets Agile dans lesquels j ai travaillé en Allemagne, on travaillait tous ensemble en adaptant Agile pour être le plus efficace possible avec les besoins et les délais:
Management du client peu impliqué, pas de manageurs de SSII, décisions techniques qu'entre ingénieurs, de ceux qui définissent les besoins (on n avait même pas de cahier des charges bien défini!) aux développeurs et testeurs. On ne respectait pas forcément tous les principes de Agile, mais il me semble qu on en avait au moins l esprit.

Dans un projet en particulier, on faisait des cycles de 4 mois, décidions tous ensemble avec le mgt le contenu du cycle en terme de fonctionnalités. Ensuite au sein de l équipe de dev (4-5 dev seniors only), nous définissions le calendrier et la répartition des fonctionnalités par tête, et au court du dev, les ingé côté requirements nous disaient plus précisemment ce qu ils voulaient et travaillions ensemble pour développer le possible et le plus adapté, avec la flexibilité des principes Agile.

A lire l article et les commentaires, il semble que bcp d équipes pensent faire du Agile n en font en fait pas...

[Luckyluke34]

Pour continuer sur le thème "ne blâmez pas la méthode, blâmez les gens qui l'utilisent mal", je conseille l'excellente réponse d'Uncle Bob Martin à cet article.