Je pense que c'est vrai, dans certains environnements, Agile est utilisé comme une excuse pour aucune discipline. Le vrai problème est que nous avons perdu de vue pourquoi nous avons une méthodologie. Personnellement, j’estime que la méthodologie est un problème d’architecture en ce sens que l’architecture du système est censée prendre en compte les attributs de qualité non fonctionnels. Elle devrait traiter de certains de ces mêmes attributs (maintenabilité, productivité du développement, transfert de et al.)
Considérer la méthodologie comme un contrôle des attributs de processus implique deux choses: 1) sans métriques, nous ne pouvons pas comparer l'efficacité d'une méthodologie à une autre, 2) une décision active doit être prise concernant les attributs importants (délai de livraison par rapport au code). qualité vs transfert de connaissances).
Sans avoir à la fois les métriques et un objectif concret, nous choisissons simplement une méthodologie comme notre "plume magique" qui, si nous nous en tenons à nous-mêmes, nous pourrons livrer des logiciels.
Maintenant, les opposants de Agile, XP, Scrum, etc. parlent de la fragilité de cette catégorie particulière de méthodologies. L'argument étant: pourquoi utiliser une méthodologie qui peut être sabotée par un individu sans discipline pour suivre toutes les règles? La question est valide. Cependant, c'est le symptôme, pas la cause. Si un ensemble de métriques de processus précises et significatives (c'est la partie difficile) sont définies, testées et que les retours d'information sont donnés rapidement, je pense que nous découvrirons que la méthodologie en question a peu à voir avec le succès. (De manière anecdotique, j'ai vu des projets couronnés de succès utilisant une myriade de méthodologies et deux fois plus échouant avec les mêmes méthodologies)
Alors, quelles sont les métriques? Ils varient d'un projet à l'autre, d'une équipe à l'autre et de temps en temps. Utile lorsque le calendrier de livraison est important, celui que j'ai personnellement utilisé est la compétence et la qualité de l'estimation. La plupart des développeurs peuvent estimer avec précision les tâches d'une semaine ou moins. Une approche consiste donc à diviser le projet en tâches d’une semaine par développeur et à déterminer qui a effectué l’estimation. Au fil du projet, ils peuvent modifier leurs estimations. Une fois la tâche terminée, si nous la désactivons de plus de 10% (une demi-journée), nous la traitons comme un bogue - nous identifions la raison pour laquelle l’estimation était désactivée action corrective (c'est-à-dire associer l'administrateur de base de données à l'estimation), puis passer à autre chose. En utilisant ces informations, nous pouvons créer des mesures telles que le nombre de bugs d'estimation par semaine, le nombre de bugs par développeur,
Et alors? C'est à ce moment que les méthodologies entrent en jeu - si vous avez un modèle prédictif qui ne répond pas aux qualités du processus, vous pouvez choisir d'ajouter ou de supprimer un aspect de la méthodologie et voir comment cela affecte votre modèle. Certes, personne ne veut jouer avec un processus de développement par peur des échecs, mais nous échouons déjà à un rythme constamment élevé et prévisible. En apportant des modifications individuelles et en mesurant le résultat, vous constaterez peut-être qu'Agile est la méthodologie idéale pour votre équipe, mais vous pouvez tout aussi bien trouver que RUP, une cascade ou tout simplement un fouillis de meilleures pratiques est idéal.
Je suggère donc de cesser de nous inquiéter de ce que nous appelons le processus, de mettre en place des contrôles pertinents pour nos objectifs de processus de développement et d'expérimenter différentes techniques pour améliorer ce processus.
