Comment arrêter de pêcher des œufs à la hâte, en baissant simultanément les délais? Quelle chaîne d'outils choisir pour détruire plusieurs tâches à la fois? Nous révélerons tout cela dans notre article.

Essayer d'attraper tous les œufs

À l'époque où notre entreprise émergeait à peine dans l'utérus vitré du bureau et où l'équipe ne comptait que trois personnes (un directeur et deux développeurs), enthousiastes et riches en café, nous n'avions absolument aucune méthodologie de gestion de projet et avons agi de manière pressante, aborder les travaux sur le principe «une personne - un projet». Dans le même temps, il ne s'agissait même pas du fait que les développeurs, interagissant au sein de la même tâche, détenaient des morceaux de code séparés entre eux, et l'ensemble du paysage de l'environnement de développement était suspendu à la machine du développeur lui-même. En tant que référentiel et système de contrôle de version, nous avons ensuite utilisé SVN , qui à l'époque ressemblait plus à un dossier avec des archiveurs zip. Malgré le fait que SVN est l'un des plus grands systèmes de contrôle de version et dispose d'une communauté appropriée, sa fonctionnalité ne nous convenait qu'en termes de préservation du code, sinon tout était un peu pauvre: il n'y avait pas de version locale et la possibilité de fusionner le code. Par conséquent, nous avons commencé à chercher quelque chose de plus adapté à nos appétits - le développement du processus de travail a commencé. La première chose à régler était la planification et la définition des tâches, ainsi que leur répartition les unes par rapport aux autres, afin de passer de la monoprojectivité au développement conjoint et au respect des délais. À cette époque, le seul type de planification était des réunions avec des cahiers. Avec cette approche, avant l'efficience et l'efficacité c'était comme la lune sur le cosaque, quelqu'un a réussi à tout noter, quelqu'un a oublié ou oublié. En conséquence, les gens ont quitté la réunion sans comprendre clairement quoi et comment faire, avec un tas d'informations dans leur tête et quelques gribouillis dans un cahier.

Nous sélectionnons une chaîne d'outils

La première étape pour réduire l'entropie du flux de travail a été de créer un référentiel normal pour travailler ensemble sur des projets et connecter les différentes parties du code. Nous avons jeté un vieux SVN et levé GIT sur la machine locale de notre PDG. Pour afficher et connecter le code, utilisez des utilitaires de console simples. Ce n'était pas très pratique, mais au moins cela permettait de maintenir l'ordre et la transparence des changements dans le projet.

Nous avons toujours eu des problèmes de planification et, par conséquent, nous avons dû respecter les délais. Pour ce faire, il a fallu trouver un moyen de décomposer les tâches et d'afficher l'état de leur mise en œuvre. Une tentative pour résoudre ce problème a été l'utilisation de l'application de gestion de projet RedMine, à partir de laquelle l'analyse comparative active de la chaîne d'outils a commencé. L'utilitaire était bien adapté aux développeurs (capacités de gestion de projet, forums, suivi des bogues), mais malheureusement, il était très difficile pour les gestionnaires. Les développeurs devaient constamment traiter toutes les informations (merzhrekvesta, pullrekvesta, etc.) du SUV et les saisir dans le programme RedMine , afin que les gestionnaires puissent suivre le degré d'achèvement de la tâche. En plus de cela, il n'y avait pas assez de fonctions de gestion de projet supplémentaires, nous avons donc commencé à jeter un coup d'œil vers FengOffice .

L'outil avait une gamme de fonctionnalités assez large, ce qui permettait d'imaginer le sujet de la combinaison d'outils de communication et de planification comme un diagramme de Gantt en un seul système de travail. Cependant, avec tout l'équipement de ce produit, les développeurs ont dû fermer manuellement les tâches, tout en compilant simultanément des statistiques, car il n'y avait pas de synchronisation automatique des tâches effectuées. De plus, l'implémentation du chat interne ressemblait plus à une ancienne version similaire d'ICQ qu'à un chat d'entreprise normal, mais pour nous, ce moment était très important.

