Finition
Envisagez-vous d’implémenter Kanban dans vos processus métier ? Voici par où commencer. Système Kanban : qu'est-ce que c'est, par où commencer, comment le mettre en œuvre, grands principes

Envisagez-vous d’implémenter Kanban dans vos processus métier ? Voici par où commencer. Système Kanban : qu'est-ce que c'est, par où commencer, comment le mettre en œuvre, grands principes

Le plus brièvement possible sur la méthode Kanban, ses termes de base et ses domaines d'application.

Nous avons décrit la méthode Kanban, ses termes de base et ses domaines d'application aussi brièvement que possible.

1. Qu'est-ce que la méthode Kanban ?

La méthode Kanban est une méthode pour améliorer votre travail. Quoi que vous fassiez, l’hypothèse est que pratiquer la méthode Kanban vous permettra de faire encore mieux votre travail. D'un point de vue Kanban, cela signifie que vous répondrez mieux aux attentes des clients.

Kanban en tant qu'outil de gestion informatique a été introduit par David J. Anderson chez Microsoft (2005) et Corbis. Et la méthode s'est généralisée et nommée en 2007.

2. La méthode Kanban et Toyota Kanban sont-ils la même chose ?

(La plus grande carte). Pas certainement de cette façon. Kanban dans les usines Toyota est une fabrication au plus juste, dont le principe déterminant est le concept de « juste à temps ». Kanban, en tant que terme de gestion, vient en réalité de Toyota. Traduit du japonais, ce mot signifie « signal » ou « carte ». Dans les usines automobiles, ces cartes étaient utilisées pour transmettre des informations d'une étape à l'autre sur le nombre et les pièces nécessaires.

Regardons un court exemple. Nous devons fabriquer trois voitures « juste à temps ». Cela signifie que nous pouvons déterminer avec précision à l'avance le nombre de pièces dont nous aurons besoin à certaines étapes, et nous commençons dès la fin à extraire le nombre de pièces requis pour créer cette voiture, en répondant aux questions : « Combien de litres de peinture allons-nous avez-vous besoin ? », « Combien de roues ? », « Combien de moteurs ? » et ainsi de suite. Ainsi, nous ne créons pas de pièces de rechange excédentaires sous forme de restes et économisons sur les entrepôts, la logistique et autres coûts.

La méthode Kanban adhère également au concept du « juste à temps », mais contrairement aux usines Toyota, on parle ici de travail intellectuel. En d’autres termes, le code d’un programmeur ou l’idée d’un spécialiste du marketing ne peut être touché ni vu par la personne moyenne jusqu’à ce qu’il se transforme en produit ou service final. Ainsi, la méthode Kanban permet de visualiser le flux du travail intellectuel et de réduire la quantité de ce travail inachevé. De ce fait, une vitesse de fourniture de services uniforme et prévisible au consommateur final est obtenue.

3. La méthode Kanban peut-elle être utilisée en dehors de l’informatique ?

Oui. La méthode Kanban convient pour visualiser le flux de tout travail créatif et intellectuel. Mais il est bien plus efficace de l’utiliser à travers le prisme du paradigme du service. Regardez ce que vous faites en tant que service. Par quelles étapes passent les travaux pour que le service soit rendu ? Selon quels critères comprendrez-vous que la prestation est fournie conformément aux attentes du Client ? C'est le point de départ pour utiliser la méthode Kanban. Les praticiens du Kanban appellent ce point « commencez par ce que vous avez maintenant ».

4. Kanban est-il comme Scrum ?

Non. Scrum est un cadre avec des règles et des limites strictes. Vous pouvez utiliser différents outils et méthodologies au sein de Scrum, mais si vous abandonnez quelque chose requis dans Scrum, cela ne peut plus être considéré comme Scrum. Kanban est une méthode, un outil avec un ensemble de pratiques et de principes. Vous pouvez utiliser toutes les pratiques, certaines pratiques, ou ne pas les utiliser du tout. Dans Kanban, il n'y a pas de concept strict de ce qui est Kanban et de ce qui ne l'est pas. Cependant, une utilisation judicieuse des pratiques peut considérablement vous aider à fournir un service de la plus haute qualité et à répondre aux attentes des clients.

5. Kanban a-t-il des valeurs ?

Oui. Il y en a neuf : transparence, équilibre, collaboration, orientation client, fluidité, leadership, compréhension, accord, respect.

6. Vous avez écrit sur les principes de Kanban. Quels sont-ils?

Kanban a des principes de base, également appelés principes de gestion du changement :

Commencez avec ce que vous avez maintenant.
D'accord sur le développement évolutif.
Encourager le développement du leadership à tous les niveaux.

Puisque la méthode Kanban s’inscrit dans un paradigme de service, elle adhère à ses principes :

Découvrez les besoins et les attentes du client.
Gérez le travail, laissez les gens s'organiser autour de lui.
Élaborer des règles pour améliorer les performances.

7. Quelles sont les pratiques en Kanban ?

Il y en a également six :

Visualiser.
Limitez le travail inachevé.
Gérer le flux de travail.
Utilisez des règles explicites.
Introduire des boucles de rétroaction (cadences).
Améliorer et évoluer.

Ce sont des techniques directement pratiques que nous utilisons pour améliorer notre travail et améliorer la qualité de service.

8. Oh, cadences ! Que sont les cadences dans Kanban ?

La cadence est un terme issu de la musique. Dans le cadre de la méthode Kanban, cela désigne le rythme. Les cadences sont des réunions régulières qui sont aussi des boucles de rétroaction. La régularité donne le rythme avec lequel le flux de travail s'écoule. Sept cadences :

Réunion Kanban (quotidiennement). Nous discutons ici du statut des tâches bloquées.
Réunion de remplissage des files d'attente (généralement toutes les deux semaines). Nous assumons la responsabilité de ce que nous ferons en tant que service.
Réunion de planification des livraisons (généralement toutes les deux semaines). Nous rendons les obligations remplies.
Réunion d'examen du service (généralement toutes les deux semaines). À l’aide de métriques, nous discutons de la qualité du service et de la manière de l’améliorer, si nécessaire.
Réunion des opérations (généralement une fois par mois). Nous discutons de la qualité de l'interaction des services associés avec les métriques.
Réunion d'examen des risques (généralement une fois par mois). Nous discutons avec les métriques de l'impact des tâches bloquées sur le fonctionnement du service.
Réunion de revue de la stratégie (généralement trimestrielle). Nous discutons des changements de stratégie avec des métriques.

9. J'ai entendu quelque chose à propos des cours de service. Qu'est-ce que c'est?

