Il s'agit d'Agile - 2: Fonctionnalités d'implémentation Agile

Nous continuons sur les nuances du développement agile qui se produisent dans la pratique. Comment comprendre si Agile est correctement implémenté, quelle pratique convient à quelle tâche et à quel secteur, qui dans l'entreprise doit transférer le travail vers «Agile-rails»? Vasile Savunov, Agile Coach ScrumTrek, continue de partager son expérience avec les rédacteurs du blog Mail.Ru Cloud Solutions .

La dernière fois, Vasily a parlé de ce qu'est l'Agile, de ses méthodologies et des stéréotypes qui se sont formés autour de lui. Parlons maintenant de sa mise en œuvre.

À propos des entreprises agiles

- Y a-t-il des «préférences de l'industrie» dans les méthodologies flexibles?

Comme le montre l' étude Agile Russia , que nous menons pour la deuxième année consécutive, Scrum est principalement utilisé dans le développement de logiciels, Kanban dans les organisations financières et les deux dans l'industrie des télécommunications.

En tant que personne qui a directement analysé les données collectées et travaillé avec de nombreux répondants, je pense que cet état de choses est dû à deux raisons:

• Le taux de variation de l'informatique est nettement supérieur à celui de la finance. Par conséquent, Scrum y est préférable en tant qu'approche qui permet, en raison d'expériences rapides, de contrôler de manière flexible les priorités et de changer de direction en fonction des changements de l'environnement extérieur et des conditions à l'entrée. La finance est plus conservatrice.
• Le coût d'une erreur dans la finance est beaucoup plus élevé que dans le développement informatique. Par conséquent, ils sont plus appréciés Kanban, basés sur les mathématiques, plutôt que sur l'expérimentation, et permettant à travers des changements petits mais constants d'améliorer le flux de travail dans son ensemble.

