Monday, May 24, 2021

Guide du débutant sur la gestion de projet Scrum 2021

 En ce qui concerne la nomenclature, les débutants peuvent être perplexes. Lorsque vous atteignez cette culture pour la première fois, les termes «Scrum» et «Agile» semblent être utilisés de manière interchangeable, mais il existe une différence significative.

Scrum Project Management est un système de gestion de projet basé sur l'approche Agile. Le terme Agile fait référence à une méthodologie de gestion de projet qui met l'accent sur le développement continu, la polyvalence de la portée, la participation de l'équipe et la livraison de produits de haute qualité.

Outre Scrum, il utilise Extreme Programming (XP) pour un développement initial cohérent et une réflexion Lean pour la réduction des déchets et l'approche Agile Unified Process (AUP) pour l'utilisation de méthodes agiles pour créer des logiciels d'application métier.

Qu'est-ce que Scrum

Scrum est une méthode de mise en œuvre du développement Agile.

Agile est décrit comme un ensemble de «méthodes et pratiques basées sur les valeurs et principes articulés dans le Manifeste Agile», qui comprend des concepts tels que le travail d'équipe, l'auto-organisation et la transversalité.

Commençons par définir ce que Scrum n'est pas. Il existe un malentendu courant selon lequel Agile est identique à Scrum. Bien que Scrum soit agile, ce n'est pas le seul moyen de mettre en pratique des concepts agiles. Scrum n'est qu'une des méthodologies de création de produits agiles. Extreme Programming (XP), Crystal, Feature Driven Development, DSDM Atern et d'autres sont des exemples d'autres approches. Le Manifeste Agile et ses principes associés sont suivis par ces deux approches. Considérez Agile comme de la crème glacée, avec Scrum, XP, Crystal et d'autres méthodologies servant de différentes saveurs, telles que le chocolat, la fraise et la vanille. Ils sont tous agiles, ils sont tous bons et beaucoup peuvent être utilisés en combinaison.

Une comparaison solide est la distinction entre une recette et un régime. Un régime végétarien est une compilation de croyances et d'approches et de pratiques fondées sur des valeurs. Une recette de tacos aux pois chiches sera un bon point de départ pour mettre en œuvre votre alimentation.

C'est comme une analogie avec la relation qui existe entre Agile (le régime) et Scrum (la recette).

Structure de Scrum 3-5-3

En termes simples, la structure est

  • 3 rôles: Product Owner, Scrum Master et l'équipe.
  • 5 événements: Sprint, Sprint Planning, Daily Scrum, Sprint Review et Sprint Retrospective.
  • 3 artefacts: Backlog produit, Backlog Sprint et Incrément.

Si vous voulez en savoir plus sur Scrum, vous devriez lire

Quelle est la particularité de la gestion de projet Scrum


Le concept de transparence est un principe Scrum important. Tous les membres de l'équipe doivent être conscients de ce sur quoi les autres travaillent, de leur progression et de ce que l'équipe essaie d'accomplir.


C'est pourquoi il est important de clarifier les choses pour tout le monde.


Le Scrum Board en est un élément essentiel. C'est ici que vous pouvez suivre votre Backlog, ainsi que les projets sur lesquels vous travaillez lors du prochain sprint et leur statut.


Les tableaux Scrum peuvent aller d'aussi basiques qu'un tableau blanc avec des notes autocollantes pour chaque tâche à des logiciels aussi sophistiqués que avancés avec des graphiques et des fonctionnalités de suivi des tâches.


La valeur de la gestion de projet Scrum


Scrum est un cadre éprouvé pour atteindre l'agilité de la machine. Ce cycle itératif peut être reproduit en exécutant des sprints courts avant que tous les éléments de travail ne soient terminés, que le budget soit épuisé ou qu'une date limite ne soit arrivée. L'élan du projet est préservé, et lorsque le projet se termine, Scrum garantit que le travail le plus important a été fait.


Ceci est en contraste direct avec l'approche en cascade plus conventionnelle, qui fixe la portée du projet à l'avance, nécessitant des spécifications complètes, un examen et une documentation de conception avant le début de la construction. Les retards et les dépassements de budget sont normaux, et le fait de ne pas hiérarchiser l'ensemble de fonctionnalités entraîne souvent des produits de mauvaise qualité surchargés de fonctionnalités dont le client n'a pas besoin.


Scrum Project Management Books to Read

  • Ken Schwaber. Agile project management with Scrum. Redmond, WA: Microsoft Press.

Agile Project Management with Scrum (Developer Best Practices): Schwaber, Ken
  • Mike Cohn. Succeeding with Agile: Software Development Using Scrum