Kanban utilise des classes de service pour prioriser certains types de travaux, certains clients, ou atténuer les impacts commerciaux tels que le coût des retards. Le coût du retard correspond à la perte de profit ou aux coûts encourus en raison d'une livraison tardive des services. Examinons l'impact des coûts de retard et la classe de service correspondante à l'aide d'exemples :

Cours accéléré – premiers secours-réanimation d’urgence. Conduire sur une voie dédiée. Il n’y a pas de temps à perdre pour résoudre le problème. J'en ai besoin dès que possible.
Classe à date fixe – Les coûts de retard augmentent considérablement après une certaine période. Exemple : un projet sous forme de loi fédérale avec une date de démarrage fixe. Si nous n'arrivons pas à temps, nous risquons de perdre notre licence.
Classe standard - le coût du retard augmente proportionnellement au temps. Si nous le faisons tout de suite, nous obtenons immédiatement des bénéfices. Si nous le faisons pendant longtemps, nous obtenons des bénéfices pendant longtemps.
Classe intangible - nous le faisons, mais ce travail n'apporte aucun profit évident, le coût du retard augmente lentement. Par exemple, nettoyer la maison. Vous n’êtes pas obligé de nettoyer régulièrement, mais après six mois, vous devrez effectuer un nettoyage en profondeur.

10. Qu'en est-il des métriques ? Comment mesurer l’efficacité d’un service ?

La méthode Kanban dispose de métriques qui vous permettent de répondre aux questions : quels sont les problèmes dans le flux de travail, quel est le débit du service, quel est le temps d'exécution, quel est le temps de résolution des verrous, quel est le temps de cycle et quoi types de travaux sont-ils distribués ? Tout cela permet au responsable du service de prendre des décisions sur le développement et l'amélioration de la qualité du service sur la base des données accumulées.

11. À quels défis Kanban est-il confronté lors de la mise en œuvre ?

Le principal défi est d'expliquer aux personnes à tous les niveaux l'intérêt des pratiques Kanban : visualisation et limitation des travaux en cours. Du fait que les gens ne voient pas le volume de travail intellectuel, il leur est difficile de comprendre la charge à laquelle ils sont exposés. Mais le cerveau, par exemple, est le même muscle que le biceps. Imaginez une salle de sport : vous entrez et voyez le poids sur la barre : « Bon, c'est trop peu. Et maintenant c'est trop. Mais c’est juste ! Vous devez travailler avec le cerveau de la même manière : « Celle-ci est une grande tâche, et celle-ci est une petite, et en général, d'une manière ou d'une autre, j'en ai entrepris beaucoup. Je vais limiter la charge. Lorsque nous visualisons le flux de travail de bout en bout à tous les niveaux et limitons la quantité de travail en cours, nous créons un principe d'attraction pour le travail de connaissance et effectuons un flux uniforme de ses résultats vers nos clients.

12. Quels programmes existe-t-il pour la méthode Kanban ?

Il y en a aussi beaucoup. Nous listons uniquement les professionnels, développés spécifiquement pour la méthode. Notre cœur est consacré au développement russe de Kaiten. En plus de cela, il existe également TargetProcess, SwiftKanban, LeanKit et autres.

13. Et quelles entreprises utilisent déjà la méthode Kanban ?

Parmi les sociétés russes figurent Alfa-Bank, Home Credit Bank, Pochta-Bank, Dodo Pizza, HeadHunter, Clever et d'autres. De l'étranger : Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb's, Siemens, Tupalo. Cette liste peut être continuée pendant longtemps.

14. Y a-t-il autre chose d'important ?

Oui. Enfin, je voudrais souligner l’importance de deux rôles dans la méthode Kanban. Il s’agit du responsable de la prestation de services et du gestionnaire des demandes de service. Le premier est chargé de supprimer les obstacles dans le flux d’approvisionnement. La seconde consiste à gérer le flux de demandes adressées au service par de nombreux clients. Il est très important que ces deux rôles soient partenaires et travaillent ensemble.

15. D'accord, je comprends. Par où commencer à mettre en œuvre Kanban dans une organisation ?

Pour commencer à implémenter Kanban dans les organisations, nous utilisons l'outil S.T.A.T.I.K. – une approche systématique de l’utilisation du Kanban. Vous pouvez en savoir plus à ce sujet sur Internet. Mais nous recommandons de suivre une formation où cet outil est enseigné sous forme de business game. En utilisant votre service (organisation) comme exemple, vous pouvez concevoir un système Kanban pour une utilisation ultérieure dans des conditions de combat.

Formateur et consultant sur les méthodologies agiles, Scrumtrack.

Bon après-midi

L'un de mes intérêts professionnels, en tant que coordinateur d'une équipe de tests, concerne les méthodologies de développement de logiciels. Actuellement, les méthodologies dites Agile, notamment Scrum et Kanban, deviennent de plus en plus populaires. Des « formateurs » sans scrupules jouent sur des termes « hype » ; les séminaires et les certifications (« Scrum master certifié », « Product Owner certifié », etc.) se multiplient à pas de géant.

Dans la plupart des articles et formations sans scrupules, toute méthodologie est présentée comme une solution magique qui résoudra instantanément les problèmes de communication et sauvera immédiatement les membres individuels de l’équipe de l’incompétence. En général, cela vous aidera à résoudre exactement vos problèmes. Cette année, j'entre dans le programme de maîtrise de l'Université d'État de Biélorussie avec un diplôme en technologies de gestion des ressources humaines et j'ai l'intention d'examiner en détail les avantages et les inconvénients, ainsi que les limites de l'applicabilité des méthodologies de développement de logiciels les plus courantes.

Au cours du travail, j'ai souvent rencontré des malentendus et des interprétations incorrectes des outils méthodologiques, l'utilisation de méthodologies à la mode sans tenir compte du contexte. Après avoir lu l'article, j'ai réalisé que le problème est plus global que local. Aujourd'hui, je propose de jeter un petit coup d'œil sur Kanban, son histoire, ses principes de base et ses limites d'application possibles.

Histoire du terme

Kanban est un terme japonais qui a commencé à être utilisé en relation avec la production dans les années 60 du 20e siècle chez Toyota. Ce principe est basé sur la méthode de production du convoyeur, ainsi que sur différentes vitesses pour effectuer des opérations technologiques individuelles en production. Je vais essayer de l'expliquer avec mes doigts. Dans toute production, il existe une production principale (« convoyeur principal ») et une production supplémentaire (« convoyeurs supplémentaires »). Le taux de production des produits finaux est fixé par le convoyeur principal, tandis que les convoyeurs supplémentaires ne peuvent pas accélérer le taux de libération du produit, mais peuvent le ralentir si les pièces requises ne sont pas libérées à temps.

