Ceci est un des contrastes frappant avec un projet de développement traditionnel, où un des premiers objectifs est de capturer toutes les exigences connues et leur champ d’application et que toute modification doit être suivie d’une conduite du changement.
Traditionnellement, les utilisateurs sont éduqués qu’il est beaucoup plus coûteux de changer ou d’ajouter des exigences pendant ou après la phase de développement du logiciel. Certaines sociétés citent quelques statistiques impressionnantes destinées à effrayer les utilisateurs. Il devient donc impératif d’inclure tout ce qu’ils peuvent penser – en fait tout ce qu’ils ont toujours rêvé !
Et qui plus est, il est important de le faire lors de la première version du logiciel, parce que nous savons tous que la phase 2 est toujours difficile à obtenir, une fois approuvée 80% des dépenses ont été réalisés de la phase 1.
Ironiquement, les utilisateurs utilisent seulement une infime partie de tout logiciel, plus ou moins 20%. Mais de nombreux projets commencent leur vie avec une portée pléthorique. En partie, parce que personne ne sait réellement qu’elles seront les 20% du produit qui seront réellement utilisés par l’usager. De même, même si les exigences sont soigneusement analysées et traitées en priorité, il est impossible de penser à tout, les choses changent, et les choses sont comprises différemment par des personnes différentes.
Le développement Agile travaille sur un principe complètement différent. Le développement Agile fonctionne sur le principe que les besoins apparaissent et évoluent. Quelques que soient les analyses et conceptions que vous faites, ce sera toujours le cas parce que vous ne pouvez pas vraiment être sûr de vous jusqu’à ce que vous utilisez le logiciel. Et le temps que vous avez passé en phase d’analyse des besoins et de conception, les conditions extérieures ont peut-être changé.
Donc, si vous pensez que personne ne peut réellement imaginer ce que sera la solution finale en début de projet – il est intrinsèquement difficile, voire pratiquement impossible, de construire la bonne solution en utilisant une approche traditionnelle de développement.
Les méthodes de projet traditionnelles combattent le changement, avec des processus de contrôle du changement visant à minimiser et à résister au changement dans la mesure du possible. En revanche, les projets de développement Agile acceptent le changement, en fait, ils l’attendent et l’évaluent. Parce que la seule chose qui est certaine dans une vie, c’est le changement.
Il existe différents mécanismes dans le développement Agile pour gérer cette réalité. Dans les projets de développement Agile, les besoins sont autorisés à évoluer, mais le calendrier est fixe. Donc, pour inclure un nouveau besoin, ou pour modifier une exigence, l’utilisateur ou le directeur de produit doit retirer du projet une charge de travail comparable afin de tenir compte de ce changement.
Ainsi, l’équipe peut continuer à se concentrer sur les délais, et le produit permet d’évoluer dans la bonne direction. Toutefois, il faut aussi présupposer qu’il y a suffisamment de fonctions optionnelles prévues dans le projet pour permettre ces changements, cela doit se faire sans compromettre fondamentalement le produit final.
Mais qu’est ce que l’entreprise pour attendre de ses équipes de développement ? Délivrer le logiciel dans les délais et le budget prévus dans le contrat, et bien sûr avec une qualité acceptable. Tous les professionnels du développement sont bien conscients que vous ne pouvez pas de manière réaliste résoudre tous ces facteurs et espérer répondre aux attentes. Quelque chose doit être variable pour la réussite du projet. En développement Agile, il existe toujours un champ d’application (ou des caractéristiques du produit) qui est variable, le coût et le calendrier ne doivent pas l’être.
Bien que la portée d’un projet de développement Agile est variable, il est reconnu que seule une fraction d’un produit est réellement utilisée par ses utilisateurs et donc une partie des fonctionnalités d’un produit n’est pas vraiment indispensable. Pour pratiquer cette philosophie de travail, il est impératif de commencer le développement par le noyau, et par la suite avec les cas d’utilisation qui ont la priorité la plus élevée, en s’assurant qu’ils sont livrés dans les temps.
Dans cette méthode, nous favorisons le CRI (Conception – réalisation – Intégration) par itérations. Chaque itération terminée, peut-être livrée pour que le client final puisse valider le contenu de l’itération. Cette méthode permet rapidement d’avoir un état des lieux de la charge consommée et celle restant pour satisfaire au besoin.
Commentaire