Je pense que la première chose à réaliser est qu'il y a une différence entre être agile et être agile. Déployer lentement des techniques et des caractéristiques agiles - les équipes interfonctionnelles, la planification adaptative, la livraison évolutive / incrémentielle, les itérations temporelles et même l'introduction de concepts de Lean sont très différentes de l'introduction de la programmation extrême, Scrum ou Crystal.
Vous mentionnez explicitement l'implication du client. Oui, de nombreuses méthodologies Agile nécessitent une implication du client, mais cela n'est pas obligatoire pour être agile. Dans chaque programme lié au gouvernement / à la défense, j'ai toujours eu un chef de programme ou de projet qui était le point de contact avec le client. Cette personne devient la «voix du client». Cela peut être ralenti lors de la téléconférence, du courrier électronique ou de l'appel et de la clarification, mais vous pouvez avoir une seule personne (ou un groupe, si vous avez également des adjoints au PM) qui est le représentant client de votre équipe. Certes, ce n'est pas tout à fait la même chose. Mais n'est-ce pas agile d'être flexible et de réagir au changement?
Vous mentionnez également quelques concepts clés: des exigences prédéfinies, des demandes de fonctionnalités «jetées par-dessus le mur», un manque de hiérarchisation car «elles sont toutes importantes» et des projets à coût fixe et / ou à calendrier fixe. Chacun de ces éléments peut être traité de différentes manières.
Si vous pensez que vous avez toutes vos exigences à l'avance, il y a de fortes chances que ce ne soit pas le cas. Les exigences changent. Ce n'est pas parce que vous avez une spécification «terminé et signé» qu'elle est gravée dans le marbre. Étant donné le document sur les exigences dont vous disposez, saisissez-les comme vous vous sentez à l'aise et / ou de la manière spécifiée par le contrat et livrez les exigences, la conception et l'architecture. De plus, voyez si vous pouvez traiter ce sont des documents vivants (un document de conception que j'ai vu aujourd'hui au travail est étiqueté comme la révision G, ce qui signifie qu'il s'agit de sa 8e mise à jour). Demandez combien vous pouvez laisser en tant que TBD dans une itération donnée et combien doit être raffermi maintenant - il pourrait y avoir des concessions mutuelles.
Soyez agile avec votre documentation. Ne dupliquez pas les efforts entre «ce que veut votre équipe» et «ce que veut le client». Par exemple, si votre client souhaite une spécification de configuration logicielle traditionnelle et que votre équipe souhaite utiliser des user stories, essayez de vous adapter à un SRS traditionnel et utilisez des éléments d'action et une liste d'éléments d'actions roulants au lieu de user stories afin de ne pas perdre de temps formulant à la fois "le système doit ..." et "doit pouvoir le faire". Cela prend cependant de la discipline de la part de l'équipe pour s'adapter aux différences entre les projets. Capturez les problèmes dans les réflexions.
Une fois que vous arrivez au développement, vous pouvez exécuter 5 ou 6 itérations, puis inviter votre client à votre installation pour voir un sous-ensemble de votre implémentation. Rincez et répétez ce processus. Ce n'est pas l'implication constante exigée par certaines méthodologies, mais vous avez l'avantage d'une grande visibilité. Si votre client dit non, au moins vous avez essayé. S'ils disent oui, vous pouvez les éclairer sur leur agilité. Sur un projet sur lequel j'étais, le client a visité le site tous les quelques mois (3-5 mois, généralement). Ils nous regardaient passer les tests d'AQ, ils discutaient des préoccupations avec les ingénieurs et les affaires avec le bureau du programme / projet. C'était l'occasion pour tout le monde de se retrouver sur la même longueur d'onde.
Les tests et la maintenance se déroulent de la même manière que sur les autres projets agiles. Créez vos procédures de test et documentez les défauts de la manière appropriée, suivez les mesures par obligations contractuelles et documentez les résultats des tests. Si vous voulez suivre TDD, allez-y. L'intégration continue est une autre bonne idée. Pendant les réunions sur l'état du projet, votre chef de projet peut utiliser ces informations pour dire "nous avons mis en œuvre N exigences, faire passer M tests, X tests réussissent" et mettre à jour l'état et la situation du projet aux personnes disposant de l'argent.
En parlant d'argent, nous avons le problème des coûts fixes et / ou des horaires fixes.
Traiter avec un horaire fixe est assez simple. Compte tenu de vos besoins, vous savez combien d'itérations vous pouvez effectuer. Votre charge de travail pour chaque itération est à peu près figée en termes de fonctionnalités à implémenter, tester et intégrer. Cela peut être difficile, mais il n'est pas impossible de diviser les fonctionnalités et de les affecter à des itérations à l'avance. Cela revient à mon point sur l'invitation du client - si vous avez un an et utilisez des itérations de 2 semaines, invitez peut-être le client tous les trimestres (et invitez-les tous les trimestres) et montrez-leur les résultats des travaux précédents. Faites-leur voir votre ordre de priorité des exigences, vos plans futurs et la façon dont vous allez planifier.
Gérer un budget fixe est similaire. Vous savez combien de temps vous avez, combien de ressources vous avez pour le projet, combien elles coûtent et donc combien d'heures chacun peut travailler par itération. C'est juste une question de s'assurer que tout le monde garde une trace de cela attentivement. Si votre entreprise peut supporter le coût des heures supplémentaires, allez-y. Sinon, assurez-vous que tout le monde travaille la durée appropriée et utilisez de bonnes compétences de gestion du temps et de boxe pour garder tout le monde productif. Des heures plus productives sont ce dont vous avez besoin pour réduire les coûts - fournir plus de documents et de logiciels à valeur ajoutée sans les frais de réunions et les frais généraux.
En fin de compte, il ne s'agit pas nécessairement d'être Agile, mais d'appliquer les choses qui rendent Agile bon et d'être agile. Être en mesure de répondre aux changements des exigences, être en mesure de fournir des logiciels fréquents même si le client ne le souhaite pas, produire uniquement une documentation à valeur ajoutée (avec tout ce que vous êtes contractuellement obligé de produire), etc.