De plus, pendant la production, les priorités peuvent changer. Par exemple, il s'est avéré que la station qui produisait les rétroviseurs gauches produisait 20 pièces et la station qui produisait les rétroviseurs droits en produisait 10 pièces, alors qu'il y a 15 voitures sur la chaîne de montage et 15 pièces de rétroviseurs des deux types sont nécessaires. Il existe un conflit de mesures : la production n'a pas diminué quantitativement (des convoyeurs supplémentaires ont produit 30 produits à temps), mais la production risque toujours de s'arrêter. Kanban est conçu pour résoudre ce problème.

Dans sa forme la plus simple, Kanban comprend deux règles simples :

La station de production dispose d'un plan de production de pièces (« backlog »). Le plan est trié par priorité, et peut changer à tout moment (par exemple, une station produisant trop de rétroviseurs gauches devrait pouvoir passer au plus vite aux rétroviseurs droits) ;
le nombre de tâches effectuées simultanément à la station est limité (c'est-à-dire ne pas produire plus d'un nombre donné de miroirs en même temps). Cette limitation est nécessaire pour contrôler la vitesse de production en station, ainsi que la vitesse de réponse aux changements de plan.

Le présent

Dernièrement, Kanban a gagné en popularité dans la production de logiciels. Certaines équipes trouvent cette méthodologie extrêmement utile, d’autres l’utilisent comme un « culte du Cargo ». D'après mon expérience empirique, le Kanban pur fonctionne mal pour les équipes produit (lire « pipeline principal »), mais fonctionne très bien pour les équipes de support telles que :

les groupes de support logiciel, où le « plan » n'est pas important, mais la rapidité de réponse aux changements est importante ;
des équipes de test travaillant séparément des équipes de développement ;
services de soutien;
d’autres exemples d’« industries non essentielles ».

Par ailleurs, il convient de noter que Kanban fonctionne bien dans les startups qui n'ont pas de plan clair, mais qui travaillent activement au développement. Je propose de considérer un exemple d'utilisation de Kanban dans le développement de logiciels. Je m'excuse d'avance pour les illustrations laides. Imaginons une équipe composée d'un développeur travaillant sur un petit projet. Le plan de développement (backlog) est trié par ordre de priorité des tâches, la limite d'équipe pour les tâches du processus est de 1 pièce.

Pour gérer le processus, le chef de projet peut :

modifier la limite du nombre de tâches en cours de travail ;
ajouter une tâche avec une priorité plus élevée (par exemple p0) pour qu'elle soit prise le plus tôt possible ;

Au cours du processus de travail, il peut arriver que le travail soit bloqué (l'hébergement est en panne, le framework requis n'a pas été téléchargé, etc.). En général, le travail bloqué est renvoyé dans le backlog et une nouvelle tâche ayant la priorité la plus élevée est sélectionnée. Selon la nature des tâches et le type d'équipe, la limite peut être augmentée ou diminuée. Par exemple, notre développeur peut simultanément dessiner un formulaire d'inscription et observer le processus de déploiement d'un nouveau serveur. Cependant, si le temps d'exécution de la tâche est inférieur à celui requis, le chef de projet peut réduire la limite ou augmenter l'équipe. Ainsi, avec une bonne gestion, Kanban offre la vitesse de travail la plus élevée possible pour une équipe donnée, une vitesse de réponse maximale aux changements et réduit en même temps les « coûts » de support de la méthodologie. Eh bien voilà tout! Kanban n'est pas facile, simple. C'est très simple!

Les limites de Kanban lorsqu'il est utilisé dans les équipes produit incluent :

cette méthodologie ne fonctionne pas bien avec les grandes équipes (plus de 5 personnes) ;
Dans sa forme pure, Kanban ne fonctionne pas bien avec les équipes interfonctionnelles. Ceux. Contrairement à Scrum, il est difficile de combiner tests et développement au sein d’une seule équipe. Une meilleure idée est de diviser le processus en une « station » de développement et une « station » de test avec des gestionnaires et des backlogs distincts ;
De par son histoire et ses spécificités, Kanban n’est pas destiné à une planification à long terme.

Conclusion

En conclusion, je voudrais ajouter que comparer des méthodologies sur le principe de « qui est le plus cool » n'est pas productif et contre-constructif (Captain Obvious). Chaque méthodologie plus ou moins courante a ses avantages, ses inconvénients et ses limites d'application. De plus, les méthodologies Agile imposent intrinsèquement de plus grandes exigences au travail d’équipe et à l’expérience des membres de l’équipe.

Si le sujet suscite un intérêt, je continuerai à examiner Kanban plus en détail, puis je proposerai de trier Scrum et RUP en morceaux et en images.

Vous pouvez regarder plus en détail et plus clairement.

Kanban - qu'est-ce que c'est ? Quelle quantité d’informations intéressantes contient une carte Kanban et quelle fonction la méthode remplit-elle dans la production ? Dans l'article, nous expliquerons en détail les règles d'utilisation efficace du kanban et donnerons également une description claire du schéma d'utilisation des cartes correspondantes à l'aide d'un exemple spécifique. De plus, après vous être familiarisé avec le matériel, vous apprendrez pourquoi un tableau Kanban est nécessaire, dans quels domaines, en plus de la production, il est conseillé d'utiliser cette méthode et ce qui peut constituer une bonne alternative.

L'essence du concept et les principales caractéristiques de la méthode

Aujourd'hui, on peut observer une nette tendance à l'augmentation des coûts de stockage des stocks, ce qui est la principale raison de la formation de complexes de gestion des stocks « instantanés », qui incluent le système Kanban. Traduit du japonais, « kanban » signifie « tag », « badge ». Ce terme sert de méthode d'information par laquelle une autorisation ou une indication est donnée pour la production ou l'exclusion (transfert) d'un produit dans un système pull.

L'option présentée pour transmettre des informations vous permet de gérer entièrement les lignes de production Lean grâce à l'utilisation de cartes d'information pour transférer un ordre de production spécifique de l'étape suivante à la précédente.

Le développeur d'un tel système productif est Toyota Motors, ce qui explique l'idée présentée comme l'une des premières tentatives de mise en œuvre pratique de la méthode juste à temps. Selon le système Kanban, la production s'effectue selon la règle suivante : les divisions de l'entreprise sont approvisionnées en ressources dans une quantité précise et dans un délai clairement défini nécessaire à l'exécution de la commande.

Détails du processus

Le schéma de la méthode présentée est extrêmement simple, mais il a un impact très efficace sur l'organisation du processus de production. Après avoir fourni les divisions de l'entreprise en ressources, un calcul détaillé du volume de travail en cours requis est effectué, qui doit provenir directement de l'avant-dernière étape (la commande du produit fini est donc la dernière étape de le processus). De même, dès l'avant-dernière étape, une demande est adressée à l'étape précédente pour un volume spécifique de produits semi-finis.

