Bonjour,
je suis Manager d'une équipe pluridisciplinaire assez vaste. Entre autre, une partie de dévelopement informatique avec des Business Analyst, des Développeurs Java, des DBA d'études...
Voilà 8 ans que nous sommes agiles !
Je dis bien "nous sommes agiles" et non "nous utilisons une méthode agile" car sans donner dans le philosophique, ce qui compte dans un projet c'est l'équipe. Faire de l'agile ne peut pas être imposé, cela ne correspond pas à tous et parfois il vaut mieux faire du cycle en V que faire de l'agile avec des gens qui ne sont pas fait pour.
Après l'idée de ne fournir aucune doc et aucune planification est une ineptie. Et puis on peut tout à fait faire un cycle en V sans doc (experience vécue).
Comment croyez-vous que j'arrive à vendre des projets à mon DSI et nos clients si je balance "Je ne sais pas combien ca coute ni quand on fini !" ?
Enfin je reviens sur une idée reçue : une équipe agile est faite pour la maintenance (évolutive) et non seulement pour du projet !
Déjà parce que l'agilité c'est savoir refactorer facilement/rapidement son code et aussi parce que vous avez à l'avance une enveloppe vous permettant de staffer et aucun objectif défini.
Le contenu des iterations est défini tout au long de l'année par les clients leurs donnant la possibilité d'arbitrer les correctifs au fur et à mesure... le seul challenge est de leur faire entendre que l'on étale les correctifs sur l'année et que non on ne sera pas 50 ce mois-ci et 0 le reste de l'année (ce serait anti-agile ;-) )
Donc ma critique de cet article serait plutot pourquoi ne pas interroger des clients qui ont fait face à des équipes classiques et des équipes agiles ?
Au final mon conseil, soyez pragmatiques !
ATTENTION là ce n'est plus une question d'Agilité mais de qualité de code et de Knowledge Management
Partager