Devops for Growth
112.1K views | +2 today
Follow
Devops for Growth
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...

Popular Tags

Current selected tag: 'livre'. Clear
Scooped by Mickael Ruau
January 1, 2024 5:38 AM
Scoop.it!

The Gold Mine par Michael et Freddy Ballé –

The Gold Mine par Michael et Freddy Ballé – | Devops for Growth | Scoop.it
The Gold Mine est le premier épisode de la trilogie rédigée par Michael et Freddy Ballé sur le sujet de la mise en œuvre du Lean Management. Tout comme les deux autres épisodes (The Lean Manager et Lead With Respect) il s’agit d’une fiction. Lorsqu’on a demandé à Michael les motifs derrière ce choix du Business Novel pour écrire sur le Lean, il a expliqué qu’il s’agissait selon lui de la forme de la plus adaptée pour « mettre en valeur la dimension pratique du Lean en l’inscrivant dans un contexte précis. »

Mais selon nous, la vertu principale de cette perspective rédactionnelle est sa capacité à donner corps à la notion d’apprentissage. Car The Gold Mine est avant tout un roman d’apprentissage, l’apprentissage d’un dirigeant au pied du mur alors que son entreprise traverse des difficultés importantes.
Mickael Ruau's insight:

 

On retrouve ces quatre personnages principaux dans les 10 chapitres du livre, chapitres présentés dans l’ordre de la transformation à mettre en œuvre.

La suite de ce billet ne décrit pas ces 10 chapitres mais s’intéresse plutôt aux idées qui me semblent les plus importantes.

1/ Comprendre la situation

Le premier chapitre est un exemple de gemba : une visite terrain à travers laquelle les auteurs expliquent comment voir la valeur. Bobby le père donne une excellente explication de cette approche :

Lorsque je visite les opérations, je compte les opérateurs : ceux qui travaillent sur le produit, ceux qui attendent, ceux qui déplacent des pièces, ceux qui sont là à se promener ou à discuter. Le ratio entre ceux qui apportent de la valeur au produit et le nombre total me donne une bonne indication de l’efficience du processus.

Il s’agit d’un point essentiel : dans le Lean on veut établir une compréhension factuelle de la situation et cela ne peut se faire qu’en allant sur le terrain. Par ailleurs, c’est ainsi que le construit le lien entre la stratégie et l’opérationnel, en s’intéressant au travail des opérationnels et aux obstacles qui leur empêchent de créer davantage de valeur.

2/ Qualité

Une fois la situation comprise à travers l’observation sur le terrain, le premier sujet à traiter est toujours la qualité. Pour une raison qui nous échappe (et sur laquelle Michael a déjà écrit) on ne pense pas à cela en premier. On pense qu’en modifiant le processus ou en ré-organisant l’équipe, les résultats vont s’améliorer. Et on s’obstine malgré d’innombrables exemples qui nous prouvent le contraire. Car comme le dit The Gold Mine : la non-qualité a un coût et ces coûts se reflètent dans le prix des produits ou services que commercialisent l’entreprise.

L’objectif est d’avoir un système qui permet de rendre ces problèmes de qualité visibles, et de montrer les pièces non conformes. Respecter les personnes c’est déjà donner à chacun, sur l’ensemble de la chaîne de production les moyens, de déterminer si oui ou non leur travail est de qualité (la notion de built-in quality).

La stratégie consistant à déléguer la qualité à une équipe dédiée en bout de chaîne est une manière de dire au reste des équipes que la qualité n’est pas leur sujet : cela encourage inconsciemment la non qualité sur l’ensemble de l’entreprise. Et c’est précisément ce message que combattent nos 4 amis.

3/ Priorités

A plusieurs reprises, inlassablement, le vieux loup de mer revient sur l’ordre de mise en œuvre du Lean dans l’entreprise :

  1. Régler autant de problèmes que possible pour protéger le client
  2. S’assurer que les pièces traversent la chaîne de production en un flux le plus continu possible en utilisant des outils évitant la variabilité dans le cycle de l’opérateur
  3. Standardiser le travail
  4. Tirer le flux afin qu’aucune pièce n’arrive à une étape du processus sans avoir été commandée
  5. Enfin on lisse la la charge en réduisant la taille des lots à chaque étape du processus

4/ Inventaire

La réduction de l’inventaire et les stocks n’est pas la clef mais un indicateur de l’efficacité des processus, un peu comme l’aiguille sur compteur de vitesse. Il est important de catégoriser les stocks : matière première, en-cours (WIP pour Work In Progress), produits manufacturés.

Par démagogie, on réduit parfois le Lean à du bon sens mais nous sommes ici à l’opposé des intuitions habituelles.

Par ailleurs, comme l’on souhaite que les opérateurs n’aient sous la main que les choses dont ils ont besoin autour d’eux, il leur faut un poste de travail de taille limitée que l’on ne veut pas encombrer avec des pièces inutiles (dans le sens où il n’en a pas besoin maintenant).

Les auteurs expliquent que cet inventaire est créé par la différence du flux entre deux processus. Si l’on parvient à bien lisser la charge, on peut tirer le flux sans avoir besoin de trop d’inventaire. Le risque étant de supprimer les stocks intermédiaires (approche radicale) sans avoir au préalable supprimé les causes de variations.

Le Juste-à-temps permet de réduire ces stocks en déplaçant le juste nécessaire (les pièces nécessaires au prochain produit à construire) en permanence. (…)

Les stocks de produits terminés sont eux rendus visibles avec une zone de chargement contenant les produits prêts pour la livraison. Cela ne permet pas seulement de réduire le temps nécessaire au chargement mais aussi de contrôler le flux de livraison.