Ainsi, l'échelle de production sur un certain site est formée en fonction des besoins de l'étape de production suivante. Il est logique qu’entre chacune des deux étapes du processus de production situées à proximité, un double type de connexion s’établisse :

De la nième étape à n-1, la quantité de travail en cours requise est demandée (« tirée »).
De la n-1ère étape à la n-ème étape, les ressources matérielles sont envoyées dans la quantité requise.

Outils de transfert d'informations

Pour mieux comprendre le kanban - de quoi il s'agit, vous devez comprendre que les outils de transmission d'informations dans ce système sont des cartes spéciales, qui sont classées en deux groupes :

Outils directement liés à l'ordre de fabrication. Dans ce type de fiches, le nombre de pièces qui doivent être produites à l'étape précédente du processus de production est d'abord indiqué. Ils passent de la nième étape de production à l'étape n-1 et constituent la principale raison d'élaborer le programme de production de ces sites.
Les outils de sélection contiennent des informations sur le volume des ressources matérielles nécessaires (cela peut inclure des produits semi-finis, des matériaux, des pièces, etc.) qui doivent être prélevées lors de l'étape d'assemblage précédente. Les cartes de ce type affichent le volume de ressources réellement reçu par la nième étape du processus de production à partir de la n-1ère.

Il est important de noter que les cartes peuvent circuler non seulement en relation avec l'infrastructure interne de l'entreprise, mais également entre ses succursales ou sociétés qui soutiennent la coopération.

Méthodes efficaces d'utilisation de Kanban - qu'est-ce que c'est ?

Taiichi Ohno, président de Toyota Motor Corporation, a développé un certain nombre de principes pour utiliser les cartes Kanban avec une efficacité maximale :

L'opération ultérieure de l'activité de production supprime le volume de pièces indiqué par la carte de l'opération précédente.
L'opération de production située en face est réalisée conformément à la création de pièces dans la quantité et l'ordre indiqués sur une fiche spécifique.
Aucune pièce ne peut être créée sans carte. Cette disposition permet de réduire la surproduction, ainsi que les mouvements excessifs de produits. Ainsi, le volume de cartes en circulation est égal au montant maximum de stock.
Une carte est une commande de fabrication d'un produit (le produit est de toute façon attaché à la carte correspondante).
Les pièces présentant un défaut ne peuvent pas être transmises au processus en aval. Cette disposition permet de rendre la fabrication des produits aussi exempte de défauts que possible.
Réduire le nombre de cartes augmente leur niveau de sensibilité. Ainsi, les problèmes existants sont révélés et un contrôle efficace des stocks est effectué.

Caractéristiques de l'utilisation des cartes

Il s'est avéré que la gestion Kanban s'effectue selon un certain schéma, qui implique l'utilisation de cartes spéciales. Ainsi, lors de leur utilisation, les exigences visant à assurer une visibilité absolue et une sécurité maximale du système en question doivent être pleinement mises en œuvre : la perte des cartes, ainsi que leur mélange, sont totalement éliminés.

Les experts ont développé un outil efficace qui vous permet d'offrir une productivité maximale au système Kanban. Le tableau de cette méthode sert de point de collecte des cartes actives, car les employés utilisent souvent plusieurs outils différents sur leur lieu de travail. Ainsi, les cartes destinées au fabricant sont placées sur le tableau de commande. Et lorsque les outils à cartes nouvellement reçus atteignent le champ « démarrage », l'ensemble des cartes du numéro de pièce correspondant est transféré pour mener à bien la suite du processus de production.

Avantages de l'utilisation de la méthode Kanban - qu'est-ce que c'est ?

Les entreprises qui l'utilisent reçoivent quotidiennement des approvisionnements en ressources matérielles (et souvent plusieurs fois dans la journée). Cela permet de mettre à jour entièrement les stocks de production environ 100 à 300 fois au cours de l'année. Si nous comparons Kanban avec des systèmes tels que MRP ou MAP, alors dans ce cas, les mises à jour se produisent environ 10 fois plus souvent.

Il est conseillé d'évaluer la méthode Kanban avec des exemples qui révèlent son avantage absolu par rapport à d'autres méthodes moins productives. Ainsi, Toyota Motors Corporation a fourni des ressources à l'un des nombreux sites de production trois fois par jour en 1976 et en 1983 toutes les dix minutes.

Les Kanbans sont souvent utilisés dans les collaborations avec les supermarchés (stock spécialement constitué à cet effet). Ainsi, le consommateur envoie au supermarché un kanban de sélection, qui indique, comme indiqué ci-dessus, le volume du produit, et le supermarché lui transfère le nombre de produits spécifié. Dans le même temps, le supermarché envoie un kanban de réapprovisionnement au fournisseur, après quoi celui-ci transfère les produits au supermarché.

Éléments fondamentaux de la méthode

Les composants les plus importants d’un système Kanban sont les suivants :

Un complexe d'informations qui contient dans sa structure non seulement des fiches, mais aussi des plannings de production, de transport ou d'approvisionnement, ainsi que des cartes technologiques.
Un complexe directement lié à la maîtrise des besoins et professionnellement.
Un complexe qui permet un contrôle qualité total (TQM) et sélectif (Jidoka) des produits.
Un complexe qui assure un nivellement absolu de la production.

Les éléments présentés, utilisés ensemble, permettent d'atteindre le cycle de production le plus court, un niveau élevé de rotation des actifs (y compris les stocks), ainsi que d'éliminer ou de minimiser les coûts de stockage pour la production et, bien sûr, d'obtenir la plus haute qualité de produit à chaque étape du processus de production.

Inconvénients du système et les résultats de son utilisation

Comme tout développement, le système juste à temps présente certains inconvénients. C'est d'abord la difficulté d'organiser un haut niveau de cohérence entre les étapes de production d'un produit particulier.

Deuxièmement, il existe un risque important de perturbation du processus de production et, par conséquent, de la vente des produits. Néanmoins, une analyse détaillée de la pratique mondiale relative à l'application de la méthode en question a montré que le système présenté permet de réduire les stocks de production de moitié, et les stocks de 8 %, avec une accélération significative de la rotation du fonds de roulement et , bien entendu, une augmentation de la qualité du produit fini.

Il est important de noter que l’utilisation des kanbans ne s’arrête pas aux processus de production. Ainsi, le système est activement utilisé dans les activités de bureau et de projet, dans la programmation (il existe tout un complexe de développement de kanban), ainsi que dans l'obtention de résultats personnels (type personnel de kanban).

Le système Kanban a commencé son parcours dans les années 1950 sur les lignes de production de Toyota Corporation, après quoi il a migré vers les bureaux et est devenu un outil important pour les chefs de projet.

La flexibilité infinie de la pratique et ses possibilités d'auto-organisation du personnel ont permis d'atteindre l'efficacité là où d'autres approches n'ont pas fonctionné. C'est le cas lorsque la carte elle-même est devenue la carte de visite du système - elle s'est imposée comme monnaie interne dans les organisations qui ont mis en œuvre Kanban.

Origine

Tout comme le concept de Lean Manufacturing, le système Kanban a été développé par les managers de Toyota. L'auteur du système, l'ingénieur japonais Taiichi Ono, s'est inspiré du principe de fonctionnement des supermarchés américains, où l'acheteur choisissait lui-même les produits dont il avait besoin. Le rôle de « supermarché » dans la société Toyota était rempli par un entrepôt.

Là, les cartes de signalisation - et c'est ainsi que « kanban » est littéralement traduit du japonais - les ouvriers échangeaient des cartes de signalisation, régulant le processus de production de leurs propres mains.

Les cartes étaient attachées à des conteneurs contenant des pièces. Ces étiquettes contenaient des informations sur le nombre et la quantité de pièces, le service qui les envoyait et l'endroit où elles devaient arriver.

L'ouvrier qui était directement impliqué dans l'installation et le montage des machines - l'aval - prenait des pièces dans le conteneur, sur lequel était attaché un « kanban » avec une demande d'entrepôt. La carte a été retirée et, avec la boîte vide, a été transférée par le transporteur à l'entrepôt. Là, un autre employé avait déjà préparé un nouveau conteneur de pièces de rechange, sur lequel était attaché un « kanban » de production - une étiquette contenant des informations sur les pièces de rechange produites.

Le kanban de production a été remplacé par un kanban de demande pour l'entrepôt et envoyé vers la ligne de production de pièces - en amont. Par conséquent, le nombre exact de pièces indiqué sur la carte a été produit. Des conteneurs contenant des pièces de rechange neuves ont été acheminés vers les transporteurs sur la chaîne de montage.

Principes Kanban

Les dirigeants de Toyota ont formulé 6 règles de formation du système :

Les travailleurs en aval retirent exactement autant de pièces de l'entrepôt qu'indiqué dans le kanban
Les représentants de l'amont fournissent également des pièces détachées en stricte conformité avec les fiches
Rien n'est produit ou déplacé sans Kanban.
Kanban doit toujours être attaché aux pièces
Les pièces défectueuses ne sont pas utilisées dans le système
La réduction du nombre de cartes Kanban rend la direction plus réactive au changement. Mais sauf nécessité absolue, vous ne devez pas modifier le nombre de cartes établi.

Kanban est un système « pull ». Il crée un équilibre entre un flux constant, qui élimine les coûts d'attente, et un travail en cours minimum (WIP), qui réduit le risque de surproduction. Le RVP est régulé à l'aide de cartes : leur numéro est fixe, et les instructions qu'elles contiennent guident les interprètes en aval.

La règle du tag obligatoire fonctionne comme la loi de conservation de l’énergie.

La limite RVP est établie proportionnellement au nombre de cartes kanban, qui est calculé en fonction du niveau des ventes et de la variation statistique des processus en cours. Le nombre maximum de balises – la même « énergie » dans le système – fixe le niveau supérieur du RVP à un moment donné. Le RVP est également limité par le principe du pull : la vitesse de production du flux supérieur dépend de la vitesse du flux inférieur.

Le graphique montre que l’un des éléments fondamentaux du système est la culture Kaizen. Les processus autonomes et la variation des normes libèrent la direction d'une gestion constante afin qu'elle puisse se concentrer sur l'amélioration des performances des employés.

Application du Kanban en informatique

Si le Kanban continue d’apporter de la valeur sur les lignes de production, il a fait son chemin dans le monde du logiciel.

Seules les cartes contenant des informations sur les délais, une description ou un numéro de processus et le nom de l'interprète sont désormais attachées non pas au conteneur de pièces de rechange, mais à un tableau avec des colonnes lignées :

Backlog - tâches qui doivent être accomplies
Tâches en cours de développement
Tâches terminées mais pas encore transférées aux testeurs
Tâches prêtes à être transférées au service de tests
Tâches revues par le chef de projet (PM)
Tâches terminées

Un nombre est généralement écrit au dessus des colonnes - limite, indiquant le nombre maximum de processus qu'il contient. La limite du backlog est calculée en fonction du délai d'approvisionnement. Si le système a 5 tâches en cours et que chacune d'entre elles prend en moyenne 1 jour, le retard peut être limité à 5.

La structure ci-dessus n'est pas stricte - Selon les spécificités du projet, des intervenants improvisés peuvent être ajoutés. Il existe souvent un système Kanban dans lequel il est nécessaire de déterminer les critères de préparation d'une tâche avant son exécution. Ensuite, deux colonnes apparaissent, appelées en anglais spécifier(préciser les paramètres) et exécuter(commencer à travailler).

Plus une colonne avec une file d'attente prioritaire peut être ajoutée.Lorsque l'interprète est libre, il doit vider cette colonne de tâches particulière, puis en assumer d'autres.
Les tâches qui n'ont pas été achevées sont soit renvoyées dans le backlog, soit rayées du programme.

Kanban n'encourage pas le multitâche, donc une limite de processus est fixée pour un exécuteur.

Un travail terminé est préférable à plusieurs commencés.

Vous pouvez reprendre un deuxième emploi si le premier a été bloqué.
Le temps nécessaire pour accomplir une tâche doit être équilibré.Un délai trop court affectera la qualité. Une limite trop étendue gaspille les ressources de l’équipe et augmente le coût du processus.

Pourquoi un tableau Kanban est-il utilisé partout, et pas, par exemple, sur des tablettes ou un énorme écran ? Comme les fans du système répondent à cette question, un tableau ordinaire présente deux avantages : il est simple et offre un contrôle visuel. Il est facile d’apporter des modifications et permet une interaction tactile et sociale entre les membres de l’équipe.

Avantages et inconvénients du Kanban

Kanban présente les avantages suivants :

Flexibilité de planification. L'équipe se concentre uniquement sur le travail en cours, la priorité de la tâche est fixée par le manager.
Forte implication de l'équipe dans le processus de développement. Grâce à des réunions régulières, des processus transparents et des opportunités d’auto-organisation, les collaborateurs s’unissent et manifestent un réel intérêt.
Durée de cycle plus courte. Si plusieurs personnes ont des compétences similaires, la durée est réduite, mais s’il n’y en a qu’une, un goulot d’étranglement apparaît. Les collaborateurs doivent donc partager leurs connaissances et ainsi optimiser les temps de cycle. Ensuite, toute l’équipe peut reprendre le travail bloqué et rétablir un flux fluide.
Moins de goulots d'étranglement. Les limites RVP vous permettent de trouver rapidement les goulots d'étranglement et les problèmes survenus en raison d'un manque d'attention, de personnes ou de compétences.
Visibilité. Lorsque tous les travailleurs ont accès aux données, les goulots d’étranglement sont plus faciles à repérer. Les équipes Kanban, en plus des cartes elles-mêmes, utilisent généralement deux rapports généraux : des graphiques de contrôle et de flux cumulé.

