Méthodologie en tant que constructeur: instructions d'assemblage

Un seul modèle de jouet peut être assemblé à partir du concepteur LEGO moderne, par exemple, un avion. Personnaliser? Vous pouvez échanger les sièges pilotes - c'est toute la personnalisation. Il y a environ 30 ans, le concepteur a pu assembler presque tout, de l'avion au camion, avec le même nombre de pièces que dans les modèles modernes. Les créateurs de la plupart des méthodologies modernes dans l'enfance ont joué le vieux Lego. Ceux qui utilisent maintenant des méthodologies ont déjà joué dans le moderne. La différence dans les pratiques d'ingénierie est énorme.



Sous la coupe, Philip Delgado ( dph ) parlera de l'approche d'ingénierie pour former une méthodologie. Tous les projets et équipes sont différents et les leaders sont uniques. Une méthodologie adaptée à tous ne fonctionnera pas - il n'y en a tout simplement pas. Nous devrons prendre un concepteur et en construire quelque chose d'unique. En déchiffrant l'un des meilleurs rapports TeamLead Conf , il n'y aura pas de secrets secrets des moines Shaolin - seulement des banalités vérifiées par l'expérience. Nous attendons un catalogue des détails de la méthodologie de développement, ce qu'il faut rechercher lors de sa conception et de sa mise en œuvre, et les règles de reconstruction des méthodologies. Pour toutes les idées, de vrais exemples sont donnés de l'expérience de Philippe. Au cours de sa carrière, il a tout essayé, de Visual Basic au SQL hardcore, développé le plus grand moteur de bookmaker en Russie et Yandex.Money, et travaille maintenant sur des projets Java chargés. Elle donne régulièrement des présentations lors de diverses conférences, dont HighLoad ++.

Défi

Il y a quelques années, je suis à nouveau venu sur un projet de création d'un système de paiement à partir de zéro. Au tout début du projet, il n'y avait rien: pas de développeurs, pas de processus, pas de productions. Où commencer à travailler s'il n'y a rien? Introduire immédiatement quelque chose est étrange et même stupide. Par conséquent, la première étape consiste à comprendre ce qui est réellement nécessaire de la technique.

Kent Beck, à la fin de son livre sur SCRUM, a écrit:

Toutes les méthodes sont basées sur la peur. Vous essayez de développer vos habitudes qui vous aideront à éviter que vos peurs ne deviennent réalité.

Par conséquent, la première chose à faire est de découvrir auprès de l'entreprise ce dont elle a peur .

En règle générale, l'entreprise a peur pour l'ensemble du projet: effrayant de faire trop longtemps ou de ne pas faire du tout . Technologiquement, il a peur de la fiabilité et de la sécurité . Dans notre cas, ces craintes sont justifiées: le système de paiement est constitué de contreparties, d'argent et d'obligations graves.

Des craintes différentes conduisent à des méthodologies différentes. La peur de payer trop cher conduit à embaucher des développeurs bon marché qui sont faciles à changer - c'est SCRUM. La peur de l'erreur conduit à des GOST ou des RUP avec un tas de documents formalisés.

Les développeurs ont également leurs propres peurs: écrire sans support ou mal faire . Malheureusement, presque personne ne développe des méthodologies sous la crainte des développeurs. Seul XP mentionne brièvement que les développeurs ont peur de mal faire, essayons de les aider à bien faire leur travail.

En plus des craintes, l'entreprise souhaite à quelles fins optimiser les processus:

• rapide
• bon marché;
• prévisible;
• d'une manière contrôlée;
• qualitativement;
• évolutif
• HYIPOVO.

Choisissez n'importe quelle option, et peut-être, un jour, probablement, si rien ne se passe et que Mars converge avec la Lune en Capricorne, vous réussirez. La plupart des souhaits d'optimisation portent également sur la peur, mais dans un libellé différent: bon marché - sur la peur de payer trop cher, contrôlé - sur la peur, ne le faites pas, de manière prévisible - sur la peur, il n'y a pas de temps.

Habituellement, une entreprise veut tout à la fois . Lors de la collecte des exigences, respectez la présupposition «le patient ment toujours». Quand une entreprise veut tout, il ment. Essayez de comprendre ce que l'entreprise veut vraiment et essayez de le lui vendre. Ce n'est pas l'ensemble de compétences le plus standard pour un chef d'équipe. Mais si vous ne savez pas comment connaître les besoins réels d'une entreprise, vous devez trouver une personne qui le peut.

