Saucy Bird Structures: flux de développement

Si vous ne pouvez pas décrire la structure de votre organisation, département, travail en général sur vos doigts, cela signifie que vous le faites de manière inefficace.

Efficacité et transparence ne sont jamais la même chose. Vous pouvez faire en toute transparence des choses inefficaces et des choses effectivement opaques.

Construire une structure de travail est un processus complexe et individuel, avec une touche d'audace. Parce que nous avons besoin non seulement de courage et de réflexion («nous travaillons de manière inefficace, pourquoi?»), Mais aussi de la capacité de faire des tas gracieux.



Des tas gracieux sont la clé de la création de structures. Il semble que "nous n’ayons pas besoin, nous travaillons et bien, pourquoi avons-nous besoin de couches supplémentaires", mais en fait - une couche réfléchie élèvera votre travail à un nouveau niveau. C'est un tas, mais c'est élégant. Quelque chose comme l'injection de dépendance ou l'utilisation de Photoshop au lieu de la peinture.

Si maintenant vous pensiez «non, tout est efficace avec nous» - n'espérez même pas. Inefficacement. Même si vous n'êtes absolument, complètement, jamais coincé dans votre travail, alors vous vivez simplement dans des illusions. Ce n'est pas possible. L'efficacité est un putain de processus, pas une donnée. Et une personne spécifique doit fournir ce processus. Et d'autres - pour soutenir. Pas parce que "ils l'ont dit", mais parce que tout le monde ira bien - tout le monde travaillera comme il se sent à l'aise et efficace.

En bref, nous appelons notre idée originale de tas gracieux «l'oiseau impudent des structures» ou «flux de développement». Maintenant, nous allons le décrire, et nous mangerons également quelques-uns de vos chiens lors de conflits.

Pourquoi est-il nécessaire

Le flux de développement est conçu pour remplir 4 obligations:

• Structuration des processus
• Solutions aux problèmes
• Donne de la rétroaction
• Fournit un langage d'interaction universel

Development Flow est un outil de création de système .

Le système

Le système est composé d'éléments, les éléments sont différents et «actuels» les traversent - le processus de travail. En informatique, «parler» est le code, la conception, les documents et les autres choses avec lesquelles nous travaillons.

Les systèmes sont manquants

Si vous ne savez pas à quelle étape de votre flux privé vous vous trouvez actuellement (par exemple, «développer une fonctionnalité») et que vous ne savez pas à quelle étape vous vous trouvez dans le flux général (par exemple, la quatrième, après le Product Owner, Scrum Wizard et Designer), et qui la scène devrait vous suivre, quels sont ses critères de retour, et bien d'autres petites choses encore ...

Ou si vous le savez, mais pour votre travail, le chef de projet devrait s'asseoir à côté de vous et vous rappeler ce que vous devez faire exactement à cette seconde (ne vous arrachez pas au moniteur, puis aux programmes suivants) ...

Ou si vous vous sentez simplement inefficace ...

... alors vous n'avez probablement pas de système.

Le système ne fonctionne pas correctement

