Habituellement, pour rallier des équipes, nous pratiquons des sorties sur le terrain: le reste du temps, ils travaillent à distance de leurs villes, ils se rassemblent dans une partie du monde. L'après-midi, ils parcourent une partie du sprint, le soir ils s'amusent ensemble. Mais les délais étaient serrés, alors nous sommes allés dans l'autre sens. Voici ce que nous avons proposé - et il semble que cette approche puisse être utilisée par n'importe quelle équipe dans laquelle il n'y a pas de gestion autoritaire.
Merci à Ray pour l'idée
Au printemps 2019, il n'a été question que du livre «Principes. Vie et travail »de Ray Dalio. Aleksey Kataev a également entendu parler d'elle - il est également "Team Lead Leonid" et notre chef d'équipe à l'époque.
Ray Dalio? Qu'est-ce?
1975- Bridgewater Associates. 2010- - . 100 .
, , , , .
, , , , .
Lyosha est venu à la facturation pour établir des processus. Il avait une vision claire de ce que devrait être l'équipe - et la capacité de persuader. Quand tout fonctionnait, il montait. Et avant de partir, il a proposé de former des contrats et de consolider le travail des processus déjà débogués dans l'équipe, en écrivant les «règles de vie» pour l'équipe de développement. Le nouveau chef d'équipe a soutenu l'idée - et cela a commencé.
Pour commencer, nous lisons ces principes mêmes de Dalio . Il y en a 16 au total, mais
- Acceptez la réalité et travaillez avec elle.
- , , .
- .
- , .
Pathétique, bien sûr. Mais nous avons décidé d'essayer de les adapter nous-mêmes. Lyosha a esquissé une liste de 10 principes, et l'équipe l'a complétée, portant le nombre total de résumés à 43. Nous avons ouvert un référentiel sur github: c'est symbolique que les règles de travail seront hébergées au même endroit que son résultat.
Et, pour être honnête, il est plus facile de maintenir et de développer toute l'entreprise de cette façon.
Puis ils ont commencé à raccourcir la liste et à améliorer la formulation, en évaluant chaque item selon trois critères: le caractère concret, l'accord avec le principe, l'importance. Discuté et affiné jusqu'à ce que la thèse convienne à tous les intéressés.
Nous nous sommes mis d'accord sur le rivage. C'était l'idée de Lyosha.
Dans le processus, il est devenu clair ce que nous regardons différemment, mais après plusieurs jours de discussion active, nous avons un candidat à la libération.
La demande de pool devait être approuvée par chaque membre de l'équipe.
Après le vote final, le chef d'équipe a publié la première version officielle des règles de vie de l'équipe.
Annoncez la liste complète, s'il vous plaît
Nous avons décomposé notre «constitution» en deux parties: 12 règles générales de vie et de comportement en équipe, plus 15 principes techniques. Le texte est assez long, nous allons donc cacher son volume principal sous les spoilers. L'orthographe et la ponctuation sont conservées dans l'original.
Principes de travail
1.1. Nous suivons des principes acceptés, que nous soyons d'accord ou non avec eux.
Un désaccord personnel n'est pas une raison pour s'écarter des principes. Cependant, vous pouvez commencer à discuter de n'importe quel principe si les circonstances changent et qu'il n'est plus utile.
11 points de plus
1.2
— . — . — . , . , .
1.3
- . , . . . , . . . . — .
1.4
: , , , . — . — .
1.5 ,
1.6
— . : , , , .
1.7
. , , . — .
1.8
— , — . , . , .
1.9
1.10 —
, , — , — . : , , , . , , . -, “ ”, “ ” “ ”. , .
1.11 , ,
. — , , , — .
1.12
. .
Principes techniques
2.1. Nous réfléchissons aux conséquences
Avant un déploiement ou une migration difficile, nous réfléchissons à ce que nous ferons si tout va mal. Nous réalisons des sauvegardes, des scripts de rollback, évaluons les risques de chute. Nous chassons les pensées «ah, ça va souffler, tout ira bien».
13 points de plus
2.2 ,
“ ” -.
2.3
, , , . , .
2.4
!= . .
2.5 , —
— , Skyeng. , , .
2.6 ,
, - , - . “ ” “, ”.
2.7
, :
— RabbitMQ: ,
— : ,
—
— SOLID, DI, IoC
2.8
— , . : . “ ” — . .
2.9 , QA
. — . — QA. “in development”, production : .
2.10
100% coverage , 100% coverage.
2.11
.
2.12
: , .
2.13
, . , .
2.14
, . , phpdoc, , README.
2.15 Nous ne réécrivons pas les projets à partir de zéro. Les
chances que ce soit une bonne idée sont minimes. Nous chassons l'idée d'écrire quelque chose à partir de zéro en jetant du code fonctionnel qui a été testé au fil des ans. Nous améliorons et refactorisons constamment, faisant du code de merde un code de rêve. Nous nous débarrassons des systèmes «doubles», mais ne les créons pas.
À propos, Lyosha a fait un rapport séparé sur le dernier point .
Ok, comment ça marche?
- : , , GitHub — , , .
- — . 360, : . - .
- — : , . (, ) , , . , ( ) « !». , , . , .
- , . : , , — « ». , .
Après un certain temps, l'équipe s'est virtualisée lors du rallye de Sotchi. Ensuite, nous avons imprimé les principes sur du papier comme du papyrus, les avons cousus et chacun a reçu une belle brochure qu'ils ont emportée chez eux.
Teamlead dit qu'il voulait obtenir nos autographes sur papier dans le sang. Il plaisante, je suppose.
Les principes peuvent être modifiés maintenant. Si quelqu'un a une bonne idée, n'aime pas quelque chose ou veut ajouter quelque chose, n'importe quel membre de l'équipe peut créer une demande et voter dessus: 100% «pour» et l'amendement a été apporté.
L'essentiel est de ne pas avoir peur de négocier et de discuter des problèmes.
Je me demande comment cela fonctionne avec vous.