Lors de notre dernière entrevue, nous en étions arrivé à la conclusion que pour être vraiment agile, il faut avant tout être en capacité TECHNIQUE à accueillir favorablement le changement, et ce à n'importe quel moment du projet.
Ce sujet n'est pratiquement jamais traité par les agilistes, car ils se concentrent sur des problèmes humains, mais la dégradation des relations humaines dans un projet trouve souvent sa source dans l'incapacité technique à répondre aux besoins du client.
Or, dans un contexte extrêmement dense où se mélangent obligations réglementaires, flux de travail complexe, normes industrielles floues, règles d'exploitation contradictoires et autres préceptes organisationnels hasardeux, il est absolument impossible pour des utilisateurs experts de leur métier d'avoir une vision claire et globale de la solution logicielle idéale. Et c'est là que vous débarquez, tout seul, en tant que développeur !
Rajoutez à ça le besoin naturel qu'a le client de maîtriser ses coûts et ses délais, et vous comprendrez très rapidement que vous vous êtes fourré dans un beau bourbier.
Au cours de ce talk, je ferai le tour de toutes les techniques (crafts et autres) qui peuvent vous permettre de survivre à ce genre de situation, agrémenté d'expériences personnelles ainsi que les cheminements intellectuels qui m'ont mené à faire certains choix personnel.