Récemment, j'ai rejoint l'étude et la tournée Amoeba au Japon et j'ai découvert l'Amoeba de Kyocera et le TPS de Toyota. À l'époque où j'ai commencé à apprendre le développement agile, j'ai entendu dire que ce développement agile a beaucoup appris de la direction de Toyota. Faire ce voyage d'étude m'a fourni une expérience plus directe et intuitive de la gestion d'Amoeba et j'ai fait une comparaison de Amoeba management, TPS, Scrum, Extreme Programming.
Regardons d'abord quelques informations générales.
Depuis l'invention des ordinateurs, des logiciels informatiques ont été développés. Avec le développement logiciel, il y a la gestion de projet logiciel. La méthode de gestion de projet populaire auparavant était Waterfall. Waterfall comporte quatre étapes: l'analyse des exigences, la conception du cadre, le codage et les tests. Il est supposé que chaque étape d'un projet doit être effectuée correctement, de sorte que le travail de l'étape suivante puisse être garanti.
Les inconvénients de Waterfall deviennent de plus en plus évidents avec le marché en constante évolution. Son cycle est long, il est difficile de répondre aux évolutions du marché dans le temps, et il y a une longue attente au milieu de celui-ci. Par exemple, un développement complet d'une cascade peut prendre six mois, voire quelques années. Pendant ce temps, il n'y aura pas de produit à livrer, donc d'autres départements, tels que le marketing et les ventes, devront attendre et ils n'auront aucun retour du marché. Il est probable que le produit échoue sur le marché lorsqu'il est finalement lancé.
Dans de telles circonstances, de nombreux prédécesseurs de l'industrie du logiciel ont étudié et proposé leurs solutions. En 2001, certains d'entre eux se sont réunis pour présenter le célèbre manifeste Agile et le concept d'Agile. Dans Agile, un logiciel fonctionnel est plus important que la documentation, et il met l'accent sur la communication avec les clients, le travail d'équipe et la planification adaptative en temps réel, au lieu de suivre strictement le plan. Parmi les nombreuses écoles d'Agile, les plus connues sont la programmation extrême (XP) et Scrum.'
Extreme Programming met l'accent sur l'ingénierie logicielle, qui garantit la qualité et la rapidité du développement logiciel grâce aux user stories, à la programmation par paires, à la propriété collective du code, à l'intégration continue et aux tests automatisés. Scrum est plus axé sur la gestion de manière micro. Il spécifie quels rôles dans une équipe de développement logiciel doivent jouer à différentes étapes. Extreme Programming et Scrum mettent l'accent sur la fourniture de logiciels exécutables aussi rapidement que possible par Sprints, en recueillant les commentaires du marché et de ses clients, puis en les ajustant à l'étape suivante. Cette approche, que nous appelons itération, ne prend généralement pas plus de quatre semaines et peut être livrée en une semaine, voire un jour.
Dans une itération, Scrum comprend l'analyse des exigences, la répartition des tâches, les réunions quotidiennes, les réunions de révision après l'itération et les réunions rétrospectives. Une équipe Scrum, dirigée par un Scrum Master, complète toutes les sessions, et termine finalement tout le travail nécessaire de développement et de test de logiciels, et délivre finalement des logiciels exécutables.
La plupart des équipes de développement adoptent simultanément Scrum et Extreme Programming. Scrum fonctionne comme un cadre au niveau macro, tandis que Extreme Programming guide les utilisateurs sur la façon de coder. À ce stade, je pense personnellement qu'il existe une similitude entre la gestion d'Amoeba et TPS. Amoeba traite de la façon de gérer votre entreprise, mais il ne vous dit pas comment minimiser les coûts et maximiser les profits, ce qui peut être fait dans TPS grâce à une série d'outils tels que Kanban.
Ensuite, voyons les similitudes d'Amoeba, TPS et Scrum, Extreme Programming.
La direction d'Amoeba insiste sur le fait que tout le monde est un manager et que chacun doit avoir le sens du management. Dans Scrum, une équipe autogérée est d'une grande importance et mise en valeur. Une équipe Scrum doit prendre des décisions pour elle-même, ajuster ses plans et gérer les problèmes. À cet égard, Amoeba et Scrum sont similaires à certains égards. Ils mettent tous les deux l'accent sur les initiatives des membres de l'équipe et améliorent le fonctionnement de l'entreprise en mobilisant l'enthousiasme de tous.
En termes de structure organisationnelle, la direction d'Amoeba et Scrum sont également similaires. La structure organisationnelle d'Amoeba a tendance à être plate et le nombre de membres dans chaque Amoeba n'est pas grand. La taille idéale d'une équipe Scrum n'est pas supérieure à dix. Les petites équipes sont plus flexibles et la communication est plus efficace, il est donc plus probable que les membres de l'équipe améliorent leur sentiment d'accomplissement.
En termes d'opérations, la direction d'Amoeba demande une déclaration Amoeba à chaque Amoeba. En calculant les dépenses directes, les dépenses partagées, les revenus externes et les revenus internes, le profit d'une Amoeba est calculé, puis la valeur ajoutée unitaire de temps de l'Amoeba est calculée. Scrum demande le Product Backlog de chaque itération (l'objectif de cette itération), le Burnout Chart (un graphique pour montrer la progression du projet) et la vitesse (à quelle vitesse une équipe Scrum termine un story point. Pendant ce temps, une variété d'estimations sont nécessaires, avec les accessoires d'estimation (Scrum Poker).
En étudiant l'amibe à Kyocera, j'ai constaté que les réunions quotidiennes du matin et les réunions d'analyse commerciale sont similaires aux réunions quotidiennes debout et aux réunions rétrospectives dans Scrum respectivement. De plus, la rencontre régulière avec ouverture et cordialité est cohérente avec l'esprit d'équipe dans de nombreuses sociétés informatiques.
Amoeba met également l'accent sur la gestion visuelle d'une équipe. Une équipe Scrum utilise une variété d'outils pour visualiser la progression de toute l'équipe et la présenter à tout le monde.
Grâce à la mise en œuvre d'Amoeba, les membres de l'équipe sont formés pour avoir le sens des affaires. Scrum met également l'accent sur l'autogestion et la croissance au sein de l'équipe, et de nombreux talents managériaux émergeront en faisant Scrum.
Toyota TPS réduit les déchets et livre rapidement grâce à la réclamation post-processus, au nivellement de la production et à la garantie d'auto-travail. Parce que je n'ai qu'une compréhension préliminaire de Toyota TPS, je ne peux parler que brièvement de ses similitudes avec la programmation extrême.
Une pratique très importante dans la programmation extrême est le test unitaire. Les plus petites unités du logiciel sont la fonction. Chaque fonction a sa propre entrée. Il complète certaines fonctions et a finalement sa propre sortie. Les tests unitaires garantissent que la fonction fonctionne correctement en écrivant des cas de test dans divers scénarios. Par exemple, une fonction Sum (A, B). Le paramètre A peut être positif, négatif, décimal, zéro, chaîne, etc. Couplé au paramètre B, il y aura une douzaine, voire des dizaines de scénarios typiques. Lorsque nous terminons cette fonction ou y apportons des modifications ultérieures, nous devons exécuter tous les cas de test pour nous assurer que la fonction sera correcte. Même si dans des situations anormales, nous pouvons encore y faire face. Ceci est similaire à la garantie d'auto-travail dans TPS. Dans les ateliers de production de Toyota, une variété d'outils de détection et d'outils de guidage sont fournis. Par exemple, si la vis n'est pas serrée, le voyant correspondant apparaît. Il s'agit d'un cas de test unitaire en programmation.
Après les tests unitaires, les tests d'intégration, les tests du système, etc. seront effectués, ce qui est très similaire à une variété de contrôles et de tests après l'assemblage de la voiture chez Toyota. Une fois l'assemblage de la voiture terminé, le test d'apparence, le test du volant, le test de démarrage et le test de freinage seront effectués par un testeur particulier, ainsi que le test sur les différents tableaux de bord et ainsi de suite en état de conduite à grande vitesse. Il y a plus de 1 500 tests ou plus pour une voiture chez Toyota.
La programmation extrême met l'accent sur l'automatisation. Par exemple, il existe divers frameworks de test d'automatisation pour aider les programmeurs lors de l'exécution de tests unitaires. Il existe également une variété d'outils pour aider QA, lorsqu'ils effectuent des tests de système. L'automatisation est également au cœur du TPS. Dans l'usine de Toyota, toutes sortes d'outils d'automatisation sont partout. Ils ont même créé un mot en japonais pour cela: un caractère signifiant être humain est ajouté au verbe pour souligner les initiatives sous le principe de l'automatisation mécanique.
Afin de réduire les déchets, Toyota a mis en œuvre la réclamation post-processus. Je pense que c'est similaire au développement piloté par les tests. Le développement piloté par les tests consiste à écrire d'abord des codes pour un test unitaire, puis à écrire un programme capable de passer le code de test unitaire.
Le nivellement de la production et le développement Agile sont également similaires. La production de nivellement est caractérisée en évitant la production de masse et en économisant le temps de changement de moule pour atteindre une efficacité globale. Par exemple, si nous réalisons une production en série de la procédure A, le travail du personnel de la procédure B sera suspendu. La manière de mélanger AABBCC peut garantir l'efficacité de chacun. Dans le développement Agile, la conception, le développement et les tests sont effectués simultanément, et il s'agit de fournir à tout le monde la concurrence et d'éviter trop de temps d'attente et de gaspillage.
Il existe quatre principes d'assurance qualité dans les postes de travail TPS: suivre le fonctionnement standard, correspondant à la spécification de code dans Extreme Programming; Auto-inspection, correspondant à l'autotest en cours de développement; reconnaissance mutuelle de la qualité, correspondant à la programmation par paires et à la mesure mutuelle en développement; et améliorer les opérations faciles à utiliser, correspondant à une optimisation continue du développement.
L'ouvrier polyvalent dans TPS et l'ingénieur full stack en développement logiciel sont complètement les mêmes concepts.
La gestion TOYOTA Kanban a été complètement adoptée dans le développement de logiciels.
Qu'il s'agisse d'Amoeba, TPS, Scrum ou Extreme Programming, c'est un processus d'amélioration continue et sans fin, et d'apprentissage sans fin. Écrit le 24 août 2018 sur un bus de tournée pressé, juste pour votre référence.
See also
TOYOTA Kanban is so canonical
ReplyDelete