Résumé: Cet article prend comme exemple un produit clé d'une société leader dans le secteur des valeurs mobilières pour discuter du résumé de la pratique d'une mise en œuvre agile et à grande échelle basée sur les caractéristiques de l'industrie tout en s'écartant du cadre existant.
Lorsqu'il s'agit d'échelle et d'agilité, les gens pensent généralement immédiatement à divers cadres traditionnels sur le marché. Il est vrai que lorsque le cadre existant peut être mieux intégré au statu quo de l'entreprise, la mise en œuvre basée sur le cadre permettra d'économiser du temps et des efforts.
Cependant, en pratique, nous rencontrons souvent des situations où la situation d'une entreprise est en constante évolution, souvent loin des hypothèses du cadre, et parfois l'application du cadre existant est coûteuse, et produit même l'effet de couper les pieds et de s'adapter à la performance. Cet article prend un produit clé d'une société leader dans le secteur des valeurs mobilières comme exemple pour discuter du résumé pratique d'une mise en œuvre à grande échelle et agile basée sur les caractéristiques du secteur tout en s'écartant du cadre existant.
01 Échelle et agilité à nos yeux
Comment se renforcer dans la recherche et le développement de produits pour saisir rapidement les opportunités du marché, les transformer en avantages commerciaux et continuer à le faire est un problème que de nombreuses grandes entreprises doivent résoudre. Plus précisément, dans le développement de produits complexes,
-Comment fédérer plusieurs équipes agiles avec un objectif commun?
-Comment collaborent plusieurs équipes agiles?
-Comment lancer de nouvelles fonctionnalités produit rapidement et en continu?
-Comment contrôler la complexité de la collaboration pour réduire les coûts de gestion et réduire les goulots d'étranglement du système?
-Comment maintenir la transparence, rendre visible le processus de développement des produits, afin que les risques et les obstacles soient facilement révélés et supprimés?
-Comment évoluer pour s'adapter aux changements de l'environnement?
À notre avis, l'essence de l'agilité à l'échelle est d'appliquer des idées et des pratiques lean et agiles pour trouver des solutions à ces problèmes.
02Regarder une pratique agile à l'échelle à partir de cinq capacités de base
Il peut y avoir d'innombrables perspectives d'analyse pour une flexibilité d'échelle. Nous pensons que, du point de vue des pratiques spécifiques, l'agilité à grande échelle dépend le plus de cinq capacités de base:
Alignement des objectifs, rythme, synchronisation, découplage des dépendances, amélioration continue
Nous pouvons dériver et faire évoluer des pratiques basées sur ces capacités de base, afin que les organisations puissent travailler ensemble et réagir rapidement. Cette section prendra un produit clé comme exemple pour présenter comment aider le développement de produit dans la pratique sur la base de ces cinq capacités de base.
Figure 1 Cinq compétences de base de Scale Agile
La figure suivante montre le contexte du produit. Dans l'ellipse à deux couches de l'extérieur vers l'intérieur, la couche externe représente le portefeuille auquel appartient le produit et la couche interne représente la gamme de produits de ce texte. Le produit contient plusieurs applications relativement indépendantes et chaque application a un Scrum Master (SM) et un Product Owner (PO). Les deux applications de la figure sont à titre d'illustration. Chaque application crée une équipe basée sur la méthode Scrum, et chaque application comprend plusieurs équipes Scrum fixes à plein temps.
Il convient de noter que les applications incluses dans ce produit dépendent souvent en même temps d'autres produits du portefeuille, ce qui forme une relation d'interdépendance complexe et constitue une contrainte clé pour les activités de développement de produits.
Remarque: le "Scrum Master" (SM) et le "Product Owner" (PO) mentionnés ci-dessous sont tous des rôles au niveau de l'application, et ils sont généralement responsables de plusieurs équipes Scrum.
Figure 2 Portée du produit et principales activités
(Réunion de collaboration produit: chaque PO d'application dirige et collabore pour définir les priorités
Planification de la réunion de collaboration: SM domine chaque application, planifiant l'itération suivante et passant en revue l'itération précédente
Point d'alignement d'interface, déterminez l'interface entre les produits dépendants avant le début de l'itération)
2.1 Alignement de la cible
Vous avez probablement entendu cette histoire:
Trois maçons s'affairent sur le chantier. Un passant a demandé, que fais-tu? Le premier tailleur de pierre a dit, je pose des murs. Le second a dit, je gagne de l'argent pour subvenir aux besoins de ma famille. Le troisième a dit que je construis une cathédrale.
Les gens admirent souvent la disposition du troisième maçon, mais le premier maçon peut être trop «d'ailleurs» sous-estimé. En effet, nous devrions avoir la cathédrale que nous construisons dans nos cœurs, c'est là que réside notre mission. Cependant, le mur à construire maintenant doit-il être au centre de l'attention?
Du point de vue de l'alignement des objectifs, nous devons nous baser sur des objectifs commerciaux à long terme, mais nous devons être en mesure de:
- Décomposer les objectifs à long terme en petits objectifs à court terme,
- Aligner les "petits objectifs" des personnes concernées et de l'équipe,
- Alignez les équipes concernées dans le processus de réalisation de petits objectifs.
Les grands objectifs à long terme nous donnent une direction, les petits objectifs à court terme nous permettent de nous concentrer. L'alignement des grands et petits objectifs nous permet de travailler dur ensemble avant de pouvoir continuer à livrer rapidement.
L'alignement cible du produit est motivé par les trois activités clés suivantes.
Figure 3 Trois activités clés conduisent à l'alignement des objectifs du produit
Conférence sur la collaboration produit et ses activités pilotes
Sur la base de la valeur commerciale et en tenant compte de l'interdépendance, chaque bon de commande du produit est co-créé pour le fractionnement de la demande et la priorisation (décision commerciale si nécessaire). La collaboration produit produira une liste des exigences prévues pour la prochaine itération.
La collaboration produit sera une combinaison d'activités hors ligne et en ligne, et la plupart des travaux de fond auront lieu avant la réunion. Avant la réunion, les OP doivent analyser leurs besoins en profondeur et communiquer pleinement avec les parties liées; la réunion est davantage un point de contrôle pour vérifier et pourvoir les postes vacants.
Tableau 1 Réunion de collaboration produit
(Remarque: chaque itération prend deux semaines; W: la première semaine de l'itération en cours; W + 1: la deuxième semaine de l'itération en cours; W-1: la semaine avant le début de l'itération ... autre analogie.)
Planification de la réunion de collaboration et ses principales activités
Sur la base du résultat de la réunion de collaboration produit, la planification de collaboration SM de chaque application du produit. (Comme mentionné précédemment, "SM" est une application Scrum Master, et il peut y avoir plusieurs équipes Scrum derrière.)
La planification de la collaboration consiste essentiellement à extraire le travail de planification au niveau du produit des réunions de planification Scrum traditionnelles (l'équipe Scrum établira alors des plans détaillés lors de la réunion de planification d'itération).
À l'instar de la réunion de collaboration produit, la plupart des travaux de planification de fond se produisent également dans la communication hors ligne avant la réunion.
Tableau 2 Réunion de coopération de projet
Point d'alignement d'interface
Sur la base du résultat de la réunion de collaboration planifiée, chaque architecture de produit définit des interfaces interdépendantes; avant le début de l'itération (semaine W-1), déterminez les interfaces d'application interdépendantes. Cette activité est un suivi de la réunion de planification de l'itération et le prélude au travail de débogage conjoint dans l'itération.
Tableau 3 Points d'alignement de l'interface
On peut voir que le mécanisme d'alignement de ce produit combine une petite quantité d'activités de routine et une grande quantité de communication hors ligne: la collaboration produit sera similaire à la collaboration planifiée, les réunions sont utilisées comme points d'alignement, mais la plupart du travail de fond se déroule hors ligne; les points d'alignement d'interface sont plus Il n'existe que comme point de contrôle. Ceci est évidemment différent des cadres agiles courants: par exemple, SAFe et LeSS mettent l'accent sur des activités de planification collective à grande échelle à des degrés divers.
Il y a deux raisons derrière cette différence: Premièrement, le portefeuille du produit est un cluster de plusieurs produits connexes, et plusieurs flux de valeur sont entrelacés; de nombreuses applications dont le produit dépend servent d'autres produits du portefeuille en même temps. , Ce qui est très différent de la seule solution dans les scénarios typiques de SAFe ou LeSS. Deuxièmement, les employés partenaires (sous-traitance) qui sont largement utilisés dans le développement de produits ne sont actuellement pas profondément impliqués dans les activités de demande précoce.
Dans ce scénario complexe, une planification collective à grande échelle est difficile à garantir l'efficacité. En revanche, la méthode d'alignement adoptée par ce produit est basée sur une méthode de planification décentralisée et progressive, et est limitée par des points de contrôle centralisés, qui ont une valeur de référence pour des situations similaires.
2.2 Rythme et synchronisation
Si vous avez participé à une compétition de tir à la corde, vous savez probablement que la personne qui se tient à côté de crier détermine en grande partie le résultat du match. Crier est en fait le contrôle du rythme. Utiliser un rythme stable pour créer des ondes de choc dans le jeu est une astuce pour gagner.
La dépendance au rythme du développement de logiciels à grande échelle est également comme un bras de fer. Tous les produits associés coopèrent entre eux selon un rythme itératif fixe, et les activités importantes sont prévisibles et gérables, de manière à former une synergie entre les équipes et à éviter le chaos et le désordre.
La synchronisation se produit au rythme, y compris les activités formelles et informelles, sur la base du partage d'informations pour promouvoir la coopération, et sous le principe de l'alignement des objectifs, les gens ont la possibilité de peser les compromis dans leur ensemble.
Les applications du portefeuille des produits décrits dans cet article partagent le même rythme itératif en deux semaines. Pour les produits hautement connectés, un tel rythme unifié est propice à l'alignement des cibles.
Au moment de la rédaction de cet article, le rythme d'itération et les principales activités sont indiqués dans la figure ci-dessous.
- La "co-création de priorités inter-produits" a 2 cycles d'avance sur l'itération de développement. Son activité principale est le "Product Collaboration Meeting" mentionné ci-dessus, qui sert de déclencheur pour la recherche et le développement.
- «Le peignage des exigences et la planification d'itérations croisées» fournit une entrée directe pour les itérations de développement, y compris les activités de communication des exigences, les activités de synchronisation d'interface, ainsi que l'analyse et la conception des exigences. Ces activités sont un cycle avant l'itération de développement.
- «L'itération de développement» est la principale étape de création de valeur. Dans l'itération de développement, il existe des points de contrôle de débogage conjoints, qui indiquent l'heure de début de contrôle du débogage conjoint intersystème; et les points de contrôle de test indiquent l'heure de début de contrôle de la soumission des tests système, qui sont légèrement différentes pour différentes équipes.
Figure 4 Rythme itératif et activités de synchronisation
Le même rythme fournit un rythme cardiaque fiable pour l'alignement des cibles multi-produits et la collaboration en R&D, et constitue la base d'une livraison stable.
Limitée par la situation actuelle du personnel, la conception du rythme actuelle est encore un peu compliquée: une partie considérable du développement et des tests du produit est réalisée par le partenaire, et la forte mobilité des employés du partenaire rend difficile la formation de l'accumulation, ce qui conduit à davantage de besoins de contrôle et de réponses correspondantes Process link-here, nous devons continuer à explorer le mécanisme simplifié.
2.3 Découplage des dépendances
Dans les scénarios à grande échelle, la dépendance entre les équipes est souvent un tueur d'efficacité. Le «découplage des dépendances» consiste à appliquer diverses méthodes pour réduire et contrôler les dépendances afin que le travail de l'équipe soit le plus indépendant possible. Certaines personnes croient même que l'essence de l'agilité à l'échelle est la «réduction d'échelle», ce qui signifie réduire la complexité de la collaboration organisationnelle grâce au découplage entre les organisations de R&D. Un découplage organisationnel complet peut ne pas être réalisable ou optimal. Le meilleur point d'entrée-sortie de découplage doit être progressivement approché par l'exploration. Les tentatives typiques utilisées par ce produit incluent le découplage à long terme des capacités commerciales de base et des mécanismes passagers à court terme.
Renforcement des capacités de base des entreprises
Les capacités commerciales de base sont incarnées sous forme de services publics partagés par plusieurs applications. L'extraction des capacités métier de base est une tentative de réduire la complexité du système, la clé ici est d'éviter que les services publics ne deviennent dépendants du développement des entreprises.
Le devoir absolu du service informatique est de répondre aux besoins de l'entreprise rapidement et avec une grande qualité. Cependant, en raison de ressources limitées, les capacités de réponse à court et à long terme sont une contradiction. À court terme, nous devons répondre aux demandes commerciales le plus rapidement possible avec toute notre main-d'œuvre; à long terme, nous devons réserver de la main-d'œuvre pour le renforcement des capacités commerciales de base, car un soutien mature des capacités commerciales de base peut rendre le développement des fonctions d'application plus efficace. (Remarque: cette pratique nécessite de la prudence. Si la capacité commerciale de base ne peut pas atteindre une indépendance élevée, elle est susceptible de produire des effets contre-productifs.)
Dans le développement de ce produit, nous avons adopté l'idée de la construction progressive des capacités commerciales de base.
Comme le montre la figure ci-dessous: En tant que vision, les capacités commerciales de base attendues et le développement de produits d'application devraient être découplés, et le développement des capacités commerciales de base devrait avoir une vision prospective et une maturité appropriées, se concentrer sur les services publics et soutenir le développement d'applications.
Cependant, les capacités métier de base actuelles incluent également la partie «service spécifique à l'application», dont le contenu est toujours étroitement lié à des applications spécifiques.
Afin d'assurer la vitesse de réponse de l'entreprise, la partie «service spécifique à l'application» doit suivre de près le rythme du développement des applications; dans le même temps, les développeurs concernés doivent maintenir une coopération étroite avec les capacités de base de l'entreprise (en particulier les architectes), et sont soumis à l'infrastructure et aux règles des capacités de l'entreprise. Restrictions pour préparer la plate-forme des fonctions associées.
À long terme, avec l'amélioration des capacités commerciales de base, les fonctions logicielles de la partie "services spécifiques aux applications" devraient être différenciées dans les directions supérieure et inférieure - partie des services généraux des capacités commerciales de base, et une partie d'entre elles sera intégrée dans le développement des besoins commerciaux.
Figure 5 Équilibre des fonctions d'application et développement des capacités métier de base
Mécanisme passager
Les équipes agiles doivent être basées sur une organisation basée sur la valeur. Dans le même temps, les équipes agiles devraient également rester stables. Cependant, ces deux principes sont parfois en conflit. Que faire en cas de conflit? Nous nous basons ici sur le concept de passagers dans LeSS (en se référant plutôt qu'en empruntant, les passagers dans LeSS sont plus enclins à responsabiliser l'équipe cible, et l'objectif principal des passagers ici est la livraison à la demande).
S'il y a un travail de développement d'application plus spécifique pour la capacité métier de base dans une certaine itération, l'ingénieur R&D de l'équipe de capacité métier de base peut temporairement rejoindre l'application en tant que «passager» et travailler selon la priorité d'application. Les effets de cette approche sont:
Premièrement, réduire le degré de couplage entre les équipes, réduisant ainsi la complexité de la coordination (la communication inter-équipes se transforme en communication intra-équipe).
Deuxièmement, équilibrez le développement des capacités commerciales de base avec le développement des exigences des applications. Entre les deux, le système de passagers haut et bas offre de la flexibilité.
3. Promouvoir une coopération étroite entre les capacités métier de base et les applications métier, et maintenir le développement des capacités métier de base sensible.
Bien sûr, le mécanisme du passager n'est qu'une tentative possible, loin d'être une solution miracle. Dans cette situation où plusieurs flux de valeur sont entrelacés, nous devons trouver un équilibre entre «éliminer la dépendance» et «gérer la dépendance».
2.4 Amélioration continue
Évolution du style de travail
Sur la base de la compréhension de concepts lean et agiles et du retour d'expérience de la pratique, les pratiques de développement de produits sont constamment ajustées et adaptées.
Dans différents domaines, les principales activités porteuses du mécanisme d'amélioration continue comprennent:
(1) Réunion de revue des itérations de l'équipe Scrum
Il s'agit d'une activité d'inspection et d'ajustement de base dérivée du cadre Scrum classique.
(2) Réunion régulière SoS dans l'application
L'exemple SoS de l'application a deux fonctions: l'une est la synchronisation du travail quotidien, et l'autre est l'examen et l'amélioration en temps opportun des problèmes dans le processus de développement. Les améliorations résultant de cet examen opportun seront enregistrées dans le Wiki, et les résultats seront vérifiés lors de la prochaine réunion. Chaque rétrospective met l'accent sur la découverte ascendante des problèmes et la direction s'engage à aider l'équipe à résoudre les problèmes.
(3) Réunion de collaboration itérative de la gamme de produits
Cette activité a été présentée dans la section "Alignement des cibles" ci-dessus. Je ne la répéterai donc pas ici.
Bénéficie de pratiques agiles à grande échelle
(1) Dans le scénario à grande échelle, il est particulièrement nécessaire d'éviter que chaque équipe se batte séparément. La conception du mécanisme d'alignement de ce produit est basée sur la co-création prioritaire de plusieurs applications. Chaque application collabore pour produire une liste de fonctions à compléter à chaque itération et des objectifs commerciaux à prendre en charge, de sorte que chaque application ait le même objectif reconnu, qui devient la collaboration entre les applications. Fondation solide.
(2) Le rythme unifié de plusieurs applications fournit un cadre de processus fiable pour chaque événement du développement de produit. Le même rythme facilite les activités de synchronisation décentralisées, et les points de contrôle de routine (centralisés) et les outils de soutien (Wiki, Jira) sont utilisés pour améliorer la transparence et garantir la qualité des activités décentralisées. Cela simplifie la communication et la collaboration tout en exposant et en éliminant efficacement les obstacles dans l'exécution itérative.
(3) Le double cycle itératif de demande et de réalisation (complété par des processus, des rôles et des responsabilités clairs) rend les activités de recherche de demandes rigoureuses et ordonnées, et la planification des produits et la réalisation de la demande se chevauchent et avancent régulièrement.
03 Principaux défis actuels et exploration en cours
Dans la situation de flux de valeur multiples, la direction d'évolution de l'échelle
Comme mentionné ci-dessus, le portefeuille de ce produit est confronté à un scénario complexe où plusieurs produits coexistent et dépendent les uns des autres, et de multiples flux de valeur sont entrelacés. Dans ces circonstances, le cadre à grande échelle existant ne peut pas fournir une solution systématique et il faut explorer sa propre voie. Notre exploration en cours est basée sur la prise en compte des points clés suivants:
Tout d'abord, l'alignement des cibles multi-produits. Dans le cadre du portefeuille d'investissement, le réseau formé par plusieurs produits est considéré comme un réseau de flux de valeur dans son ensemble, qui a des objectifs commerciaux communs. Une direction sur laquelle nous travaillons est: basée sur la co-création prioritaire de plusieurs applications, et soutenir la stratégie organisationnelle à long terme avec une feuille de route (alignement des objectifs à long terme), afin que plusieurs applications puissent concentrer leurs forces, collaborer dans la même version et se soutenir ensemble Besoins métiers à travers les produits (alignement des objectifs à court terme).
Deuxièmement, la collaboration décentralisée. Plus le réseau de chaînes de valeur est vaste et complexe, plus les activités et décisions collectives à grande échelle sont coûteuses et plus nous devons nous appuyer sur une collaboration décentralisée. Nous nous appuyons sur des collaborateurs exceptionnels pour mener à bien leurs réalisations respectives avec une grande autonomie et une grande qualité, et nous nous appuyons davantage sur leur étroite collaboration et leur soutien mutuel avec les partenaires.
Troisièmement, la transparence . Dans le scénario décentralisé, nous avons besoin d'une conception de mesure efficace pour former une vue d'ensemble du processus et de la mesure, afin d'être en mesure d'exposer la nécessité de prêter attention aux problèmes de développement et aux problèmes systémiques. De cette manière, nous avons la possibilité de supprimer les obstacles au processus de développement des exigences et d'éviter le chaos lors de la décentralisation.
Support "Big Need": un défi spécifique
La «grande demande» qui affecte plusieurs produits du portefeuille n'a pas encore été pleinement intégrée au mécanisme d'alignement et au rythme d'itération: à l'heure actuelle, une forte demande est souvent basée sur une planification indépendante et une acceptation ponctuelle à un moment de livraison fixe, fonctionnant en dehors du rythme itératif.
À cet égard, nous essayons de démonter la grande demande de la manière «MVP + incrément», et sur cette base, de renforcer le mécanisme d'alignement au sein du portefeuille, d'amener le développement de la grande demande dans le même rythme itératif et de fournir l'ensemble à travers le Kanban visuel en conséquence vue.
Figure 6 Schéma de principe de la méthode de fractionnement MVP pour une forte demande
Enfin
L'exploration à grande échelle et agile de ce cas est entrée dans la zone des eaux profondes. Bien que nous nous engageons à explorer les solutions à ces problèmes profonds, nous espérons que ces explorations dans le développement de ce produit pourront être une valeur de référence pour vous, et nous sommes également invités à discuter de la pratique du développement agile à grande échelle avec nous.
Bienvenue sur le forum de discussion.