🤽🏿 🚣🏼 🧑🏾‍🤝‍🧑🏽 Collection d'exigences pour un projet logiciel

Le développement ... c’est comme une drogue - ils écrivent un système, ils l’écrivent, parce que ça se précipite. Et puis, il s'avère soudainement que la «pension alimentaire» doit être payée. Et tout changement dans le système entraîne une montagne d'erreurs. Mais même au début du siècle dernier, le grand Kurt Gödel l'a prévu et a strictement prouvé que même en arithmétique nous n'avons pas assez d'intelligence pour exprimer toutes ses lois sans contradictions. Et dans la programmation et plus encore - nous allons commencer à marcher sur nos pieds et à nous embrouiller. En général, c'est ce qui se passe: soit l'ordinateur portable s'allume et redémarre la nuit, puis les applications mobiles font des erreurs afin qu'elles commencent à tomber de leur poche et à se disperser, à gronder et à grincer sur le sol.

Et comment aimez-vous les versions bêta à la mode de tout et de tout maintenant? Bientôt, les avions commenceront à apparaître dans les versions alpha-bêta, semble-t-il.

Mais vous pouvez programmer sans erreur pour que l'âme se réjouisse et qu'il soit non seulement agréable de boire de la bière avec le client, mais aussi en toute sécurité!

Dans cette série de publications sur divers aspects du développement de logiciels, je vais essayer de créer un ensemble minimaliste de valeurs et de règles qui, d'une part, sont placées dans la tête de la personne moyenne, et, d'autre part, elles permettent généralement ... de gagner avec le moins de temps et d'argent. Aujourd'hui, parlons franchement de la collecte des exigences pour un système logiciel.

Théâtre, théâtre partout. Mais l'industrie du développement de logiciels bénéficiera sans aucun doute si tous les participants au processus se disent la vérité, d'une part, à eux-mêmes, et, d'autre part, personne ne soutiendra les émotions non systématiques et le ministère à Cthulhu.

Vous n'avez pas besoin d'aller loin pour des exemples - les modèles de développement ouverts et leur succès (pas nécessairement à but non lucratif) montrent de manière convaincante:

clarté, ouverture, courage
discussion avec la communauté et le client
identification et résolution rapides des problèmes

ainsi que les communications les plus justes basées sur la confiance et le respect les uns des autres - conduisez une solution logicielle, par exemple un site Web, vers le succès.

Le monde change activement. Les communications horizontales se produisent à la vitesse de la lumière, et si nous n'apprenons pas à utiliser cette nouvelle arme, nous perdrons définitivement. Mais d'abord, regardez autour de vous.

D'où viennent les «guerres saintes» dans la programmation?

Tout est simple. Il suffit de rappeler le cours de géométrie de l'école. La compréhension scientifique du monde dans lequel nous vivons est basée sur ... la foi en "vérités immuables" = axiomes, par exemple, que "les lignes parallèles ne se coupent pas" ou dans le nombre de nombres premiers dans une plage (bien que ce soit un théorème, mais il le chien fonctionne, mais personne ne comprend pourquoi).

Il est impossible de prouver l'axiome, il ne reste plus qu'à croire qu'il fonctionne toujours. Mais nous ne pouvons pas voler vers l'horizon des événements de Black Hole et vérifier. Et expliquez également pourquoi l'interaction entre les photons est transmise beaucoup plus rapidement que la vitesse de la lumière.

De nombreuses théories scientifiques utilisent des axiomes pour la conclusion logique des théorèmes, et ainsi de suite et des livres épais avec une certaine période de garantie sont nés. En conséquence, et ce n'est plus drôle, le Grand Théorème de Fermat a été prouvé dans les années 90 de telle sorte que seule une poignée de ceux avec un excellent niveau d'éducation spéciale peut comprendre la preuve, capable de pelleter des dizaines de pages d'un texte fin avec des formules au microscope :-) C'est pourquoi ils continuent rechercher des preuves "réelles", simples et belles.

Même en apparence ce qui pourrait être plus simple, arithmétique, des tentatives ont été faites à plusieurs reprises pour mettre les axiomes en ordre - mais les choses sont toujours là ...

De même, les langages de programmation et les technologies sur lesquels nous créons des sites Web, des applications mobiles et des systèmes d'information, représentent en fait également un ensemble d'axiomes ou de points de référence, auxquels vous devez également d'abord "croire" et sur lesquels les fondements de la technologie sont construits, mais il est impossible de prouver qu'elles sont vraies (bien que parfois cela soit encore possible: essayez d'écrire un site Web en C ++ et voyez combien de temps et d'argent vous perdez).

Par exemple, dans le monde de Java / C # et d'autres langages d'autorité et de bonne réputation, modernes, strictement typés avec typage statique, il vous suffit de prendre et de «croire» que le monde est constitué de psychopathes, sujets à la violence et à la perte de l'auto-identification, et donc d'un «ensemble d'axiomes» fait tout pour protéger le développeur non seulement de ses collègues, mais aussi de lui-même (bien sûr, je plaisante).

Le résultat est des systèmes logiciels qui sont créés depuis longtemps, à partir de fer et de béton, qui sont ensuite recouverts de centaines d'autotests, et en conséquence, il peut s'avérer que lorsque la construction est terminée, les exigences commerciales sont dépassées depuis longtemps, les armes nucléaires sont interdites et un bunker avec des murs de 100 mètres ira immédiatement au musée. Mais souvent une telle perception du monde - fonctionne bien, par exemple, dans le développement de systèmes étroitement spécialisés ou lorsque le coût de l'erreur est très élevé (banques, etc.).

Dans le monde des langages dynamiques à typage strict / non strict (PHP, JavaScript, Python, Ruby), l'ensemble des axiomes est parfait, du mot «complètement», un autre:

nous sommes entourés de gens intelligents qui écrivent bien et bien tout de suite
manie de persécution (changer le type d'une variable sous la liste, l'accès à des membres de classe cachés par un autre développeur avec une intention «malveillante», une refactorisation profonde du code est nécessaire à l'avance, etc.) - une maladie que vous devez essayer de récupérer rapidement
le matériel devient moins cher, vous devez donc compiler le programme uniquement en morceaux puis, si nécessaire
plus il y a de code, plus il y a d'erreurs, donc le code doit immédiatement bien lire, être clair, concis et sexy

Dans le monde des langages fonctionnels, comme Haskell / OCaml, vous devez croire que:

n'importe quelle tâche peut être exprimée par fonction
variables, cycles et mutabilité - conduit à des erreurs (il en est ainsi)
programmation - pour les sélectifs et enclins à la pensée analytique

En conséquence, au lieu de simples scripts de béquilles "faits, vérifiés, décidés et oubliés", un vrai travail scientifique commence sur le lieu de travail et les recherches sur les "fonctions de Dieu" sont très intéressantes pour exprimer le site ... avec un ensemble de fonctions sans variables, wow!

Bien sûr, j'exagère, mais il n'y a pas de fumée sans feu. Bien que dans certaines tâches, cette approche fonctionne très bien, et personne n'a trouvé une meilleure approche.

«Croisades» dans la gestion de projets logiciels

Dans le domaine de la gestion de projet, la situation est encore plus recouverte d'une morosité pseudo-scientifique. Et la raison est bien connue: une solution évidente, allongée en surface, simple et concise au front:

comprendre ce que veut le client
attirer des spécialistes et évaluer la quantité de travail
écrire du code

en réalité, pour une raison quelconque, cela ne fonctionne pas :-)

Les participants expérimentés dans les équipes de projet sont bien conscients que le client souvent, ringard, ne sait pas ce qu'il veut, car il est submergé d'émotions et a copié des problèmes de mathématiques à l'école, ce qui a finalement conduit à une «atrophie partielle de la partie du cerveau» responsable de l'expression logique cohérente de son pensées. Ayant des opus poétiques, des dessins de rouge à lèvres et des notes d'accords de guitare, au lieu des exigences techniques du site, des spécialistes, pleurant pour ne pas rire de l'impuissance, augmentent les estimations de la quantité de travail d'un ordre de grandeur, introduisent une taxe pour insuffisance, etc.

Dans ces conditions d'absence de logique et de désir stricts, pardonnez-moi, en utilisant ma tête pour son usage prévu, comme si à pas de géant, il y avait de terribles abus non scientifiques dans le style de l'astrologie / numérologie / pranyozhenie et de la bonne aventure sur le marc de café.

Les abus sont généralement activement exploités par des personnes très confiantes, capables de bien convaincre, qui n'ont jamais tenu le «code» (oui, je parle du mauvais Agile).

Ils disent que dans certaines équipes avant le sprint, même les fans les plus ardents nous obligent les ingénieurs à, excusez-moi, la thérapie d'urine :-) Cependant, ces "pratiques" elles-mêmes sont souvent créées par des développeurs très expérimentés qui, comme aucun autre, peuvent les utiliser correctement.

