Réserver une Démo

SVP notez : Cette page d’aide n’est pas pour la dernière version d’Enterprise Architect. La dernière aide peut être trouvée ici.

Pré. Proc.

Tableaux Kanban

Arrière plan

Kanban, qui se traduit littéralement par Visual (Kan) Card (Ban) ou panneau d'affichage, est une méthode opérationnelle utilisée pour augmenter l'efficacité. Il a été développé à l'origine par l'ingénieur industriel Taiichi Ohno alors qu'il travaillait chez Toyota. Ohno a analysé la façon dont les rayons des supermarchés sont approvisionnés et a appliqué les leçons apprises à l'usine, floor ainsi une efficacité sans précédent. La carte visuelle (Kanban) a été utilisée pour signaler le besoin de plus d'articles aux fournisseurs en amont sur la chaîne de production. La méthode Kanban peut être appliquée à n'importe quel domaine, y compris la planification stratégique, les ventes et le marketing et la gestion des compétences humaines, mais plus récemment, Kanban a été appliqué au processus de développement de solutions centrées sur les logiciels dans le but de s'assurer que la valeur est transmise au client. client le plus rapidement possible. L'industrie des technologies de l'information est en proie depuis ses débuts à des projets qui dépassent le calendrier et le budget, mais surtout qui ne parviennent pas à fournir de la valeur aux clients dans un délai qui leur permet d'être compétitifs et de réussir. Ces problèmes endémiques sont devenus un élément essentiel des affaires à une époque dominée par la perturbation numérique et des changements sans précédent.

Des principes

Kanban est fondamentalement très simple et repose sur un petit nombre de principes dont l'origine peut être attribuée aux ingénieurs de Toyota :

  • Rendre le travail visible
    Les méthodes traditionnelles de gestion de projet cachent les éléments de travail aux personnes qui exécutent le travail ; Kanban expose le travail à tout le monde, permettant à n'importe quel membre de l'équipe de contribuer à la façon dont les éléments de travail circulent dans le tableau et, en fin de compte, d'apporter de la valeur au client
Simple example of a Kanban Diagram with four lanes in Sparx Systems Enterprise Architect.
  • Limiter les travaux en cours
    Gestionnaires de Projet et les chefs d'équipe ont traditionnellement été sous pression pour terminer les produits ou pour inclure plus de fonctionnalités , et ont répondu à cette pression en chargeant l'équipe avec plus d'éléments de travail ; cela entraîne de nombreux changements de focus et inévitablement des éléments à moitié finis et une efficacité réduite
    Paradoxalement, Kanban incite à limiter le nombre d'articles en cours, d'où une plus grande efficacité et plus d'articles finis ; le nombre réduit d'éléments en cours permet aux membres de l'équipe de se concentrer sur une chose à la fois sans avoir à changer de focus
