Quelle est l'importance de connaître les fonctionnalités avant de coder?

Je travaille pour une société de développement de logiciels où le travail de développement nous a été abandonné. L'équipe à terre s'occupe du soutien et parle directement aux clients. Nous ne parlons jamais directement aux clients, nous parlons simplement aux gens de l'équipe à terre, qui parlent directement aux clients.

Lorsque les exigences viennent, l'équipe à terre parle aux clients et établit les documents d'exigence et nous informe. Nous réalisons des documents de conception après avoir étudié les exigences (nous suivons le modèle traditionnel en cascade).

Mais il y a un problème dans tout le processus: personne dans l'équipe off-shore ou on-shore ne comprend parfaitement les fonctionnalités de l'application. Nous savons que c'est une grande application Web complexe qui gère le traitement complexe des commandes, la gestion des catalogues, la gestion des campagnes et d'autres activités. Nous avons du mal avec le document de conception car les exigences ne seraient pas claires. Il va ensuite dans une série de questions / réponses entre l'équipe à terre, l'équipe à terre et les clients. On nous disait souvent de comprendre les fonctionnalités du code. Mais ce n'est généralement pas possible car la base de code est énorme et même la compréhension d'un élément de menu simple prend des jours, voire des semaines. Nous avons essayé de dire aux clients de nous donner le transfert de connaissancessur l'application mais en vain. Notre responsable nous disait souvent de commencer à coder même si le document de conception n'est pas complet ou si les exigences ne sont pas claires. Nous commencerions par coder la partie des exigences qui semble claire et attendons le reste.

Cela retarderait généralement le déploiement d'un mois. Dans les cas extrêmes, nous aurions de très faibles erreurs dans le développement et la production, mais les clients diraient que ce n'est pas ce qu'ils ont demandé. Cela lancerait un jeu de blâme et une série de demandes de changement et nous finirions par développer quelque chose de très différent.

Ma question est de savoir comment feriez-vous du travail de développement si vous ne connaissez pas pleinement les fonctionnalités de l'application?

MISE À JOUR

La méthodologie de développement ce n'est pas vraiment mon choix et je ne suis pas le chef d'équipe. C'est comme ça que ça a commencé. J'ai essayé de parler aux gens des avantages de l'agilité, mais en vain. De plus, je ne pense pas que mon équipe ait l'état d'esprit nécessaire pour travailler dans un environnement agile.

Version courte:

Savoir quoi faire ≠ connaître votre client.

Imaginez ceci: vous êtes une entreprise liée au développement immobilier. Vous demandez à votre partenaire de construire un grand complexe. Le partenaire dit que malgré tous les documents que vous lui avez remis, il doit également parler directement aux personnes qui achèteraient les appartements de ce complexe. Sérieusement?

Version longue:

Il est toujours agréable de savoir comment une application spécifique sera utilisée, car c'est amusant d'apprendre des choses, mais ce n'est pas toujours possible sur de grands projets.

Certains domaines sont tout simplement trop complexes. Si vous n'êtes qu'un développeur et que vous travaillez sur plusieurs applications de plusieurs domaines, vous ne pouvez pas toujours comprendre ce que fait l'utilisateur final , car cela vous obligerait à passer cinq ans à apprendre la comptabilité, dix ans à la faculté de médecine, six ans en droit, etc.

D'un autre côté, un produit logiciel fabriqué sans aucune compréhension du domaine spécifique sera au mieux un peu inutilisable .

C'est pourquoi les exigences fonctionnelles et non fonctionnelles doivent être écrites par des personnes qui comprennent parfaitement le domaine. En général, la collecte des exigences implique en même temps:

1. Techniciens (par exemple des développeurs qui diraient qu'une fonctionnalité spécifique est impossible, que cette autre peut être bien meilleure si elle est effectuée de cette façon, et celle-ci coûtera des milliers de dollars alors qu'il existe une alternative beaucoup moins chère),

2. Des personnes spécialisées en gestion de projet,

3. Des personnes spécialisées dans le domaine du client , qui ont une parfaite compréhension de ce domaine et des besoins précis du client. Bien sûr, cela peut être le client lui-même.

Une exigence fonctionnelle et non fonctionnelle est écrite et suffisamment précise, vous n'avez besoin de rien d'autre en tant que personne dont le travail consiste à traduire ces exigences en code.

Quant à votre cas spécifique, vous décrivez vous-même la cause du problème:

Nous avons du mal avec le document de conception car les exigences ne seraient pas claires.

Ce n'est pas le manque de connaissances sur le client qui cause tous les ennuis , c'est la faible qualité des exigences. Dans un projet correctement géré, les exigences fonctionnelles et non fonctionnelles doivent être parfaitement claires et sans ambiguïté. Si le document d'exigences n'est pas clair ou s'il vous dit que "le design visuel du produit doit être attractif" ou d'autres bêtises comme ça, c'est parce qu'il a été écrit par des gens qui ne savent pas l'écrire.

Sachant cela, vous devez agir différemment:

• Si vous savez que l'équipe qui recueille les exigences est désespérée et que votre propre équipe a des personnes qualifiées pour la collecte des exigences, expliquez la situation à votre supérieur et dites que l'autre équipe doit être remplacée par une personne compétente , par exemple des personnes de la vôtre.

• Sinon (c'est-à-dire s'ils ne sont pas désespérés), essayez de déterminer la cause interne de ces faibles exigences et persuadez-les que faire leur travail correctement ne fera que réduire le coût global du projet . Montrer les statistiques sur la façon dont les exigences mal écrites ont influencé le projet en augmentant le coût (combien?) Et le risque de ne pas être prêt pour la date limite est une bonne idée ici.

Le document des exigences est probablement incomplet. Je le vois tout le temps: les chefs de projet inexpérimentés sont juste convaincus qu'un document d'une page suffit, et ne comprennent pas pourquoi ils écriraient jamais trois à quatre cents pages au lieu d'une. Si c'est le cas dans votre entreprise, montrez que consacrer plus de temps aux exigences diminuerait les coûts.

Vous utilisez exactement la mauvaise méthodologie de développement pour les problèmes que vous rencontrez.

En utilisant Waterfall, vous vous engagez à:

1. Obtenir les bonnes exigences dès le départ - cela ne fonctionne évidemment pas
2. Coder les exigences loin du client - vous n'êtes pas en mesure de vérifier efficacement les problèmes avec le client étant donné que vous vous êtes engagé à développer les exigences
3. La première chance pour le client de voir ses fonctionnalités est pendant les tests - c'est beaucoup trop tard étant donné les problèmes que vous rencontrez

Envisagez d'utiliser, si possible, une autre façon de gérer le projet. Le développement logiciel agile possède plusieurs fonctionnalités conçues pour résoudre les problèmes auxquels vous êtes confronté.

Une comparaison décente de Waterfall vs Agile a été écrite il y a quelque temps, prenons quelques citations qui mettent en évidence vos problèmes:

Manquer la marque:

Une fois qu'une étape est terminée dans la méthode Waterfall, il n'y a pas de retour en arrière, car la plupart des logiciels conçus et mis en œuvre sous la méthode Waterfall sont difficiles à modifier en fonction du temps et des besoins des utilisateurs. Le problème ne peut être résolu qu'en reculant et en concevant un système entièrement nouveau, une méthode très coûteuse et inefficace.

Attaché...

Les méthodes agiles permettent de modifier les spécifications selon les exigences de l'utilisateur final, ce qui traduit la satisfaction du client. Comme déjà mentionné, cela n'est pas possible lorsque la méthode de la cascade est utilisée, car tout changement à effectuer signifie que le projet doit être recommencé à nouveau.

... et incapable de bouger

Pour résumer la différence entre les deux, on peut dire que la méthode classique de la cascade est synonyme de prévisibilité, tandis que la méthodologie Agile définit l'adaptabilité. Les méthodes agiles sont bonnes pour réduire les frais généraux, tels que la justification, la justification, la documentation et les réunions, en les maintenant aussi bas que possible. Et, c'est pourquoi les méthodes Agiles profitent aux petites équipes avec des exigences en constante évolution, plutôt qu'à des projets plus importants.