5/ Stratégie

Bobby insiste sur les deux priorités de l’entreprise de Philip : livrer les machines au client en premier lieu, puis réduire les stocks.

Et le rôle du dirigeant est de mettre l’ensemble de l’entreprise sous pression pour résoudre les problèmes des opérateurs. Car l’endroit le plus important de l’entreprise est le poste de travail de l’opérateur, là où l’on crée de la valeur pour le client : les autres équipes ne sont que des équipes support, leur permettant de le faire.

Une autre assertion contre-intuitive dans l’entreprise telle que nous la connaissons aujourd’hui.

Le dirigeant doit développer deux facultés dans ses équipes. Celle d’atteindre les cibles fixées pour répondre à la demande du client, quels que soient les obstacles à surmonter. La seconde est de comprendre les problèmes et d’imaginer des solutions alternatives pour atteindre les objectifs en résolvant les problèmes un par un.

Les auteurs de rajouter ce point essentiel :

Essayer d’améliorer les processus sans développer ces facultés parmi les équipes ne donnera comme résultats que d’autres processus dysfonctionnels.

6/ Management

Toyota a un team leader pour chaque groupe de 5 à 7 opérateurs et un manager pour 3 team leaders. Toyota a donc davantage de supervision sur le terrain que les entreprises classiques et cela s’avère beaucoup plus efficace. Harada et Ohno en expliquent la raison : ces encadrants sont en charge de garantir le flux continu et l’amélioration continue.

Le travail dans la plupart des entreprises est un peu comme si l’on nous demandait de courir plus vite dans un match de football où le score serait dissimulé et où il n’y aurait pas d’arbitre pour distribuer des cartons.

7/ 5S et standard

Le point essentiel est que les opérateurs se responsabilisent pour faire le ménage dans leur univers : leur poste de travail. Le simple fait de se débarrasser de vieilles choses qui les encombrent est à la fois un choix et un engagement.

L’analogie intéressante entre l’entretien de son bateau et la politique de Total Productive Maintenance :

D’habitude, les problèmes de machines se produisent dans les pires conditions, quand les équipements sont sous le coup de mers déchainées et de tempêtes. Si quelque chose se casse à ce moment-là, je peux me retrouver dans une situation très compliquée. C’est pour cela que, par temps calme, je nettoie et j’entretiens mon matériel, je remplace les pièces abîmées. Le nettoyage est une partie essentielle de la vérification et de la maintenance du matériel. (…)

Des équipes insatisfaites sont un accident en puissance. L’idée est que la maintenance continue c’est bien plus que ranger sa chambre. C’est un outil de management. L’enjeu est le comportement professionnel au travail.

Même si les auteurs ont choisi de parler de standard en privilégiant la dimension 5S c’est probablement parce qu’il s’agit du premier point sur lequel insistent les sensei . Ils rappellent la raison d’être du standard :

On stabilise le cycle de production grâce au travail standardisé qui définit la séquence des opérations, leur durée et les points de contrôle pour vérifier à chaque étape de la bonne qualité de ce qui a été réalisé. Le standard supporte ainsi, au niveau de l’action unitaire, le flux (temps) et la qualité.

8/ Kaizen

On ne veut aucun investissement en termes de management. L’objectif est de combattre la mentalité automatique de « grosse machine » qui réagit à chaque problème en installant encore plus de nouvelle technologie onéreuse et inflexible. Les personnes demandent sans cesse davantage d’équipement, d’automation ou de tout ce que vous voulez avant de mettre leur cerveau en marche pour trouver comment améliorer le travail grâce à une meilleure organisation.

9/ Finance

Il s’agit d’un point bien évidemment capital pour un dirigeant. Même si l’objectif de toute transformation Lean est de placer l’ensemble des équipes dans une dynamique d’amélioration continue, au final ce qui importe c’est la viabilité de l’entreprise et des emplois. Et cela est garanti par une situation financière améliorée.

Comme l’indique le titre du premier chapitre : Profit is King but Cash Rules, un des avantages incomparables du Lean avec l’approche par flux limitant les stocks est de libérer rapidement de la trésorerie. C’est cette trésorerie qui va garantir une plus grande autonomie à l’entreprise, et sa capacité à investir dans de nouveaux produits et de nouveaux emplois. Les auteurs invitent au sujet de l’équilibre financier à changer de perspective :

Les résultats financiers sont générés par la performance de nos opérations. C’est cette performance que l’on doit améliorer pour voir croître les résultats financiers.

Un ouvrage essentiel pour raconter la découverte de cette opportunité stratégique pour l’entreprise.

No comment yet.
Scooped by Mickael Ruau
January 1, 2024 3:39 AM
Scoop.it!

aqoba - La bibliothèque agile idéale

aqoba - La bibliothèque agile idéale | Devops for Growth | Scoop.it
7 livres références de la transformation d'entreprise à mettre sur votre table de chevet

Dans la communauté des coachs en transformation, vous trouverez de gros lecteurs. Nous en faisons partie.

Nos lectures nous ouvrent de nouvelles démarches, de nouveaux outils, de nouvelles pratiques : elles nous permettent d’enraciner la transformation plus profondément dans les organisations que nous accompagnons.

Dans cet article, pas de bla-bla. Juste 7 livres que nous avons sélectionnés car ils nous inspirent et ont largement influencé les dernières transformations que nous avons menées. Juste 7 livres que nous vous recommandons d’avoir sur votre table de chevet, s’ils n’y sont pas déjà !

Si vous n'avez pas déjà lu l'un des livres suivants, prenez quelques minutes pour parcourir cet article :

Retrouvez tous nos conseils lecture ici : #Bibliothèque