En pratique, le système fonctionne bien dans les domaines de production non essentiels :

support logiciel ou équipes d’assistance.
Kanban fonctionne bien lors de la gestion de startups sans plan clair, mais où le développement avance activement.

Kanban présente également des inconvénients :

le système ne fonctionne pas bien avec des équipes de plus de 5 personnes
il n’est pas destiné à une planification à long terme.

Différences avec Scrum

Scrum, comme Agile Kanban, est une méthodologie flexible et est également souvent utilisée dans le domaine informatique. Les différences entre eux ne sautent pas aux yeux au premier abord. Il existe de nombreuses similitudes, par exemple la présence d’un retard dans les deux approches.

	Mêlée	Kanban
Rythme	Sprints répétables de durée fixe	Processus continu
Libération de libération	A la fin de chaque sprint après approbation du chef de projet (productowner)	Le flux se poursuit sans interruption ou à la discrétion de l'équipe
Les rôles	Product Owner, Scrum Master, équipe de développement	Une équipe dirigée par un PM, dans certains cas des formateurs kanban agiles sont impliqués
Principaux indicateurs	Vitesse d'équipe	Délai d'exécution
Acceptabilité des changements	Les changements au cours d'un sprint ne sont pas souhaitables car ils peuvent conduire à des estimations incorrectes des tâches	Le changement peut survenir à tout moment

Exemples d'applications en informatique

Directement de Microsoft : Kanban fait ses débuts dans le développement de logiciels

L'utilisation des principes Kanban dans le secteur des technologies de l'information a commencé il y a un peu plus de 10 ans. David Anderson, l'un des principaux vulgarisateurs de Kanban auprès des développeurs de logiciels, consultant pour Microsoft en 2005. Ils n'étaient pas satisfaits du travail de leur département - XIT Sustained Engineering, qui éliminait les erreurs dans les applications internes. Au début de l'année sous revue, ce département était le pire de son département. Le retard a dépassé la taille autorisée de 5 fois et le temps de traitement d'une demande a été délai d'exécution- cela prenait généralement 5 mois.

Le nouveau PM, avec l'aide des consultations d'Anderson, a augmenté la productivité du département problématique de 155 % en 9 mois. Délai d'exécutionétait désormais de 5 semaines, le retard est revenu à sa taille normale et l'achèvement des tâches dans les délais a été établi à 90 %. Tous ces résultats ont été obtenus avec une implication minimale des nouveaux employés ; le personnel a continué à corriger les erreurs logicielles en utilisant les mêmes méthodes - Seules les approches d'organisation du travail ont changé.

Fait intéressant : le responsable du programme Dragos Dumitriu, qui a entrepris de renverser la tendance au XIT, était fasciné par le livre d'Anderson. À sa grande surprise, il a rencontré l'idéologue du logiciel Kanban chez Microsoft même, où il avait trouvé un emploi la veille. Dumitriu a demandé à Anderson de l'aider dans sa tâche, et ce dernier a accepté de mettre en pratique les principes de son livre.

Dumitriu a trouvé un département composé de trois développeurs et de trois testeurs qui avaient accumulé 80 demandes dans leur backlog. Le Premier ministre lui-même a été nommé temporairement, car les exigences pour le poste comprenaient la capacité de travailler avec la technologie ASP, l'administration à l'aide de SQL Server et la connaissance de MS Project Server. Les patrons considéraient ce poste comme celui d'un « technicien » qui sait programmer, doit compiler des rapports et prédire la charge du retard. On pensait alors que le problème du ministère serait identifié si une quantité impressionnante de données était collectée. Dumitriu n’était pas un tel « technicien ».

Cependant, alors que lui et Anderson commençaient à analyser les performances de XIT, il a rapidement identifié les facteurs clés qui avaient un impact négatif sur la vitesse du département :

Il fallait trop de temps pour prédire les conséquences (ROM) de l'exécution d'une requête. Le développeur et le testeur ont dû passer une journée entière pour effectuer les calculs nécessaires, les révisions de code et la documentation complète. En moyenne, une demande était reçue quotidiennement. Selon les estimations du PM, 40 % de la productivité du département a été consacrée au ROM ;
La priorité a été donnée aux demandes de plus grande valeur. XIT a reçu un financement provenant du coût de la commande. La priorité des demandes était discutée chaque mois lors d'une réunion des chefs de service avec les clients - responsables des autres services. Avec un retard considérable au rythme actuel, alors que seulement 6 à 7 demandes étaient traitées par mois, les priorités des autres demandes changeaient constamment en raison du passage du temps. Beaucoup d’entre eux ont été reportés à un « plus tard » impressionnant, même pas égal au mois suivant.
Au stade ROM, la moitié des demandes ont été éliminées. Certains d'entre eux étaient trop importants et ont été requalifiés comme projets à transférer à d'autres départements, d'autres étaient trop coûteux et ont été tout simplement annulés. Certaines demandes n'ont pas été prises en compte car leur mise en œuvre aurait été trop longue. Ainsi, 40 % de la productivité du service a été consacrée à l'analyse des demandes, dont 50 % ont été rejetées. Environ 15 à 20 % des ressources en main-d'œuvre ont été gaspillées.
Les travaux préparatoires à la demande pourraient durer des mois avant le début de la mise en œuvre. Les calculs au stade ROM pourraient être perdus ou oubliés pendant cette période. Surtout si la mise en œuvre n'a pas été réalisée par le même développeur qui a lancé l'analyse.

Solutions Kanban pour un service Microsoft en difficulté