Succeeding with Agile: Software Development Using Scrum: Cohn, Mike

  • Jeff Sutherland. Scrum: The Art of Doing Twice the Work in Half the Time

  • Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process

Logiciel de gestion de projet Scrum: gratuit et payant


Le logiciel Scrum favorise le travail d'équipe, l'ouverture et la productivité entre les membres de l'équipe en facilitant le cadre Scrum. Le logiciel Scrum, en réalité, peut profiter à presque toutes les organisations en facilitant la communication, en organisant la charge de travail et en aidant les participants à planifier plusieurs itérations.


Des outils de gestion Scrum qui sont bons répondraient à toutes les exigences du projet Agile. Ces outils mettent l'accent sur la collaboration quotidienne en utilisant une série d'activités spécifiques à Agile. Ce qui fonctionne le mieux, c'est une réévaluation polyvalente des plans qui est effectuée en phases de travail rapides et itératives.


Cette analyse du logiciel de gestion de projet Scrum compare les fonctionnalités, les prix, les intégrations et les avantages et inconvénients des outils suivants:

  • ZenTao ALM- Best Scrum tool for automations and integrations

  • Wrike- Best scrum tool for teams of all sizes

  • MeisterTask- Best Scrum tool for beginners

  • Nutcache- Best Scrum tool for managing time, expenses, and billing

  • Jira- Best Scrum tool software for software engineering and testing

  • Targetprocess- Best Scrum tool for SAFe and LeSS

  • ClickUp- Best Scrum tool for bargain hunters who want lots of features

  • Vivify Scrum- Best Scrum software user interface

  • Axosoft- Best Scrum tool for complex projects

  • Scrumwise- Best simple Scrum software with core Scrum features

Mots finaux

Le système Scrum est simple. Les règles, objets, événements et fonctions du jeu sont tous simples à comprendre. Son approche semi-prescriptive aide en fait à lever les ambiguïtés dans le processus de production tout en permettant aux entreprises d'ajouter leur propre saveur unique.

Il est parfait pour les projets difficiles car il organise les activités compliquées en user stories gérables. En outre, la délimitation cohérente des responsabilités et des activités planifiées garantit la transparence et le contrôle partagé tout au long du cycle de développement. Les versions rapides maintiennent l'équipe motivée et les utilisateurs satisfaits en leur permettant de voir les améliorations dans un court laps de temps.

Scrum, d'un autre côté, peut prendre un certain temps à apprendre, en particulier si l'équipe de développement est habituée à un modèle de cascade traditionnel. Des itérations plus petites, des réunions de mêlée fréquentes, des évaluations de sprint et la nomination d'un scrum master peuvent être un changement culturel difficile à faire pour une nouvelle équipe. Pensez à utiliser un outil de gestion de projet Scrum alors =)

Thursday, May 20, 2021

Qu'est-ce que MVP

 Dans la Silicon Valley Bible d'Eric Ries, The Lean Start-Up, l'idée de Minimum Viable Product est apparue pour la première fois. Depuis lors, le MVP est devenu une pratique standard pour les équipes produit de divers secteurs, y compris le SaaS, le commerce électronique et les consommateurs l'électronique, les appareils portables et une variété d'autres.

Image from https://www.dynamicyield.com/glossary/minimum-viable-product/




Si vous voulez faire une voiture, ne faites pas d'abord les roues, puis faites les essieux, puis faites la coque de la voiture ... De cette façon, vous ne pouvez avoir une voiture qu'après que toutes les pièces sont finalement assemblées. vous devez d'abord construire une planche à roulettes, puis vous pouvez l'utiliser pour, par exemple, transporter des boîtes ou d'autres choses, puis transformer la planche à roulettes en scooter avec accoudoirs, puis la transformer en vélo. Puis une moto et enfin une voiture. Dans ce processus, vous pouvez avoir des «roues» à exécuter à chaque étape.

Suivez la méthode traditionnelle en cascade, effectuez toutes les analyses des exigences, puis toute la modélisation de la conception, puis toutes les implémentations de codage et enfin tous les tests. Vous ne l'avez pas fait de cette façon. Au lieu de cela, vous libérez les nouvelles fonctions développées à chaque itération, même tous les jours au cours de l'itération. Chaque petite fonction passera par l'ensemble du processus d'analyse, de conception, de codage et de test dans un cycle de 2/3 jours. Les fonctions libérées à chaque itération sont disponibles en elles-mêmes, et l'ensemble du système sera être disponible lorsque toutes les fonctions seront terminées. Vous publierez donc officiellement le système à la fin des trois itérations. Après tout, comment utiliser un système incomplet?

Le processus de développement est déjà très agile, n'est-ce pas? 