Ici, j'aime vraiment l'analogie avec les nunchucks - cela semble être une arme simple, mais seuls quelques-uns peuvent l'utiliser correctement, et la plupart se blessent, désolé, vous savez ce que vous-même.

Un autre mythe est l'interchangeabilité

Parfois, ils essaient de nous convaincre de l' interchangeabilité des ingénieurs . Il est bien connu que pour acquérir une bonne et profonde compréhension de la technologie logicielle, vous devez relire de nombreux livres, écouter des dizaines de cours , résoudre plusieurs centaines de problèmes et participer à cinq projets logiciels, dont au moins un a atteint la ligne d'arrivée. Ensuite - l'expérience commence, ce qui après 5 ans, au moins, fait de l'encodeur - spécialiste.

Habituellement, travaillant constamment sur des projets, le développeur parle couramment un ou deux langages de programmation et les technologies connexes. Le succès et la croissance professionnelle d'un ingénieur réside précisément dans sa spécialisation étroite, car en plus des langues elles-mêmes, il est nécessaire de se plonger profondément dans les bibliothèques système, qui sont souvent très nombreuses et leur documentation est très étendue.

Le problème est que maintenant, pour une raison quelconque, il est à la mode de ne pas lire des livres - mais de les chercher sur Google et de les radier, sans compter le cerveau, tout en se masturbant mentalement dans les réseaux sociaux et les notifications de smartphones.

Trouver un vrai spécialiste qui apprend systématiquement de bas en haut, lentement mais sûrement, combler les lacunes de ses propres connaissances - devient de plus en plus difficile. Le marché, malheureusement, est rempli d '"autodidacte" avec ... "des mains gâtées".

Que faire? Valeurs de survie recommandées

Premièrement, il n'est pas nécessaire de désespérer et il est très important de ne pas se laisser aller aux émotions. Il est nécessaire de comprendre clairement que le développement est, tout d'abord, des mathématiques rigoureuses (généralement au niveau de l'école) et une logique avec des métriques, dans lesquelles, en utilisant terver et l'intuition, vous devez gérer les risques prioritaires et les patrons «mouillés» dans la petite enfance.

Nous avions l'habitude de jouer à des jeux en ligne avant et cela a bien fonctionné - alors allez-y, seulement au lieu des patrons, vous aurez des projets logiciels, et au lieu des bugs - zerg!

Il est toujours possible et nécessaire de gérer sobrement les risques et, par expérience, s'il est fait «systématiquement et scientifiquement», un projet logiciel décollera à temps, ou il sera rapidement clair pourquoi le missile ne démarre pas et quel / qui, spécifiquement, le problème.

Compte tenu de ce qui précède, il est recommandé de commencer à adhérer aux valeurs suivantes de l'approche étroitement scientifique et empirique, qui se croisent étroitement avec l'hymne bien connu du bon sens - " python Zen " et " manifeste agile ":

Recherchez la solution la plus simple et la plus claire
Plus c'est clair, plus c'est correct
Cela est devenu difficile - cela signifie quelque part un montant et vous devez continuer à chercher plus loin
Arrogance - de l'insécurité ou d'une enfance difficile
Les capacités du cerveau humain sont limitées, en particulier sous l'influence des hormones, et même à certaines périodes
De l'alcool et du tabagisme - nous nous émoussons intensément
Nous avons tendance à oublier rapidement même ce que nous connaissions bien et encore plus récemment
Viser une transparence et une ouverture maximales
Se respecter mutuellement
Encourager l'ascension et la discussion les plus rapides possibles des problèmes dans le cercle le plus large possible - idéal immédiatement dans tous
Tirer des conclusions et ne pas marcher sur le râteau 3,14 fois de suite :-)

Collection des exigences

Après avoir appris quelques secrets et caractéristiques des tendances du développement logiciel, nous allons continuer en toute confiance - nous apprendrons comment assembler correctement les exigences du système.

Le client est-il capable de penser en principe?

Rien de drôle - c'est toujours une situation régulière. Et le client dans ce contexte est un concept collectif. Tout d'abord, essayez d'évaluer le niveau de réflexion logique et la capacité de concentrer les représentants des clients. Avec qui allez-vous travailler et qui vous aidera? Options possibles:

Parti politique. Il faut faire, par exemple, un projet web à la date car quelqu'un veut / promet quelque chose ... Les exigences sont vagues, personne ne connaît les détails, et qui savait - va quitter depuis longtemps. Le projet a été scié par une équipe qui est partie et il était presque impossible de comprendre ce qu'ils ont vu. Sur les murs - cerveaux séchés, peut-être, du suicide d'un programmeur de premier plan. Le code est mauvais et fragile, il sent tellement qu'il fait mal aux yeux. Souvent dans une telle situation, ils essaient de trouver, excusez-moi, le "sacrifice sacré", qui peut être blâmé pour les six prochains mois et ... commencer à en chercher un nouveau. Sentiment de peur, déprimant et suppression de l'ouverture du processus avec un mélange de sang sur les lèvres. La probabilité de faire une solution logicielle à temps, bien que faible, est toujours là - si vous le faites à nouveau sur un cadre prêt à l'emploi avec une documentation prête à l'emploi. Habituellement, le seul moyen et aucun autre moyen.
Vous communiquez avec les représentants des clients et comprenez qu'il est sincèrement difficile pour les gens d'exprimer de manière cohérente / formelle leurs propres pensées, qui sont confuses après la troisième phrase, sont répétées et tournent en rond. Après 15 minutes de dialogue, les plaintes de maux de tête commencent. Le rire se fait entendre, l'ambiance de la fête, le selfie, la vie était réussie ... Mais les envies, en général, sont compréhensibles et sincères - il suffit de les aider un peu à se faire rigoureusement comprendre. La probabilité de décoller ici est généralement plus élevée qu'au paragraphe 1, mais encore une fois, l'utilisation de la solution la plus prête à l'emploi, avec une documentation prête à l'emploi et des scénarios typiques aide généralement.
Le client comprend bien ce qu'il veut et essaie d'exprimer de manière logique et cohérente ses propres pensées et désirs. En cela, il est aidé par un analyste qui n'est pas confus, exposant les pensées de la direction et les faisant passer pour les siennes. L'équipe cliente compte également au moins un expert dans son domaine (drôle, mais c'est encore assez rare). Dans ce cas, la probabilité d'aider et de résoudre le problème par programme est très élevée. Ici, vous pouvez vous impliquer dans la conception, la discussion conjointe du glossaire, les modèles d'objet, les modèles de données, les flux de données, les scénarios de test de charge. Très probablement, vous pouvez collecter les exigences dans un délai raisonnable.

Un autre point important ici est de construire des relations aussi confiantes que possible avec le client, de montrer votre ouverture et votre désir d'aider le client à exprimer clairement ses pensées. Souvent, une certaine forme de formation aide, au cours de laquelle les représentants des clients sont expliqués comment travailler avec les outils de collecte des exigences suivants:

Glossaire général
Un modèle de données logique dans lequel des relations de multiplicité strictes sont introduites entre les éléments du glossaire (un à un, un à plusieurs, plusieurs à plusieurs)
Rôles et chaînes d'utilisation qui montrent qui utilise le système et comment

Alarmes qui indiqueront des problèmes imminents dans la collecte des exigences:

les représentants des clients traduisent les «flèches» les uns sur les autres et ne peuvent pas relier les deux mots, il y a beaucoup d'émotions - il est recommandé d'intensifier le problème le plus rapidement possible et d'aller à un niveau supérieur - sinon vous, en tant que «sacrifice sacré», serez présenté comme un cadeau au culte du mess et retraite / congé de maternité. Travailler dans de telles conditions sur Agile est extrêmement dangereux, il vaut mieux écrire des exigences techniques strictes et se déplacer par petites étapes
les représentants des clients répondent de la façon suivante: oh, votre tête vous fait mal, mais vous êtes intelligent, un «programmeur», alors faites les choses correctement. Ici, vous devez demander de trouver un expert dans le domaine, qui est responsable des réponses au nom du client et dès que possible. Ou voir le paragraphe ci-dessus.
ils préfèrent ne pas parler de problèmes (code illisible, manque de documentation pour les principaux processus métier), car de l'argent a été dépensé, des postes reçus, des primes exprimées et parler des risques peut conduire à un nettoyage intensif du personnel (néanmoins tout le monde "comprend", et ici les ingénieurs roulent le baril) - il est difficile de donner des conseils, d'agir sur la météo réelle

Dans les cas cliniques ci-dessus, encore une fois, le développement d'une solution box / cloud prête à l'emploi avec une documentation prête à l'emploi aide beaucoup. Une telle approche réduira les risques de changements soudains du cours de 180 degrés par ordre de grandeur. Mais les garanties sont déjà moins.

Dans le cas d'une approche adéquate de la part du client, d'un désir de vous apprendre et de vous comprendre, d'un désir sincère de lancer un projet à temps et de se développer davantage, l'utilisation simultanée de plusieurs plateformes technologiques aide beaucoup. La conception n'est plus effrayante - vous sentez que le client partage à 100% la responsabilité de la collecte des exigences et vous pouvez essayer de bien le faire. Vous - assurez-vous les uns les autres et luttez ensemble avec la complexité:

Site Web PHP avec framework, solution en boîte
analyse prédictive en Python
une application mobile soit sur une seule plateforme qui fonctionne partout, soit nous écrivons pour chaque appareil

Ne perdez pas de temps!

Si pendant 2-3 semaines, dans les cas extrêmes, un mois et demi, le sentiment ne passe pas que vous participez à la pièce "discutez avec un look intelligent et prenez le temps et mettez tout sur quelqu'un", tirez la grue d'arrêt, mettez le feu au train et criez fort à crier: "rentrez chez vous, les enfants! la performance est terminée. "

Sérieusement, organisez une réunion avec la direction du client et insistez pour inclure des employés adéquats dans l'équipe de projet, qui comprennent en détail le fonctionnement de l'entreprise et sont en mesure de répondre aux questions strictes des ingénieurs. Ou arrêtez - c'est parfois la bonne étape: sauvez votre visage et grandissez en tant que spécialiste.

Liste de contrôle

Par conséquent, nous pouvons considérer le processus de collecte des exigences comme un succès et il est logique de continuer si, avec le client, vous avez pu préparer les artefacts suivants en quelques semaines:

Glossaire répertoriant les termes de domaine 50-150
Modèle de données logique avec relations de termes du glossaire
Cas d'utilisation avec termes du glossaire
Pour les algorithmes complexes - organigrammes ou diagrammes d'activités d'UML
Interfaces de système logiciel qui ne contredisent pas logiquement les éléments ci-dessus
Vous avez décidé d'un ensemble d'axiomes qui décrivent votre attitude envers le monde = choisissez la technologie logicielle. Ici, beaucoup, à cause de l'amour de la créativité, sont attirés par le sado-masochisme et le désir de réinventer la roue - combattre ce désir. Décidez: soit le monde entier est plein de sales tours et de psychopathes et fabriquez un bunker qui peut résister à une attaque d'OVNI, soit les développeurs veulent sincèrement vous aider. La meilleure technologie et un ensemble d'axiomes: un cadre développé ou une solution de boîte prête à l'emploi - les risques de ne pas décoller diminueront de plusieurs ordres de grandeur (dans l'expérience, 95% et plus les projets décollent)
Vous avez raté le système logiciel par le client, vous-même, par votre cerveau, et nulle part il n'y a de taches boueuses ou de boue émotionnelle. S'il y a de tels endroits potentiellement gâtés (et cela, en règle générale, se produit toujours) - incluez-les dans le plan de gestion des risques et exprimez-les à chaque réunion de projet. Et attendez-vous à ce que vous soyez encadré et n'oubliez pas de demander comment vous l'avez manqué

Si les artefacts ci-dessus pour la période spécifiée n'ont pas pu être collectés, et qu'il n'y a que des articles couvrant le cinquième point tels que le vague «rouge à lèvres» des savoirs traditionnels, les analystes ne vont pas coopérer les uns avec les autres, les experts dans le domaine ne sont pas attendus du côté client, les problèmes sont étouffés et l'atmosphère des vitrines règne et "Seule bonne nouvelle" - préparez vos affaires: très probablement, ils ne vous laisseront pas voler, l'exploration de la lune est reportée pour une durée indéterminée et vous entrez dans une représentation théâtrale "nous prendrons du temps un peu plus longtemps ne sera pas dispersé. "

Pour atteindre un véritable succès, il est très, très important d'aimer vraiment les systèmes logiciels, de se soumettre à la collecte des exigences et de la conception au maximum, de souhaiter un démarrage rapide des fusées, de boire de la bière avec un client, de se faire mutuellement confiance et de se répéter constamment les mots d' Edsger Dijkstra : «la simplicité est la clé fiabilité "!

Avec la venue de tous et vous souhaite sincèrement bonne chance dans la mise en œuvre de projets logiciels.

Collection d'exigences pour un projet logiciel - sans coupures