Dumitriu et Anderson ont insisté lors de conversations avec la direction et les responsables clients sur l'abandon de la scène ROM. Les calculs ont été effectués immédiatement avant la mise en œuvre et par le même interprète, c'est-à-dire qu'ils sont restés « frais ».
La priorisation des demandes s'effectuait non pas lors de réunions mensuelles, mais selon les situations, au travers d'appels téléphoniques ou de mails. 80 tâches du backlog ont été triées en fonction des clients. Il a été demandé à ces derniers de mettre en évidence les principales requêtes qui doivent être complétées en premier.
Le financement XIT est devenu fixe.
Le coût des demandes n'est plus pris en compte.
Le PM a saisi les tampons sur le tableau Kanban. Les développeurs ont pris le travail dans deux zones : les tâches approuvées et terminées. Il y avait 6 demandes dans le tampon, 5 ont été mises au travail. Testeurs sélectionnés dans le tampon « en attente de test ». Certaines tâches qui ne nécessitaient pas de modifications du code se retrouvaient là, contournant les développeurs. En décomposant les demandes en processus à tâche unique, le PM pourrait avoir un meilleur contrôle sur la situation et assurer la transparence aux clients. L'introduction de tampons a réduit les délais d'exécution. Les clients, dans un système prévisible, sont mieux à même de déterminer quelle demande doit ensuite être mise en mémoire tampon.
Si les demandes étaient trop importantes ou trop coûteuses, une décision était prise immédiatement. Si le développeur confirmait qu'il était prêt à terminer la tâche dans les 15 jours ou que les modifications en valaient la peine, alors la demande était acceptée, quels que soient sa taille ou son coût.
Après avoir observé le flux dans le département, le Premier ministre est arrivé à la conclusion que la structure du personnel devrait être modifiée en faveur de développeurs plus chargés de travail. Les changements ont été réalisés dans un rapport de 2 : 1 : 4 développeurs et 2 testeurs ont commencé à travailler chez XIT.

Fin 2005, la productivité du département a augmenté de 155 %. Pour améliorer encore le travail de XIT, deux employés y ont été embauchés : un développeur et un testeur. Le nombre de demandes en attente est tombé à 10 et un développeur a commencé à traiter systématiquement 11 demandes par trimestre. En moyenne, 56 demandes ont été complétées par trimestre contre 11 auparavant. Le coût des demandes est passé de 7 500 $ à 2 900 $.

Candidature chez Corbis

Après avoir connu du succès chez Microsoft, Anderson a commencé à relever un nouveau défi en 2006. Il travaillait désormais chez Corbis, une autre entreprise de Bill Gates, qui n'avait pas encore quitté MS. L'une des activités de Corbis était l'octroi de licences pour les photos. À cette époque, il s’agissait du deuxième plus grand stock de photos au monde, avec une base de données d’environ 3,5 mille images.

Le travail d'Anderson consistait à accélérer les versions majeures de l'entreprise. L'intervalle entre leurs sorties était de trois mois et pourrait encore s'allonger. Le simple fait de discuter du plan de sortie a pris deux semaines à la direction. Il était nécessaire de prévoir des versions mineures ou des mises à jour toutes les deux semaines. Dans le même temps, des ressources clés devaient être affectées au travail sur le projet principal.

Un tableau Kanban est apparu dans le bureau de Corbis, où Anderson communiquait quotidiennement avec l'équipe. Le but du PM était d'améliorer le contrôle visuel des processus, de promouvoir l'auto-organisation et une plus grande responsabilité personnelle des artistes interprètes. Le système Kanban visait également à réduire la surveillance de la direction et à augmenter la productivité.

En plus des cartes et des graphiques multicolores, une « poubelle » est apparue sur le tableau : les tâches trop volumineuses y ont été envoyées.

Photo du fonctionnaire

Un système Kanban pour soutenir l'ingénierie des systèmes logiciels par David J Anderson

Le système Kanban a clairement indiqué où le flux cesse d'être fluide et où se produisent des retards, ce qu'on appelle les goulots d'étranglement. Des discussions rapides avec l'équipe ont permis d'identifier les problèmes actuels. Par exemple, les tests ont duré 3 jours, ce qui a eu un impact négatif sur la date de sortie. Trois employés se sont associés et ont trouvé un moyen de réduire le temps à une journée.

Un goulot d’étranglement est une section du schéma opérationnel ou de l’algorithme d’une entreprise dans laquelle les limitations des ressources ou la productivité des personnes réduisent considérablement le flux des tâches. Une pénurie de travailleurs, une connexion Internet médiocre ou un directeur en vacances bloque ou ralentit l'exécution des tâches.

Les limites des cartes Kanban ont été fixées empiriquement à deux reprises. Dans la colonne « prêt pour le développement », les limites ont été augmentées. Il y a aussi une nouvelle colonne - « prêt pour les tests ». De nombreuses demandes destinées à l’aval étaient mal formulées, entraînant une perte de temps inutile. Par conséquent, le PM a examiné le fonctionnement du flux supérieur et a trouvé des erreurs.

Le traitement des demandes pouvait prendre 100 jours, mais les versions ont quand même commencé à sortir toutes les deux semaines, comme prévu. La décision sur le contenu du numéro a été prise 5 jours avant la publication. Les pratiques de comptage, comme dans le cas du département XIT de Microsoft, ont été abandonnées au profit de la productivité. Les tâches ont été hiérarchisées en fonction du « coût du retard » ou de la disponibilité des ressources.

Le système Kanban a non seulement aidé Anderson à atteindre son objectif, mais a également amélioré l'ambiance au sein de l'équipe. Grâce aux échanges communs et à la visibilité des processus, les collaborateurs ont développé une confiance mutuelle. Le personnel a également rejoint le Kaizen, c'est-à-dire la pratique de l'amélioration continue.

Qu'est-ce que la méthodologie Kanban et comment vous aide-t-elle à terminer les tâches à temps ?

Dans des conditions de multitâche constante et de grand nombre de clients, tôt ou tard, tout système devient surchargé. Les délais commencent à être manqués, les attentes ne sont pas satisfaites et le système se transforme en chaos. Aujourd'hui je vous propose de vous familiariser avec une méthodologie telle que le kanban. Cette approche promet d’allouer efficacement les ressources et de résoudre tous nos problèmes. Allons vérifier.

Un moment d'histoire du kanban

La base de l'idée du kaban a été inventée par Toyoyta Motors. Un constructeur automobile subissait de lourdes pertes en raison d’une mauvaise répartition des stocks et des capacités sur la chaîne de production. Certaines étapes de production pouvaient être inactives et d’autres étaient surchargées.

En 1959, un système de contrôle de la production est proposé permettant d'équilibrer tous les tronçons de la ligne. Le principe de base était qu'à chaque étape, les travailleurs affichaient des cartes indiquant le nombre de pièces requis, qui étaient transmises à toute la chaîne. Chaque ouvrier qui suivait la chaîne de production prenait exactement autant de pièces du précédent que ce qui lui était attribué sur la carte.

De cette façon, chaque pièce avait une carte et il ne pouvait tout simplement pas y avoir de surplus. En conséquence, les stocks n'ont pas augmenté dans les zones et chaque travailleur suivant a reçu exactement le nombre de pièces dont il avait besoin.

Formulons ce qu'est le kanban et appliquons-le au développement de produits Internet.