Beaucoup de gens ne peuvent pas comprendre cette image, car ils pensent que c'est une métaphore, pas vraiment des scooters aux vélos en passant par les motos et les voitures. Cependant, le tournant fondamental du développement logiciel agile est démontré dans cette image ci-dessus. Le logiciel est doux. Un vélo peut vraiment être converti en une moto avec un moteur, et cela n'affectera pas l'utilisation continue du vélo au moment de son installation. Cela peut même être plus absolu: si votre processus de développement logiciel ne se déroule pas de la même manière que le deuxième moitié de l'image, vous n'avez pas du tout pratiqué Agile.

Pendant tout ce processus, l'ensemble du système métier (pas seulement le système informatique) est disponible à tout moment, la modification du système métier est contrôlable et réversible à tout moment, et les avis d'amélioration sur le système métier peuvent être émis à tout moment. temps et être inclus dans les fonctionnalités suivantes.

Il s'agit d'une livraison itérative: le système logiciel est progressivement déployé dans le système d'entreprise de manière itérative, en changeant progressivement le système d'entreprise (plus numérique, plus pratique, meilleure expérience ...), et en veillant à ce que chaque étape du changement dans l'entreprise le système est sûr et fiable.

Qu'il s'agisse de déployer des systèmes logiciels et de modifier les systèmes d'entreprise de manière itérative, ou de déployer des systèmes logiciels et de modifier les systèmes d'entreprise de manière tout-en-un, c'est le tournant entre agile, non agile ou faux agile. Vous pouvez fermez la porte et engagez-vous dans le développement itératif. C'est amusant, mais au final, le logiciel est publié en grande quantité, et c'est en cascade.

Pour parcourir ce tournant, les user stories doivent être plus granulaires. L'étendue de la diffusion sélectionnée pour chaque itération doit être de bout en bout.

See also

Tuesday, May 18, 2021

Lectures Agile recommandées 2021

agile books recommended


Cette liste de livres est parfaite pour ceux qui s'intéressent à Agile, Scrum ou Lean! Cette liste a été compilée en gardant une trace des livres les plus répertoriés dans les communautés de gestion de projet en ligne. Pour compiler notre liste ultime de livres agiles, nous avons passé au peigne fin les critiques d'Amazon et avons ajouté les notes par étoiles. Bon nombre des principes décrits dans ces livres sont utilisés pour enseigner des cours de gestion de projet agile, qui sont de plus en plus courants.

** / * marque les lectures préférées

1  Life and Philosophy

Tao (by LaoZi)
Live Act(by Kazuo Inamori)
Steve Jobs (by Walter Isaacson)
Designing Design (by Kenyahara)
* Zen Mind, Beginner’s Mind (by Shunryu Suzuki )
Out of Control (by Kevin Kelly)
* Complexity: A guided tour (by Melanie Mitchell)

2  Leadership and Coaching

* Influence (by Robert B. Cialdini)

Creativity, Inc. (by Ed Catmull)
** Drive (by Daniel Pink)
Quiet Leadership: Six Steps to Transforming Performance at Work (by David Rock)
The Wisdom of Teams (by Jon R. Katzenbach and Douglas K. Smith)
Coaching for Performance (by John Whitmore)
Co-Active Coaching (by Henry Kimsey-House and other 3 authors)
The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace (edited by Brian Stanfield for the Canadian Institute of Cultural Affairs)
The inner game of Tennis (byW. Timothy Gallwey)
Fearless Change (by Mary Lynn Manns, Linda Rising)
Zero to One(by Peter Thiel, Blake Masters)
Start with Why (by Simon Sinek)
* Switch (by Chip Heath, Chip Heath)
** Overcoming the Five Dysfunctions of a Team (by Patrick Lencioni)
Reinventing Organizations (by Frederic Laloux, Ken Wilber)

3 General Management

*  AntiFragile (by Nassim Nicholas Taleb)
The Leader’s Guide to Radical Management (by Stephen Denning)
The Steve Jobs Way: iLeadership for a New Generation (by Jay Elliot and William L. Simon)
Good to Great (by Jim Collins)
The Fifth Discipline (by Peter Senge)
Becoming a Technical Leader (by Gerald M.Weinberg)
Peak: How Great Companies Get Their Mojo from Maslow (by Chip Conley)
Amoeba Management (by Kazuo Inamori)
Participatory Marketing of XiaoMi (by Li Wan Qiang)
The TOYOTA Way (by Jeffrey Liker)
The Essential Drucker (by Peter F. Drucker)
** Mythical Man-Month (by Frederick P.Brooks)
* Hackers and Painters (by Paul Graham)
Getting Real (by Jason Fried / David Heinemeier Hansson / Matthew Linderman from 37signals)
* Rework (by Jason Fried、David Heinemeier Hansson from 37signals)