Nous avons compris que pour que tout le mécanisme fonctionne en harmonie, de simples réunions ne sont clairement pas suffisantes. Il était nécessaire de sélectionner des outils opérationnels pour établir de courtes communications qui étaient nécessaires même pour les personnes assises côte à côte dans la même pièce. Deux points se posent ici: le premier - si vous menez de courtes conversations dans le format habituel, alors elles prendront trop de temps de travail, ce qui signifierait bonjour à l'effondrement de tous les délais et un retard important par rapport au calendrier, et le second - si vous faites au moins de courtes interactions, cela conduira à communication étroite entre les membres de l'équipe, incohérence de leurs actions, duplication de code et autres problèmes. Par conséquent, nous sommes arrivés à une solution simple - pour transférer des micro-réunions vers un chat d'équipe, qui vous permet de communiquer en permanence sans être fortement distrait du flux de travail, de coordonner les actions des développeurs et d'éviter l'exécution répétée des mêmes tâches, ainsi que les différends concernant qui a mieux exécuté la tâche. La solution peut sembler évidente et banale, mais la question n'est pas dans les moyens d'interaction, mais dans l'approche et la qualité d'utilisation de l'outil. La question était de savoir comment transformer le chat d'un lieu inondé et brûlé en remplacement partiel des réunions et des conversations personnelles.

Pendant ce temps, le GIT habituel n'était pas suffisant, il y avait un fort manque d'interface web. Nous avions deux options au menu: un référentiel privé sur GitHub et un référentiel sur GitLab. GitLab est gratuit - et ils l'ont pris. Il a également une communauté cool et amicale. De plus, GitLab avait déjà un système de planification des tâches intégré et offrait une interface pratique pour merzhrekvest. Si vous avez travaillé en équipe, vous savez probablement à quel point il est important d'obtenir rapidement un merzhrekvest approuvé. Finalement, nous avons enterré FengOffice et nous sommes installés sur GitLab. De plus, à cette époque, nous utilisions déjà Slack comme chat d'équipe, et étant donné que GitLab prévoyait une intégration mutuelle avec Slack, et tout cela était également gratuit, le choix pour nous est devenu plus évident que jamais.

Les livres ne mentaient pas

Puis est venu le moment où il a fallu choisir la méthodologie la plus adaptée à notre gestion de projet flexible. Nous avons opté pour deux des approches les plus développées et les plus populaires: Kanban et Scrum. L'initiative est venue entièrement de notre PDG, Ilya Bykoni, qui, avec le feu prometheus dans les yeux, a parlé à l'équipe des changements à venir. Mais à sa grande surprise, l'équipe a d'abord rencontré des innovations, comme les Spartiates ont rencontré Xerxès, avec un entêtement féroce de copies conservatrices. Que pouvez-vous faire, illusions, illusions, parce que dans les livres qu'ils ont mis en garde ... Un fait intéressant a immédiatement été remarqué qu'une attitude négative envers les nouvelles approches n'est pas en corrélation avec l'adéquation et la capacité des gens à travailler. Même les jeunes juin, qui étaient censés ramasser facilement tout cela, ont résisté, arguant que: "ils feraient mieux de programmer pendant 15 minutes que de passer ce temps le lendemain", "pourquoi avez-vous besoin de planifier si les délais sont de toute façon ne sont pas exécutés ou sont en cours d'exécution, mais avec des écarts »,« pourquoi le développeur frontend devrait-il écouter le backend », etc. Le fait est que la méthodologie de l'approche Agile implique un style de travail dans lequel il est impossible de s'asseoir sur les épaules atlantes d'un développeur fort et d'accéder au projet sur ses compétences, comme beaucoup de gens ont l'habitude de travailler dessus, alors de tels changements deviennent pour eux douloureux.


Lorsque nous avons commencé à introduire Agile dans le travail, nous avons pleinement ressenti la valeur des communications courtes et de haute qualité. Il arrive souvent que lorsque des tâches similaires proviennent de la contribution du département RnD de plusieurs sources, les chefs de projet ne peuvent pas détecter les doublons. Et ici, les interactions à court terme et les rallyes quotidiens, qui protègent complètement contre de tels problèmes, commencent à jouer un rôle très important en identifiant un terrain d'entente entre les développeurs de différentes équipes. Il y a un autre point intéressant - la plupart des programmeurs sont des introvertis, c'est-à-dire que toute communication est micro-stress, surtout quand il s'agit de rassemblements en grandes équipes, où une personne doit parler à un large public de spécialistes divers. Et beaucoup de gens, par crainte d'un tel inconfort, ne réalisent pas que l'alternative à de si courtes réunions peut être encore plus désagréable que le quotidien. Celui-ci sera remplacé par une communication constante tout au long de la journée, dans le but d'amener le travail à un processus contrôlé. Pour nous, nous avons conclu qu'Agile prend en compte l'introversion des développeurs et réduit au minimum l'inconfort associé au besoin de communication. Bien sûr, pour les jeunes employés de l'entreprise, en tout cas, cela sera stressant pendant un certain temps jusqu'à ce qu'il se penche sur les spécificités de son travail et apprenne à connaître l'équipe de plus près, donc plus la culture Agile est conviviale et efficace dans l'entreprise, plus le processus d'adaptation se terminera rapidement.

