Programmeur, gestionnaire, MVC et critères d'acceptation

J'ai remarqué. que travailler avec n'importe quel client est très similaire à une application Web. L'article montre comment vous pouvez utiliser ces connaissances pour améliorer les processus.

À propos de qui est le contrôleur et qui est le modèle sous la coupe.

Cet article suppose que le lecteur sait ce qu'est MVC .

Lors de la construction d'un modèle, je passe à des simplifications délibérées.

1. Tous les participants à la relation sont des personnes responsables et souhaitent obtenir un seul résultat.
2. Considérez un développement personnalisé typique.

Acteurs

Client - une personne qui commande un produit ou un projet. Il peut être à la fois externe et interne.

Entreprise (entrepreneur) - partie à la relation contractuelle avec le client.

Manager - une personne qui interagit avec le client et l'exécuteur final (programmeur). Il accepte les tâches du client en entrée, traduit ces tâches au contractant et renvoie le résultat au client.

L'exécuteur ultime est un programmeur qui exécute la tâche. Idéalement, ne communique qu'avec le gestionnaire.

Le processus

Le processus de développement personnalisé ressemble à ceci:

1. Le client définit la tâche de l'entreprise.
2. L'entreprise, agissant en tant que routeur, confie la tâche au Manager.
3. Le gestionnaire clarifie les détails avec le client.
4. Le gestionnaire définit la tâche au programmeur.
5. Le programmeur exécute la tâche et transfère la tâche terminée.
6. Le gestionnaire identifie les lacunes et revient à l'étape 4.
7. S'il n'y a pas de lacunes, le gestionnaire transfère la tâche au client.
8. Le client identifie les défauts et revient au paragraphe 3.
9. S'il n'y a pas de défauts, le client paie le travail.

Le point le plus doux pour la Compagnie est le paragraphe 9. Mais le chemin qui y mène est généralement long et épineux.

Problème d'un tel processus

À première vue, tout dans ce processus est correct et il n'y a rien à améliorer. Mais ce n'est pas le cas. Nous mettons en évidence les problèmes.

Un très mauvais gestionnaire n'est qu'un routeur de tâches. J'espère que vous avez de la chance et que vous ne travaillez pas avec de tels gestionnaires routeurs. J'ai eu de la chance. Lorsque vous travaillez avec un vrai manager, il y a aussi des problèmes.

Le gestionnaire confie la tâche au programmeur en l'exprimant dans sa voix ou dans une salle de chat. Les clarifications sur le problème ne sont enregistrées nulle part. Le programmeur semblait comprendre l'énoncé du problème. Mais bien sûr, je l'ai compris à ma manière, et non pas comme l'explique le manager (du point de vue du manager). L'énoncé du problème n'étant pas figé, chacun des participants l'interprète à sa manière.

Avec cette approche, de nombreuses itérations 4-6 et 3-8 apparaissent. Un bon manager se distingue d'un mauvais manager par le rapport entre le nombre de ces itérations. Un bon gestionnaire a un nombre unitaire de tentatives de transfert d'une tâche à un client. Et la tentative, vous l'aurez deviné, a immédiatement réussi. En même temps, les itérations peuvent demander beaucoup de travail au programmeur. Le routeur ne vérifie rien pour le programmeur et transmet simplement la tâche au client. Et le nombre d'itérations 3-8 atteint ses valeurs maximales et est égal au nombre d'itérations 4-6. Et bien sûr, le programmeur est à blâmer pour tout, car du point de vue du manager, il a fait un mauvais travail.

Un grand nombre de communications entre le gestionnaire et le programmeur dans le processus de réussite de la tâche entraîne une augmentation du négatif entre eux. De plus, les délais de réalisation de la tâche, les dépassements de coûts, etc. sont perturbés. Dans le même temps, cela ne me dérange pas de communiquer lors de la spécification des exigences et au stade de la définition de la tâche.

Que faire pour éviter de tels phénomènes indésirables?

Les associations

Examinons un schéma simplifié de collaboration avec le client:

Un développeur expérimenté verra une correspondance complète avec MVC:

Il est très simple d'effectuer une comparaison d'entités.

• Client = Utilisateur
• Manager = Contrôleur
• Artiste = modèle
• Résultat de travail = Voir
• Société = demande complète

Juste une coïncidence? Je ne pense pas. Si les schémas d'interaction coïncident, vous pouvez essayer d'appliquer les approches que nous utilisons dans le développement au processus de gestion du développement personnalisé.

Premières étapes pour corriger

Quels outils avons-nous lorsque nous développons?

Nous définissons les couches d'application. Nous définissons les contrats d'interaction entre les couches et décomposons l'application en modules. Essayons d'appliquer ces outils ici.

Couches

Le programmeur dans son rôle habituel ne communique pas avec le client. Il peut être impliqué au stade de la spécification des exigences en tant qu'expert. Dans d'autres cas, seul le gestionnaire communique avec le client, isolant ainsi la couche modèle de l'impact direct du client.

Dans le processus de transmission de la tâche au client, le programmeur qui a effectué la tâche ne doit pas être impliqué. Jamais. Jamais du tout.

Décomposition

Les grandes tâches doivent être divisées en petites. Une petite tâche est une tâche pour un maximum de quelques jours.

TK

Tout le monde connaît l'expression: sans savoirs traditionnels clairs - le résultat de HZ.

Lors de la clarification des exigences, un artefact tel que les termes de référence doit apparaître avec le client. Ensuite, l'énoncé du problème au programmeur enrichi complété par TK. Pour l'instant, nous accepterons cela comme un contrat non seulement entre la Société et le Client, mais également entre le gestionnaire et le programmeur.

Dans toute entreprise normale, les savoirs traditionnels sont un élément indispensable à la tâche. Certes, cela ne s'applique qu'aux grandes tâches.

Il semblerait que les savoirs traditionnels soient assez similaires à un contrat dans le contexte de la programmation. Ce que je vois des problèmes avec les savoirs traditionnels:

1. Pour une tâche importante, il y aura TK de pages de 400 ou plus, que le programmeur ne rentrera pas entièrement dans sa tête. Je commence à m'endormir à la page dix.
2. Pour une tâche moyenne, il y aura un lien vers une section ou un paragraphe dans les TdR. Ensuite, le programmeur ne lira que cet élément. Ensuite, bien sûr, il s'avère qu'un petit point dans une autre section du mandat modifie radicalement l'ensemble de la mise en œuvre
3. Pour une petite tâche qui fait partie du support, les savoirs traditionnels ne le seront pas du tout.
4. Les savoirs traditionnels ne sont pas toujours clairement interprétés par les parties au processus de développement. Et tout ce qui peut être mal compris sera exactement faux et mal compris.

On peut voir ici que les savoirs traditionnels ne sont clairement pas suffisants. La question est quoi faire?

Critères d'acceptation

Dans la pratique du développement, les tests occupent une place de choix. Les tests ont prouvé leur besoin de développement de la qualité.

Pouvons-nous appliquer des tests dans notre pratique? Oui, et donc nous testons tout et même dans la description du processus, un lecteur attentif dira. Oui, mais non. Je parle un peu d'autres tests.

Le test dans le processus décrit ci-dessus consiste à vérifier manuellement la conformité du résultat avec les savoirs traditionnels livrés. Chaque participant à ces tests, s'étant familiarisé avec les savoirs traditionnels, les interprète d'une manière ou d'une autre dans sa propre image. Le problème est que tout le monde a une image différente. L'homme est un interprète imparfait. Vous devez compiler le TK dans le binaire une fois. N'interprétez pas plusieurs fois et de différentes manières. Et une fois sur le «papier». En conséquence, un certain ensemble d'artefacts devrait apparaître. Il peut s'agir de cas de test ou de critères d'acceptation.

Les critères d'acceptation doivent être développés par le manager en collaboration avec le client. Les critères d'acceptation ne contredisent pas les savoirs traditionnels, mais l'expliquent seulement. Les critères d'acceptation peuvent ou doivent même devenir un document distinct, signé par le Client et la Société. Ensuite, le client acceptera la tâche selon les mêmes critères d'acceptation.

Avec des critères d'acceptation correctement formulés, le programmeur ne peut avoir aucune divergence dans les TdR et même douter de ce qu'il doit faire exactement.

Pour une petite tâche, il peut ne pas y avoir de savoirs traditionnels, mais des critères d'acceptation doivent être présents. Les critères d'acceptation sont similaires aux tests écrits avant la mise en œuvre. Est-ce que cela vous rappelle quelque chose?

Pour décrire les critères d'acceptation, vous pouvez utiliser le langage Gherkin proposé par BDD . Afin de faciliter le démarrage, vous pouvez les décrire dans la langue russe habituelle.

Objections

Je prévois une question des managers:

L'élaboration des critères d'acceptation prend plus de temps. Où l'obtenir?

Sans prendre le temps d'élaborer des critères d'acceptation, vous répartissez ces coûts à toutes les étapes. Et beaucoup de gens passent du temps: manager, programmeur, testeur, client.

Mais vous développez toujours des critères d'acceptation. Et plus d'une fois. Lors de l'élaboration des TdR, certains critères d'acceptation se posent à la tête de l'analyste et du client. Lors de la définition du problème, la même chose se produit. Le programmeur les façonne dans sa tête. Au moment de la livraison de la tâche à n'importe quelle étape, le même processus est effectué. Mais à aucun moment aucun artefact n'est apparu. C’est toute la différence.

S'il existe des critères d'acceptation, le nombre d'itérations avant l'acceptation de la tâche par le client est considérablement réduit. Le nombre de communications négatives est naturellement réduit. En conséquence, les relations avec le Client sont améliorées, auxquelles la Société passe la tâche la première fois.

J'ose vous assurer que l'élaboration de critères d'acceptation porte ses fruits.

Résultat

Comment le processus change-t-il après l'introduction des critères d'acceptation avec les savoirs traditionnels?

Le programmeur fait son travail selon les critères d'acceptation. Le manager prend le boulot. Ensuite, le client fait de même. Et il n'a aucune raison de ne pas payer pour cette tâche.

Cela fonctionnera-t-il toujours sans aucun problème? Je suppose que non. Premièrement, il y aura des problèmes avec le développement, la formulation des critères d'acceptation et leur accord avec le client. Et cela provoquera des itérations répétées avec le programmeur et le client. Mais leur nombre est minimisé.

Qu'en pensez-vous?