L’écriture de logiciels en l’absence d’exigences est-elle une compétence à posséder ou une situation à éviter?


44

Je trouve que certains développeurs de logiciels sont très habiles à cela, et souvent, ils sont félicités pour leur capacité à fournir un concept fonctionnel avec des exigences abstraites. Franchement, cela me rend fou, et je n'aime pas "inventer" ce que je fais. J'avais l'habitude de penser que c'était problématique, mais j'ai commencé à sentir un changement, et je me demande si j'ai besoin d'ajuster mon processus de pensée (et de programmation) avec très peu de directives. Devrais-je commencer à acquérir cette capacité en tant que compétence ou rester fidèle à l'idée que la collecte des exigences et les règles de gestion constituent la première priorité?


2
Une situation à éviter. La seule chose est que vous ne pouvez pas. Et j'en ai parlé il y a quelques semaines ...
yannis

64
C'est les deux, un peu comme si vous utilisiez un extincteur.
Ben Brocka

3
Si vous ne parvenez pas à planifier, vous prévoyez d'échouer. Ces projets construits sans exigences peuvent répondre ou non aux attentes du client quand ils quittent la boutique, mais ils cachent certainement une multitude de péchés qui signifient que lorsque les exigences changent (et elles le font toujours), un monde de blessures attend la personne qui faire les changements nécessaires. Les programmeurs qui écrivent sans exigences formelles ne devraient pas être félicités, ils devraient être réprimandés pour ne pas être préparés à la maintenance à long terme du projet
GordonM


5
Parfois, le client ne sait pas ce qu'il veut. Ils veulent que vous exécutiez des "expériences" pour déterminer ce qu'ils veulent. J'ai déjà écrit un système de commission où la seule exigence était de payer des commissions. Le pourcentage et les éléments sur lesquels la commission devait être payée devaient être déterminés en fonction de l’expérience acquise avec le système de commission expérimental.
Gilbert Le Blanc

Réponses:


80

L'habileté n'est pas d'écrire un logiciel sans exigences. Il s’agit plutôt d’obtenir des exigences du propriétaire du projet, qu’il existe ou non une documentation des exigences formelles.

Rassembler les exigences est certainement votre première priorité, mais vous n'avez pas nécessairement besoin de connaître immédiatement tous les besoins du client. Le risque est bien sûr que vous manquiez certaines informations vitales qui rendraient l’architecture de votre système inutile si vous n’aviez pas réussi à avoir le type de conversation approprié avec votre client. Toutefois, il n’est pas inhabituel de définir un produit et même d’obtenir une grande partie du développement reste à l’écart, tout en reportant les décisions majeures en matière d’architecture système au dernier moment possible. Il s'agit d'une approche de développement allégée qui vise à garantir que vous ne vous engagez pas trop tôt dans une architecture potentiellement incompatible dans le développement de votre produit, jusqu'à ce que vous disposiez d'informations plus fiables. Dans les situations décrites par le PO dans sa question,

Oui, il est parfois nécessaire de regarder un peu la boule de cristal pour comprendre ce que le client demande réellement, c’est-à-dire le pic de prototypage et la lenteur - parfois même pénible - des exigences supplémentaires vous développez de bonnes compétences en relation client et la patience de réaliser qu'avec une idée de logiciel complexe, le client ne sait souvent pas beaucoup plus que vous ce que le logiciel doit réellement faire. Le plus souvent, le client vous appelle au début pour vous fier à votre expertise pour définir ses besoins, car il ne dispose pas toujours de l'expertise ou de la connaissance nécessaire du processus de développement logiciel.


22
"L'habileté n'est pas d'écrire un logiciel sans exigences. C'est plutôt de demander des exigences au propriétaire du projet, qu'il y ait ou non une documentation des exigences formelles." C'est aussi une chose à laquelle j'ai beaucoup réfléchi. C'est presque comme être un bon détective, ou savoir interviewer quelqu'un et poser les bonnes questions. Dans cette situation, je trouve la question "Pouvez-vous me dire ce que vous voulez faire?" fonctionne beaucoup mieux que "Pouvez-vous me dire comment cela devrait fonctionner?"

5
@BrianReindel Je commence parfois par une combinaison Mind-Map / Binary-Tree des pensées du client. Je demande "Quelle est l'idée?", Puis utilisez l'association de mots pour voir ce que chaque idée apporte au client. À partir de là, je construis une image de ce que pense le client et je commence à définir les exigences à partir de là. Chaque exigence évoque des questions qui doivent être posées. Les questions "Pourquoi" me donnent généralement une meilleure réponse que les questions "Quoi / Comment", car elles donnent au client l'occasion de penser au-delà des notions de base. C'est un art d'utiliser la psychologie pour que le client révèle ses besoins.
S.Robins