Pas tout l'or qui brille. Tous les V12 ne sont pas sous le capot. Et surtout - tous les moteurs ne fonctionnent pas correctement, même s'ils roulent (bonjour, l'industrie automobile bien-aimée).

Il est important d'avoir un système qui fonctionne correctement, car c'est notre confiance. Dans son travail, dans le travail de tout le système. Vous trouverez immédiatement des problèmes, dont la plupart peuvent être résolus.

Un moteur en marche a un son. Il est rythmé, agréable. S'il y a un problème, il est entendu par l'oreille sensible du maître. Grincement, éternuements, perturbation du rythme, cognement. Il détruit le moteur lentement ou rapidement, et la "machine commerciale" tombe en panne au moment où vous avez pris une hypothèque en dollars sur un billet de trois roubles à l'intérieur du ring.

Dans le système de travail des gens, ces bruits - violation des délais, mécontentement, fuite de personnel, ton bas des employés, jeter des problèmes au département suivant - et bien plus encore. Un bon gestionnaire se promène dans le bureau avec des localisateurs supersensibles évasés au lieu d'oreilles. Il connaît la tempête imminente, il sent que la pression a baissé. Il entend tous les petits soupirs et remarque ses yeux rétractés. Il est le système.

Flux de développement: système

Le système DF implique deux sections - Flux général (fonctionnement du système dans son ensemble) et Flux privé (fonctionnement de ses différentes parties).

Débit total

Le système se compose d'éléments combinés dans une structure pour atteindre l'objectif visé.
L'objectif en informatique est de sortir le produit au bon moment, avec la bonne qualité. Éléments du système - participants au processus: Product Owner, Project Manager, Scrum Master, Developer, Designer, Tester, Technical Writer ... Ce sont tous des éléments, et ils ne sont pas tous présents tout le temps. Parfois, les rôles sont combinés. Vous devez mettre en valeur vos éléments.

Vous devez mettre en valeur vos éléments. Notez-les et dessinez votre première flèche de flux. C'est ce qu'on appelle Common Flow.

Propriétaire → SM → Concepteur, développeur → Testeur → Rédacteur technique

La tâche consiste à combiner les éléments en une structure et à montrer quelles interactions professionnelles sont possibles. Non professionnel - que le concepteur et le propriétaire du produit vivent ensemble, n'est pas nécessaire. Ce ne sont que des rôles nécessaires. Le propriétaire ne doit pas interagir avec le concepteur ou le développeur. Seul Scrum master. Seulement. Scrum master.

Lorsque nous mettons en évidence les interactions, ces flèches, nous devons montrer ce que le premier donne, et que le second le renvoie en retour. Le système commence donc à vivre.

Propriétaire → donne une description de la tâche → SM

SM le reformulera à la fois pour le propriétaire et pour le reste. L'évaluation de la tâche - approximative - s'alignera. Mais la tâche de SM - à partir d'une simple description, en appliquant un tas gracieux, pour faire SUFFICIENT_DESCRIPTION. Il discutera et distribuera des parties de ceci AVANT avec l'équipe.

SM → donne des pièces À → Concepteur et développeur

DO inclut un schéma, tous ses états possibles et bien plus encore (je ne veux pas encore m'empiler). Chacun a sa part. Pas toujours en même temps. En règle générale, le concepteur est un sprint devant le développeur.

Concepteur et développeur lors d'un rassemblement quotidien alors que les commentaires de SM lui rendent sa vision de la tâche. Nous nous assurons que nous comprenons tout de la même manière. Cela prend 25-28 secondes. Et cela fait gagner des heures et des semaines.

Développeur → après son flux privé (plus à ce sujet plus tard), passe le code → au testeur

Le développeur donne le code, le testeur regarde sa partie du TO et remplit son flux. Le feedback du testeur est pour SM → «positif», c'est-à-dire comment il comprend la tâche, et pour le développeur → «négatif» - seulement s'il est cassé.

Le développeur n'a aucune idée que son code est testé jusqu'à ce qu'il y ait des problèmes.

Je pense que General Flow est correctement formulé comme suit. Le premier donne au second, le second traite, renvoie un Feedback «positif» ou «négatif», avance plus loin dans le flux général. La rétroaction positive est la conviction que tout fonctionne comme prévu; rétroaction négative - montre où et ce qui a mal tourné.

Flux privé

Dans cet article, je décrirai le flux privé du propriétaire, du CM et du développeur, à titre d'exemple. Si vous êtes intéressé, je posterai le reste du travail.

Le propriétaire

Objectif principal
Énoncé du problème (backlog ← description), lire les commentaires

Et ensuite
Lorsque les tâches sont formulées par le propriétaire, le SM les décrit → conduit à Sufficient_Description.

Commentaires de
Le SM réécrit la tâche et discute rapidement des étapes clés avec le propriétaire, y compris les délais.

Interagit avec
SM

SM

Objectif principal
Acceptez la tâche, mettez-la sous la forme d'Adequate_Description, évaluez les tâches, distribuez, lisez les commentaires

Et ensuite
Distribue les tâches aux employés

Commentaires de
Concepteur, développeur, testeur, rédacteur technique

Interagit avec
Propriétaire, designer, développeur, testeur, rédacteur technique

Développeur

Objectif principal
Développement de fonctionnalités et corrections de bugs. Dans General Flow, il reçoit des tâches de SM, et avec l'aide de son activité professionnelle, il les met en œuvre (git flow, rebase flow, feature flow, etc.).

Et ensuite
Il peut faire des suggestions de modifications, en discuter avec SM et le concepteur.

Commentaires de
CM, Designer, Testeur

Interagit avec
SM, par le concepteur, (il est important - il ne peut pas générer d'interaction avec le testeur)

(Dans cette description, je n'aime pas vraiment le schéma, c'est ma présentation avec une description différente, et je suis plus heureux de travailler avec. Mais j'explore des options, j'essaye, je perfectionne, et ça s'est avéré comme ça.)

Dans le résidu sec

Le flux de développement résout les problèmes suivants:

• Structuration des processus
• Résolution des problèmes
• Donne du feedback
• Fournit un langage universel dont nous n'avons pas encore dit un mot

Les principaux avantages - tout le monde sait ce qui se passe, ce qu'il faut faire et n'est pas chargé de travail inutile.

Les Scrum Masters ont beaucoup de travail (Timlid, CTO). Mais il devrait en être ainsi, il est le principal tracteur de cette approche.

présentation très courte et sèche

Restez dans le noir ou créez des structures audacieuses. Nous vous proposons notre oiseau, mais il est grand et ce n'est qu'une partie, en première approximation. Nous avons besoin de plus que tout autre cas. Par conséquent, je vous demande - accrochez tous les chiens sur moi, je veux aborder un meilleur sujet.

(J'ai dû couper beaucoup pour réduire au moins un peu la taille de l'article. À cause de cela, je pourrais manquer quelque chose, mais je vais rapidement le corriger, écrire.)