4  Agile Management

Agile Project Management with Scrum (by Ken Schwaber)
** Clean Agile (by Robert Martin, Uncle Bob)
* Large Scale Scrum (LeSS) (by Craig Larman / Bas Vodde)
** Scrum: The Art of Doing Twice the Work in Half the Time (By Jeff Sutherland )
Essential Scrum (by Ken Rubin)
* Management 3.0 (by Jurgen Appelo)
The Principles of Product Development Flow: Second Generation (by Donald G. Reinertsen)
* User Stories Applied (by Mike Cohn)
Succeeding with Agile (by Mike Cohn)
** Agile Retrospectives (by Esther Derby, Diana Larsen)
* Coaching Agile Teams (by Lyssa Adkins)
Agile Coaching (by Rachel Davies, Liz Sedley)
* ScrumMaster – The Great ScrumMaster(by Zuzana Sochova)
Lean Software Development : An Agile Toolkit (by Mary Poppendieck, Tom Poppendieck)
* Inspired: How To Create Products Customers Love 2nd Edition (by Marty Cagan)
** Scrum and XP from the Trenches (by Henrik Kniberg)
** Lean from the Trenches: Managing Large-Scale Projects with Kanban (by Henrik Kniberg)
Extreme Programming Explained: Embrace Change (by Kent Beck, Cynthia Andres)
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (by Craig Larman, Bas Odde)
Kanban: Successful Evolutionary Change for Your Technology Business (by David Anderson)
* Lean Startup (by Eric Ries)
* Impact Mapping (by Gojko Adzic)

5  Agile Technical


* Test-Driven Development (by Kent beck)

* Refactoring: Improving the Design of Existing Code (by Martin Fowler)

Working with Legacy Code (by Michael Feathers)

** Clean Code (by Robert Martin, Uncle Bob)

Agile Software Development (by Robert Martin)

* Self-expressed Codes(by Stephen Wang)

* Effective Unit Testing (by Lasse Koskela)

SOA with REST (by Thomas Er, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian)

Agile Testing (by Lisa Crispin, Janet Gregory)

The Pragmatic Programmer: From Journeyman to Master (by Andrew Hunt, David Thomas)

Clean Coder (by Robert Martin)

Clean Architechure (by Robert Martin)

Specification by Example (by Gojko Adzic)

The Art of Agile Development (by James Shore, Shane Warden)


See also

Monday, May 10, 2021

Amoeba, TPS, Scrum et XP

 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

Sunday, April 25, 2021

Guide du débutant sur la gestion de projet Scrum

 En ce qui concerne la nomenclature, les débutants peuvent être perplexes. Lorsque vous atteignez cette culture pour la première fois, les termes «Scrum» et «Agile» semblent être utilisés de manière interchangeable, mais il y a une différence significative.

Scrum Project Management est un système de gestion de projet basé sur l'approche Agile. Le terme Agile fait référence à une méthodologie de gestion de projet qui met l'accent sur le développement continu, la polyvalence de la portée, la participation de l'équipe et la livraison de produits de haute qualité.

Outre Scrum, il utilise Extreme Programming (XP) pour un développement initial cohérent et une réflexion Lean pour la réduction des déchets et l'approche Agile Unified Process (AUP) pour l'utilisation de méthodes agiles pour créer des logiciels d'application métier.

Qu'est-ce que Scrum

Scrum est une méthode de mise en œuvre du développement Agile.

Agile est décrit comme un ensemble de «méthodes et pratiques basées sur les valeurs et principes articulés dans le Manifeste Agile», qui comprend des concepts tels que le travail d'équipe, l'auto-organisation et la transversalité.

Commençons par définir ce que Scrum n'est pas. Il existe un malentendu courant selon lequel Agile est identique à Scrum. Bien que Scrum soit agile, ce n'est pas le seul moyen de mettre en pratique des concepts agiles. Scrum n'est qu'une des méthodologies de création de produits agiles. Extreme Programming (XP), Crystal, Feature Driven Development, DSDM Atern et d'autres sont des exemples d'autres approches. Le Manifeste Agile et ses principes associés sont suivis par ces deux approches. Considérez Agile comme de la crème glacée, avec Scrum, XP, Crystal et d'autres méthodologies servant de différentes saveurs, telles que le chocolat, la fraise et la vanille. Ils sont tous agiles, ils sont tous bons et beaucoup peuvent être utilisés en combinaison.

Une comparaison solide est la distinction entre une recette et un régime. Un régime végétarien est une compilation de croyances et d'approches et de pratiques fondées sur des valeurs. Une recette de tacos aux pois chiches sera un bon point de départ pour mettre en œuvre votre alimentation.

C'est comme une analogie avec la relation qui existe entre Agile (le régime) et Scrum (la recette).