3
Une partie de l'habileté consiste à connaître l'ordre dans lequel faire les choses et à éviter de "perfectionner" des choses qui vont se déchirer de toute façon. De cette façon, vous pouvez rencontrer le client / le responsable / ce que vous voulez, leur montrer ce que vous avez jusqu'à présent et vous adapter au fur et à mesure. Vous devez d'abord savoir faire les grands pas dans la bonne direction.
David Schwartz

4
Une façon de déterminer les exigences est de leur donner quelque chose de fondamental et de voir de quelles parties ils se plaignent. Par exemple, créez un prototype en papier ( amazon.co.uk/… ) et parcourez les interactions avec eux.
deworde

35

C'est très ambigu…

Deux choses que je peux dire:

  1. Il y a beaucoup de techniciens très doués dont la carrière est interrompue parce qu'ils attendent des exigences parfaites. Ou ils jouent le "Désolé, je ne peux pas le faire, ce n'était pas dans les exigences." La réalité est que la rédaction des exigences est très difficile. La précision requise pour de bonnes exigences est différente de tout ce que la plupart des gens d’affaires ont jamais créé. Il existe un pont entre la technologie et le monde des affaires, et les personnes qui font que les autres viennent à 100% du chemin pour les rencontrer perdent généralement.

  2. Il existe des informaticiens qui apprennent les domaines aussi bien ou mieux que leurs clients. Ces personnes valent leur pesant d'or, même si elles ne sont pas à 100% les meilleurs développeurs. J'ai vu des spécialistes du logiciel anticiper les besoins en marketing quantitatif des meilleurs gestionnaires de marques du pays. Ils n'étaient pas les meilleurs pour coder toutes les solutions, mais ils étaient des héros parce qu'ils pouvaient traverser le pont.

La vie ne concerne pas les noirs et les blancs. Si vous dessinez une boîte étroite autour de vous, vous vous limitez. D'un autre côté, une organisation qui rejette ce qui est nécessaire pour créer de la technologie est également limitée. Vous devrez voir où dans le gris vous préférez être.


12

Les exigences sont les étapes du voyage, une vision est la direction

Pour de nombreuses applications, une spécification technique très détaillée est trop complexe dans l’hypothèse où une discussion rapide pourrait rendre leur document soigneusement composé inutile. Au lieu de cela, commencez par une vision. Si tout le monde comprend la situation dans son ensemble, les exigences peuvent être remplies tout au long des discussions.

En tant que développeur, vous devez apprendre à utiliser ces discussions pour rechercher les besoins . Cela signifie poser aux clients des questions incitatives qui les incitent à réfléchir à la manière dont leur décision s’intègre dans la vision globale. Plus tôt ces discussions plus détaillées auront lieu, plus vite la vision globale se concrétisera dans une conception cohérente.

Vous devez suivre le résultat de ces discussions dans une sorte de suivi des problèmes afin que les autres utilisateurs puissent les commenter s'ils ont manqué la discussion initiale. Et pour que vous ayez un dossier que vous-même, ou d'autres membres de votre équipe, pouvez consulter si vous avez besoin de précisions.

Alors, apprenez à coder contre la vision, mais soyez prêt à rechercher ces exigences le moment venu.


+1 pour "Les exigences sont les étapes du voyage, la vision est la direction"
utilisateur,

10

Steve Jobs pensait que les clients ne pouvaient pas décrire exactement à quoi ils souhaitaient ressembler les futurs produits. Il vous incombe donc de les fournir. Donc, à moins de fournir tout le temps un logiciel personnalisé, oubliez les spécifications techniques et commencez par créer des prototypes et laissez les clients jouer avec eux et vous dire ce qu'ils pensent. Vous devez mettre la bonne personne en train de faire le prototypage et elle a besoin d'aide. Je le dis par expérience - je suis le singe du prototypage qui aime créer des interfaces intuitives et je me suis associé à une personne du produit qui comprend ce que les clients veulent et peut expliquer des choses sur papier ou avec Excel.

Nous ne sommes ni l'un ni l'autre des génies, mais nous pensons la même chose - vous pouvez presque dire que nous avons la chimie et que nous avons eu un impact énorme sur la manière dont les choses sont construites. Désormais, seule une équipe de taille moyenne à grande peut se permettre d'avoir un prototypeur et un non-codeur qui développent un produit exclusivement, mais cela en vaut la peine. Le prototypage étant l'étape la moins chère du développement logiciel, il est donc logique de définir correctement l'interface utilisateur et le comportement apparent. Je n'ai pas lu Code Complete, mais je pense qu'il y a quelque chose comme ça écrit dans ce livre.

Les spécifications sont agréables, mais elles ne sont jamais parfaites. Il existe un théorème à ce sujet. Vous ne pouvez pas prouver que la spécification est complète ni que l’outil n’a aucun bogue ou s’arrêtera :)