Livre #1 : Work Rules !
Livre #2 : Agile HR, Deliver value in a changing world of work
Livre #3 : Le thérapeute et le philosophe
Livre #4 : Reinventing organizations
Livre #5 : Apprendre à apprendre avec le Lean, accélérateur d'intelligence collective
Livre #6 : Accelerate, The Science Behind Devops: Building and Scaling High Performing Technology Organizations
Livre #7 : Empowered : Ordinary People, Extraordinary Products
No comment yet.
Scooped by Mickael Ruau
December 5, 2021 5:39 AM
Scoop.it!

Working Effectively with Legacy Code | Structure and Interpretation of Computer Programmers

Working Effectively with Legacy Code | Structure and Interpretation of Computer Programmers | Devops for Growth | Scoop.it


Almost the entire book is about resolving that dilemma, and contains a
collection of patterns and techniques to help you make low-risk
changes to make the code more testable, so you can introduce the tests
that will help you make the high-risk changes. His algorithm is:

identify the “change points”, the things that need modifying to
make the change you have to make.
find the “test points”, the places around the change points where
you need to add tests.
break dependencies.
write the tests.
make the changes.

The overarching model for breaking dependencies is the “seam”. It’s a
place where you can change the behaviour of some code you want to
test, without having to change the code under test itself. Some examples:

you could introduce a constructor argument to inject an object
rather than using a global variable
you could add a layer of indirection between a method and a
framework class it uses, to replace that framework class with a
test double
you could use the C preprocessor to redefine a function call to use
a different function
you can break an uncohesive class into two classes that collaborate
over an interface, to replace one of the classes in your tests
No comment yet.
Scooped by Mickael Ruau
December 5, 2021 5:33 AM
Scoop.it!

Summary of the book The Pragmatic Programmer by Andrew Hunt and David Thomas

Summary of the book The Pragmatic Programmer by Andrew Hunt and David Thomas | Devops for Growth | Scoop.it

This is my summary of the The Pragmatic Programmer, by Andrew Hunt and David Thomas. I use it while learning and as quick reference. It is not intended to be an standalone substitution of the book so if you really want to learn the concepts here presented, buy and read the book and use this repository as a reference and guide.

No comment yet.
Scooped by Mickael Ruau
December 5, 2021 5:25 AM
Scoop.it!

The Greatest Software Development Books of All Time - DZone Web Dev

The Greatest Software Development Books of All Time - DZone Web Dev | Devops for Growth | Scoop.it
This list is not complete, as there are always some new and good books, but these ones made the most impact in the careers of many software developers.
Mickael Ruau's insight:

[1] 20 Most-Recommended Books for Software Developers

[2] 10 Best Programming Books You Should Know

[3] Top 10 Books That Every Programmer Must Read Once

[4] The 10 Best Software Engineering Books in 2019

No comment yet.
Scooped by Mickael Ruau
November 7, 2021 5:44 AM
Scoop.it!

Software Project Survival Guide | Microsoft Press Store

Software Project Survival Guide | Microsoft Press Store | Devops for Growth | Scoop.it
Table of Contents

Acknowledgments
Preliminary Survival Briefing
Part I: The Survival Mind-Set
Chapter 1: Welcome to Software Project Survival Training
Chapter 2: Software Project Survival Test
Chapter 3: Survival Concepts
Chapter 4: Survival Skills
Chapter 5: The Successful Project at a Glance
Part II: Survival Preparations
Chapter 6: Hitting a Moving Target
Chapter 7: Preliminary Planning
Chapter 8: Requirements Development
Chapter 9: Quality Assurance
Chapter 10: Architecture
Chapter 11: Final Preparations
Part III: Succeeding by Stages
Chapter 12: Beginning-of-Stage Planning
Chapter 13: Detailed Design
Chapter 14: Construction
Chapter 15: System Testing
Chapter 16: Software Release
Chapter 17: End-of-Stage Wrap-Up
Part IV: Mission Accomplished
Chapter 18: Project History
Chapter 19: Survival Crib Notes
Appendix : Epilogue
Appendix : Notes
Appendix : Glossary
Appendix : About the Author
No comment yet.
Scooped by Mickael Ruau
November 3, 2021 10:49 AM
Scoop.it!

Episode 205: Rescue The Problem Project (Free)

Episode 205: Rescue The Problem Project (Free) | Devops for Growth | Scoop.it


Enter Todd Williams, PMP who wrote the book “Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure”. Todd and I sat down at the PMI® Global Congress last year and in this interview, we discuss the approaches to project rescue.
No comment yet.
Scooped by Mickael Ruau
November 3, 2021 10:46 AM
Scoop.it!

Rescue the Problem Project [Book]

Rescue the Problem Project [Book] | Devops for Growth | Scoop.it
Back from the brink—the first fail-safe recovery plan for turning around troubled projects. When budgets are dwindling, deadlines passing, and tempers flaring, the usual response is to browbeat the project … - Selection from Rescue the Problem Project [Book]
No comment yet.
Rescooped by Mickael Ruau from LEAP EntrepreneurshiԀPassion - lasting enterprise action practices
October 20, 2021 3:47 AM
Scoop.it!

The 7 Books Product Owners Should Read to Create a Value-Driven Mindset | by David Pereira | Serious Scrum

The 7 Books Product Owners Should Read to Create a Value-Driven Mindset | by David Pereira | Serious Scrum | Devops for Growth | Scoop.it
The biggest flaw of most Product Owners is the misunderstanding of value. A faulty perception of value will lead Scrum Teams in the wrong direction, which results in pointless…
Via Oliver Durrer swissleap.com
No comment yet.
Scooped by Mickael Ruau
October 1, 2021 10:13 AM
Scoop.it!

