L'écriture de logiciels en l'absence d'exigences est-elle une compétence à posséder ou une situation à éviter?
Je trouve que certains développeurs de logiciels sont très compétents dans ce domaine, et souvent, les temps sont loués pour leur capacité à fournir un concept de travail avec des exigences abstraites. Franchement, cela me rend fou et je n'aime pas "inventer" quand je vais. Je pensais 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) quand on me donne très peu de direction. Dois-je commencer à acquérir cette capacité en tant que compétence, ou m'en tenir à l'idée que la collecte des exigences et les règles commerciales sont la première priorité?
La compétence n'est pas d'écrire des logiciels sans exigences. Il s'agit plutôt d'obtenir des exigences du maître d'ouvrage, qu'il existe ou non une documentation formelle sur les exigences.
Rassembler les exigences est certainement votre première priorité, mais vous n'avez pas nécessairement besoin de noter tous les besoins du client à l'avance. Le risque est bien sûr que vous puissiez manquer certaines informations vitales qui rendent votre architecture système inutile si vous n'avez pas réussi à avoir le bon type de conversations avec votre client, mais il n'est pas inhabituel de définir un produit et même d'obtenir une grande partie du développement à l'écart, tout en différant les principales décisions d'architecture du système jusqu'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 tant que vous ne disposez pas d'informations plus solides. Dans les situations décrites par le PO dans sa question, cette approche allégée serait assez importante à mon humble avis pour éviter des retouches importantes et une explosion des coûts plus tard, c'est-à-dire lorsque vous avez finalement réussi à savoir ce dont votre client avait vraiment besoin.
Oui, vous avez parfois besoin de regarder un peu la boule de cristal pour aller au cœur de ce que le client demande vraiment, c'est-à-dire là où les pics de prototypage et le lent - et parfois douloureux - dessin progressif des exigences nécessitent que vous développez vraiment de bonnes compétences en relation avec la clientèle, ainsi que la patience de réaliser qu'avec toute idée de logiciel complexe, au début, 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 tôt pour dépendre de votre expertise pour définir ses besoins car le client n'a pas toujours l'expertise ou la connaissance nécessaire du processus de développement logiciel.
C'est très ambigu…
Deux choses que je peux dire:
Il y a beaucoup de techniciens très doués dont la carrière est interrompue car ils attendent des exigences parfaites. Ou ils jouent le "Désolé, je ne peux pas le faire, ce n'était pas dans les conditions requises." 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 y a un pont entre la technologie et l'entreprise, et les gens qui font venir les autres à 100% pour les rencontrer perdent généralement.
Il y a des gens du logiciel qui apprennent les domaines aussi bien ou mieux que leurs clients. Ces gens valent leur pesant d'or, même s'ils ne sont pas à 100% les meilleurs développeurs. J'ai vu des gens du logiciel anticiper les besoins de marketing quantitatif des meilleurs chefs de marque du pays. Ils n'étaient pas les meilleurs pour coder toutes les solutions, mais ils étaient des héros car ils pouvaient traverser le pont.
Mais la vie n'est pas faite de noir et de blanc. 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.
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 tout simplement trop à l'avant car une discussion rapide pourrait rendre inutile leur document soigneusement composé. Commencez plutôt par une vision. Si tout le monde comprend le tableau d'ensemble, les exigences peuvent être remplies tout au long des discussions.
En tant que développeur, vous devez apprendre à utiliser ces discussions pour parcourir les exigences . Cela signifie poser aux clients des questions directrices qui les amènent à réfléchir à la façon dont leur décision s'inscrit aujourd'hui dans la vision globale. Plus tôt ces discussions plus détaillées auront lieu, plus vite la vision globale se solidifiera en une conception cohérente.
Vous devriez garder une trace des résultats de ces discussions dans une sorte de suivi des problèmes afin que d'autres puissent les commenter s'ils ont raté la discussion d'origine. Et pour que vous ayez un dossier auquel vous ou d'autres membres de votre équipe pouvez vous référer si vous avez besoin d'éclaircissements.
Alors, apprenez à coder contre la vision, mais soyez prêt à chaluter pour ces exigences le moment venu.
Steve Jobs pensait que les clients ne peuvent pas décrire exactement à quoi ils veulent que les futurs produits ressemblent, c'est donc à vous de les livrer. Donc, à moins que vous ne fournissiez tout le temps des logiciels personnalisés, oubliez les spécifications formelles et commencez par créer des prototypes et laissez les clients jouer avec eux et vous dire ce qu'ils en pensent. Vous devez mettre la bonne personne à 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 j'ai fait équipe avec quelqu'un dans le produit qui comprend ce que veulent les clients et peut expliquer les choses sur papier ou en utilisant Excel.
Aucun de nous n'est un génie, mais nous pensons de la même façon - vous pouvez presque dire que nous avons la chimie et que nous avons eu un impact énorme sur les choses qui sont construites et comment. Maintenant, seule une équipe de taille moyenne à grande peut se permettre d'avoir un prototyper et un non-codeur qui développe exclusivement des produits, mais cela en vaut la peine. Le prototypage est l'étape la moins chère du développement logiciel, il est donc logique de bien définir l'interface utilisateur et le comportement apparent. Je n'ai pas lu Code complet mais je pense qu'il y a quelque chose comme ça écrit dans ce livre.
Les spécifications sont agréables à avoir, 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 et vous ne pouvez pas prouver que l'outil n'a pas de bogues ou qu'il s'arrêtera :)
Pourtant, les éditeurs de logiciels expédient des logiciels tout le temps malgré ces imperfections du processus. La spécification ne sera jamais parfaite. La spécification est également NON NATURELLE et obsolète. Une spécification à un prototype est comme le tableau de logarithme à un seul graphique - une spécification est essentiellement une brochure ennuyeuse destinée à être imprimée alors que vous pourriez interagir avec un outil/graphique à la place. Découvrez http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html pour 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. C'est votre travail de comprendre comment fabriquer des prototypes à bon marché.
Si vous voulez travailler en tant que développeur de logiciels dans une startup, c'est une compétence à posséder.
Si vous voulez travailler dans une société de conseil, c'est une situation à éviter à tout prix. En effet, votre entreprise est rémunéré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, 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. De plus, ce n'est pas une chose universelle, certains projets nécessitent l'un ou l'autre type d'approche. Habituellement, si vous choisissez le mauvais sur l'un de ces projets, vous le découvrirez assez rapidement.
J'ai souvent constaté que dans certaines situations, je devais agir en tant qu'analyste commercial, découvrir exactement comment l'entreprise fonctionne actuellement, comment les gens pensez cela fonctionne (souvent des choses très différentes) et comment ils le feraient - comme ça marche.
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, j'écris de la documentation sur ce que j'ai découvert, je fais des graphiques et je les distribue à tout le monde, etc.
Vous ne ferez probablement pas une très bonne impression en refusant de faire un travail jusqu'à ce que les exigences complètes soient remises. Mais en rassemblant vous-même de bonnes exigences de qualité (sans nécessairement attirer l'attention sur le fait), vous atteindrez le même objectif de logiciel de qualité.
Et oui, comme d'autres commentateurs l'ont dit, construisez toujours le logiciel en supposant qu'il changera. Le changement est la seule constante sur laquelle vous pouvez compter. Créez toujours votre logiciel suffisamment flexible et modulaire pour qu'il ne soit pas pénible de le mettre à jour lorsque de nouvelles exigences apparaissent soudainement.
Un peu des deux. Vous devez satisfaire vos clients, ce qui signifie que vous devez savoir ce qu'ils veulent. D'un autre côté, les clients sont notoirement mal à communiquer ce qu'ils veulent vraiment.
Donc, vous voulez éviter les scénarios où vous ne savez pas ce que veulent les clients, mais vous rencontrerez inévitablement un scénario où les exigences sont au mieux "spongieuses" et, au pire, trompeuses. Un bon programmeur réel nécessite une adaptabilité.
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 à ce sujet, j'ai rencontré 2 types de personnes:
1) Les personnes qui ont besoin d'exigences formelles. Il faut leur dire exactement quoi faire et, au mieux, comment le faire. Ils aiment les phrases comme La procédure A prenant l'argument B produira C, et ils les détestent: Le programme devrait rendre le travail de notre département plus efficace. Ce sont généralement des animaux de compagnie.
2) Les gens qui sont opposés à 1. Ils détestent qu'on leur dise quoi faire et comment faire, ils aiment qu'on leur dise 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 des pigistes et ne correspondent pas bien à la société.
Je ne dirai pas lequel est le meilleur. Les deux ont leurs avantages et leurs inconvénients. Ils sont simplement adéquats pour les autres conditions.
Vous pouvez PAS développer un logiciel opérationnel sans connaître les exigences; mais, vous pouvez avoir une bonne idée de développer ce que votre expérience vous dit que les exigences sont susceptibles d'être. Le développement agile utilise une combinaison de techniques "intuitives", y compris 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 fait une meilleure estimation de ce qui est nécessaire et produit un prototype du logiciel. La règle des 80:20 dit qu'ils seront corrects à 80%. Les parties prenantes du projet examinent ensuite le prototype tangible. Leurs commentaires commencent à combler l'écart de 20% dans notre compréhension des exigences. Donc, en fait, Agile ne consiste pas à écrire un logiciel sans aucune exigence, il s'agit plutôt d'utiliser votre expérience antérieure pour dire: "voulez-vous quelque chose comme ça?" Ce qui, dans 80% des cas, vous permettra de prendre de l'avance et de confirmer ce qui est vraiment nécessaire plus rapidement que de parcourir les processus d'exigences traditionnels.