Pourtant, les éditeurs de logiciels expédient les logiciels tout le temps, en dépit de ces imperfections. La spécification ne sera jamais parfaite. La spécification est également UNNATURAL et obsolète. Une spécification à un prototype ressemble à une table de logarithme à un seul graphique - une spécification est essentiellement une brochure ennuyeuse destinée à être imprimée, alors que vous pouvez interagir avec un outil / graphique. Consultez http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html pour trouver l' inspiration.

Maintenant, les spécifications sont bonnes si vous devez avoir un contrat pour couvrir vos fesses. Mais une spécification devrait toujours venir après un prototype, pas avant. Il vous appartient de déterminer comment fabriquer des prototypes à bas prix.


+1 pour la spécification jamais parfaite, mais -1 pour la spécification non naturelle et obsolète. Considérez les exigences comme une liste de fonctionnalités souhaitées par un client, et une spécification étant la liste de comportements définissant les besoins de ce dernier. Il s’agit essentiellement d’un contrat définissant le fonctionnement du système au lieu de ce qu’il est. Une conception et des spécifications de premier plan sont problématiques, mais, comme tous les gros problèmes, il est plus facile à résoudre lorsque les problèmes sont résolus un à un. Le prototypage est également rarement rentable si vous n’avez aucune idée de ce qu’il faut prototyper. C'est là que les spécifications offrent un point de départ ...
S.Robins

... cependant, les spécifications ne doivent pas nécessairement être écrites dans la pierre. Le prototypage (essentiellement les problèmes de dopage) est particulièrement utile lorsqu'il introduit de nouvelles informations dans la spécification et lorsque la spécification est autorisée à être modifiée pour tenir compte de ce que vous avez appris du prototype. Sans les spécifications, vous risquez simplement d'inventer des choses au fur et à mesure, ce qui n'est pas toujours dans l'intérêt du client. Les clients s'attendent à ce que vous répondiez à leurs besoins, et vous risquez moins de frictions lorsque vous pouvez prouver que vous avez accepté quelque chose, même si ce n'est que provisoirement.
S.Robins

@S. Robins, un médecin (client) pourrait dire quelque chose d'aussi simple que "Je veux voir un arbre généalogique avec le risque de cancer estimé correspondant pour chaque membre de la famille". Comme il existe de nombreuses façons différentes de présenter ces informations et de s’inquiéter des familles nombreuses qui couvrent plusieurs pages, je pense qu’il serait absurde de commencer à documenter cela immédiatement comme une spécification. Nous avons compris ce que le médecin a dit, mais nous voulons être plus précis. Un prototype interactif qui affiche des nombres et des noms aléatoires qu'un document peut dire oui ou non est plus naturel qu'une spécification de 30 pages incomplète qui tente de décrire les mêmes.
Job

1
Je comprends d’où vous venez, mais ce que vous suggérez est généralement une approche coûteuse. Évidemment, je ne dis pas que le prototype est un produit complet, mais tout ce que vous construirez où il y a une interactivité nécessitera du temps pour se développer. Une option moins coûteuse consiste à se tenir devant un tableau blanc, à esquisser quelques idées et à poser des questions ciblées pour vous aider à préciser vos critères. Je ne préconise pas non plus la création d'une grande spécification. Les documents hiérarchiques, ou même les modèles de code de test, produits de manière itérative et au besoin, sont généralement plus simples et moins coûteux que le prototypage.
S.Robins

3

J'ai souvent constaté que dans certaines situations, je devais agir en tant qu'analyste commercial, en découvrant exactement le fonctionnement actuel de l'entreprise, la façon dont les gens pensent que cela fonctionne (souvent, des choses très différentes) et comment ils voudraient que cela fonctionne.

J'ai trouvé le succès en étant toujours clair sur les décisions que je suis obligé de prendre pour construire le logiciel. J'explique mon raisonnement, rédige de la documentation sur ce que j'ai découvert, crée des graphiques et les distribue à tout le monde, etc.

Vous ne ferez probablement pas une très bonne impression en refusant d'effectuer des travaux tant que les conditions requises ne seront pas complètement transmises. Mais en réunissant vous-même de bonnes exigences en matière de qualité (sans nécessairement attirer l'attention sur vous), vous atteindrez le même objectif de logiciel de qualité.

Et oui, comme l'ont dit d'autres commentateurs, construisez toujours le logiciel en supposant qu'il va changer. Le changement est la seule constante sur laquelle vous pouvez compter. Construisez toujours votre logiciel de manière suffisamment souple et modulaire pour ne pas avoir à vous soucier de le mettre à jour lorsque de nouvelles exigences apparaissent soudainement.


3

Si vous voulez travailler en tant que développeur de logiciel dans une startup, c'est une compétence à posséder.