The Flow System - The Evolution of Agile and Lean Thinking in an Age of Complexity

The Flow System is a holistic FLOW based approach to delivering Customer 1st Value. It is built on a foundation of the Toyota Production System (TPS/LEAN) and the new Triple Helix of Flow creating the DNA of Organizations.

The Flow System enables business growth through eliminating non-value-added activities, fostering an environment for innovation, enabling the rapid delivery of value, and shortening the time to market. The Flow System provides a re-imagined system for organizations to understand complex problems, embrace distributed leadership, and build high performing teams.

The Triple Helix of Flow relates to the interconnected nature of the three helixes:

Complexity Thinking Helix &; A new form of thinking to aid the understanding of uncertainty and complex adaptive systems.

Distributed Leadership Helix &; An emergent hybrid leadership model that is capable of making bold and disruptive moves across an industry.

Team Science Helix &; A multidisciplinary field that studies all things related to teams and small groups in the workplace.

The Triple Helix identified the interactions between and among agents (people, machines, events&;) that emerge into new patterns, networks, and knowledge to advance an organization&;s ability to be more innovative, adaptive, resilient, and agile when operating in complex environments.

&;The Flow System shows how to generate and nurture self-organizing teams that mobilize the full talents of those doing the work to cope with dizzying change and complexity, while also drawing on the contributions of those for whom the work is being done&;the customers.&;&;Steve Denning, author of The Age of Agile

No comment yet.
Scooped by Mickael Ruau
September 27, 2021 6:10 AM
Scoop.it!

Organizations and Change | Organizations and Change | InformIT

Organizations and Change | Organizations and Change | InformIT | Devops for Growth | Scoop.it
Change can be intimidating, particularly when it comes to your organization. This chapter will help ease you through those changes with finesse. Who knows? Maybe you'll even find yourself looking forward to change.
Mickael Ruau's insight:

 

This research has identified several factors that speed up or slow down the innovation-decision process and, as a result, the time it will take the change to become part of the environment. We consider three factors: the change agent, the culture, and the people. To begin a successful change effort, you will need to understand all three and how they work together.

No comment yet.
Scooped by Mickael Ruau
September 27, 2021 6:05 AM
Scoop.it!

Fearless Change: Book Review ·

The Book Fearless Change by Mary Lyan Manns and Linda Rising
The Review I came across this book while watching an interview with Linda Rising on InfoQ. She mentioned some ideas from Malcolm Gladwell’s The Tipping Point which intrigued me and a strong recommendation from a colleague ensured this book made it onto my reading list.

Mickael Ruau's insight:

I am not currently working on a project where I need to instigate a lot of change so I was going slightly against my own principle of only reading books when I need to, but I recalled several times previously when I have tried to introduce what I thought were good ideas and didn’t really get anywhere.

No comment yet.
Scooped by Mickael Ruau
September 21, 2021 5:09 AM
Scoop.it!

Re-Read Saturday, Project to Product, Week 1, Foreword and Introduction

Re-Read Saturday, Project to Product, Week 1, Foreword and Introduction | Devops for Growth | Scoop.it
https://amzn.to/3nHC5YK This week we begin our re-read of Mik Kersten’s Project to Product. I am reading from my Kindle version published by IT Revolution (buy a copy).Today we are tackling the front matter which includes the Foreword by Gene Kim (author of the DevOps Handbook) and the Introduction,...
No comment yet.
Scooped by Mickael Ruau
January 1, 2024 5:35 AM
Scoop.it!

Le Gold Mine : Un récit en Lean

Le Gold Mine : Un récit en Lean | Devops for Growth | Scoop.it
Je vous livre ce que j’en retiens :

Tout d’abord, la réussite d’une démarche Lean repose sur deux piliers : la mise en place d’un système de production adapté et d’un système managérial inclusif.

Système de production adapté :

La performance est liée au bon fonctionnement des processus -> il convient donc d’étudier ses processus afin de détecter toutes les sources de gaspillages.
La qualité est un paramètre clé à maîtriser sous peine d’avoir des répercussions sur le coût des produits commercialisés. Des outils tels que le JIDOKA, l’ANDON ou le POKA YOKE peuvent aider.
L’état des stocks permet de juger de l’efficacité d’un processus. Produire en flux tiré permet de ne produire que ce dont le client a besoin et ainsi d’éviter une surproduction.

Système managérial inclusif :

La compréhension des processus et la capacité à identifier la valeur produite impliquent une connaissance du terrain. Le gemba permet d’aller à la rencontre des opérationnels et de comprendre ce qui les empêche de créer de la valeur.
La performance passe par le développement des équipes : les responsabiliser, leur donner le temps et la confiance nécessaires pour résoudre les problèmes permet de créer un cercle vertueux.
No comment yet.
Scooped by Mickael Ruau
December 25, 2021 3:24 AM
Scoop.it!

Startup superset: summaries of key concepts, ideas, insights

Startup superset: summaries of key concepts, ideas, insights | Devops for Growth | Scoop.it

Summaries

 

Liftoff

 

Ways of working

 

People

 

Teamwork

 

Strategy

 

Strategy analysis

 

Business model canvas

 

Tactics

 

Practices

 

Markets

 

Product/market fit

 

Customer development

 

Product development

 

Modeling

 

Markup

 

Management

 

Practice makes perfect

 

Metrics

 

Meetings

 

Brainstorming

 

Quality assurance

 

Sales

 

Investment

 

Startup advice

Mickael Ruau's insight:

Books to read

Books to read, in order of importance for immediate tactical usefulness.

 

Startup workbooks

The Startup Owner's Manual: The Step-by-Step Guide for Building a Great Company

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers

 