En plus des souhaits de l'entreprise, vous devez connaître les limites importantes.

• Délais serrés . Dans mon cas, il n'y avait pas de date limite, par exemple, les Jeux olympiques, quand il n'y a que deux options: être à l'heure ou non.
• Contrat strict . Si vous travaillez avec une entreprise publique, le contrat ne doit pas être violé. Tout le reste peut être fait comme vous le souhaitez. Cela affecte grandement la technique.
• Envoi régulier . Vous devez constamment déployer de nouvelles fonctionnalités, ce qui est important pour les entreprises.
• Certification: CB, PCI DSS . Il s'agit de la principale limitation de la conception du système de paiement. Les principaux risques et préoccupations sont liés à la certification des titres, PCI DSS et autres.

Ce sont les limitations essentielles qui distinguent, par exemple, les processus FixPrice des processus Time & Material.

Dans notre projet de système de paiement, il s'est avéré qu'il était effrayant de faire trop longtemps et de ne pas avoir peur, effrayant pour la fiabilité et la sécurité, mais il est conseillé de tout faire rapidement. En même temps, il n'y a pas de productions au début du travail, il n'y a pas de développeurs, mais il y a des spécialistes dans le domaine (par exemple, moi). Seuls les blocs importants et assez indépendants les uns des autres sont clairs: traitement, clients, intégrations, back office et front office.

Après avoir déterminé les objectifs et les limites, vous pouvez commencer à construire une méthodologie, pour comprendre exactement comment nous développerons le système souhaité - au moins à la toute première étape.

Nous construisons une méthodologie pour démarrer un projet

Mais qu'est-ce qu'une technique? Que voulons-nous construire en général? La réponse aux questions est une belle image d' Alistair Cowber avec un tas de points.



Trois choses sont importantes pour nous à partir de cette image en premier lieu: les gens - ceux qui le font; processus - comment ils fonctionnent; et artefacts - ce qui doit être fait. Nous n'avons pas encore de personnes et de processus, nous allons donc déterminer de quels artefacts nous avons besoin.

Commencer avec des artefacts est un bon modèle lors de la conception d'une technique , même si des personnes et des processus existent déjà. Il est conseillé de commencer la conception des artefacts «à partir de la fin», avec la valeur livrée, à partir des artefacts qui seront présentés lors de la vente ou envoyés au client. Pourquoi est-il préférable de cette façon - une question distincte pour un article séparé. Si vous connaissez la réponse - écrivez dans les commentaires.

Choisir des artefacts

Nous prenons des peurs et comprenons quels artefacts que les peurs ferment.

La peur de «travailler trop longtemps sur un projet» est sauvée par un plan à long terme et un fait marquant . De la peur de la fiabilité - autotests . Par crainte de «ne pas faire» - relevez la position «presque au combat». Nous lui démontrerons les progrès de l'entreprise . Vous pouvez donc immédiatement voir ce qui est et ce qui fonctionne, et dans un pincement, nous publierons au moins un certain résultat.

Nous formons des processus

Nous sommes au début du développement, il n'y a donc pas de temps et de raison pour créer des processus formalisés complexes. Nous simplifions donc tous les processus et nous nous concentrons sur la facilitation de la communication .

En conséquence, il existe exactement deux processus: déterminer une tâche importante - réfléchir à une solution et vérifier ce qui a été accompli . Ces processus sont longs, de recherche et peu liés les uns aux autres, ce qui conduit à des pratiques de développement appropriées.

Pour faire vite - nous embauchons des employés sympas . Mais les spécialistes sympas n'utilisent pas un système de paiement inconnu de quiconque sur le marché. D'une manière ou d'une autre, cela a fonctionné, mais la solution à ce problème est une discussion distincte. Au fait, écrivez dans les commentaires comment vous l'avez résolu à la maison et avez-vous décidé du tout?

---

Retraite: sur l'embauche

Lors de l'embauche, ils regardent généralement les descriptions de travail standard et les gradations habituelles des niveaux de candidats, en dessinant une telle carte des rôles dans l'équipe:



Mais les descriptions standard ne nous permettent pas de comprendre le besoin d'une personne spécifique sur un projet. J'essaie généralement de garder plusieurs cartes différentes dans ma tête pour différents projets, en mettant en évidence les différents rôles et compétences qui sont importants pour le projet. Par exemple, technologique .

