Il s'agit d'Agile 1: Mythes de l'agenda populaire

Les méthodologies de développement agiles ont pris racine à la fois dans les TI et dans les non-TI, envahies par leurs présages, stéréotypes, superstitions et mythologie. Les rédacteurs du blog Mail.Ru Cloud Solutions ont décidé de parler de cette mythologie avec le coach Agile Vasily Savunov de ScrumTrek.

Agile est une philosophie de développement agile dont les fondements sont décrits dans le Manifeste de développement logiciel Agile . Le concept repose sur quatre valeurs fondamentales:

• les gens et l'interaction sont plus importants que les processus et les outils;
• un produit fonctionnel est plus important qu'une documentation complète;
• la coopération avec le client est plus importante que l'accord sur les termes du contrat;
• la volonté de changement est plus importante que de suivre le plan initial.

Les principes de l'approche Agile ont transformé le processus de développement et ont gagné le respect. Le monde moderne accélère beaucoup - des dizaines de nouveaux services et solutions numériques apparaissent chaque jour. Agile permet à l'entreprise d'être assez rapide lors du développement de nouveaux produits pour suivre ce rythme rapide et le plus tôt possible pour donner aux utilisateurs et aux clients quelque chose qui résoudra leurs problèmes.

Avec la popularité en Agile est venue son interprétation formelle. Nous analyserons les mythes et les stéréotypes qui nous empêchent de voir l'essence d'une approche flexible et d'en tirer le meilleur parti.

Mythe 1. L'agilité est uniquement informatique

Plus maintenant. Il suffit de consulter la liste des entreprises au nom desquelles interviennent les intervenants des Agile Days et Agile Business Conference: Gazpromneft, Rostelecom, Severstal, PTG-Group, 12Storeez. Ces organisations et de nombreuses autres qui ne sont pas liées à l'industrie informatique utilisent plus qu'efficacement les approches Agiles.

Mythe 2. Agile - pas pour les projets à budget fixe

Dans un budget fixe, vous pouvez travailler très différemment. La question est de savoir quelle est la relation entre l'entrepreneur et le client. Si vous utilisez Agile, vous devez vous concentrer sur ce qui résout le problème du client. En d'autres termes, si au départ le client et l'entrepreneur effectuent ensemble la planification et identifient les principales priorités du produit, alors rien ne les empêchera de déterminer quelle partie du produit, la plus utile, peut être mise en œuvre par l'entrepreneur dans un budget limité. Et si vous stipulez également des affichages réguliers faits au client, il est tout à fait possible d'ajuster le processus en segments courts et, en conséquence, d'ajuster les coûts du projet.

Mythe 3. Agile - une panacée pour les affaires et le développement: mettre en œuvre, laisser quelque chose s'améliorer

Il me semble que c'est une vision simplifiée et très néfaste des choses. Tous les cas et les entreprises sont différents, et vous devez choisir la bonne approche qui vous aidera dans ce cas particulier.

Certainement, Agile n'est pas nécessaire lorsque la clé du succès est de suivre un algorithme d'actions bien défini. Par exemple, dans le travail d'un centre d'appels, où pour un meilleur service, les opérateurs devraient mener une conversation en utilisant des «scripts», c'est-à-dire scénarios de communication prédéfinis. Il n'y a pas de champ d'expérimentation, et ils peuvent même être nuisibles ici. Ainsi, Agile n'est pas nécessaire dans les activités des opérateurs de centres d'appels.



L'agilité sera néfaste lorsque le coût de "transformation" ou de "raffinement" du produit est colossal, voire peut impliquer des sacrifices humains. Disons que lors de la construction d'une centrale nucléaire, il est évident que nous ne pouvons pas construire de manière itérative-incrémentale, comme nous le dit Agile.

Mythe 4. Scrum, Lean, Kanban ne se croisent pas.

Les méthodologies et les outils doivent être séparés. La méthodologie est un algorithme pour construire un workflow. Les outils sont ces «briques» utilisées dans cet algorithme.

Différentes méthodologies peuvent inclure les mêmes outils, mais dans une disposition différente. Vous pouvez souvent voir comment, lors de la mise en œuvre de Scrum, ils ont recours à des outils XP (programmation extrême) ou Kanban. Et c'est normal, car ils répondent tous aux valeurs Agile et vous permettent de rendre le workflow de création de produit flexible.

Si nous parlons des approches Agiles spécifiques qui sont maintenant les plus répandues, alors c'est certainement Scrum et Kanban. D'autres - FDD, XP, RUP et ainsi de suite, ont quitté la scène ou sont rarement utilisés dans leur ensemble, mais des outils individuels de leur arsenal sont impliqués dans la mise en œuvre de Scrum ou Kanban.

Mythe 5. Scrum - comment fabriquer un produit rapidement et à moindre coût.

Quant au «rapide», tout est vrai, mais quant au «bon marché» - non. Jugez par vous-même: vous devez former une équipe à part entière, en mettant en évidence à 100% les compétences nécessaires. Ces personnes ne seront occupées que par le développement du produit qui leur est confié et rien d'autre, ce qui signifie qu'elles devront soit engager ces spécialistes, soit les «arracher» à un service. Il en va de même pour la partie commerciale: si vous le souhaitez, si vous ne le souhaitez pas, vous devrez affecter le propriétaire du produit, qui consacrera 50 à 80% de son temps uniquement à cette équipe et à son produit.