Un bâton fait mal, beaucoup de bâtons sont mortels

L'une des principales motivations d'une approche flexible est que les gens s'habituent à minimiser leur fakapy et leurs bugs. Le fait est que si vous prenez la structure de gestion verticale standard, le développeur est responsable de ses erreurs envers le patron immédiat qui punit et «frappe avec un bâton sur la tête» si l'employé fakapit ou «caresse la tête» si tout est fait clairement. Autrement dit, dans la structure verticale, une personne a la possibilité de rebondir en raison de relations personnelles ou de «savoureux cookies». Dans Agile, l'interaction d'équipe est construite horizontalement, ce qui signifie qu'une personne doit se présenter à toute l'équipe lors des rallyes quotidiens. Il n'a tout bêtement pas assez d'argent pour autant de cookies. Par conséquent, vous devez vous habituer au fait que vos erreurs seront examinées par vos collègues, et soit vous serez sur un cheval et ils vous verseront des pétales de rose à cause des louanges de votre professionnalisme, soit vous serez sous un cheval ... En tout cas, c'est un fort pompage des compétences personnelles d'une personne, et si l'atmosphère de l'entreprise est suffisamment chaleureuse, la personne commence à s'ouvrir lentement, contribuant de plus en plus à l'écosystème de son département et de l'entreprise dans son ensemble. Nous avons également fait l'expérience de l'effet de filtrage d'Agile, confronté plus d'une fois à une situation où les développeurs objectivement faibles ne peuvent pas supporter l'analyse constante de leurs erreurs, et finalement fusionnent s'ils se rendent compte qu'ils manquent de motivation interne et de force pour pour passer du statut bagodel au statut bogacode.

Pour résumer

Je dois dire que le processus de mise en place d'une machine Agile s'est avéré assez long et très stressant, "cela n'aurait pas pu se passer sans violence" - au départ, les gens devaient être pratiquement conduits avec un bâton pour les rassemblements et les événements quotidiens, afin que les gens commencent en quelque sorte à exprimer leur position sur les tâches qu'ils étaient en train de résoudre. Bien que nous devions constamment «grimper sous le capot» et bricoler le «moteur», nous salir les mains dans le mazout, cela en vaut la peine lorsque l'équipe prend de la vitesse et se précipite vers l'avant, collectant le point de contrôle pour le point de contrôle. Nous n'arrêtons pas notre évolution même une seconde, nous sommes toujours dans le statut de transitaires éternels, étudions constamment de nouveaux et modifions les modèles existants de gestion et d'interaction entre les employés. Une chose que nous comprenons absolument avec certitude - là où il n'y a ni mouvement ni lutte, il n'y a pas de vie. Comme disent les moines zen: "J'ai atteint le sommet, continuez l'ascension ..." Bonne chance à tous dans vos ascensions et laissez tout le monde aller vers son apogée, quoi qu'il arrive!

PS:

Voici un exemple de liste et le calendrier des étapes que nous avons franchies:

1. Planification de la formation ~ 4 mois
2. Travailler avec de courtes communications ~ 1 mois
3. Rechercher une chaîne d'outils et un développement de workflow appropriés ~ 2 mois
4. Choix de la méthodologie ~ 2 mois
5. Introduction de Scrum au workflow ~ 8 mois

Et voici une petite sélection de notre PDG:

1. Comprendre l'agilité - Andrew Stellman et Jennifer Green
2. «La voie du Scrum-Master» - Zuzan Shokhov
3. «Scrum, une méthode de gestion de projet révolutionnaire» - Jeff Sutherland
4. «Kanban Alternative Way to Agile» - David Anderson
5. «À la tête de la transformation. Application des principes d'Agile et DevOps dans toute l'entreprise "- Harry Gruver et Tommy Mauser