Où vous êtes maintenant est mauvais; vous ne répondez pas aux exigences du client et, si vous êtes dans le blâme du développement de logiciels, la productivité va disparaître, la méfiance va augmenter et les choses vont probablement empirer, pas mieux.

La relation avec le client est critique ; ici, il semble que vous ne puissiez pas collecter efficacement leurs problèmes et vous adapter à leurs besoins changeants dans la façon dont vous travaillez actuellement; vous devez donc chercher des moyens de changer cela.

Ce n'est pas ainsi que cela fonctionne. L'un des sujets de ma formation actuelle est celui de l'analyse et de la relation avec un client. L'accent a toujours été mis sur la définition claire du projet. Imagine ça:

• Vous ordonnez à une entreprise de construction de construire une maison mais vous ne savez pas à quoi vous voulez qu'elle ressemble. Vous venez de personnaliser le premier étage, de sorte que l'équipe construit une maison jusqu'au premier étage. Ensuite, vous souhaitez que le rez-de-chaussée soit aménagé différemment. Oops...

À moins que vous ne soyez très sûr de pouvoir (partiellement) créer les fondations correctes pour l'application, je dirais simplement au client qu'il n'y a pas d'autre moyen de le faire qu'avec des objectifs et des fonctionnalités clairement définis. Parce que si vous essayez simplement ce que cela pourrait être, vous risquez de jeter beaucoup d'argent et de perdre du temps.

Voici quelques éléments qui aideront à surmonter les problèmes:

1. Améliorez la communication entre les deux équipes. Demandez à l'autre équipe de compresser l'exigence en 3 mots, puis le programmeur implémentera ces mots exactement. Les mots doivent juste être corrects. Rien ne sera mis en œuvre sans ces mots. Chaque mot vous donne 2000 lignes de code. L'implémentation commence lorsqu'un nouveau mot est connu.
2. Si un mot n'est pas immédiatement clair pour vos programmeurs, ils sont autorisés à poser une seule question . Encore une fois, la question doit être correcte. Il a besoin d'une réponse immédiate - la réponse ne peut pas attendre un aller-retour de l'autre côté du monde, mais elle doit être connue à l'avance. La mise en œuvre commence immédiatement après réception de la réponse et la réponse sera suivie à la lettre.
3. Si au cours de la mise en œuvre, il existe des exigences floues ou floues, la façon de les résoudre consiste à examiner d'abord les 3 mots (existants). S'il n'est toujours pas clair, le programmeur fait la meilleure supposition possible . Tout retard dans ce processus est absolument interdit; et demander de l'aide à l'autre équipe n'est pas la bonne façon de le résoudre - ils ont déjà eu la chance de changer les exigences en décidant de 3 mots corrects.
4. Si après tout cela, l'exigence n'est toujours pas claire ou impossible à mettre en œuvre, la bonne façon de gérer est de rejeter les 3 mots qui ont causé le problème et de passer aux mots suivants. Tous les mots rejetés seront collectés et transmis à l'autre équipe, et ils devront modifier les mots avant de les saisir à nouveau dans le système. Le rejet des mots déplace toujours le délai et la mise en œuvre devra être planifiée à nouveau.
5. Les équipes devraient être évaluées en fonction du nombre de mots rejetés dont elles disposent. Une fois l'exigence mise en œuvre, elle est fixée pour toujours et ne peut plus être modifiée . Toute tentative de modification des fonctionnalités déjà implémentées sera rejetée.
6. Le problème réel de la question est qu'elle suppose que plus d'informations facilitent la mise en œuvre. Ce n'est pas vrai. La plus grande liberté vos programmeurs ont, plus facile la mise en œuvre . La compression des exigences permet de communiquer de grandes quantités d'informations sans trop restreindre ce que les programmeurs sont autorisés à faire.