Lean startup development

The Four Steps to the Epiphany: Successful Strategies for Products that Win

Lean Customer Development: Building Products Your Customers Will Buy

The Lean Startup: ... Use Continuous Innovation to Create Radically Successful Businesses

 

Business management

The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers

Zero to One: Notes on Startups, or How to Build the Future

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

 

Change opportunity

Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers

The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail

Only the Paranoid Survive: How to Exploit the Crisis Points That Challenge Every Company

 

Teamwork

Work Rules!: Insights from Inside Google That Will Transform How You Live and Lead

Getting to Yes: Negotiating Agreement Without Giving In

The Primes: How Any Group Can Solve Any Problem

Crucial Conversations: Tools for Talking When Stakes Are High

No comment yet.
Scooped by Mickael Ruau
December 5, 2021 5:38 AM
Scoop.it!

Notes on Michael Feathers' *Working Effectively with Legacy Code*. · GitHub

Notes on Michael Feathers' *Working Effectively with Legacy Code*. · GitHub | Devops for Growth | Scoop.it

Notes by Jeremy W. Sherman, October 2013, based on:

Feathers, Michael. Working Effectively with Legacy Code. Sixth printing, July 2007.

No comment yet.
Scooped by Mickael Ruau
December 5, 2021 5:30 AM
Scoop.it!

The Pragmatic Programmer

The Pragmatic Programmer | Devops for Growth | Scoop.it
“The Pragmatic Programmer” est une bible pour les développeurs. Il est l’œuvre d’Andrew Hunt et Dave Thomas d’après leurs expériences en tant que développeurs. Leur objectif est simple, faire du lecteur un Pragmatic Programmer, un développeur fier de son travail et qui utilise les meilleures techniques à sa disposition pour faire un travail de qualité.
Mickael Ruau's insight:


Pour le résumé de “The Pragmatic Programmer”, je vais reprendre les “tips” qui accompagne les 46 items.

Tips :

