“Je pense que la chose la plus importante dans notre éducation est probablement qu'elle nous a appris à remettre en question même les choses que nous pensions savoir.” – Thabo Mbeki

Depuis qu'il travaille comme directeur du développement des affaires à Code d'inspirationune société de développement à cycle complet, j'ai constaté que les clients souhaitent souvent appliquer Agile directement sans une compréhension approfondie de ce à quoi s'attendre.

De nos jours, les entreprises décident de passer à l'agilité sans avoir une compréhension approfondie de ce que c'est et si cela s'applique à leur cas particulier. Tout comme une “pilule qui guérit tout”, ils attendent d'Agile qu'il résolve tous leurs problèmes en même temps.

Certains propriétaires de produits ne se concentrent pas sur la participation fréquente au processus de développement logiciel. En fait, certains d'entre eux s'attendent à ce qu'Agile apporte une livraison rapide du projet tandis que d'autres sont prêts à procéder sans directives de spécification, etc. Dans cet article, vous découvrirez les 5 attentes les plus courantes qui sont aussi des mythes.

Les 5 principaux mythes du développement logiciel Agile :

  1. Agile est uniquement lié au développement informatique
  2. Agile est toujours plus rapide
  3. Les parties prenantes peuvent modifier la portée des travaux à tout moment
  4. Agile signifie pas de guides de spécifications
  5. Agile ne nécessite pas la participation constante du Product Owner

1. Agile n'est lié qu'au développement informatique

Agile, en tant que méthodologie, a été mentionnée pour la première fois dans le Manifeste Agile, un document créé en février 2001 concernant le développement informatique. L'approche a été un grand succès et s'est étendue à toutes les niches d'entreprises en tant qu'instrument de gestion clé.

Qu'est-ce que l'agilité ? Il s'agit simplement d'une division de l'ensemble de la portée d'un projet en itérations logiques. Par rapport à l'exécution simultanée de toutes les tâches, Agile est une approche qui offre la possibilité de modifier les objectifs commerciaux en ajoutant des modifications aux itérations définies et en se concentrant uniquement sur les tâches hautement prioritaires que vous définissez dans le sprint.

Toutes les autres recommandations, considérations et réflexions des actionnaires peuvent aller dans le soi-disant «backlog» et peuvent être revues à chaque fois avant la prochaine formation de sprint. Vous décidez de commencer à travailler dessus ou non.

Bien que l'idée que l'agilité soit uniquement liée à l'informatique soit l'un des mythes les plus populaires de nos jours, cela ne le rend toujours pas vrai.

Agile n'est pas le développement informatique

Agile est bien plus que du développement informatique, et vous pouvez le faire fonctionner pour vous.

2. Agile est toujours plus rapide

Dans le point précédent, j'ai mentionné qu'Agile a gagné en popularité de manière durable et, par conséquent, a conduit les gens à commencer à appliquer la méthodologie Agile à chaque projet. Que cela convienne ou non au projet, l'agilité a été appliquée à tous les projets de développement informatique et à tous les modèles de travail.

L'une des parties très importantes de l'agilité consiste en des itérations de travail bien testées. Le test de régression est appliqué à chaque étape définie comme un sprint. Dans certains cas, et pour certains projets, ce n'est pas si nécessaire.

De plus, je dirais qu'un projet à portée fixe bien documenté serait développé plus rapidement en appliquant la cascade. Dans certains cas, il est important de montrer une grande quantité de fonctionnalités en peu de temps pour obtenir un investissement pour un développement ultérieur. Par exemple, il serait beaucoup plus rapide d'utiliser Kanban.

Par rapport à une tortue et un lièvre, la méthodologie agile est rapide comme un lièvre.

Agile vs non agile

Comment souhaitez-vous aborder votre projet ? Comme une tortue ou un lièvre ?

3. Les parties prenantes peuvent modifier la portée des travaux à tout moment

Bien que flexible au changement, agile ne signifie pas que la portée du travail peut être modifiée à tout moment, ce n'est pas Kanban. De plus, chaque intervenant ou propriétaire de produit doit garder à l'esprit que certains changements peuvent nécessiter la reconstruction de l'architecture initiale.

De plus, selon agile, tous les changements doivent être ajoutés au backlog et le sprint actuel (généralement d'une durée de 2 ou 3 semaines) doit rester le même.

Agilité du changement

Ainsi, par rapport à un projet à portée fixe où les changements sont fortement déconseillés pendant le développement, agile est considéré comme un modèle flexible qui accepte les changements et les modifications.

Cependant, il est important de consulter un PM pour savoir quand et comment il serait préférable d'appliquer un changement nécessaire.

4. Agile signifie pas de guides de spécifications

L'un des éléments les plus importants pour procéder à un développement propre et bien géré est un guide de spécifications détaillé. Qu'il s'agisse d'un projet à portée fixe ou d'un développement continu sprint par sprint, un guide de spécifications générales est fortement recommandé.

Pour éviter les erreurs humaines ou les malentendus, il vaut la peine de créer un guide de spécifications du logiciel que vous envisagez de développer. Cependant, il est également possible de discuter et de créer des tickets dans Jira – ou tout autre outil de gestion – et de procéder dès que la portée de l'itération est approuvée.

Mais gardez à l'esprit qu'il existe de nombreuses façons d'implémenter la fonctionnalité décrite. Lorsque vous avez un guide qui donne une idée de ce qui se passerait ensuite, il est toujours possible de mettre en œuvre des éléments du sprint en cours afin qu'ils correspondent à un plan de développement ultérieur.

5. Agile ne nécessite pas la participation constante du Product Owner

Ce n'est pas vrai. Agile nécessite définitivement la participation constante du propriétaire du produit. Il est de la plus haute importance d'avoir le propriétaire du produit, ou un représentant technique de l'autre côté, pour former des sprints.

Comme agile est généralement d'environ 2 ou 3 semaines de sprints, le processus de travail ressemble généralement à ce qui suit :

  • Formation du premier sprint
  • Négociations et formation du deuxième sprint
  • Livraison du premier sprint et début du deuxième sprint
  • Négociations et formation du troisième sprint

Notez que les négociations et la formation se produisent simultanément pendant que le sprint précédent se déroule.

Ainsi, vous voyez que les formations constantes des sprints et la vérification des résultats lorsque l'itération est terminée demanderont beaucoup de temps au propriétaire du produit.

Si vous n'avez pas assez de temps pour participer aux réunions quotidiennes et aux appels constants avec les chefs de projet, pensez peut-être à une autre option.

Communiquer en Agile

N'oubliez pas que le propriétaire du produit doit se connecter avec l'équipe agile par n'importe quel moyen de communication.

Démystifier les mythes du développement logiciel agile

La sélection d'un modèle pour le développement de votre produit est toujours une décision importante pour votre entreprise. Ces 5 mythes montrent l'agilité telle qu'elle est afin de fournir aux clients une compréhension claire de ce à quoi s'attendre.

D'après mon expérience, j'ai appris que les réponses incorrectes aux questions – qui semblent simples pour tout le monde – entraînent en fait une perte de temps sur les projets, des relations de travail gâchées et des malentendus.

Cependant, vous savez maintenant que l'application agile nécessitera votre participation constante au projet et ne sera pas toujours le moyen le plus rapide en matière de livraison.

De plus, il n'est pas toujours appliqué au développement informatique, dans certains cas, l'agilité ne concerne que les objectifs commerciaux divisés en itérations.