Si vous voulez travailler dans une société de conseil, alors c'est une situation à éviter à tout prix. En effet, votre entreprise est payée en fonction de la manière dont vous mettez en œuvre les spécifications / exigences et non de la manière dont vous avez résolu le problème du client.

Si vous codez pour le plaisir pendant votre temps libre, alors c'est votre appel. Si vous ne vous sentez pas qualifié pour faire l'appel pour vos projets de temps libre, essayez-en un dans chaque sens et voyez ce qui fonctionne. En outre, il n’est pas nécessaire d’adopter une approche uniforme, certains projets préconisant l’un ou l’autre type d’approche. Habituellement, si vous choisissez le mauvais sur l'un de ces projets, vous vous en sortirez vite.


2

Un peu des deux. Vous devez satisfaire vos clients, ce qui signifie que vous devez savoir ce qu'ils veulent. D'autre part, les clients sont notoirement mal à communiquer ce qu'ils veulent vraiment.

Vous voulez donc éviter les scénarios dans lesquels vous ne savez pas ce que les clients veulent, mais vous allez inévitablement vous retrouver dans un scénario dans lequel les exigences sont au mieux «spongieuses» et au pire trompeuses. Un bon programmeur du monde réel requiert de la faculté d'adaptation.


2

Il n'est pas possible d'écrire un programme sans exigences. Même le «Hello World» a l'exigence: produire une sortie. Donc, je pense que vous posez des questions sur les exigences formelles, sous la forme d’une grosse pile de quelque chose comme UML. Et concernant ceux-ci, j'ai rencontré 2 types de personnes:

1) Les personnes qui ont besoin de conditions formelles. Ils doivent savoir exactement quoi faire et, au mieux, comment le faire. Ils adorent les phrases telles que La procédure A en prenant l’argument B produira la sortie C , et les déteste: Le programme doit rendre le travail de notre département plus efficace . Ce sont généralement des animaux d'entreprise.

2) Les gens qui sont opposés à 1. Ils détestent se faire dire quoi faire et comment faire, ils aiment se faire dire ce qui devrait être accompli. Ils aiment parler au client, analyser ce qu'ils disent et ensuite développer leur propre solution. Ils sont généralement indépendants et ne conviennent pas à la société.

Je ne dirai pas lequel est le meilleur. Les deux ont leurs avantages et leurs inconvénients. Ils sont simples et adéquats pour les autres conditions.


0

Vous ne pouvez PAS développer un logiciel opérationnel sans connaître les exigences; mais, vous pouvez avoir un très bon coup pour développer ce que votre expérience vous dit que les exigences sont probablesêtre. Le développement agile utilise une combinaison de techniques «intuitives», notamment la règle 80:20 et la «découverte» des exigences par prototypage. En d’autres termes, une équipe de développement expérimentée détermine au mieux les besoins et produit un prototype du logiciel. La règle 80:20 dit qu'ils seront corrects à 80%. Les parties prenantes du projet examinent ensuite le prototype tangible. Leurs commentaires commencent à combler les 20% de lacunes dans notre compréhension des exigences. Ainsi, dans les faits, Agile ne consiste pas à écrire un logiciel sans aucune exigence, mais à utiliser votre expérience antérieure pour dire "voulez-vous quelque chose comme ça?" Ce qui, dans 80% des cas, vous permettra d’aller de l’avant et de confirmer ce qui est réellement nécessaire plus rapidement que de passer à travers les processus traditionnels d’exigences.


Agile ne concerne pas l'intuition, mais la communication. Livrer des logiciels en bon état de fonctionnement souvent afin de recevoir des commentaires est souvent une manière d'encourager la communication et de valoriser la fourniture des éléments dont le client a besoin. Oui, l'expérience entre en jeu, mais vous êtes plus susceptible de développer ce que le client a besoin si vous lui demandez d'abord ce qu'il a besoin. La règle dite des 80:20 ne s'applique vraiment que si vous connaissez très bien le domaine professionnel du client, et même dans ce cas, je prendrais cette "statistique" avec une grosse cuillère de sel.
S.Robins

-2

Qui a dit qu'Agile écrivait du code en l'absence d'exigences? Je sais que le Manifeste a été interprété de cette façon par certains ... mais cela ne le rend pas juste.


1
Bonjour Trent, bien que je sois d'accord avec votre commentaire de principe (et j'en ai marre de voir comment les gens utilisent Agile comme excuse pour bousiller le processus de développement et l'appeler "être agile"), cette réponse ne s'adresse pas vraiment aux PO. question, qui ne concerne pas Agile, mais demande plutôt si écrire un logiciel sans exigences est une compétence à développer. Peut-être avez-vous eu l'intention d'ajouter ceci comme commentaire à la réponse de quelqu'un d'autre?
S.Robins
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.