🤗 👩🏿 💏 Configuration logicielle requise pour Finger 📊 👩🏾‍🏫 👨‍👦

Un article sur les bases du développement des exigences - sans diagrammes, termes et tableaux complexes, mais avec des gifs.

En bref, les principales étapes de l'élaboration des exigences sont les suivantes:

Pourquoi devons-nous faire quelque chose? (Besoin de plus d'or)
Qu'est-ce qu'on fait? (tout est comme les gens, mais moins cher)
Comment faisons-nous cela? (avec blockchain et dataientists, bien sûr)
Quand ferons-nous cela? (hier, et refactoriser "plus tard")

Et maintenant plus en détail.

Si vous avez déjà demandé à faire quelque chose, cela signifie que vous avez créé des exigences. Ils peuvent prendre la forme d'un souhait oral, d'une lettre, d'une tâche technique, d'une tâche ou de toute autre chose.
Les exigences sont donc partout.

Si, après avoir répondu à la demande, quelque chose s'est mal passé - cela a gâché l'interprète
ou vous avez mal réglé la tâche.

Comme vous le savez, la mauvaise tâche peut être assez coûteuse. Par exemple, si pendant six mois, une équipe de 5 programmeurs a développé un système dont personne n'avait besoin.

En cette ère turbulente, les exigences de conception Agile sont souvent négligées. Mais les méthodologies flexibles ne vous épargnent pas toujours de grosses pertes. Par conséquent, même si vous n'avez pas d'analyste sur le projet, même si vous n'êtes pas du tout informatique, n'oubliez pas le bon sens et tirez des meilleures pratiques ce dont vous avez besoin pour le moment.

Quelles sont donc les exigences et pourquoi est-il important de pouvoir les développer?

Passons donc aux sources:

c'est-à-dire que vous pouvez parler d'exigences et de propriétés futures. Que diriez-vous d'un produit qui répond aux objectifs de développement?

Par où commencer à développer des exigences? Un indice est caché dans la définition: vous devez commencer par l'objectif - pourquoi devons-nous faire quoi que ce soit.

1. Pourquoi?

Comme "DÈS QUE POSSIBLE !!!!" il n'était pas nécessaire de faire quelque chose - il est important de trouver le temps et l'énergie pour savoir pourquoi cela est nécessaire.

Parce que souvent, après avoir clarifié l'objectif, la tâche change ou est complètement éliminée.

Par exemple, le

Client lui montrera rapidement toutes les commandes passées dans le système. Disons que nous avons tendu et poussé une tâche au milieu d'un sprint pour afficher toutes les commandes pour l'administrateur. Après cela, le client demande d'afficher dans une fenêtre séparée une liste de toutes les entreprises dont il voit les commandes. Ils l'ont fait aussi. Ensuite, le client demande de retirer en plus toutes les entreprises partenaires. D'accord ... Après un certain temps, nous rencontrons le client et voyons comment il télécharge les deux listes dans Excel, reconnaît la différence et commence à téléphoner aux entreprises qui n'ont pas de commandes pour leur rappeler de passer des commandes via notre système.

Si nous demandions au client dès le début quel objectif il souhaite atteindre en examinant toutes les commandes, nous gagnerions beaucoup de temps et d'efforts en signalant immédiatement aux entreprises qui n'ont pas passé de commandes jusqu'à présent.

Vous pouvez utiliser la méthode «Five Why» ou toute autre méthode. Mais généralement, les gens ne résistent pas: si vous vous intéressez à leur travail, une solution devient disponible.

Après avoir décidé d'un objectif, il est nécessaire de le définir clairement et d'établir des critères permettant de dire avec précision que l'objectif a été atteint.

Par exemple, le

processus de commande de matériaux est considéré comme automatisé si> 90% des entreprises partenaires passent des commandes via le système.

Cela facilite la compréhension des tâches et en même temps libère les mains dans le choix des moyens pour atteindre l'objectif.

Et oui, n'oubliez pas de coordonner cette beauté avec les clients. En général, n'oubliez pas de coordonner les exigences avec toutes les parties intéressées.

2. Quoi?

L'objectif est atteint de différentes manières. Et la deuxième étape importante dans l'élaboration des exigences consiste simplement à choisir le chemin - que ferons-nous exactement pour atteindre l'objectif.

, :

. . . // .

. — , .

. . .

Pour réfléchir à toutes les options, vous devez déterminer - que se passe-t-il maintenant? Comment le processus fonctionne sans votre système, comment fonctionnent les utilisateurs et les clients? Même s'il n'y a pas encore de processus, des informations détaillées sur l'état actuel sont très importantes. Nous allons donc comprendre quelle solution résoudra le problème, et non en créer un autre.

Chaque option de mise en œuvre a ses avantages et ses inconvénients, ses ressources nécessaires et son niveau de résultat. Après avoir modélisé toutes les options, avoir élaboré ou au moins avoir simplement parlé de ces informations avec les parties intéressées, vous serez en mesure de faire un choix équilibré et informé.

3. Comment?

Nous avons donc compris notre objectif et ce que nous ferons pour l'atteindre. Il reste à déterminer comment nous allons mettre en œuvre cela: quelles pages nous montrerons aux utilisateurs, sous quelle forme nous afficherons le rapport pour le client, comment nous recevrons les données d'un autre système, comment nous les stockerons, etc.

Cette étape est une question de technologie. Et si vous avez réussi les deux précédents, ce sera beaucoup plus facile.
Bien que la technique dépende du contexte, il est utile de parcourir la «liste de contrôle» des Wigers et autres personnes intelligentes. Si pour vous un certain type d'exigences n'est pas pertinent pour le moment - d'accord, nous ne le décrirons pas. Mais il est important de ne pas oublier et de se tester.

par exemple

Le questionnaire doit contenir un fichier avec une photo, car une photo est nécessaire lors du traitement des documents - c'est une exigence commerciale . Et peut-être une règle commerciale.
- , — . , .
, — , . , .
base64 . — .
, . : 10.

Pour chaque exigence métier, il existe en règle générale plusieurs exigences utilisateur. Un besoin utilisateur est décomposé en un certain nombre de besoins fonctionnels. Pour chaque exigence fonctionnelle, des exigences et limitations non fonctionnelles doivent être prises en compte.

En outre, les exigences et les restrictions non fonctionnelles peuvent découler directement des exigences des utilisateurs et des exigences et règles métier.
De cette façon, les arbres sont obtenus à partir d'exigences, au sommet de chacune desquelles est une exigence commerciale.

4. Quand?

Dans la «forêt» de vos besoins, il est probable qu'il y en ait qui s'excluent mutuellement et qui se répètent. Par conséquent, il est utile de documenter et de présenter toute cette beauté sous forme de tableaux et de diagrammes.

Il existe de nombreux outils ici: par exemple, BPMN pour décrire les processus métier et UML pour créer des schémas d'interactions entre services et composants.

Si vous parvenez à expliquer à tout le monde quoi et comment vous voulez faire avec le système, en utilisant une serviette et 3 taches de café, alors vous êtes John Wick de l'analyse et c'est incroyable.

Cependant, en règle générale, le niveau de détail «ponctuel» ne vous permet pas de voir les pièges et de réfléchir à tous les scénarios possibles. Après tout, tout semble clair, mais j'ai dessiné un petit diagramme - et ici vous avez un défi sans fin, une branche de processus oubliée et le chemin le plus court vers l'or.
Par conséquent, il est utile de savoir quels outils sont disponibles pour inverser le chaos.

Sous une forme schématique et structurée, les exigences doivent être hiérarchisées - en fonction de l'utilité (le client et les utilisateurs vous le diront) et la complexité (l'équipe de développement vous le dira).