1. Care About Your Craft Pourquoi passer son temps à développer des logiciels si on ne prend pas le soin de le faire bien ?
2. Think! About Your Work Désactiver le pilote automatique et prenez le contôle. Ayez un sens critique et réévaluez constamment votre travail.
3. Provide Options, Don’t Make Lame Excuses Au lieu de fournir des excuses, proposez des solutions de contournement. Au lieu de dire que c’est impossible, expliquez ce qu’il est possible de faire à la place.
4. Don’t Live with Broken Windows Améliorer les mauvais choix de conception, les mauvaises décisions et le code “sale” quand vous tombez dessus.
5. Be a Catalyst for Change Vous ne pouvez pas imposer le changement aux personnes. Montrez leur plutôt comment pourrait être le futur et encouragez-les à participer à sa création.
6. Remember the Big Picture Ne restez pas le “nez dans le guidon” et levez la tête pour voir ce qui se passe autour de vous.
7. Make Quality a Requirements Issue Impliquez vos utilisateurs à définir le niveau réel de qualité du projet.
8. Invest Regularly in Your Knowledge Portfolio Apprendre doit devenir une habitude, un réflexe.
9. Critically Analyze What You Read and Hear Ne vous laisser pas influencer par les vendeurs, “buzzs” médiatiques, ou dogmes. Analyser les informations dans votre contexte et celui de votre projet.
10. It’s Both What You Say and the Way You Say It De bonnes idées ne sont rien sans une communication efficace.
11. DRY - Don’t Repeat Yourself Chassez la duplication. Chaque connaissance, au sens large, doit avoir une représentation unique, non ambigu et faisant référence pour tout le système.
12. Make It Easy to Reuse Si votre code est facilement réutilisable, il sera réutilisé. Créer un environnement qui encourage la réutilisabilité.
13. Eliminate Effects Between Unrelated Things Concevez des composants indépendants et qui ont un but unique et bien défini.
14. There Are No Final Decisions Aucune décision n’est gravé dans la pierre. Voyez-les plutôt comme inscrites dans du sable à la plage et préparez-vous aux changements.
15. Use Tracer Bullets to Find the Target L’utilisation de “balles traçantes” permet de raffiner vos idées en essayent des choses et en voyant comment elles se comportent en situation réelle.
16. Prototype to Learn Le prototypage est une expérience d’apprentissage. Sa valeur n’est pas dans le code que vous produisez mais dans les leçons que vous pouvez en tirer.
17. Program Close to the Problem Domain
Concevez et codez dans le langage de vos utilisateurs.
18. Estimate to Avoid Surprises
Estimer avant de commencer. Vous ferez remonter les problèmes potentiels à la surface
19. Iterate the Schedule with the Code
Utiliser l’expérience acquise au cours du projet pour affiner vos estimations.
20. Keep Knowledge in Plain Text
Contrairement à des formats fermés, le “plain text” ne peut devenir obsolète. De plus, il facilite le debuggage et les tests.
21. Use the Power of Command Shell
Ne sous-estimez pas la puissance des commandes Shell face aux interfaces graphiques.
22. Use a Single Editor Well
L’éditeur de texte devrait être une extension de vos mains. Assurez-vous que votre éditeur est configurable, extensible et programmable.
23. Always Use Source Code Control
Un gestionnaire de versions est une machine à voyager dans le temps pour votre travail : vous pouvez revenir dans le passé.
24. Fix the Problem, Not the Blame
Peu importe si un bug est votre faute ou celle d’un autre, ça reste toujours votre problème et il nécessite toujours d’être corrigé.
25. Don’t Panic When Debugging Prenez une grosse inspiration et réfléchissez sur la cause du bug.
26. “select” Isn’t Broken
Il est rare de trouver un bug dans le système d’exploitation ou dans le compilateur, ou même dans une bibliothèque tierce. Le problème est plus vraisemblablement dans l’application.
27. Don’t Assume It, Prove It
Prouver vos intuitions dans l’environnement du projet avec les données réelles et les conditions limites.
28. Learn a Text Manipulation Language
Vous passez la majeure partie de votre journée à travailler avec du texte. Pourquoi ne pas laisser l’ordinateur en faire un peu à votre place ?
29. Write Code That Writes Code
Les générateurs de code augmente votre productivité et évite la duplication d’information.
30. You Can’t Write Perfect SoftwareIl n’y a pas de logiciel parfait. Protéger votre code et les utilisateurs des inévitables erreurs.
31. Design with Contracts
Utiliser la notion de contrat comment documentation et pour vous assurer que votre code ne fasse ni plus ni moins que ce qu’il prétend.
32. Crash Early
Un programme mort fait normalement moins de dégât qu’un programme estropié.
33. Use Assertions to Prevent the Impossible
Une assertion valide vos hypothèses. Utilisez-les pour protéger votre code d’un monde incertain.
34. Use Exceptions for Exceptional ProblemsRéservez les exceptions aux choses exceptionnelles.
35. Finish What You Start
Quand c’est possible, une routine ou un objet qui alloue une ressource devrait aussi être responsable de sa désallocation.
36. Minimize Coupling Between Modules
Évitez le couplage en écrivant du code “timide” et en appliquant la Loi de Déméter.
37. Configure, Don’t IntegrateImplémentez les choix de technologies pour une application avec des options de configuration plutôt que par de l’intégration.
38. Put Abstractions in Code, Details in Metadata
Programmez pour le cas général et placer les spécificités en dehors du code compilé.
39. Analyze Workflow to Improve Concurrency
Utiliser la concurrence pour améliorer les flux de votre application.
40. Design Using Services
Concevez en termes de services : des objets indépendants, concurrents derrière des interfaces bien définies et cohérentes.
41. Always Design for ConcurrencyAutorisez l’accès concurrent et vous concevrez des interfaces plus propres avec moins d’hypothèses.
42. Separate Views from Models
Gagnez en flexibilité facilement en concevant vos applications en termes de modèles et de vues.
43. Use Blackboards to Coordinate Workflow
Utiliser des “tableaux noirs” permet de coordonner des faits et des agents très différents tout en maintenant l’indépendance et l’isolation des différents participants.
44. Don’t Program by Coincidence
Ne compter que sur des choses fiables. Méfiez-vous des complexités accidentelles et ne confondez pas une heureuse coïncidence avec un plan bien déterminé.
45. Estimate the Order of Your Algorithms
Ayez une idée de combien de temps vont prendre vos routines avant de les écrire.
46. Test Your Estimates
L’analyse mathématique de vos algorithmes ne vous dit pas tout. Essayez de mesurer votre code dans l’environnement cible.
47. Refactor Early, Refactor Often
Tout comme réarranger un jardin et enlever la mauvaise herbe, réécrivez, retravailler et revoyez l’architecture de votre code quand c’est nécessaire. Attaquez-vous à la racine du problème.
48. Design to Test
Commencer à réfléchir aux tests avant d’écrire la moindre ligne de code.
49. Test Your Software, or Your Users Will
Tester impitoyablement. Ne laissez pas les utilisateurs trouver les bugs pour vous.
50. Don’t Use Wizard Code You Don’t Understand
Les assistants peuvent générer des portions de code. Soyez sûr de les comprendre dans leur globalité avant de les intégrer dans votre projet.
51. Don’t Gather Requirements, Dig for Them
Les besoins émergent rarement tous seuls. Ils sont souvent enfouis sous des couches d’hypothèses, de méconnaissance et de politique.
52. Work with a User to Think Like a User
C’est la meilleure façon de voir comment un système est utilisé dans des conditions réelles.
53. Abstractions Live Longer than Details
Investissez dans l’abstraction, pas dans l’implémentation. Les abstractions peuvent survivre aux changements d’implémentations et de technologies.
54. Use a Project Glossary
Créez et maintenez une source unique de tous les termes et vocabulaire spécifiques au projet.
55. Don’t Think Outside the Box, Find the Box
Devant un problème impossible, identifiez les contraintes réelles. Demandez-vous : “Est-ce que ce doit être traité de cette façon ? Est-ce que ça doit être fait tout court ?”
56. Start When You’re Ready
Vous augmentez votre expérience toute votre vie. Ne sous-estimez pas vos doutes et votre petite voix intérieure.
57. Some Things Are Better Done than Described
Ne tombez pas dans la spirale de spécifications, à un moment il faut commencer à coder.
58. Don’t Be a Slave to Formal Methods
N’adoptez pas les yeux fermés n’importe quelle technique sans la confronter avec le contexte des pratiques et capacités de développement de votre projet.
59. Costly Tools Don’t Produce Better Designs
Méfiez-vous des super vendeurs, des dogmes de l’industrie et de l’aura des prix. Jugez les outils sur leurs mérites.
60. Organize Teams Around Functionality
Ne séparez pas les concepteurs des codeurs et des testeurs. Construisez vos équipes comme vous construisez votre code.
61. Don’t Use Manual Procedures
Un script exécutera les mêmes instructions dans le même ordre, jour après jour.
62. Test Early, Test Often, Test Automatically
Des tests joués à chaque “build” sont beaucoup plus efficaces que des plans de tests qui dorment sur une étagère.
63. Coding Ain’t Done Until All the Tests RunTout est dit !
64. Use Saboteurs to Test Your Testing
Placer des bugs volontairement dans une copie du code source pour vérifier que vous tests les capturent.
65. Test State Coverage, Not Code Coverage
Identifier et tester les états significatifs de votre programme. Tester seulement les lignes de code n’est pas suffisant.
66. Find Bugs Once
Une fois qu’un testeur humain trouve un bug, ça devrait la dernière fois qu’un humain trouve ce bug.
67. English is Just a Programming LanguageÉcrivez vos documents comme vous écrivez votre code : respectez le principe “DRY“, utilisez les metadata, MVC, génération automatique, etc
68. Build Documentation In, Don’t Bolt It On
La documentation écrite en dehors du code a peu de chance d’être correcte et à jour.
69. Gently Exceed Your Users’ Expectations
Commencez par comprendre les attentes de vos utilisateurs, et ensuite délivrez-leur à peine plus.
70. Sign Your Work
De tout temps, les artisans sont fiers de ce qu’ils produisent. Vous devriez l’être aussi.