Dépanneur . Il s'agit d'une personne qui peut plonger dans un code hérité avec une sorte de bogue sans documentation et tests pendant 2 jours, et émerger avec la phrase: "Dans cette ligne, remplacez + par - et cela fonctionnera."

Et ça marchera. Les gens comme le trèfle à quatre feuilles sont rares. Malheureusement, le marché ne valorise pas ces personnes, il est difficile d'expliquer à l'entreprise qu'un dépanneur est indispensable et mérite le respect et un gros salaire. En conséquence, la plupart d'entre eux vont aux chefs d'équipe et cette ressource est épuisée. Il ne reste plus qu'à promouvoir l'utilité de tels spécialistes, et peut-être qu'après un certain temps la situation va changer.

Intégrateur Il s'agit d'une personne qui sait créer quelque chose d'intégral à partir de plusieurs composants, bibliothèques et modules différents. Il n'est plus programmeur XML, mais celui qui comprend la structure interne. Il s'agit d'une compétence extrêmement rare, qui est généralement très demandée dans le développement réel.

Guru: Framework, sécurité, base de données, DevOps . Tout est clair sur le gourou - ce sont des gens qui peuvent être contactés pour des questions sur des sujets pertinents.

De plus, il existe également des rôles «non technologiques», une carte sociale des rôles. Un générateur d'idées est une personne qui peut proposer quelque chose. Critique - qui peut critiquer de manière constructive. Expérimenté - une personne expérimentée qui peut dire: "Nous avons essayé et cela s'est avéré absurde." Un perfectionniste est une personne qui veut que tout soit bon. C'est un rôle important. S'il n'est pas là, généralement tout tombe rapidement en décadence, car il n'y a personne qui vous dit: "Vous l'avez à nouveau, tout va mal - réparons-le!"

Si un rôle dans la carte des rôles de votre projet spécifique n'est pas rempli, l'équipe devra le remplir.

Par conséquent, pensez à qui prendre et gardez à l'esprit que les différents entretiens conviennent à différents rôles et positions . Avec un senior chevronné, l'entretien sera rapide - découvrez ce qu'il faisait. Vous devez généralement parler longtemps avec un junior, effectuer des tâches de test et découvrir ce qu'il peut faire.

Plus le niveau du candidat est élevé, plus l’entretien est court.

De quelles autres personnes avez-vous besoin?

Un extraverti est celui qui veut et peut communiquer activement en dehors du développement. Nous n'avons pas de productions exactes, nous avons donc besoin de quelques personnes capables de comprendre les utilisateurs finaux, y compris les utilisateurs internes, par exemple, nos comptables. Un extraverti n'a pas peur d'aller parler, de découvrir les besoins de ces "non-programmeurs" inhabituels - et il y en a peu.

Critique - J'ai d'abord besoin d'un critique de moi. C'est la personne qui critiquera mes décisions. Sans critique, j'ai peur de porter des bêtises. Quand ils me critiquent, je dois réfléchir sérieusement aux arguments, et il s'avère que ce n'est pas tout à fait absurde.

Spécialiste des problèmes monotones : rapports, intégrations. Je savais avec certitude que nous aurons un grand nombre de rapports dans le projet. Six mois pour rédiger des rapports comptables et ne pas devenir fou - une compétence rare. Diffuser cette fonction entre différentes personnes est également gênant, j'avais donc besoin d'un spécialiste des problèmes monotones.

Ne vous en souciez pas . C'est une personne qui ne se soucie pas des tâches à faire, ne serait-ce que pour payer. Ce rôle est extrêmement important pour le projet, car il y avait différentes tâches: monotones, mais complexes, incroyablement intéressantes ou pas du tout liées à notre expérience précédente en raison de l'exigence externe rampante.

Revenons à notre projet. Nous n'avons pas besoin de l'outil de dépannage, car l'héritage n'est pas encore là. Nous avions besoin d'un intégrateur et d'un ensemble de gourous. Le gourou de la sécurité est en fait cultivé à l'intérieur.

Database Guru a été externalisé avec succès. J'aime vraiment l'idée de "prendre des compétences dans la base de données quelque part à l'extérieur" - trouver une telle personne dans le personnel est généralement irréaliste si vous n'avez pas une grande entreprise, et au moins 5 personnes sont nécessaires pour prendre en charge une importante base de données 24 * 7. Nous avons également externalisé DevOps Guru, mais avec moins de succès, ce rôle est plus difficile pour les artistes externes.