Et puis, vous pouvez déjà vous disperser sur les sprints / étapes de développement et de mise en œuvre. Eh bien, répétez ces exercices à chaque itération. Et vous serez heureux - pas de modifications, un client satisfait, une équipe heureuse, un produit qui fonctionne et profite, les elfes jouent de la harpe sur un fond arc-en-ciel.

Bien sûr, il y aura toujours des problèmes. Il y aura des modifications, des délais brûlés et des bugs. Il ne sera pas toujours possible de passer par toutes les étapes et de faire des analyses normales, d'accord ou même de simplement parler avec le client, de documenter et de suivre les exigences. Mais dans toutes les situations, comprendre «comment ça devrait être» aide à améliorer le produit. Même si en ce moment vous faites «comment ça se passe» - vous êtes conscient que vous manquez et vous connaissez les risques. Et si vous connaissez les risques, vous pouvez les gérer.

Je recommande de lire davantage sur les exigences dans le livre de Wigers et Beatty: «Développement des exigences logicielles». Bien que le livre ne soit pas toujours simple, mais très utile. La plupart des autres documents sur le sujet sont un récit de ces vérités avec différents degrés de liberté.

Merci pour votre attention et votre bon design.

Configuration logicielle requise pour Finger

1. Pourquoi?

2. Quoi?

3. Comment?

4. Quand?

More articles: