Get best of the week

Méthode Kanban: comprendre votre processus comme un processus d'apprentissage collectif

Préface


Dans la communauté professionnelle russophone des gestionnaires de processus, il existe très peu de littérature sur la méthode Kanban en russe. Nous avons décidé de corriger cette injustice et nous publierons les articles les plus significatifs de notre point de vue en russe, qui ont influencé le développement de la méthode.

Comprendre votre processus comme un processus d'apprentissage collectif


Et le premier article de la série sur la façon de construire plus efficacement une visualisation de vos processus de travail et de percevoir un tableau. L'auteur de l'article original est Alexei Zheglov et peut être trouvé ici

Il y a une tendance générale et un désir de rendre le travail plus collectif. Cependant, lorsque je demande aux gens du bureau de dessiner un processus de leur travail, ils fournissent souvent quelque chose comme ça (je simplifie):


Dans cette perspective, les travailleurs forment une bande transporteuse, mais leur travail ne ressemble pas vraiment à une chaîne de montage. Par exemple, un développeur de logiciels peut détecter une incohérence logique dans la spécification des exigences et renvoyer le travail à Business Intelligence. Un ingénieur qualité (AQ) peut faire de même lors des tests de logiciels créés. L'analyste mettra à jour la spécification et renverra la tâche à QA. QA peut y trouver une erreur et la renvoyer au développeur. Un spécialiste de l'implémentation peut trouver quelque chose dans le code qui empêche la livraison. Ensuite, le développeur apporte les modifications nécessaires. Maintenant, le code doit être re-testé, donc il revient à QA, après quoi il revient à l'implémentation.

Une telle interaction se produit non seulement entre les membres individuels de l'équipe, mais aussi (ce qui est important) entre les départements d'entreprise, les services et les équipes interfonctionnelles. Par conséquent, les gens dessinent beaucoup de flèches connectées dans différentes configurations pour afficher tous ces programmes.

Certains tentent de visualiser ce processus sur un tableau qu'ils appellent "kanban":


Ensuite, ils se demandent: que faire si, par exemple, le testeur retourne l'élément de travail à l'analyste ou au développeur? La carte doit-elle rester en place ou bouger? Et si nous avons une limite WIP (ces chiffres sont dans les en-têtes de colonne)? Et si cette colonne est déjà remplie à la limite, une autre carte devrait revenir en arrière?

Y a-t-il une meilleure façon?


Cette question est assez courante et trouve son origine dans une mauvaise compréhension de la nature du travail de service professionnel. Au lieu d'une série de transmissions entre métiers spécialisés, il s'agit principalement de créer des informations et d'accumuler des connaissances. Cela devient un obstacle lorsque vous essayez de faire ressembler le processus à un organigramme. Ainsi qu'une limitation lors de la tentative de visualisation, suite à l'exécution du travail.

Dans l'exemple de la fourniture de nouvelles fonctionnalités d'un produit logiciel, les connaissances suivantes peuvent être créées (pas nécessairement dans cet ordre):

  • configuration exacte de l'environnement de travail (OS, serveur Web, serveur de base de données, logiciel tiers)
  • exemples clés du comportement des fonctionnalités développées, cas d'utilisation, critères d'acceptation, spécifications exécutables, etc.
  • ( , . .)
  • -
  • : , , ..
  •   , .

Chacun dans n'importe quel service professionnel peut proposer sa propre liste de connaissances qu'il crée dans son processus de livraison. Lorsque le travail est terminé, toutes ces connaissances existent déjà, mais lorsque nous commençons à peine à travailler sur les besoins du client ou la demande de fourniture de quelque chose, tout cela manque.

Si nous essayions de visualiser le processus d'accumulation de ces connaissances, le résultat pourrait ressembler à ceci:


Dans cet exemple, le travail de spécification est dominant à un stade précoce du processus de livraison. Les analystes commerciaux peuvent effectuer une analyse fonctionnelle, une décomposition et un raffinement des exigences. Mais en même temps, d'autres professionnels peuvent contribuer. Les testeurs peuvent aider à transformer les critères d'acceptation en tests exécutables. Les spécialistes du déploiement et les développeurs peuvent évaluer l'impact sur la base de code et l'infrastructure.

Cette activité génère beaucoup de connaissances au tout début, mais à la fin elle s'estompe. Nous ne pouvons pas analyser sans fin jusqu'à la livraison. Ainsi, le développement du code à un moment donné devient le principal moyen d'accumuler des connaissances.

Bien sûr, la majeure partie du développement du code tombe sur les épaules des développeurs, mais d'autres peuvent aussi aider. Les exigences peuvent encore nécessiter des clarifications et des clarifications (bonjour analyste). Le testeur peut prendre un logiciel partiellement prêt à l'emploi, le tester et donner des commentaires au développeur. Les développeurs peuvent collaborer avec des spécialistes de la mise en œuvre pour voir comment les changements émergents auront un impact sur le déploiement.

Mais cette activité s'estompera. Nous ne pouvons pas progresser davantage en polissant le code. Nous passons donc au test.et se concentrer sur la résolution des erreurs restantes. Une autre activité dans l'étude des connaissances commence à dominer. Les testeurs en sont responsables, mais ils ont besoin de l'aide des développeurs, des corrections de bugs, ainsi que d'autres spécialistes.

Notez que les trois points de basculement dans le nouveau diagramme de processus ne sont pas des transferts entre spécialistes fonctionnels ou départements. Ce sont des changements dans l'activité dominante et des changements correspondants dans le schéma d'interaction.

Conclusion


Nous n'avons pas besoin de considérer les processus comme un réseau de spécialistes et le transfert d'autorité. Lorsque nous essayons de visualiser visuellement nos processus, nous n'avons pas besoin de les représenter sous la forme de blocs représentant des spécialistes, et de nombreuses flèches les reliant dans toutes les directions.

Au lieu de cela, nous pouvons voir notre processus de livraison comme l'obtention d'informations et la création de connaissances. En nous posant la question, quelles actions effectuons-nous pour accumuler des connaissances afin de livrer ce que nous livrons , nous pouvons visualiser notre processus comme une séquence d'actions conjointes.

Et après?


Dans les prochains articles, je voudrais donner des exemples de la réflexion du processus d'accumulation de connaissances, pour des processus en dehors du monde du développement logiciel.

Je dois préparer un certain nombre d'articles, sous forme de recommandations: comment un spécialiste des processus peut composer une réflexion sur les processus avec des équipes de services professionnels . Pour ceux qui utilisent des systèmes Kanban, cette approche présente plusieurs avantages dans la conception et le fonctionnement de ces systèmes.

Un grand merci à Aleksey Pimenov etStepev.

More articles:


All Articles