Les rôles sociaux étaient également remplis (et il y avait même quelques critiques).

---

Pratique

Nous avons donc trouvé les artefacts nécessaires, découvert ce dont les gens ont besoin et quelles exigences de processus. Que s'est-il passé, comment exactement nous organisons le développement:

• Nous prévoyons de grands coups. Nous n'avons aucune production, il est donc impossible de planifier plus précisément. Il faut créer un compte personnel en trois mois - et c'est tout. Nous réalisons des plans à Confluence.
• Chacun est un peu un analyste . Il n'y a pas de productions normales et la compétence dans le domaine est détenue par des personnes qui ne savent pas écrire des productions. Personne ne leur a enseigné, vous devez leur retirer ces informations. Mais nous avons des «extravertis».
• Un tracker n'est pas nécessaire . Nous n'avons que 20 tâches principales pour le projet - pourquoi démarrer un tracker.
• Une branche dans VCS. Au stade initial, un travail complexe avec contrôle de version n'est pas nécessaire.
• Les processus sont approximatifs . Il y a encore peu de monde, il n'y a pas de communication et de problèmes, et le projet lui-même est instable. Pas besoin de décrire quoi que ce soit en détail.

Lorsque les gens parlent de méthodes similaires, pas trop formalisées, ils disent souvent simplement: « Nous avons une méthode agile».

Nous avons également obtenu le classique «We have Agile». Mais j'ai clairement compris pourquoi une telle technique et pourquoi elle était «agile», et non quelque chose de plus spécifique et complexe. Et moi (et les affaires), cette technique était tout à fait adaptée.

Un lecteur attentif remarquera que lors de la conception de la méthodologie, nous avons oublié deux craintes importantes: la peur de la sécurité et le besoin de certification . Essayons de comprendre comment y faire face.

---

Digression: matrice de Cowburn

En 1980, Alistair Cowbern a dessiné une matrice de la complexité du projet .


Vertical - la criticité du projet . Ce qui peut être perdu en cas d'erreurs importantes: de la perte de confort de l'utilisateur à la perte de vie de l'utilisateur, par exemple, si nous concevons des logiciels pour les centrales nucléaires. Horizontal - la taille de l'équipe . La taille affecte le nombre de communications. La critique porte sur le détail de ces communications. Au total, cela affecte la complexité du processus.

Alistair fait valoir que se déplacer vers la droite ou vers le haut dans chaque carré complique considérablement et augmente le coût du développement. C'est logique - plus de gens ont besoin de plus de coûts de communication. Si des relations plus formelles sont nécessaires, alors plus de coûts de communication sont nécessaires. C'est-à-dire plus loin, plus les ressources sont dépensées pour des tâches et des pertes improductives.
Soit dit en passant, comme troisième axe, Alistair dessine l'optimisation pour différents souhaits commerciaux.

Essayons de placer notre système de paiement sur cette matrice. La matrice est très pratique comme modèle pour comprendre la complexité estimée de votre projet, de votre système.

Nous avons un système de paiement, ce qui signifie qu'à la rigueur, nous perdrons de l'argent de l'utilisateur. Ceci, bien sûr, est désagréable, mais ne conduit pas à une forte augmentation de la complexité.

Mais nous avons presque une banque, et dans certains cas, en cas de violation des normes ou des exigences de la Banque centrale, une licence peut être retirée de la banque. C'est déjà une perte de beaucoup d'argent, presque la fermeture d'une entreprise, très triste.


Nous avons une équipe d'une vingtaine de personnes, nous entrons donc sur la place E30 . C'est mauvais, car un bon exemple de la technique dans ce carré sera le processus unifié Rational à part entière - processus formels, nombreux documents, déclarations claires. 20 à 30 personnes ne peuvent pas y faire face. Vous devez en embaucher 50 et la difficulté augmentera comme une boule de neige. Des systèmes similaires dans de telles méthodologies sont généralement écrits par des centaines ou plus de personnes.

Que faire Des ennuis? Non, tout le projet n'est pas tout aussi critique . Nous n'avons que quelques pièces critiques.

• Chèque de blanchiment d'argent - pour lequel la Banque centrale a frappé durement la tête.
• Travailler avec des cartes bancaires - pour lesquelles les systèmes de paiement mondiaux se sont fait mal à la tête.
• Stockage de données personnelles - pour cela, l'État a frappé durement la tête.