De plus, vous devrez les réunir tous, dans une seule pièce, leur fournir leur propre espace, les accessoires pour les activités d'équipe, etc. De plus, vous devez garder à l'esprit qu'au moins huit heures par sprint seront consacrées à la communication, car Scrum implique une série de réunions obligatoires d'une ou deux heures. Vous devrez investir dans tous les cas, mais le gain final de vitesse et de qualité que Scrum fournit est très important.


Sprint comprend 4 réunions obligatoires: planification, mise en œuvre, publication, revue de sprint avec une rétrospective. De plus, des réunions de courte durée (réunions debout) ont lieu chaque jour au cours desquelles les membres de l'équipe «vérifient l'horloge» dans un format unique et coordonnent leurs actions. Vous ne pouvez pas ajouter de nouvelles tâches au sprint ouvert - cela habituera l'équipe à la planification et assurera contre le chaos managérial.

Mythe 6. Kanban est un tableau avec des tâches affichées sur eux.

Pas du tout! Les tableaux ne sont que la première étape la plus simple de Kanban. Mais l'affaire ne se limite pas à eux . Au cœur de Kanban se trouve un appareil mathématique complexe basé sur des données statistiques. Par conséquent, assimiler Kanban à des planches signifie ne pas regarder au-delà de sa façade.

En résumé, le principal objectif de Kanban est de:

• Rendre le flux de travail actuel transparent et couvrir toutes les étapes - de l'occurrence de la tâche dans le chef d'entreprise à sa mise en œuvre et l'expédition du produit au consommateur.
• Gérez votre flux de travail en identifiant les pertes de temps et en les éliminant. Ainsi, nous rendons notre workflow prévisible.
• Prenez des décisions de gestion basées sur des métriques, pas sur des sentiments.

Mythe 7. Scrum et Kanban peuvent être implantés dans tous les projets et entreprises.

Je n'aime pas le mot «planter», après tout, Agile, c'est travailler avec les gens. Il serait plus correct de parler d '«inculquer» une nouvelle philosophie de réflexion à l'équipe.

Dans le même temps, l'algorithme de greffe Scrum et Kanban sont différents.

Le taux de réussite de l'utilisation de Scrum dépend de la culture d'entreprise dominante de l'entreprise. Dans une structure hiérarchique rigide, où tout le monde a besoin d'un morceau de papier, aucun effort pour «grandir» Scrum ne réussira sans le soutien de la direction. Nous devrons construire une nouvelle structure parallèle basée sur une approche d'équipe. Une sorte de "réserve Agile", qui protégera l'un des managers du plus haut niveau. Dans de telles conditions, il est possible d'afficher un résultat rapide en trois à quatre mois. Mais il y aura une tâche plus difficile à accomplir - diffuser cette culture dans toute l'organisation. Combien cela durera est extrêmement difficile à évaluer. Mais, d'après mon expérience, si la nouvelle approche couvrait 30% de l'entreprise, elle commence à se propager davantage et n'a plus besoin d'être protégée d'en haut.

La mise en œuvre de Scrum nécessite généralement de grands changements, à la fois dans la structure de l'organisation et dans les contrats avec les contractants (vous avez besoin d'un contrat de temps et de matériel ), et dans la budgétisation (budgétisation progressive), et tout le reste.



Kanban n'exige pas un changement aussi radical. Il propose: "Commencez par ce qui est et commencez à l'améliorer évolutivement." Le taux de changement sera nettement inférieur à celui de Scrum, mais tous les changements seront basés sur des statistiques et auront une justification claire.

Mythe 8. Scrum est conçu uniquement pour les projets créés à partir de zéro.

Il existe différents cas, il n'y a pas de règle rigide selon laquelle Scrum est uniquement destiné au développement à partir de zéro. Le transfert de projets existants vers Scrum est non seulement possible, mais souvent approprié. Tout dépend de la volonté des interprètes et des clients de restructurer leur travail afin d'accélérer le développement. S'ils sont prêts, tout est réalisable.

Par exemple, l'un des créateurs de Scrum, Jeff Sutherland, dans son livre Scrum: The Art of Doing Twice the Work in Half the Time, a expliqué comment il avait utilisé Scrum pour développer un système comptable automatisé du FBI. Quand il a commencé le projet, le développement s'est poursuivi pour la quatrième année, aucune fonction n'a été apportée à la sortie, et ni la fin ni le bord du projet n'étaient visibles. Jeff a pu accélérer radicalement le développement et le rendre transparent pour les clients. Six mois plus tard, la première version de travail du produit a été lancée et, en deux ans, le développement a été achevé avec succès.

Mythe 9. Lors de l'introduction de méthodologies flexibles, les conflits avec les représentants de la hiérarchie traditionnelle sont inévitables

Si tout est fait correctement - pour séparer l'équipe de la hiérarchie traditionnelle, donner le budget au propriétaire du produit et embaucher un Scrum-master vraiment qualifié, il n'y aura pas de conflits. Mais cela ne se produit pas toujours. Il est souvent impossible de combiner ces deux structures, il n'y a donc qu'une seule issue: construire une nouvelle structure, affûtée pour une prise de décision et une mise en œuvre rapides du produit.

Et à propos de qui un tel Scrum-master, vous apprendrez dans la prochaine série. Attendez dans la deuxième partie de l'histoire de Vasily sur la mise en œuvre de méthodologies de développement flexibles: les difficultés, les avantages, les pièges et les bombes à retardement.

UPD Et voici la suite: il s'agit d'Agile - 2: caractéristiques de la mise en œuvre du développement agile

Il n'y a pas de temps pour expliquer, le matériel a été préparé de manière désintéressée et amoureuse par l'équipe Mail.Ru Cloud Solutions .