No comment yet.
Scooped by Mickael Ruau
December 5, 2021 1:24 AM
Scoop.it!

The Greatest Software Development Books of All Time - DZone Web Dev

The Greatest Software Development Books of All Time - DZone Web Dev | Devops for Growth | Scoop.it
This list is not complete, as there are always some new and good books, but these ones made the most impact in the careers of many software developers.
No comment yet.
Scooped by Mickael Ruau
November 3, 2021 10:52 AM
Scoop.it!

Home: Rescue the Problem Project

Home: Rescue the Problem Project | Devops for Growth | Scoop.it
Home page for the bestselling book Rescue the Problem Project
No comment yet.
Scooped by Mickael Ruau
November 3, 2021 10:48 AM
Scoop.it!

Book review: Rescue the Problem Project •

Book review: Rescue the Problem Project • | Devops for Growth | Scoop.it


Todd Williams’ book, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure, really does live up to its name. If you were ever in doubt about how to spot a project teetering on the brink of going ‘red’, then this is the book for you.
A five step recovery approach

Williams presents a five step approach to project recovery. The steps are:

Realisation: you must recognise that there is a problem before you can attempt to solve it.
Audit: carry out an objective project audit to determine the problems.
Analysis: analyse the data from the audit to establish root causes and begin to form the solutions.
Negotiation: mediate between the parties involved to establish an acceptable solution.
Execution: implement the recovery plan.
No comment yet.
Scooped by Mickael Ruau
October 21, 2021 9:04 AM
Scoop.it!

10 Books Every New Software Developer Should Read - DZone Web Dev

10 Books Every New Software Developer Should Read - DZone Web Dev | Devops for Growth | Scoop.it
Here is a list of the best books new software developers can learn from. I’ve selected books with long-lasting advice that will remain relevant for many years.
No comment yet.
Scooped by Mickael Ruau
October 8, 2021 1:52 AM
Scoop.it!

Diversity and Complexity | Princeton University Press

Diversity and Complexity | Princeton University Press | Devops for Growth | Scoop.it

This book provides an introduction to the role of diversity in complex adaptive systems. A complex system — such as an economy or a tropical ecosystem — consists of interacting adaptive entities that produce dynamic patterns and structures. Diversity plays a different role in a complex system than it does in an equilibrium system, where it often merely produces variation around the mean for performance measures. In complex adaptive systems, diversity makes fundamental contributions to system performance.

Mickael Ruau's insight:


Scott Page gives a concise primer on how diversity happens, how it is maintained, and how it affects complex systems. He explains how diversity underpins system level robustness, allowing for multiple responses to external shocks and internal adaptations; how it provides the seeds for large events by creating outliers that fuel tipping points; and how it drives novelty and innovation. Page looks at the different kinds of diversity — variations within and across types, and distinct community compositions and interaction structures — and covers the evolution of diversity within complex systems and the factors that determine the amount of maintained diversity within a system.

 

    • Provides a concise and accessible introduction

 

    • Shows how diversity underpins robustness and fuels tipping points

 

    • Covers all types of diversity

 

  • The essential primer on diversity in complex adaptive systems
No comment yet.
Scooped by Mickael Ruau
September 27, 2021 6:15 AM
Scoop.it!

Agile Adoption Mistakes, Agile Lessons Learnt, Agile Book

Agile Adoption Mistakes, Agile Lessons Learnt, Agile Book | Devops for Growth | Scoop.it

Table of Contents

  1. Waterfall Organization - Agile Projects
  2. Scrum Master As Project Manager
  3. Scrum Master On Auto Pilot
  4. Opaque Product Backlog
  5. Ungroomed Product Backlog
  6. A Definition That Doesn't Lead To Done
  7. Undone Work - Long Releases
  8. Teams That Aren’t Cross Functional
  9. Organization Vs. Self-Organization
  10. Sprint Zero - Waterfall Reborn
  11. Absent Product Owner
  12. Split Product Lifecycle Responsibility
  13. Sprint Review Mini Anti-Patterns
  14. Retrospective Mini Anti-Patterns
  15. Daily Scrum Mini Anti-Patterns
  16. You Get What You Measure
  17. Ad hoc Agile
No comment yet.
Scooped by Mickael Ruau
September 27, 2021 6:08 AM
Scoop.it!

Linda Rising on "Fearless Change" Patterns

Linda Rising on "Fearless Change" Patterns | Devops for Growth | Scoop.it
In this interview made by Floyd Marinescu, co-founder of InfoQ, Linda Rising talks about the book "Fearless Change: Patterns for Introducing New Ideas" and offers examples of how the patterns presented in the book can ease the stress of Agile adoption.
Mickael Ruau's insight:
 
   