Soulignons les modules critiques individuels . Nous rédigerons pour eux des pratiques spéciales pour travailler avec ces parties de notre projet: un audit PCI DSS complet pour chaque validation , une bonne documentation, une double revue de code, un processus de calcul spécial et bien plus encore. Seuls les développeurs seniors peuvent écrire ces parties du projet.

Mais ces pièces sont peu nombreuses. Par conséquent, la matrice Cowbern pour le projet est la suivante.


Pour différentes parties du projet, il y aura une complexité différente de la méthodologie, un ensemble différent de pratiques. Le plus difficile et le plus terrible est trois personnes . Logique de paiement - personne 8. Toutes les autres tâches moins importantes, qui sont avant tout, comme un système d'aide ou la mise en page d'un site pour le back-office, dans lesquelles l'erreur n'est pas fondamentale, sont surtout gérées par des personnes. Mais ces processus peuvent être les plus simples et les plus informels.

Un grand projet complexe peut utiliser différents ensembles de pratiques pour ses différentes composantes.

C'est l'un des grands avantages de l'architecture de microservices - la possibilité de prescrire une image dans laquelle différents services répondent non pas tant à des techniques différentes, mais à des pratiques différentes au sein d'une même technique. Dans le même temps, des choses importantes restent communes: la planification, les artefacts, une approche commune de l'interaction.

---

Pour résumer

Nous avons découvert les exigences de la méthodologie : objectifs et limites. Identifié les éléments de base : processus, artefacts et personnes. Ils ont décrit les pratiques : comment mettre en œuvre des processus, les exigences pour les artefacts, le type de personnes nécessaires.

Il s'agit d'un schéma de conception technique classique: nous avons des exigences, puis nous avons spécifié l'architecture, puis l'avons programmée.

La conception de méthodes est une pratique d'ingénierie, un processus d'ingénierie qui n'est pas différent de la programmation d'un module.

Pratiques de la première étape

Un peu de pratique pour détourner de la théorie la réalité.

Droit à "Pourquoi?"

Ceci est ma pratique préférée.

Chaque employé a le droit de poser des questions sur n'importe quelle tâche: pourquoi le faire, pourquoi le faire de cette façon et qui en a besoin?

Les gens ont peur de demander «pourquoi» - peut-être parce que dans l'enfance, ils n'ont toujours pas répondu à ces questions. Si vous avez explicitement écrit et répété «peut et devrait» plusieurs fois, les gens le font. Dès que vous commencez à vous demander «pourquoi» à tous les niveaux, y compris les affaires, le volume des tâches diminue plusieurs fois et la motivation augmente également. Les gens comprennent le sens du travail et le font plus rapidement et plus économiquement, en coupant les coins.

Ne pas généraliser à trois

Ne créez pas de solution unique tant qu'il n'y a pas trois exemples différents . Si vous concevez trois avions différents, vous ne pouvez pas écrire la classe correcte qu'elle représente sur l'un d'eux à la fois.


Cette solution est également pour le développement - ne construisez pas d'intégration universelle avec les entrepreneurs, jusqu'à ce qu'il y ait trois intégrations différentes et qu'il n'y ait pas de compréhension où elles sont différentes. Mais lors de la conception d'une technique, ne dessinez pas immédiatement une description formelle de l'artefact - un diagramme ou un modèle - avant d'essayer trois approches différentes et de découvrir ce qui est commun en elles. Il s'agit d'une pratique simple mais utile qui vous permet de ne pas créer d'abstractions redondantes à l'improviste.

Développement piloté par IDE

JetBrains — ! , IDE.

, IDE.

. , IDE , . IDE — . IDE — : , , , . : , , .

, , IDE call stack . .

IDE — .

, , . . : « ?» , . , - . , .


3–4 . .

, . , . , , , .

. — , , .

- , . .

— .

: « , , , ».

— , , . . — , , , .

. , - . .

, — , . : , ,

, : . . .

• . , , .
• . , , , , - .
• . 3 -, , , , . , .
• . , . , - — .

, SCRUM , SCRUM . , , , .

. 20 . SCRUM , , , - . .

.


- — , 3 .

- .

- : PCI DSS , ( ., ), - .


. « , », . , 1 — , - . , . shit happens , — , . , , , , .

, , , — , , .

— . . . - , , — .