Telecom Kanban convient également. Ne serait-ce que parce que le vecteur de développement de l’industrie est la numérisation. Cependant, peu de gens comprennent à quoi cela devrait ressembler exactement. De plus, en télécom, la partie «rapide» du travail (développement logiciel) est adjacente à la partie «lente» (support et développement de l'infrastructure matérielle). Par conséquent, avec les expériences menées sur Scrum, il est logique d'accélérer l'évolution des processus actuels en utilisant Kanban.


Pratiques de développement agile adoptées dans diverses industries. Les montants ne sont pas égaux à 100% car plusieurs éléments peuvent être sélectionnés. Image / ScrumTrek

- Et les développeurs mobiles? Agile a-t-il des spécificités dans le développement mobile?

De mon point de vue, la principale difficulté dans le développement d'applications mobiles est d'identifier les exigences des applications, car il peut être difficile d'identifier les parties prenantes. Ces difficultés peuvent être surmontées en utilisant le développement client pour rechercher les besoins des clients et Scrum pour tester rapidement les hypothèses de produits.


En général, Agile va bien avec le développement mobile: il nécessite une réaction rapide, l'implication et le travail coordonné de différents spécialistes, la capacité de fournir rapidement le résultat et, si nécessaire, de le changer.

En plus de Scrum, vous pouvez utiliser ici directement axé sur les approches de développement mobile. Par exemple, Mobile-D est basé sur XP, Crystal et RUP - les approches sont assez anciennes et bien établies. La principale différence entre Mobile-D et Scrum: la présence de phases claires et l'accent mis sur l'ingénierie du développement de produits. Alors que Scrum accorde plus d'attention à la gestion et à la livraison des produits, Mobile-D se concentre sur le processus de fabrication et inclut des pratiques XP qui améliorent considérablement la qualité du produit final. Dans le même temps, l'influence de RUP affecte, donc le processus est assez formalisé.

Une autre approche la plus moderne du développement mobile est SLeSS , combinant Scrum et Lean Six Sigma . Tout d'abord, il implémente le paramétrage du workflow Scrum, puis applique les approches Lean Six Sigma pour la gestion statistique de la qualité. Il me semble que SLeSS allie la flexibilité nécessaire aux mécanismes de prise de décision éclairée basés sur des statistiques.

Dans le même temps, le Guide Scrum n'interdit pas initialement l'inclusion d'autres approches et outils dans le flux de travail Scrum qui peuvent être utiles pour le développement de produits. Par conséquent, tout ce qui précède peut être implémenté dans le cadre du Scrum "classique".

- Quelle est la flexibilité des méthodologies de modification dans des conditions particulières?

Il doit être considéré séparément Scrum et Kanban.

Scrum est un framework, c'est-à-dire un framework, dont tous les éléments sont requis: événements, rôles et artefacts. Aucun ne peut être jeté. Mais il n'y a pas d'exigences strictes sur la façon de mettre en œuvre exactement ces éléments - faites comme vous le souhaitez. Et Scrum n'interdit pas d'ajouter de nouveaux éléments: réunions, artefacts, rôles dont vous avez besoin pour travailler et accélérer le processus.

Kanban est un ensemble d'outils et de métriques. Il ne donne pas de paramètres rigoureux sur exactement quels outils et dans quelle combinaison utiliser, car il est conçu pour un long changement évolutif du système existant. Mais en même temps, le succès de Kanban est déterminé par la collecte de données sur le processus de travail et leur analyse régulière. Si cela n'est pas fait, avec le temps, tout s'éteindra et il n'y aura pas d'autres améliorations. Mais ça va: comme l’a dit Edward Deming, vous n’avez pas à changer, la survie est volontaire.

- Quelles sont les erreurs typiques dans l'adaptation Scrum fait une entreprise?

La principale erreur dans la mise en œuvre de méthodologies flexibles est l'utilisation d'outils sans comprendre pourquoi ils doivent être utilisés spécifiquement.

Par exemple, dans les grandes organisations, lors de la mise en œuvre de Scrum, ils renvoient souvent simplement le chef de projet en tant que propriétaire du produit et l'équipe de projet dans l'équipe Scrum et commencent à exiger de donner le résultat final en deux semaines. Mais cela ne fonctionne pas, et pour une raison très simple: les conditions ne sont pas réunies pour que Scrum puisse fonctionner .

• Bien que le chef de projet ait été surnommé le Product Owner, il n'a pas reçu l'autorité nécessaire et n'a donc pas le droit de formuler une vision du produit ou de modifier les priorités de mise en œuvre. Comme auparavant, il est contraint de coordonner chacune de ses étapes avec la direction et est contraint dans le cadre des exigences de calendrier et de volume de travail. Ainsi, la vitesse de prise de décision est restée la même. Aucune accélération ou adaptation aux conditions changeantes.
• Bien que l'équipe de projet s'appelle l'équipe Scrum, les personnes qui y sont incluses peuvent toujours être répertoriées dans chaque département et rapporter directement à leurs supérieurs hiérarchiques. En conséquence, chaque membre de l'équipe fait d'abord ce que son supérieur hiérarchique, et non le Product Owner, lui confiera. Par conséquent, les tâches du produit seront toujours moins prioritaires, ce qui signifie que la vitesse de mise en œuvre du produit, pour laquelle l'équipe Scrum a été «assemblée», n'augmentera pas du tout.
• Très probablement, comme auparavant, les membres de l'équipe seront occupés dans d'autres projets. Alors que Scrum déclare directement: les membres de l'équipe doivent être alloués à l'équipe Scrum à 100% de leur temps de travail et ne doivent traiter que le produit dirigé par leur Product Owner. Si les gens sont «divisés par des pourcentages» entre les projets / produits, alors ils basculeront entre eux, ce qui réduira considérablement l'implication et l'efficacité du travail sur chaque projet / produit spécifique.

Une telle «mise en œuvre» inepte a de nombreuses conséquences négatives, mais elles commencent par une tentative de reproduire la mécanique, mais pas l'essence de Scrum. Les principales erreurs dans la mise en œuvre de Scrum ont été décrites en détail dans mon rapport « Stop Signals for Agile » lors de la conférence CodeFest 2017.

- Comment évaluer la mise en œuvre de méthodologies flexibles et compétentes dans l'entreprise?

Il existe un test Scrum Open , mais il sert plutôt de test de connaissances théoriques. Ce qui se passe dans la pratique, il ne permet pas de comprendre. Étant donné que la base de Scrum est le travail d'équipe et que sa priorité est la rapidité de livraison du produit et la valeur pour le consommateur, 360 enquêtes sont les plus appropriées. Il est donc plus fiable d’établir le degré de maturité de l’équipe et de satisfaction des clients.

Nous utilisons notre propre méthodologie, qui a été implémentée dans le service ScrumTrek Diagnostic Tool . Elle travaille comme ça. Une équipe et les parties intéressées extérieures doivent répondre à une série de questions sur la façon dont ils évaluent le niveau d'interaction de l'équipe, la planification de leur travail, la valeur du résultat livré au client, l'interaction avec d'autres équipes, etc. Pour chaque paramètre, la médiane des opinions est calculée et un diagramme circulaire complexe est créé - Radar, qui affiche l'apparence à la fois de l'intérieur de l'équipe et de l'extérieur.


Radar ScrumTrek. Nous regardons la dispersion des notes


Radar ScrumTrek. Nous regardons les médianes

Le diagramme contient de nombreuses informations utiles.

• Les estimations atomiques des individus et leurs moyennes sont intéressantes en elles-mêmes et aucune explication n'est nécessaire ici.
• La dispersion des notes dans une équipe est une chose intéressante. Lorsqu'il est très important, il y a lieu de s'entendre sur ce que nous, en tant qu'équipe, entendons par l'un ou l'autre aspect de notre travail. Qu'entend-on par «valeur client», par exemple? Et qu'en est-il de la «vitesse de livraison»? Un large écart indique que l'équipe n'a pas formé une position unique sur un certain nombre de questions.

Un petit écart indique un consensus et un bon travail d'équipe.

• Les évaluations sont classées. Vous pouvez voir que tout va bien avec la culture, mais la productivité diminue à certains endroits. Il est clair où «creuser».
• La différence entre l'évaluation à l'intérieur et à l'extérieur de l'équipe est l'un des indicateurs les plus importants, elle montre les différences entre les attentes des clients et des autres parties intéressées de l'équipe et la façon dont l'équipe se perçoit. Agile concerne l'interaction étroite entre les entreprises et ceux qui vendent le produit, donc ces écarts sont une excellente raison de «vérifier l'horloge» entre ces deux domaines et de s'entendre sur la façon de restructurer l'équipe.

Après la collecte des données, une analyse du graphique est nécessairement réalisée avec la participation de l'ensemble de l'équipe et des parties prenantes. Tout pour leur montrer à quoi ressemble le travail de l'équipe sous différents angles, et pour transformer les résultats de l'analyse en étapes concrètes pour améliorer le travail.

À propos des équipes d'implémentation Scrum

- De qui l'entreprise doit-elle initier la mise en œuvre des méthodologies de développement agile?

La mise en œuvre de Scrum vient toujours d'un objectif commercial. Par conséquent, le client devrait être le premier à penser à l'accélération, qu'elle soit interne ou externe. Ensuite, vous devez élaborer le concept du produit afin qu'il puisse être fait de manière itérative. Et alors seulement formez une équipe. Scrum pour le bien de Scrum ne fonctionne pas. De plus, il peut être trop coûteux de résoudre des problèmes spécifiques.

Qui sera le «guide Agile» dans l'entreprise est une question sans la seule bonne réponse. J'ai vu le directeur technique devenir «l'instigateur» du changement. Il y a eu des cas où l'initiative est venue du monde des affaires et a même vu comment une telle initiative est née «d'en bas». Tout dépend de l'énergie et de la motivation de la personne, de sa capacité à intégrer sa vision du développement à l'aide d'approches flexibles dans le contexte commercial du produit ou de l'unité.

Idéal lorsque l'initiative vient de la haute direction. Des progrès dans cette direction sont perceptibles sur le marché russe.

- Quels nouveaux rôles et fonctions apparaissent dans une organisation ou une équipe avec l'introduction de méthodologies flexibles? Lesquels sont obligatoires, lesquels sont facultatifs?

Dans le cas de Scrum, ce sont les rôles du maître Scrum, du propriétaire du produit et de l'équipe de développement. Tous sont nécessaires. L'équipe de développement est également considérée comme un «rôle», car elle associe non seulement les développeurs, mais aussi tous ceux qui ont besoin que le produit apparaisse en principe: analystes, designers, etc.

Le Scrum-master et le propriétaire du produit peuvent avoir des assistants qui prennent en charge une partie de leurs fonctions, tandis que la responsabilité du résultat incombe au Scrum-master ou au propriétaire du produit.

Le propriétaire du produit est souvent une personne de l'entreprise. Mais pas nécessairement: disons, si nous créons une sorte de solution d'ingénierie pour la production, ce rôle peut être joué par l'ingénieur en chef. En fin de compte, c'est la personne qui comprend le mieux pour quel consommateur nous fabriquons le produit, quels problèmes il résout en premier lieu, comment les priorités doivent être établies lors de sa création. Il est très important que le propriétaire du produit ait le pouvoir de déterminer de manière indépendante la composition du produit sur la base des données du marché et du consommateur. Il devrait avoir le droit de dire non aux parties intéressées avec lesquelles il interagit. Cela est nécessaire pour que les priorités soient convenues et que les décisions soient prises rapidement.

Scrum-master est une personne dont la tâche est de créer une équipe forte, unie, responsable et idéalement auto-organisée. Ce qui est important, ce n'est pas un chef d'équipe , c'est-à-dire pas un chef. Scrum-master n'est pas autorisé à donner des conseils ou à intervenir directement dans le développement de produits. Il est l'organisateur, l'animateur, le coach et le praticien Agile. D'après mon expérience, les meilleurs Scrum-masters viennent de chefs de projet - à condition d'avoir été formés et parvenus à passer d'un format directif à un coaching.


En parlant de style de communication de coaching. Il y a aussi un coach Agile . Sa tâche consiste à mettre en place le flux de travail, à éduquer les gens et à leur donner des outils pour les activités quotidiennes au sein d'Agile. Y compris les outils de résolution des conflits. Tout le reste dépasse sa compétence. Idéalement, un coach Agile devrait mettre en place une équipe ou un département afin que tout fonctionne de manière autonome et qu'aucun coach Agile ne soit nécessaire.

La période de transition est toujours associée à une gêne. Agile-coach est conçu pour aider l'équipe à traverser cette période avec un minimum de friction et à développer de nouvelles méthodes de travail - pratiques et efficaces.

Lors de la mise à l'échelle, des rôles supplémentaires peuvent être introduits, comme décrit, par exemple, dans le cadre SAFe , mais ils sont toujours basés sur les termes de référence et les principes de travail du Scrum-master ou du propriétaire du produit: les niveaux de hiérarchie concernant le produit apparaissent simplement.


- Comment les fonctions du propriétaire du produit et du Scrum-master «dans un monde idéal» sont-elles différenciées?

D'un côté, les intérêts de l'entreprise que le propriétaire du produit représente, de l'autre, la vitalité et l'efficacité de l'équipe dont le Scrum master est responsable. Pour que l'équipe obtienne rapidement des résultats, le système doit être en équilibre. Si le propriétaire du produit «pince», l'équipe travaillera les nuits et les week-ends, et bientôt il fera face à une poignée de personnes démotivées et non impliquées au lieu d'une équipe bien coordonnée. Si le Scrum-master tire la couverture sur lui-même, le développement ne sera ni fragile, ni andain, avec des disputes constantes et beaucoup plus longtemps que nécessaire.


- Quelles méthodologies et modèles de gestion méritent d'être maîtrisés pour ceux qui vont assumer l'un des rôles décrits précédemment?

En termes de compétences métiers, tout est «selon les classiques», comme dans le management ordinaire, à l'exception de la nécessité de déterminer les priorités par étapes et d'interagir plus étroitement avec l'équipe.

Le propriétaire du produit doit apprendre le Lean Startup, le développement client et d'autres approches modernes de création de produits.

Pour le Scrum-master, l' éventail des compétences est plus large: facilitation, gestion des conflits, dynamique de groupe, coaching et, bien sûr, pratique Agile. Ce sont plutôt des compétences du domaine de la psychologie, donc leur manque se fait sentir lors de la formation des gestionnaires.

- La propriété collective du code réduit-elle vraiment la dépendance de l'entreprise vis-à-vis des développeurs «vedettes»? Leur motivation est-elle en baisse?

La propriété collective de code est possible sans méthodologies flexibles. Assez d'accords de révision de code et d'autres règles formelles, et les développeurs peuvent agir de manière atomique.

Souvent, l'entreprise elle-même provoque le comportement "stellaire" des ingénieurs: à première vue, il est plus avantageux pour elle de déboucher sur un super spécialiste et de lui confier toute une direction en pleine responsabilité du résultat que de constituer une équipe de paysans moyens, de réduire systématiquement les risques d'erreur et d'augmenter leur professionnalisme.

Il s'agit d'un dilemme: succès à court ou à long terme. Il semble que l'embauche d'une «star» soit bonne pour les affaires. Mais que se passera-t-il dans trois ans, cinq, sept ans après qu'un tel pro a rejoint l'entreprise? Il deviendra indispensable. Et avec au moins trois conséquences négatives.

Premièrement, une telle personne n'a presque pas de temps libre , et la société, dans l'ensemble, s'en fiche. Sa logique: "Nous ne vous payons pas un énorme salaire pour que vous puissiez vous reposer." Dans une situation similaire, les gens s'épuisent rapidement, tombent dans le cynisme et essaient de tirer le maximum d'avantages de leur position.

-, . , , , . : , , , , . , .

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

— , - ?

• , «»: . .
• . , , .
• «» , , , , . . . , , .
• «». «» , «- ». Scrum-, «», , «» , , . , , «».

, , . , « ». , , « » . , « . - ».

Mail.Ru Cloud Solutions .