Scrum 3-5-3 Structure

Simply put, the structure is

  • 3 roles: Product Owner, Scrum Master and the Team.

  • 5 events: Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.

  • 3 artifacts: Product Backlog, Sprint Backlog and Increment.

If you want to know more about Scrum, you should read

Quelle est la particularité de la gestion de projet Scrum

Le concept de transparence est un principe Scrum important. Tous les membres de l'équipe doivent être conscients de ce sur quoi les autres travaillent, de leur progression et de ce que l'équipe essaie d'accomplir.

C'est pourquoi il est important de clarifier les choses pour tout le monde.

Le Scrum Board en est un élément essentiel. C'est ici que vous pouvez suivre votre Backlog, ainsi que les projets sur lesquels vous travaillez lors du prochain sprint et leur statut.

Les tableaux Scrum peuvent aller d'aussi basiques qu'un tableau blanc avec des notes autocollantes pour chaque tâche à des logiciels aussi sophistiqués que avancés avec des graphiques et des fonctionnalités de suivi des tâches.

Livres de gestion de projet Scrum à lire

  • Ken Schwaber. Agile project management with Scrum. Redmond, WA: Microsoft Press.

Agile Project Management with Scrum (Developer Best Practices): Schwaber, Ken
  • Mike Cohn. Succeeding with Agile: Software Development Using Scrum

Succeeding with Agile: Software Development Using Scrum: Cohn, Mike

  • Jeff Sutherland. Scrum: The Art of Doing Twice the Work in Half the Time

  • Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process

Logiciel de gestion de projet Scrum: gratuit et payant


Le logiciel Scrum favorise le travail d'équipe, l'ouverture et la productivité entre les membres de l'équipe en facilitant le cadre Scrum. Le logiciel Scrum, en réalité, peut profiter à presque toutes les organisations en facilitant la communication, en organisant la charge de travail et en aidant les participants à planifier plusieurs itérations.



Des outils de gestion Scrum qui sont bons répondraient à toutes les exigences du projet Agile. Ces outils mettent l'accent sur la collaboration quotidienne en utilisant une série d'activités spécifiques à Agile. Ce qui fonctionne le mieux, c'est une réévaluation polyvalente des plans qui est effectuée en phases de travail rapides et itératives.


Cette analyse du logiciel de gestion de projet Scrum compare les fonctionnalités, les prix, les intégrations et les avantages et inconvénients des outils suivants:


  • ZenTao ALM- Best Scrum tool for automations and integrations

  • Wrike- Best scrum tool for teams of all sizes

  • MeisterTask- Best Scrum tool for beginners

  • Nutcache- Best Scrum tool for managing time, expenses, and billing

  • Jira- Best Scrum tool software for software engineering and testing

  • Targetprocess- Best Scrum tool for SAFe and LeSS

  • ClickUp- Best Scrum tool for bargain hunters who want lots of features

  • Vivify Scrum- Best Scrum software user interface

  • Axosoft- Best Scrum tool for complex projects

  • Scrumwise- Best simple Scrum software with core Scrum features

Mots finaux

Le système Scrum est simple. Les règles, objets, événements et fonctions du jeu sont tous simples à comprendre. Son approche semi-prescriptive aide en fait à lever les ambiguïtés dans le processus de production tout en permettant aux entreprises d'ajouter leur propre saveur unique.


Il est parfait pour les projets difficiles car il organise les activités compliquées en user stories gérables. En outre, la délimitation cohérente des responsabilités et des activités planifiées garantit la transparence et le contrôle partagé tout au long du cycle de développement. Les versions rapides maintiennent l'équipe motivée et les utilisateurs satisfaits en leur permettant de voir les améliorations dans un court laps de temps.


Scrum, d'un autre côté, peut prendre un certain temps à apprendre, en particulier si l'équipe de développement est habituée à un modèle de cascade traditionnel. Des itérations plus petites, des réunions de mêlée fréquentes, des évaluations de sprint et la nomination d'un scrum master peuvent être un changement culturel difficile à faire pour une nouvelle équipe. Pensez à utiliser un outil de gestion de projet Scrum alors =)

Read more



Tuesday, April 13, 2021

Comment mettre à jour Kanban

 

Qu'est-ce que Kanban

Kanban est un système de gestion de processus permettant d'identifier, de gérer et d'optimiser les informations. Son objectif est de vous aider à visualiser votre travail, à améliorer votre productivité et à optimiser en permanence. Kanban se traduit par un panneau d'affichage ou une enseigne en japonais. Il est né dans la fabrication et a ensuite été revendiqué par les équipes de développement Agile.

Kanban a commencé comme une méthode de planification pour la production allégée, dérivée du système de production Toyota (TPS). Toyota a ajouté le traitement «juste à temps» à sa production à la fin des années 1940. La méthode ressemble à un mécanisme de traction. Cela signifie qu'au lieu de la méthode traditionnelle d'entraînement pour produire des produits et les pousser sur le marché, la fabrication dépend de la demande des consommateurs.

twitter  @cedwardsNZ

Configurez le tableau Kanban le plus simple avec trois colonnes de base - «Demandé», «En cours» et «Terminé» pour commencer à développer votre système Kanban. Lorsqu'il est correctement conçu, entretenu et utilisé, il agit comme un référentiel de connaissances en temps réel, exposant les goulots d'étranglement dans le système et tout ce qui peut perturber les processus de travail.

4 Principes Kanban

1-Commencez par ce que vous faites maintenant

L'adaptabilité de Kanban l'aide à être superposée aux flux de travail, procédures et procédures actuels sans affecter ce qui fonctionne déjà bien; Naturellement, il peut identifier les problèmes qui doivent être résolus et aider à évaluer et à planifier les améliorations de manière à ce que leur exécution soit la moins perturbatrice possible.


2-Accepter de poursuivre un changement progressif et évolutif

La technique Kanban est destinée à rencontrer le moins d'opposition possible. Il prend en charge de petites améliorations progressives et évolutives au sein de la méthode existante sur une base continue. En général, les réformes à grande échelle sont évitées car elles se heurtent souvent à une opposition due à l'anxiété ou à la confusion.


3-Respecter le processus actuel, les rôles et les responsabilités

Kanban comprend l'importance des structures, des devoirs, des obligations et des titres actuels et estime qu'ils devraient être préservés. L'approche Kanban n'interdit pas la réforme, mais elle ne la recommande pas non plus comme panacée. Il vise à favoriser et à inspirer de petites améliorations rationnelles sans susciter la peur du changement.


4-Encourager les actes de leadership à tous les niveaux

Il s'agit de la définition Kanban la plus récente. Il rappelle que le leadership découle des actions quotidiennes des personnes en première ligne de leurs équipes. Pour atteindre une efficacité maximale au niveau de l'équipe / du département / de l'entreprise, chacun doit cultiver une mentalité d'amélioration de la qualité (Kaizen). Cela ne peut pas être un travail au niveau de la gestion.

6 cadences Kanban

Kanban n'a pas de processus de développement logiciel prédéfini. L'équipe doit ajouter des éléments Kanban au flux de travail actuel pour révéler le gaspillage, le travail inégal, la surcharge de l'équipe, les goulots d'étranglement, les goulots d'étranglement et d'autres problèmes dans le système, ainsi que la possibilité de retard. Pendant ce temps, il apporte éventuellement des modifications de procédure en fonction des problèmes découverts. Kanban est une méthode basée sur des preuves scientifiques.

Les cadences Kanban sont

  • Visualisez le workflow
  • Limiter WiP (travail en cours)
  • Gérer les flux
  • Rendre les politiques explicites
  • Améliorez les boucles de rétroaction
  • Améliorez en collaboration, évoluez expérimentalement

Pourquoi la méthode Kanban

Avec le système Kanban, vous ne pouvez avoir qu'un nombre gérable de tâches en cours à un moment donné. Ce qui est gérable pour votre entreprise dépend de votre personnel, ce qui vous évite d'avoir à en gérer trop à la fois. Le multitâche n'étant pas aussi efficace que beaucoup le pensent, l'approche Kanban vise à l'éviter. Lorsqu'une mission est terminée, vous passerez à la suivante.

La méthode Kanban est une excellente technique pour visualiser la réussite d'un projet et identifier les goulots d'étranglement dans le processus. Les tableaux Kanban peuvent être aussi basiques que trois colonnes qui affichent les affectations qui ont été soumises, sont en cours ou ont été terminées. Si elles sont correctement suivies, vous obtiendrez des mises à jour en temps réel sur la progression du projet et sur les problèmes qui causent des problèmes, ce qui se traduira par un flux de travail plus productif.

Outils Kanban modernes

Kanban n'a cessé d'évoluer à mesure que la technologie progressait. Pour résoudre les problèmes qui se posent dans les équipes distantes, des solutions de tableaux Kanban numériques ont été créées.

Un Kanban est plus qu'un simple tas de notes autocollantes sur le mur. L'approche la plus simple pour comprendre Kanban est de suivre sa théorie et de l'adapter à votre travail quotidien. Si vous interprétez, comprenez et êtes d'accord avec les quatre concepts de base, le changement de fond deviendrait rationnel, voire imminent.