— . , «» , - bus factor — , .

. , , .

. , . , , . , , , . Style guides code review , - , .

, - . ?

Planning poker . « » — . , , . Planning poker , .

. :

• ;
• product owner ;
• ;
• .

, , , — ? , 2 10% . ?

, Planning poker — , , ? , — . . planning poker , , .

: , , . Agile — , . , .

, Agile, SCRUM XP .

, , , , , , . , - , — ? ?

. : , , , . , ?

, Planning poker , , Planning poker :

— , , !

Planning poker . . .

:

• ;
• ;
• .

.

: , , .

Jira , « » ? - -? ?


Pour que tout le non-sens ne soit pas surveillé par un chef d'équipe qui a du temps cher, embauchez un secrétaire de projet . En fait, il s'agit d'un chef de produit junior - une personne qui ne coûte pas beaucoup d'argent, mais qui peut assumer la plupart du contrôle de la qualité des artefacts bureaucratiques , ou même de leur création.

Parfois, une entreprise demande à savoir quand les programmeurs vont et viennent - laissez le secrétaire garder un œil sur cela. Cela vous fera économiser beaucoup d'argent et d'efforts de développement. Ils aiment être pris en charge. Si le secrétaire leur sert un martini - ça va!


Vérifiez avant le code. J'entends régulièrement comment une personne s'est vu confier la responsabilité d'un gros reportage, mais elle a mal fait et doit être refaite. Passons en revue le code avant de l'écrire . Avant d'écrire du code, un employé de Jira décrit un plan pour résoudre un problème en deux lignes ou deux paragraphes de texte. La révision de ces deux paragraphes est rapide et facile, mais des erreurs globales sont détectées dès le début, surtout si vous avez un chef d'équipe ou un architecte.

De plus, cette pratique permet au chef d'équipe ou à l'architecte d'être au courant de tous les changements d'un grand projet. Il ne lit pas un code tordu, mais deux paragraphes sur ce qui se passe généralement dans le système, et attrape rapidement les gens par la main. Cela est particulièrement vrai pour les parties critiques d'un produit, telles que la logique de paiement.

Comment changer la méthodologie et ne pas tuer le projet

Ainsi, en 9 mois, nous avons changé 3 méthodes: «We have Agile», SCRUM d'un jour et Kanban. Comment vous assurer de ne pas perdre de ressources? Comment changer la méthodologie du tout et ne pas tuer le projet en même temps?

Nous avons réussi à changer les méthodes afin que certains développeurs ne remarquent pas du tout les changements. Personne ne leur en a parlé, ils travaillent et la méthodologie est différente!

L'essentiel est de comprendre quand changer.

Si vous comprenez pourquoi. Souvent, les méthodes changent, car un nouveau directeur technique est venu qui veut tout refaire. C'est une mauvaise raison. Mieux vaut prendre l'ancien et le renommer - tout, la technique est différente, c'est mieux. Si vous ne pouvez pas répondre à la question pourquoi, il vaut mieux ne pas changer. J'aime généralement demander pourquoi.

Si vous pensiez "comment". Si vous comprenez comment vous allez passer du point A au point B, changez. Jusqu'à ce que vous trouviez - pas besoin.

Si satisfait "combien". Changer une technique est presque toujours une procédure coûteuse . Si vous réussissez bien, le remplacement coûtera plusieurs mois-homme des coûts des chefs d'équipe, des RH, des personnalisateurs Jira. Si c'est mauvais, quelques mois de travail de toute l'entreprise. J'ai souvent vu la transition de Kanban à SCRUM, puis de retour, chacun ayant coûté un mois de travail tout au long du développement. Si vous n'êtes pas prêt pour de tels coûts - ne commencez pas.

La préparation

Nous commençons à l'avance. Pour une petite équipe, la préparation commence un mois avant le quart de travail.

Nous dessinons des histoires d'utilisateurs. La même approche que dans la conception d'applications. Vous utilisez les User Stories pour décrire les exigences, j'espère?

Par exemple:

• User Story : en tant que développeur, je souhaite trouver ma prochaine tâche et procéder à sa mise en œuvre.
• Critères d'acceptation : en tant que développeur, je peux voir toutes mes tâches actuelles et évaluer l'urgence et la priorité des tâches.
• Exceptions: s'il n'y a pas de tâches, le développeur sait à qui demander.
• Liens: scénarios de préparation d'un plan à court terme, qui montre où obtenir la prochaine tâche.