6. Continuing with the scenario, how do you convince them to take an idea?

You bring in the cookies and some people will be convinced just because they are innovators and they like new ideas and some people will be convinced by the fact that the innovators are excited and you brought in the right kind of chocolate chip cookies, so you are slowly making headway. Other people on the technical environment are often convinced because they are early adopters and they need evidence.

So you might have a book, that you bought at QCon, about DSL or whatever the practice is that you want to introduce, and you say "Look, I have got this book, written by Martin Fowler who is a really famous guy and everybody has heard of him", and for some people that is convincing, the fact that there are experts who have written books or you might have some articles that you picked up in your presentation or tutorial that you attended and so that is sort of external validation -that is the name of the pattern-. People are convinced by a publication, a sort of a certification, a stamp of approval.

If Addison-Wesley or InfoQ published this, it must be OK, so it is convincing to them. Some people look to that kind of influence. So you have got the innovators, who like new things, you have got the people who sit down and eat chocolate chip cookies, you have got the people that like external validation, you are building steam, you are gaining ground. So, what convinces other people, in your experience? What convinces you? A good technical argument.

And some people want to see a good technical reason. There are certainly technical people who may believe that this is what they want to see, but you can forget about that. So one of the things that you can do in your brown bag, while you are serving the cookies, is actually go through some of the technical arguments for the good ideas. And some people will be convinced by that. Other people, who like technical arguments, are still not going to be won over unless they know that there is a local guru, someone they all respect - every organization has someone like that - and if they know that that particular guru says "You know, this stuff sounds pretty good. I think it looks like we might try it at least."

   

7. Is one of your patterns "Convince the guru"?

Yes. It is called "guru on your side". So, if you have the brown bag, the first person you might invite would be the local guru and give it a little head start because gurus do not get to go to conferences. They are too valuable. They are always working on 6 or 7 projects and they are loaded with deadlines, so they never let them out. They want to hear about this stuff, so you can overwhelm them, you can make them feel bad that they didn't get to go to the conference, but you give them a little preview, so when they come to the brown bag they already know enough, so they can nod at the right time and validate what you are saying and everybody in the room will be looking to the guru and say "Wow, he likes it, and we are having cookies and the innovators are excited" so they get caught up in that.

   

8. What comes next? Once you have had your meeting and you have raised the buzz, then what?

Nothing convinces people more than experience. And of course, you have just been at QCon and you have never done Agile development or whatever the new thing is, so you get maybe some available innovator, or maybe now somebody who is a little more open and say "You know, maybe we could try, just an experiment, pair programming. I am working on this particular part of the project. Would you like to try that with me? And then we could see how it works for us, so a little trial run, just a little experiment". And then, if it works, if it really does work, you have an ally because the two of you have tried it.

The friends of the ally who can hear "Yes, we tried pair programming, and here is what happened, and we really did discover something new that none of us would have thought of on our own. There really is benefit. Maybe we should try this on a larger scale". So a little experiment and then tell everybody about it, maybe have another brown bag to say "Hey, Floyd and I have been trying this pair programming and here are some of the benefits that we have seen. Maybe the rest of you would like to do, just try it. It is just an experiment" - so trial run. People are afraid of change, they don't want you to come in and say "We are going to do something totally different. Throw out everything you are doing now and we are going to do Agile stuff". Most people like to try something in the way of an experiment, and once they have tried it, not only is the experience convincing but - again this is a brain thing - why do they, when you go in to buy a new car, let you drive around the block? Because somehow that is your car, just for a little bit. And once you have tried it, you are more likely to buy it.

When you go buy a suit, or a jacket you are going to try it on. If they don't let you try it on, you are not likely to buy it. If they let you have the time and the space to try it on, see how you like it, you are much more likely to buy it. No pressure: if you don't like it, you don't have to buy the jacket. But if you try it on, they know you are very likely to take it home. So you get the innovators, the guru, all the people who follow the guru, people like chocolate chip cookies, people are convinced by reports of success, and then, of course, you need to try it full blown, pilot, have somebody try it on a real project.

Help them out and you learn yourself how it works out, and stay in touch with everybody, tell them you are doing this. Don't make it a special thing, you know, like pilots backfire most of the time is that they hand pick people and when it works no one is surprised and say "You put Floyd on that project, no wonder that worked. But that wouldn't work for my project". So it is just got to be a sort of an experiment for that project with just ordinary developers on it, ordinary scenario, nothing critical risk. They will try it for an increment or two, then let them tell us how it works.

No comment yet.
Scooped by Mickael Ruau
September 27, 2021 6:03 AM
Scoop.it!

Fearless Change

Even though change is difficult, leaders can't avoid it. So wouldn't it be wonderful if people who have successfully introduced a new idea into an organization could share their stories with you? Our book, Fearless Change: Patterns for Introducing New Ideas is the next best thing.

We have gathered proven strategies for leading a change initiative. To do this, we heard numerous experiences from people leading change in a variety of sizes and types of organizations throughout the world. While doing this, we documented our observations, read publications on the topics of change and influence, studied how change agents throughout history have tackled the problems they faced, and exposed our work for comment and feedback.

Change is hard. Leaders will struggle and so will the people they are trying to convince. But the stories of success we have heard show that there is hope. You need three things to introduce your idea: your belief in it, the determination to act on your belief, and some information on how to bring the idea into your organization. You supply the first two; the patterns in Fearless Change provide the third.

 

 

 

 

The book includes a complete version of the patterns, a framework for using them, and experience reports that describe how the patterns can help you introduce new ideas into your organization!

 

Mickael Ruau's insight:

Pattern Summaries

Book Appendix

These files are formatted for easy printing on index cards:

 

 

No comment yet.