Les chefs de projet n'utilisent plus de notes autocollantes et de tableaux blancs pour tracer les tâches du début à la fin. De nombreuses équipes planifient et mesurent déjà la mise en œuvre de projets dans un logiciel Kanban en ligne que tout le monde peut utiliser où qu'il soit.

Le logiciel Kanban est une solution de gestion visuelle des processus qui aide les équipes à travailler plus efficacement, à visualiser leur flux de travail, à analyser et à améliorer les processus métier en ligne avec la méthode Kanban.

Que vous choisissiez un logiciel Kanban autonome ou une suite PM plus grande, vous pouvez être sûr que l'intégration du logiciel Kanban dans votre stratégie de gestion de projet facilitera la vie de votre équipe.

Fonction Kanban dans ZenTao

ZenTao propose Kanban dans le module Projet / Sprint.

  • Sur Kanban, vous pouvez consulter les histoires du sprint actuel et ses tâches.
  • Les histoires peuvent être liées et classées par champs.
  • Faites glisser et déposez les tâches d'une colonne d'état à une autre.
  • Les bogues du projet en cours seront affichés. Un titre avec un signe de bogue devant lui est un bogue.
  • Les tâches attribuées à l'utilisateur actuel seront mises en surbrillance.

Sur ZenTao-Kanban, vous pouvez définir

  • s'il faut masquer les colonnes Fermé et Annulé;
  • s'il faut masquer / afficher les informations pliées
  • la couleur de chaque colonne Kanban

Si vous souhaitez mettre à jour le statut des bogues / tâches d'une histoire, faites simplement un glisser-déposer.

Voir également

Wednesday, March 24, 2021

Faites-vous du faux Agile?

 


Selon le 14e rapport annuel sur l'état de l'agilité, les organisations apprennent encore à mettre en œuvre l'agilité. Environ 50% des répondants ont déclaré que la moitié de leurs équipes utilisent l'agilité, et 84% d'entre eux admettent que leur organisation n'a pas atteint un haut niveau d'agilité.

Voyant que les entreprises et les équipes ont obtenu un grand succès après la mise en œuvre de l'agilité, de plus en plus d'équipes s'y affluent et elles passent à l'agilité. Mais ce n’est en aucun cas une tâche facile. Le problème commun est que l'équipe ne comprend pas les principes et les valeurs fondamentales de l'Agile, mais qu'elle fait de l'Agilité au lieu d'être Agile. Cela a finalement échoué. Ensuite, l'équipe ou les membres qui avaient subi cela ont commencé à faire connaître la «théorie inutile agile»: c'est engager tant de trucs et ne ferait que gaspiller plus de travail et de ressources. L'Agile est-il vraiment inutile? Ou vous l'utilisez simplement de la mauvaise manière.

Individuals and interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaboration over contract negotiation
Responding to changeover following a plan

 Certaines entreprises prétendent faire de «l'Agile», mais ce qu'elles font s'écarte du Manifeste Agile et des principes. En fin de compte, ce n'est souvent pas fait. Robert C. Martin, co-auteur du Manifeste Agile, a déclaré dans une interview que tout outil ou processus qui rend l'équipe difficile dans son environnement de travail ne peut pas être Agile. Les équipes semblent être agiles ne peuvent être que de «faux agiles».

Qu'est-ce que le faux agile?

Les sceptiques agiles ont une poignée de termes qui ont augmenté pour décrire le phénomène appelé «faux agile»:
  • Zombie Scrum
  • Faux Agile
  • Dark Agile
  • Agile Theater
  • Agile In Name Only(AINO)
  • Agile BS
La distinction est que lorsqu'il s'agit d '«être» agile, peu importe le cadre que vous utilisez tant que les principes clés agiles sont conservés. Ce sont les principes que pratiquement tous les «vrais» principes agiles partageraient avec chaque framework Agile.

D'un autre côté, le faux agile est un type de gaspillage. Tout comme ce que les équipes échouées se plaindraient ci-dessus dans la première section de cet article. Il y aura beaucoup de gaspillage car les équipes génèrent un grand nombre de builds opérationnels dans le but de faciliter les retours clients.

Faux symptômes agiles