De cette façon, passez en revue toutes vos activités principales qui découlent de votre méthodologie et écrivez des histoires d'utilisateurs.

Comment le gestionnaire peut-il voir l'efficacité du plan? Comment un cadre supérieur comprend-il que tout va bien? Écrivez des histoires d'utilisateurs, puis ajoutez des détails: créez un tableau de bord pour les utilisateurs et les cadres supérieurs - les critères d'acceptation passent, tout va bien.

Lorsque vous avez déjà des User Stories, vous pouvez commencer à les transformer en pratiques.

Remplacez tous les rôles par de vraies personnes . Une vraie personne en sait toujours plus qu'un rôle. Ensuite, vous trouverez immédiatement le goulot d'étranglement. Par exemple, toutes vos histoires d'utilisateurs utilisent une personne spécifique, bien qu'il soit simplement dans des chapeaux différents, dans des rôles différents. C'est mauvais - découvrez comment le décharger.

Réduisez les artefacts et les communications . S'il y en a trop - chaque User Story suggère ses propres artefacts et communications - quelque chose doit être fait avec cela.

Recherchez les goulots d'étranglement . Quand il existe une telle carte d'histoire, vous pouvez commencer à en faire quelque chose.

Choisir des outils

L'outil identifie les fonctionnalités . Il y a une opinion populaire selon laquelle les outils ne sont pas importants, ou n'importe quel outil convient - c'est un non-sens.

Si l'outil n'est pas pratique à utiliser, ils ne seront pas utilisés.

De plus, les vendeurs mentent toujours. S'ils disent que leur outil peut faire "1, 2 et 3", alors très probablement ils ne peuvent pas faire "1", "2" parfois, et "3" il le fait, mais c'est très mauvais. Assurez-vous de tout vérifier.

Nous discutons activement

Sans une discussion active sur la technique, vous pouvez oublier certaines fonctionnalités importantes, les histoires d'utilisateurs importantes et offenser quelqu'un. La personne offensée va saboter la mise en œuvre de la méthodologie : elle a d'abord été offensée, oubliée, personne ne lui a dit ce dont elle avait besoin.

À ce stade, les gens peuvent montrer une expérience antérieure négative de l'introduction d'autres techniques.

- Ah, n'importe quoi! Nous l'avons déjà eu et rien n'en est sorti.

Pour éviter cela, rassemblez les douleurs des gens, demandez ce qui ne va pas. Enregistrez et démontrez avec précision ce que vous avez enregistré - afin que la personne comprenne qu'elle l'a entendu.

Ne répétez pas les expériences négatives . La rétrospective n'a pas marché? Maintenant, c'est un «gâteau du vendredi». Standups à 7 heures du matin n'est pas allé? Maintenant, c'est "charger". Il est souvent utile de donner des noms différents aux mêmes pratiques afin que les gens ne leur associent pas leurs expériences négatives passées.

Malheureusement, il n'y a pas de solutions universelles. Tirez parti de votre situation.

Implémentation

La principale valeur de la gestion informatique est le respect.

Nous économisons du temps à quelqu'un d'autre . Si vous devez transférer des tâches d'un système de suivi à un autre - rédigez un script, engagez Mechanical Turk pour le faire pour vous. Résolvez ce problème afin que le développeur ne transfère pas toutes ses tâches d'un système à un autre pendant une semaine - c'est une manifestation de respect.

Nous aidons à la transition . Si nous introduisons une nouvelle pratique, nous nous asseyons à côté d'une personne et l'aidons à comprendre le nouveau système. Nous préparons les instructions à l'avance.

Nous décrivons des actions spécifiques. Nous réalisons une documentation très spécifique, juste en fonction de nos User Stories: «Nous devons entreprendre une nouvelle tâche. Comment faire est écrit dans la documentation - vous ouvrez telle ou telle page sur le wiki, vous y lisez telle ou telle chose. »
Nous introduisons progressivement - pas toutes les pratiques à la fois . Nos développeurs n'ont pas remarqué de changement de méthode, car nous n'avons pas implémenté toutes les pratiques en même temps. Lorsque nous voulions passer en douceur d'un SCRUM d'une journée à autre chose, je n'ai pas fait de rétrospectives tous les jours, les tâches sont apparues un peu plus longues, les réunions quotidiennes du matin ont tranquillement migré vers un stand-up plus standard. Il semblait aux gens que tout se passait progressivement. Ensuite, la pratique a changé de façon assez significative. À propos de certaines choses, bien sûr, je leur ai dit: "Maintenant, nous allons légèrement changer le processus de travail avec Jira - ce sera maintenant comme ça."