Kanban est un système de gestion de production Lean (en japonais : « signal »/« carte ») qui utilise des cartes d'information pour communiquer les commandes à toutes les étapes de la production. En termes simples, nous suivons le parcours complet d’un produit, depuis l’idée jusqu’à sa mise en rayon.

Ci-dessus se trouve un tableau Kanban. Il s'agit du principal outil d'affichage de l'état des tâches. Le principe de base : on voit à quelle étape du processus de production se situe une tâche particulière. De plus, le temps est suivi dans tous les domaines, c'est-à-dire que vous pouvez toujours trouver « » dans le système et travailler avec eux.

Vous déterminez vous-même le nombre de colonnes en fonction des caractéristiques de votre projet. Il est important que ce soient les principales étapes par lesquelles passe votre produit. L'exemple ci-dessus montre plus ou moins les principales étapes par lesquelles passe un produit en ligne.

L'application de la méthodologie est très large. Kanban est utilisé pour la mise en œuvre de projets, la gestion des ventes, les lignes de production, le développement informatique et même pour organiser votre propre vie.

Désolé d'interrompre la lecture. Rejoignez ma chaîne de télégramme. Nouvelles annonces d’articles, développement de produits digitaux et Growth Hack, tout y est. Dans votre attente! Nous allons continuer...

Principes Kanban

Affichage visuel des tâches. Toutes les tâches doivent être présentées sous forme de cartes et reflétées au tableau. Il est très important de mettre à jour le statut des tâches. Par exemple, si les développeurs ont préparé le code et l'ont soumis pour test, la fiche de tâche doit alors être placée dans la colonne appropriée. Ainsi, n’importe quel membre de l’équipe peut voir à tout moment à quel stade en est la tâche.
Limitation des colonnes WIP (travaux en cours ou travaux exécutés simultanément) à chaque étape de la production. Pour garantir que le système ne s'étouffe pas tôt ou tard avec le flux de tâches, il est nécessaire de définir des restrictions. Par exemple, sur le tableau Kanban ci-dessus dans la colonne Analisis (analytics), nous avons 2 personnes qui travaillent et elles ne peuvent pas gérer plus de 2 tâches, cela n'a aucun sens de les charger davantage, car les étapes suivantes du système seront inactives. Les restrictions de colonnes sont sélectionnées de manière empirique.
Concentrez-vous sur les tâches non accomplies. Lorsque vous regardez le tableau avec les tâches, faites tout d'abord attention aux tâches qui « se bloquent » dans l'une ou l'autre colonne. Si l'une des étapes vous prend le plus de temps, essayez de redistribuer les ressources ou d'ajouter des personnes, si possible.
Amélioration continue. Une fois que vous aurez équilibré la charge dans le système, il vous sera plus facile de surveiller l’ensemble du processus. Mesurez le temps de cycle (combien de temps la tâche reste dans une colonne séparée et combien de temps entre le moment où elle entre dans To do et la sortie de Done). Modifiez les charges dans le système et réduisez le temps nécessaire pour terminer toutes les étapes.
Faites attention aux détails. Par exemple, si le code que les développeurs écrivent périodiquement ne réussit pas les tests et est renvoyé pour révision, il existe peut-être des options pour améliorer la qualité du développement afin qu'un produit de meilleure qualité soit testé ?

L’approche Kanban peut paraître idéaliste, mais je vous assure que ses principes produisent des résultats. Tout d’abord, vous devez adapter la méthodologie à votre situation, puis peaufiner le système.

Outils Kanban

Ou où maintenir un tableau Kanban.

Tableaux Excel
Tableau avec autocollants
Un autre fantasme...

En fait, il existe de nombreuses options, vous pouvez les rechercher sur Google et vous inspirer. L'essentiel est que vous ayez ce tableau et que tous les participants au processus puissent voir ce qui se passe avec les tâches en ce moment.

Exemples de tableaux Kanban

Voici un tableau accroché au mur, où chaque tâche est reflétée sur des notes autocollantes.

Ou cela pourrait être un service cloud comme Trello.

Il existe un certain nombre d'opinions sur les outils et les options à utiliser dans votre travail, mais c'est avant tout une question de goût. Essayez simplement différentes solutions et choisissez celle que vous préférez. Le but est de commencer à utiliser le kanban, et de ne pas s'en tenir à l'utilisation du plus beau tableau possible.

Mon avis est le suivant : pour un brainstorming ou pour travailler sur des cas hors ligne, un tableau ordinaire avec des autocollants fonctionne bien. Mais pour le travail quotidien, il faut bien sûr utiliser une solution cloud comme Jira, Kanbantool, Trello, etc. Dans ceux-ci, toute l'équipe peut ajouter des commentaires aux tâches, les déplacer par colonnes et bien plus encore.

Nuances/pensées

Si nous parlons de produits Internet, alors Kanban fonctionne, aide et s'améliore, mais un certain nombre de préoccupations ou de nuances doivent être prises en compte.

Très probablement, l'introduction de limites d'en-cours sur une colonne peut effrayer un peu l'équipe de gestion de projet. Après tout, comment déterminer combien de tâches un développeur ou, par exemple, un testeur peut résoudre en parallèle ? Et si nous introduisions des restrictions et qu’ils se détendent ?

Vous voyez, si une personne n'est pas complètement chargée, ce n'est pas mal. Il peut étudier et analyser le travail effectué, trouver des lacunes et les corriger, et même se reposer. De plus, vous pouvez aider vos camarades d'autres parties du processus (colonnes), plus de détails ci-dessous.

Selon les gourous du Kanaban, le système fonctionne idéalement dans des équipes interfonctionnelles. Bon, quelque chose comme ça, si tu n'as rien à faire, va aider un collègue. Certes, pour constituer une équipe où les développeurs peuvent être des testeurs et vice versa, et où l'architecte système aidera le concepteur, vous devrez débourser beaucoup d'argent, et est-ce que cela en vaut la peine ?

Bien sûr, c’est formidable lorsque les membres de l’équipe apprennent les uns des autres et peuvent s’aider d’une manière ou d’une autre si quelque chose se produit. Mais pour que cette condition soit remplie, il est nécessaire de disposer de petites équipes, assises de préférence à proximité et communiquant en permanence. Sur de grands projets, il est difficile de reproduire un tel échange d'expériences.

Par conséquent, je suis plus enclin à perfectionner mes compétences si j’ai un moment de calme. Regardez ce que vous avez fait, réfléchissez à la manière dont vous pouvez l'améliorer, lisez des articles utiles. Une personne est un organisme vivant, pas un rouage sur un tapis roulant.

Total

Nous avons examiné la méthodologie Kanban et maintenant, j'espère, vous comprenez comment l'appliquer dans votre projet. Essayez de diviser vos processus en étapes principales et d'optimiser le système en fonction des connaissances acquises.