Agile extrême

  • «Agile» n'est pas seulement «rapide». En ce qui concerne l'agilité, un cadre léger, les gens croient à tort que l'agilité est «rapide»: réponse rapide et livraison rapide. Par conséquent, toute l'équipe ne recherche que la vélocité, de sorte qu'elle doit renoncer à la qualité à la poursuite de la vélocité. Un produit axé sur une livraison rapide ne peut pas répondre aux besoins des clients et ne réussit même pas les tests d'assurance qualité.
  • «Agile» n'est pas seulement «simplicité». Le dixième article des Douze Principes d'Agile est «La simplicité - l'art de maximiser la quantité de travail non effectuée - est essentielle.» Ainsi, certaines personnes comprendront que le processus inutile doit être simplifié puisque la simplicité est encouragée. Les stand-ups quotidiens prennent trop de temps, alors sautez-les; Les réunions rétrospectives n'ont pas de sens, omettez-le; La préparation des documents est trop compliquée, laissez-la; Agile préconise de répondre aux changements, il n'est donc pas nécessaire de planifier des réunions, de les ignorer ... Les absolutistes pensent souvent qu'il s'agit de simplifier plus en profondeur pour plus de simplicité, puis des réformes drastiques sont effectuées. Cependant, après un arbitrage chaotique, les véritables objets de valeur ont été «éliminés», laissant les programmeurs confus pour continuer à créer des codes dans les jours répétitifs et fastidieux.

Zombie Agile

  • Réunion Scrum quotidienne. Le stand-up quotidien est un pont permettant aux équipes agiles de communiquer entre elles. Le stand-up quotidien n'exige pas que les membres de l'équipe rédigent un rapport détaillé et clair sur leur travail. Cela ne prend que deux minutes pour faire une déclaration simple. Le temps total est généralement d'environ 15 minutes. Les 15 minutes ici ne sont qu'une durée approximative, le temps spécifique peut varier en fonction du nombre de membres de chaque équipe et de la nature du travail. Dans le processus de pratique agile, certaines équipes confondent le concept de réunion debout, mais suivent strictement la règle du temps de réunion de 15 minutes. L'exigence doit être remplie dans les 15 minutes, quoi qu'il arrive. Une fois que l'heure de la réunion sera rigide, cela mettra beaucoup de pression sur les membres de l'équipe, les incitant à trouver des tâches au coup par coup pour parfaire la réunion, afin qu'ils ne puissent pas atteindre l'objectif des réunions debout quotidiennes pour promouvoir la communication de l'équipe.
  • Tableau Kanban. Kanban est généralement utilisé pour aider l'équipe à réaliser la visualisation des tâches et la transparence du statut de travail, à motiver les membres de l'équipe à travailler et à améliorer la concentration et l'efficacité du travail. Cependant, après la mise en place du tableau Kanban, il y aura également un gros défaut: le tableau Kanban est dans un état semi-inactif et ne peut pas être mis à jour à temps, et les membres de l'équipe ne peuvent pas obtenir les informations de réponse du tableau Kanban. Le résultat de ceci est: Kanban est devenu un affichage qui représente l'agilité. Lorsque le responsable rapportait son travail, il désignait le kanban sur le mur: Regardez, notre équipe se transforme en agile. Mais si le concept agile a été complètement mis en œuvre, personne d'autre ne le sait, sauf les membres de l'équipe.

Agile conservateur

Avant que l'équipe ne passe à l'agilité à grande échelle, le leader doit être agile. Dans une transformation d'équipe traditionnelle vers l'agilité, il est également nécessaire que les dirigeants prennent les devants dans la transition vers l'agilité et possèdent une pensée lean et agile (voir aussi Le rôle de leader dans la transformation agile). Seuls les leaders maigres et agiles peuvent promouvoir l'agilité de l'équipe en utilisant les forces de l'équipe et des individus.

J'ai connu une entreprise dont le dirigeant souhaite conserver le modèle traditionnel de développement en cascade. Lorsque toute l'équipe a commencé à passer à l'agilité, les dirigeants ont toujours préconisé le développement de Waterfall, ce qui a provoqué une grande résistance de l'équipe lors de la mise en œuvre de sprints dans le développement agile. S'il n'y a pas d'attitude unifiée envers la transition agile au sein de l'entreprise, l'équipe agile aura du mal et pourrait conduire à une fausse agilité.

Par conséquent, si vous voulez briser la "malédiction" d'une transition agile médiocre, vous devez avoir le courage de briser les chaînes du modèle actuel de l'équipe, voir à travers le "faux agile" dans l'équipe, changer la stratégie en fonction du réel situation de l'équipe, et vraiment rendre agile "vivant".

Conclusion

Une organisation agile s'adaptera rapidement au changement grâce à des processus préétablis qui lui permettent d'assimiler facilement de nouvelles connaissances et d'intégrer de nouveaux apprentissages dans ses biens ou son expérience de consommation. L'agilité nécessite la responsabilisation des équipes. Cela nécessite de la confiance, ce qui prend du temps. La leçon la plus difficile pour les dirigeants est de savoir comment recruter et apprécier des employés talentueux.

Voir également

Guide du débutant sur la gestion de projet Scrum 2021

 En ce qui concerne la nomenclature, les débutants peuvent être perplexes. Lorsque vous atteignez cette culture pour la première fois, les t...