Showing how to set a maximum number of elements in a lane for a Kanban Diagram in Sparx Systems Enterprise Architect.
  • Gérer le flux de travail
    En utilisant les méthodes de gestion de projet traditionnelles, les goulots d'étranglement ou les blocages sont difficiles à identifier et ne font généralement surface qu'au moment d'une révision post-projet, souvent seulement après que le produit est livré en retard et qu'il manque des fonctionnalités .
    Grâce à Kanban, la visibilité du travail et la capacité d'identifier les processus bloqués - que ce soit en raison de goulots d'étranglement ou d'un manque d'éléments de travail - permettent d'identifier et de corriger rapidement un problème de flux
    Le diagramme suivant montre la façon dont la facilité Kanban dans Enterprise Architect répond lorsque le nombre d'éléments dans une voie dépasse le nombre spécifié dans la valeur max items (Work in Progress ou valeur limit) pour cette voie ; l'en-tête est mis en surbrillance dans une couleur configurable et les nombres (nombre d'articles/articles max) fournissent également un repère visuel qui prompt l'équipe à répondre en essaimant (un certain nombre de membres de l'équipe se concentrant) sur la voie pour réduire le nombre d'articles
Showing the effect of exceeding the maximum number of elements in a lane for a Kanban Diagram in Sparx Systems Enterprise Architect.

Exemple 1

Une User Story hautement prioritaire qui se trouve en haut du backlog pourrait être placée dans la voie « En cours » et un développeur pourrait immédiatement commencer à travailler dessus. Le travail peut impliquer le codage de règles d'affaires, la révision d'exigences détaillées, des modifications à un schéma de base de données ou l'ajout d'un élément ou d'un attribut à un schéma d'information et la création d'un environnement de déploiement nouveau ou mis à jour.

A single item in a lane on a Kanban Diagram in Sparx Systems Enterprise Architect.

Tous ces artefacts peuvent être trouvés dans le même référentiel sans qu'il soit nécessaire de lancer d'autres outils ou de planifier des réunions pour localiser les informations nécessaires. Les moteurs stratégiques peuvent être vus dans le contexte de leurs propriétaires d'entreprise, la conception et les principes architecturaux peuvent être visualisés, les Règles Métier peuvent être visualisées en relation avec les politiques qu'elles qualifient, une connexion en direct peut être établie avec les bases de données et leurs schémas analysés et modifiés , les schémas XML peuvent être inspectés et les messages construits, le code de programmation peut être écrit et les objectifs de déploiement détaillés, et tout cela réalisé sur une seule plate-forme collaborative.

Insert Related Elements in Sparx Systems Enterprise Architect provides traceability.

Exemple 2

Ce diagramme illustre un diagramme Backlog dans un flux de travail à deux ou trois étapes. L'ensemble du diagramme est utilisé pour gérer le backlog et les éléments peuvent être déplacés dans une voie pour définir leur ordre dans cette voie, ou entre les voies pour définir leur importance et leur position dans le backlog.

An example of a backlog Kanban Diagram in a two or three stage workflow in Sparx Systems Enterprise Architect.

Souplesse

Enterprise Architect a une facilité Kanban flexible et intégrée intégrée dans le produit de base, permettant aux projets de toute taille et de tout marché vertical de bénéficier des efficacités profondes qui accompagnent cette approche de gestion de projet simple, élégante et allégée. Quel que soit le type de processus utilisé, les fonctionnalités Kanban d'Enterprise Architect peuvent être intégrées rapidement et de manière transparente dans n'importe quelle méthode, créant une solution visuelle convaincante et une plate-forme de collaboration d'équipe qui se traduira par la livraison de produits, services et solutions aux clients avec efficacité et en un temps record - ravissant à la fois les propriétaires de produits et les clients.

Les fonctionnalités Kanban dans Enterprise Architect sont hautement configurables et peuvent être modifiées pour s'adapter à n'importe quelle équipe et processus, y compris les projets agiles, itératifs et incrémentiels, et même en cascade. Il y a un très faible obstacle à l'adoption et les équipes peuvent commencer immédiatement avec Kanban. Le tableau Kanban le plus basique consiste en un diagramme divisé en un petit nombre de voies ; une gamme d'éléments de travail peut être ajoutée au diagramme , y compris les Fonctionnalités , les histoires d'utilisateurs, les Défauts , les changements, les cas d'utilisation, les Exigences et plus encore. Items de travail peuvent être dessinés avec un style visuel convaincant représentant une carte colorée, et peuvent être déplacés n'importe où dans le diagramme pour changer l'ordre dans une voie donnée, ou d'une voie à l'autre en progressant de gauche à droite à travers le tableau, représentant la progression vers la valeur pour le consommateur. Les couloirs sont généralement liés aux valeurs d'une propriété "consciente de la gestion de projet" telle que le statut ou la phase, et lorsque l'élément est déplacé d'un couloir à l'autre, la valeur de la propriété liée est automatiquement modifiée. Cette facilité peut cependant être désactivée pour une voie individuelle en définissant la voie sur 'Non lié', de sorte que la propriété de l'élément ne soit pas modifiée lorsqu'il se déplace vers cette voie. Vous pouvez définir la voie sur "Non lié" si, par exemple, la voie capture des éléments qui sont sortis du processus normal et doivent être évalués en fonction de la valeur de la propriété lorsque le problème est survenu.

Allocation des ressources

N'importe quel nombre de ressources, exécutant des rôles spécifiés, peut être alloué aux éléments de travail au fur et à mesure qu'ils circulent dans le tableau Kanban, et la progression peut être visualisée sous la forme d'une ou plusieurs barres de progression affichées au bas de la carte. L'allocation est pilotée par la facilité d'allocation des ressources pratique et simple d' Enterprise Architect , qui peut être utilisée pour définir la relation entre les ressources (membres de l'équipe) et les éléments de travail (cartes). N'importe quel nombre de membres de l'équipe peut s'affecter à un élément de travail, en indiquant le rôle qu'ils joueront, et la date de début, la date de fin et le temps prévu peuvent être utilisés pour enregistrer des estimations de la durée de la tâche.

A Kanban Diagram showing a User Story with two resources working on it, in Sparx Systems Enterprise Architect.

La progression peut être mise à jour sous forme de pourcentage d'achèvement, qui peut être affiché visuellement sur la carte. Le tableau Kanban (comme tout diagramme ) peut également être affiché sous forme de diagramme de Gantt ou de liste, prenant en charge des représentations alternatives de gestion de projet.

Showing two resources being added to an element in Sparx Systems Enterprise Architect.

Configuration

Les cartes Kanban peuvent être configurées pour afficher un ensemble complet de propriétés, avec des icônes, des couleurs et des barres de progression attrayantes pour communiquer les aspects importants de l'élément de travail, l'allocation des ressources et la progression de l'élément de travail. Les propriétés incluent le nom de l'élément, le type, l'état, la version, la priorité, le stéréotype, la phase, l'auteur, etc.

A single user story element shown on a Kanban Diagram in Sparx Systems Enterprise Architect.

Les noms, les couleurs et le nombre de voies peuvent être configurés, en plus d'une gamme d'autres propriétés telles que les limites de surremplissage, les valeurs par défaut et la définition de sous-voies. L'apparence du tableau et les éléments de travail peuvent tous être configurés, en utilisant différentes couleurs, polices et styles, y compris un mode dessiné à la main qui pourrait plaire aux équipes plus habituées à utiliser un tableau physique avec des notes colorées. Il est également possible de définir l'apparence du graphique pour mettre en évidence les éléments provenant des mêmes hiérarchies.

Enterprise Architect a des diagrammes Kanban intégrés et un certain nombre de Motifs de flux de travail qui sont pré-construits et qui peuvent être utilisés « tels quels » ou configurés pour s'adapter à n'importe quel projet ou initiative. Les Motifs de workflow définissent des workflows à une, deux ou trois étapes ; par exemple, le workflow en deux étapes définit un tableau Kanban uniquement pour gérer la hiérarchisation du backlog, et les éléments du backlog sont ensuite déplacés du backlog Kanban vers la première voie de l'itération Kanban. Si nécessaire, le Product Owner peut utiliser la facilité de sécurité d' Enterprise Architect pour verrouiller le backlog Kanban, en s'assurant que l'ordre des éléments dans le backlog n'est pas modifié par inadvertance.

Il existe un certain nombre d'outils commerciaux qui permettent d'utiliser Kanban pour gérer visuellement des projets, mais la facilité Kanban d'Enterprise Architect est incroyablement utile car l'outil est également une plate-forme de modélisation sophistiquée pour l'analyse stratégique et commerciale, l'architecture, la conception, la mise en œuvre, les tests et le déploiement. . Cela signifie que les éléments de travail d'un tableau Kanban peuvent être liés à des décisions stratégiques, des règles métier, des politiques, des exigences, des éléments d'architecture et de conception, des structures filaires et des modèles UX, du code de programmation, des tableaux de base de données, des procédures, des tests, des nœuds de déploiement virtuels ou physiques, et Suite. Pour la première fois, tous les membres de l'équipe peuvent collaborer dans le même environnement en utilisant une boîte à outils de facilités spécialement conçue pour leur discipline, tout en étant en même temps capable de visualiser et de gérer la valeur livrée au client dans un ensemble visuellement convaincant de Kanban. planches.

Graphiques et tableaux de bord

Enterprise Architect a une facilité graphique facilité qui peut être utilisée pour créer des graphiques et des tableaux de bord expressifs, qui fourniront des informations sur le processus Kanban et permettront aux Product Owners et aux autres membres de l'équipe de surveiller les performances et de déterminer les moyens d'affiner le fonctionnement de l'équipe. Il existe une gamme de graphiques intégrés, notamment des graphiques à barres et à secteurs, des cartes thermiques, etc., mais une équipe est libre de créer un nombre illimité de graphiques définis par l'utilisateur pouvant être intégrés aux processus et révisions de l'équipe .

Application

La méthodologie de gestion de projet Kanban vous aide à développer un résumé d'avancement dynamique et facile à visualiser des étapes de développement d'un projet, où les étapes sont représentées sous forme de voies et de sous-voies d'un diagramme - un tableau Kanban. Dans Enterprise Architect , vous pouvez appliquer une forme de cette méthodologie à vos diagrammes d'administration de projet pour surveiller et gérer le flux de travail dans un domaine particulier.

Les étapes de développement peuvent être définies par la valeur d'une propriété de gestion de projet d'un élément, telle que Phase, Version ou Statut, ou une Valeur Étiquetée définie par l'utilisateur. Les éléments qui représentent chaque tâche ou object d'une tâche sont initialement placés dans les couloirs des étapes précédentes du projet, et le travail sur la tâche est reflété en déplaçant l'élément correspondant vers un couloir différent sur le diagramme . Si un diagramme est lié à une propriété de gestion de projet, faire glisser un élément d'une voie à une autre change automatiquement la valeur de la propriété à la valeur que la voie représente.

Dans cette illustration, les couloirs identifient le travail effectué à chaque étape de développement.

A 1-stage Workflow Kanban diagram, created in Sparx Systems Enterprise Architect.

Les nouvelles tâches commenceront généralement dans la voie la plus à gauche, et les tâches terminées passeront généralement par toutes les voies avant de s'immobiliser dans la voie la plus à droite, puis d'être déplacées hors du diagramme . Un flux de travail typique consiste à choisir la prochaine tâche sur laquelle vous allez travailler en commençant par la voie la plus à droite et en voyant si elle comporte des tâches que vous pouvez faire progresser ; sinon, passez à la voie suivante et répétez, et ainsi de suite.