Le manque d'exigences fonctionnelles est-il agile?

De nos jours, tout le monde veut être agile. Dans chaque équipe avec laquelle je travaillais, la forme de l'agile était différente. Certaines choses sont courantes - comme les stand-ups quotidiens ou la planification, mais d'autres parties varient considérablement.

Dans mon équipe actuelle, il y a un détail qui me dérange. C'est le manque d'exigences fonctionnelles. Non seulement il n'y a aucune forme écrite d'attentes, mais aussi dans les tâches, il est plutôt vague de définir ce qui doit être fait.

L'objectif du projet est de réécrire l'ancien système en utilisant de nouvelles technologies. L'ancien système n'a pas non plus de documentation raisonnable. Pour sûr, il n'existe pas à jour. La description des exigences par les propriétaires d'entreprise est - faisons-le dans la nouvelle implémentation de la même manière que l'ancienne. Cela semble raisonnable, mais ce n'est pas le cas. L'ancien système est une sorte de code spaghetti et en extraire les exigences commerciales est coûteux. Il semble que la situation affecte négativement la planification. Pour sûr, il est sujet à des erreurs et des bugs dans la nouvelle implémentation (en omettant certains détails).

Par conséquent, je pense - est-il vraiment agile de n'avoir aucune exigence commerciale en cas de réécriture de l'ancien système?

Qu'il manque ou non d'exigences fonctionnelles est agile, c'est une recette pour un désastre. Vous ne pouvez pas reconstruire un système si vous ne savez pas comment ce système fonctionne.

Vous devez dire au propriétaire de l'entreprise que vous ne savez pas comment fonctionne l'ancien système.

Votre meilleure option est de travailler avec le propriétaire de votre entreprise ou quelques utilisateurs expérimentés pour comprendre les processus métier en jeu et développer vos propres tests d'acceptation. Si vous pouvez travailler avec certains utilisateurs finaux, vous obtiendrez peut-être plus de commentaires sur le fonctionnement de l'ancien système.

A défaut, vous devrez effectuer des tests exploratoires dans un environnement non productif pour recueillir vos propres exigences. Souvent, lorsqu'un propriétaire d'entreprise dit «faites-le fonctionner comme l'ancien», il est limité dans le temps et ne peut pas vous aider comme un propriétaire d'entreprise devrait le faire. Vous avez besoin de l'expertise de certains utilisateurs chevronnés ou de nombreux tests manuels de votre part pour comprendre le fonctionnement de l'ancien système.

Informez le propriétaire de l'entreprise qu'un manque d'exigences et de compréhension de l'ancien système augmentera considérablement le temps nécessaire pour le reconstruire - environ le triple du temps ou plus. Face à l'augmentation des délais et des coûts, le propriétaire de l'entreprise vous fournira soit l'expertise requise pour rassembler les exigences plus rapidement, soit décider que la réécriture n'est pas économiquement réalisable pour le moment.

Vous obtiendrez l'un des éléments suivants:

• Exigences appropriées et cycle de développement plus rapide
• Il est temps de rassembler les exigences et de reconstruire le logiciel
• Un nouveau projet qui ne finira pas par être une marque noire sur votre carrière

Agile ne change pas le besoin d'exigences fonctionnelles, mais il change généralement la façon dont vous les rassemblez . La manière non agile consiste à ce que quelqu'un passe par un long processus, puis vous donne une sorte de document contenant toutes les exigences du système.

La manière agile de rassembler les exigences est de travailler ensemble pour spécifier les exigences pour un petit incrément du système, le construire, puis obtenir des commentaires et faire l'incrément suivant. Dans votre situation où vous avez du mal à amener les propriétaires d'entreprise à lancer le processus, je commencerais par passer une demi-journée à explorer la partie de l'ancien système sur laquelle vous souhaitez travailler ensuite, et générer une liste de questions sur les exigences.

Ensuite, asseyez-vous avec les propriétaires de votre entreprise et posez-leur les questions. Il leur sera facile de répondre à certaines questions, il vous sera plus facile de répondre en consultant le code, et d'autres seront difficiles à répondre de toute façon. Divisez les questions difficiles en morceaux de plus en plus petits jusqu'à ce que vous arriviez à une réponse.

L'objectif est d'obtenir juste assez de réponses à vos questions afin de créer quelque chose, d'obtenir des commentaires et de redémarrer le processus. N'oubliez pas que plus vos changements sont petits et plus votre cycle de rétroaction est court, moins c'est grave si vous construisez la mauvaise chose.

La capture des exigences est une partie essentielle de tout projet logiciel (réussi). Mais écrire une spécification des exigences ne l'est pas.

• Une approche centrée sur la documentation peut se terminer comme un jeu de chuchotements chinois: un expert en la matière exprime une exigence, un analyste l'écrit, un développeur essaie d'écrire quelque chose qui correspond à la description de l'analyste, l'utilisateur final est confus parce que le logiciel ne fonctionne pas 'résout pas leur problème.

  Les techniques agiles suggèrent que les développeurs doivent recueillir les exigences directement auprès des experts en la matière, généralement les utilisateurs finaux. Il existe une variété de techniques pour ce faire, par exemple en discutant d'un exemple de scénario avec la PME. Les développeurs sont bons pour repérer les cas marginaux et demander à la PME de clarifier comment le logiciel doit se comporter dans ce cas périphérique.

• Au lieu de rassembler toutes les exigences à l'avance (et donc de risquer de grands malentendus), les équipes agiles commenceront probablement par une petite tranche d'exigences, construiront un prototype et l'utiliseront pour recueillir des commentaires pour la prochaine itération.

• Au fur et à mesure que la compréhension des exigences évolue avec le temps, une spécification statique des exigences ne sera plus à jour. Comment éviter cela?

  En exprimant les exigences sous forme de tests exécutables. Il s'avère que les «spécifications lisibles» et les «tests exécutables» ne sont pas des concepts exclusifs, mais peuvent finir par être un seul et même document. Par exemple, le concombre et d'autres idées hors de l'espace BDD peuvent être très utiles ici.

Dans le cas où vous réécrivez un ancien système, le système d'origine peut être une excellente source d'exigences. Mais quels aspects sont pertinents? Ses fonctionnalités de niche sont-elles même utilisées? Quels bogues doivent être réimplémentés pour plus de compatibilité? Il n'y a généralement pas de solution pour discuter avec les utilisateurs finaux.

Avoir un système qui fonctionne peut également être très utile pour tester le nouveau logiciel, mais cela n'est pas lié à des problèmes d'agilité.

Notez que les projets à durée fixe et à durée fixe avec des échéances imminentes sont l'antithèse de l'agilité. L'approche agile normale consiste à choisir un morceau de fonctionnalité et à fournir d'abord cela, puis à répéter. Les choses les plus importantes sont faites en premier, les choses moins importantes plus tard (ou jamais). Si tout est important et DOIT être fait le plus tôt possible, alors rien n'est important et le projet est peu susceptible de livrer quoi que ce soit.

Dans votre situation, le manque d'exigences n'est pas une fonctionnalité agile mais plutôt un cas moyen de dysfonctionnement organisationnel. Si vous voulez que le projet réussisse, vous devrez trouver un moyen de surmonter ce dysfonctionnement. Par exemple, exhortez le propriétaire de l'entreprise à ne pas rédiger un document complet des exigences, mais essayez de mettre en place une réunion où il explique ses exigences pour la fonctionnalité la plus importante. Vous pouvez consulter l'ancien système pour plus de détails. Ensuite, implémentez cette fonctionnalité et itérez.

Voici comment nous l'avons fait. Nous avons parlé aux propriétaires. Nous avons parlé aux gestionnaires. Nous avons parlé aux utilisateurs qui font le travail. Ce que nous avons trouvé en nous asseyant au bureau d'un utilisateur et en regardant (et en posant des questions) était incroyablement utile. Les managers savaient avec quels utilisateurs nous devrions nous asseoir.

Nous avons découvert que certaines parties du système fonctionnaient très bien, et nous pouvions facilement écrire suffisamment d'exigences pour commencer la conception et le codage et les cas de test et ainsi de suite, mais d'autres parties avaient des solutions de contournement désagréables que les utilisateurs sur le terrain utilisaient, que les gestionnaires et les propriétaires n'étaient pas au courant. Pour ces parties de l'ancien système, nous sommes retournés à l'entreprise et avons parlé un peu du flux de travail et des processus avant de pouvoir définir quelles devraient être les petites tâches et donc les diviser en unités que notre méthode agile voulait.

Ainsi, alors qu'Agile pouvait rapidement décoller sur certaines parties du système, d'autres devaient avoir un peu plus de réflexion et de documentation avant de commencer.

Rassembler les exigences dans un cadre Agile et personne n'a mentionné les User Stories? Une user story est essentiellement une définition de haut niveau de ce que le logiciel devrait être capable de faire. En règle générale, tout commentaire ou demande émanant de l'entreprise ou de l'utilisateur final peut être écrit sous la forme d'une user story. ... Vous pouvez considérer les critères d'acceptation comme les exigences fonctionnelles qui prennent en charge une user story.

Cette question fait allusion à ce qui n'allait pas avec le mouvement agile. Ce n'est pas la faute de la personne qui pose la question; Je tombe dans ce piège tout le temps parce que des années de vie en entreprise m'ont entraîné.

Le piège dont je parle est de penser qu'il existe une manière Agile prescrite et correcte de faire les choses. Cela pourrait être dû au fait que les gens pensent qu'Agile existe. Vous ne pouvez pas faire Agile plus que vous ne pouvez faire Pragmatique.

Ne pas avoir de «spécifications fonctionnelles» ou autre chose, cela semble inquiétant, mais ce n'est peut-être pas le cas. De combien de détails avez-vous besoin pour commencer? La sécurité et les performances sont les plus évidentes qui sont connues dès le départ et s'appliquent tout au long du processus. Sinon, s'agit-il d'un moteur de tarification des options ou d'une application d'horloge?

Y aura-t-il une version continue, une discussion, un apprentissage, un retour en arrière et une modification du logiciel? Construisez-vous des logiciels ou du matériel?

Les développeurs travaillant dans un processus en cascade ne s'impliquent souvent que plus tard, ce qui est un problème. Les impliquer plus tôt ou dès le début signifie qu'ils sont au courant que les choses ne sont pas claires, non définies et à moitié cuites, ce qui semble bouleverser les développeurs de longue date, alors qu'en fait une partie de leur travail consiste à poser des questions, telles que "quelles sont les exigences fonctionnelles pour cette chose que nous allons construire? "

Identifier les trous dans le plan ne consiste pas à trouver une faute, c'est juste un développement logiciel.

Pour cette raison, j'aime la réponse de Guy.