Processus flexibles dans l'équipe informatique

Bonjour à tous, je m'appelle Alexei Fedorov, je suis chef d'équipe de l'équipe financière de Citimobil. Dans cet article, je veux partager le fonctionnement du processus de développement agile dans notre équipe.

CityMobil est le deuxième agrégateur de taxis en Russie. Au cours de l'année, nous avons progressé environ 10 fois et nous n'allons pas ralentir. Cette croissance rapide impose certaines limites: nous avons besoin d'un très court délai de mise sur le marché (TTM), le temps entre l'idée et son utilisation par de vrais clients devrait être aussi court que possible. En raison du fait que nous minimisons TTM, nous ne collectons pas la version, mais roulons chaque tâche / fonctionnalité séparément. En outre, cette approche a un avantage important - en cas de problèmes dans la prod, il est immédiatement clair pourquoi ils sont apparus. Cela vous permet d'annuler la tâche, pas la version entière.

Pourquoi pas Scrum

Depuis plusieurs années, la méthodologie Agile et sa variété Scrum (ci-après dénommée Scrum) sont très appréciées dans l'industrie informatique. Scrum essaie de mettre en œuvre en quelque sorte dans chaque entreprise. Et chacun a sa propre expérience de mise en œuvre, mais, en règle générale, il est rarement positif. Le plus souvent vient la désillusion et un retour aux processus précédents.

À mon avis, les principaux problèmes de mêlée sont:

1. Sprints fixes.
   Il s'avère rarement de clore le sprint à temps pour que tout soit fait. En règle générale, il reste une bagatelle qui est sous-fixée ou non vérifiée. Les améliorations sont transférées à un autre sprint, et pour être à l'heure, l'équipe prend moins de tâches. Équilibrer le sprint pour les tâches afin que tout le monde ait un travail est difficile. Les tâches RnD ne rentrent généralement pas dans un cadre fixe. Et surtout, les sprints fixes sont rarement demandés par l'entreprise elle-même.
2. Une variété de rallyes.
   Scrum a beaucoup d'activités: rallyes quotidiens, planification et rétrospective de chaque sprint. Souvent, ces réunions sont organisées pour le spectacle et sont plus fatigantes que bénéfiques.

En général, la mêlée me rappelle un certain culte du cargo, qui est introduit tel quel dans l'espoir qu'il devienne bon. Notre approche consiste à utiliser les techniques et les processus qui aident à atteindre le résultat et à abandonner ce qui interfère.

L'équipe

Le rôle clé dans la formation du processus est joué par l'équipe et sa structure. Notre équipe comprend des développeurs et un chef d'équipe. PM, QA, analystes, designers en option. L'équipe doit être perçue comme une seule unité de combat. Il s'agit d'une boîte grise, à l'entrée de laquelle il y a des exigences et à la sortie - le produit. L'organisation interne est entièrement à la merci de l'équipe, et en elle-même, elle peut travailler sur tout processus qui lui convient.

Comme chez nous

Notre équipe a choisi un processus très similaire à Kanban. Nous avons de nombreuses sources de tâches: trouvées par le service de support des bugs, nouvelles fonctionnalités des produits, dette technique, fonctionnalité d'une équipe adjacente, etc. Peu importe d'où vient la tâche, elle doit être encadrée dans le traqueur de tâches, de préférence par l'auteur lui-même. Toute tâche entrante passe par plusieurs statuts obligatoires: «Nouveau», «Pour travailler», «En cours», «Testé», «Prêt pour le déploiement».

Les tâches se déplacent de gauche à droite sur le plateau, revenant rarement en arrière. La priorité s'étend de haut en bas et de droite à gauche. Par exemple, le déploiement d'une tâche dans la production est plus important que le test, et le test est plus important que le nouveau développement. La colonne «To Work» constitue essentiellement l'arriéré de l'équipe - une liste linéaire priorisée de tâches pour quelques semaines à l'avance. Dès que le développeur comprend sa tâche actuelle, il prend la colonne suivante du haut.

Les tâches ne sont pas fixées à l'avance pour un développeur spécifique, cette approche permet d'équilibrer l'exécution des tâches, augmente la connaissance générale du code par tous les développeurs, augmente le facteur bus. Nous essayons de gérer une spécialisation étroite au sein de l'équipe. Chaque membre de l'équipe doit être en mesure d'effectuer n'importe quelle tâche depuis l'arriéré. Si le développeur a pris la tâche pour lui-même, il contrôle complètement son mouvement sur la carte jusqu'à ce qu'il apparaisse dans la prod. Il vérifie également le comportement de la tâche en conditions réelles.

Parmi les réunions que nous organisons quotidiennement, lors de ce rassemblement, nous discutons non seulement des plans, des problèmes et des tâches terminées, mais également des approches pour résoudre les problèmes, les propositions et en général tout ce qui inquiète les membres de l'équipe. La réunion dure rarement plus de 30 minutes pour 4 personnes. Chaque mois, nous réalisons une rétrospective sur un échantillon scram: ce qui était bon / mauvais, que pouvons-nous en faire, un plan pour augmenter l'efficacité pour le mois prochain. Nous n'avons pas de planification dédiée, nous organisons la planification si nécessaire, si nous commençons à développer une tâche importante.

Nous essayons d'enregistrer le temps pour chaque tâche, au moins 75% du temps de travail. Nous atteignons ainsi deux objectifs:

1. Nous recherchons et éliminons les tueurs de temps: des tâches qui prenaient du temps, mais qui n'apportaient pas les avantages escomptés.
2. Nous évaluons les tâches sur la base de celles déjà effectuées, augmentant ainsi la précision de l'évaluation.

Nous avons également des équipes hebdomadaires: l'un des développeurs répond aux questions de la deuxième ligne d'assistance, recherche de nouveaux problèmes dans les journaux / surveillance, résout les tâches urgentes et fait quelque chose qui ne rentre pas dans le carnet de commandes prévu. Cela permet aux autres développeurs de se concentrer davantage sur leurs tâches sans être distraits par des messagers, etc.

Résumé

Le processus décrit avec de légères variations, j'ai appliqué dans plusieurs équipes et entreprises. Il s'est imposé comme le plus flexible et le plus transparent pour tout le monde.

Nous ne nous reposons pas sur nos lauriers, à chaque nouvelle rétrospective nous rendons notre processus de travail meilleur et plus efficace. Chaque fois que nous revoyons les pratiques utilisées. Nous n'avons pas de «vaches sacrées» - ce qui fonctionnait auparavant peut cesser de fonctionner, et de nombreuses bonnes idées en théorie ne se manifestent pas dans la pratique de la meilleure façon. Nous les déposons sans regret.

Le processus d'amélioration continue est le fondement de notre équipe.