Les chemins piétinent d'eux-mêmes . Ne prescrivez pas tout de suite un flux de travail difficile - laissez les gens trouver les chemins eux-mêmes. Il est pratique pour eux de transférer la tâche dans le tracker d’un état à l’autre, même s’ils la transfèrent, et vous le réparerez. Il est difficile de prédire immédiatement ce qui sera pratique et d'interdire la transition demandée est facile. Mais alors il faut souffrir longtemps pour tout récupérer.

KISS . Faites simple, au moins au début. Ne compliquez pas trop.

Le soutien

Nous réservons des ressources à l'avance pour le processus de transition, car cela coûte cher . La transition d'une technique à une autre coûte beaucoup d'argent. Réservez pour cela votre temps et le temps des personnes qui éditeront les bugs dans votre tracker, dans votre workflow, dans les procédures de calcul. S'il n'y a pas de ressources, et en même temps une sorte de précipitation, tout se passera mal.
Nous corrigeons les erreurs le plus rapidement possible .

Conclusion

Les projets sont différents, les gens aussi - tout le monde a besoin de techniques complètement différentes ! Toutes les familles heureuses sont également heureuses, toutes malheureuses - à leur manière. La même chose avec les projets - il n'y en a pas deux identiques.

La création d'une technique est une tâche d'ingénierie. Exactement la même chose que la programmation et la conception de modules système. C’est ainsi que vous vous en approchez. Vous savez bien résoudre les problèmes d'ingénierie - utilisez donc toutes vos connaissances dans cette nouvelle pratique.

Le changement de méthodologie est un projet SMART classique . Utilisez tout ce que vous savez sur la gestion de projet: définissez des critères de réussite, vérifiez à la fin du respect des tâches définies, rappelez-vous le temps limité, etc.

Mon manifeste personnel

Les gens sont plus importants que les processus , car les processus doivent être faits pour les gens. Si la société a en moyenne 50 ans et qu'elle est issue de l'armée et que vous essayez de mettre en œuvre rapidement Kanban immédiatement, il est fort probable qu'elle ne décolle pas. Les gens sont juste habitués à autre chose.

Le principal avantage d'un programmeur est sa paresse. Créez des processus pour que les gens y passent encore moins de temps et que les développeurs soient les premiers à exécuter pour les implémenter. Si les gens ne cherchent pas à mettre en œuvre des processus, ils ne comprennent pas pourquoi.

Il arrive que certaines pratiques soient difficiles à mettre en œuvre, car elles sont difficiles à comprendre. Parfois, il est plus facile de changer la pratique, peut-être que cela ne correspond pas à vos tâches ou à votre personnel. En dernier recours - changez les gens, mais c'est plus cher que de changer de pratique.

Le résultat est plus important que les habitudes . L'habitude la plus terrible est l'habitude d'entendre parler d'un nouvel outil, de le ramener à la maison et de l'utiliser immédiatement. Le culte du fret est une terrible habitude à combattre. Mais la peur de changer certaines pratiques parce que «nous avons toujours fait cela» même si elles sont déjà inefficaces, est également nuisible.

Et parfois, en général, les tâches sont si diverses que les habitudes deviennent dangereuses. Par exemple, lors de la communication avec des personnes vivantes.

La persuasion est plus efficace que les ordres . La meilleure motivation est de comprendre le sens de votre travail et de le partager. Les développeurs aiment simplifier la vie des utilisateurs, économiser de l'argent aux entreprises et leur simplifier la vie. Parlez-leur donc des objectifs de leurs actions. Apprenez à convaincre.

Les trois principes sont mon image personnelle du monde. Si vous avez d'autres présupposés, vous avez probablement besoin d'une méthodologie différente pour construire des techniques.

Au sein du comité du programme TeamLead Conf , nous connaissons également mieux l'ancien Lego, nous sélectionnons donc des cubes dans le programme à partir desquels vous pouvez vous-même créer les processus qui vous conviennent. Pour la conférence d'automne à Saint-Pétersbourg, un ensemble de 15 parties a déjà été assemblé, mais nous acceptons toujours les demandes de rapports - écrivez .