DEVOPS
42.9K views | +59 today
Follow
 
Scooped by Mickael Ruau
onto DEVOPS
Scoop.it!

Appreciative Inquiry définition

Appreciative Inquiry définition | DEVOPS | Scoop.it
L’Appreciative inquiry est un outil de changement qui permet de découvrir ce qui va bien puis de bâtir sur la bases de ces forces. Plutôt que de regarder ce qui va mal, l’appreciative inquiry va chercher dans les organisations les racines profondes des succès passés et présents, génère des possibles et des plans d’actions pour concrétiser les rêves. En commençant  par des conversations à deux, l’appreciative inquiry explore ce que chaque personne apprécie le plus et désire ardemment puis se diffuse avec des groupes de plus en plus grands pour finir par une exploration collective du futur que le groupe veut créer ensemble.
more...
No comment yet.
DEVOPS
DEVOPS, agilité, tests, déploiement, sécurité
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...
Scooped by Mickael Ruau
Scoop.it!

Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018, présentées par Puppet et Splunk

Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018, présentées par Puppet et Splunk | DEVOPS | Scoop.it
La paternité du terme DevOps revient à un Belge du nom de Patrick Debois autour de 2009. Faisant suite à une frustration croissante lors de ses missions pour le compte du gouvernement belge à propos des conflits entre développeurs et administrateurs système.Historiquement, les DSI séparent les équipes de développement des équipes d'exploitation du SI (Operations en anglais d'où le Ops).Ces équipes ont des intérêts divergents, les développeurs souhaitent du changement (nouvelles technologies
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Qu'est-ce vraiment un Epic en Agile ?

Qu'est-ce vraiment un Epic en Agile ? | DEVOPS | Scoop.it
Une question qui pose débat dans l'univers de l'agilité et à laquelle je vais tenter de répondre : qu'est-ce vraiment une Epic en Agile ?
Mickael Ruau's insight:

Ce concept de user-stories n’est pas né avec le Scrum mais avec une autre méthode agile moins connue aujourd’hui appelée Extreme Programming (XP). Le Scrum a en effet emprunté cette façon d’écrire les « items » à l’XP car elles sont vraiment d’une efficacité redoutable.

Qu’est-ce qu’un Epic en Agile

Selon Mike Cohn

Dans l’XP, les Epics (Epopées) sont vulgairement des « Big user-stories » et rien de plus. Parce que cela serait trop simple, Mike Cohn parle même d’Epic pour parler d’une longue histoire qui sera peut-être découpée en user-stories (on en a même pas la certitude) pour être développée. Il est définit par un simple label.

Et pour Mike Cohn, les thèmes sont des ensembles de user-stories regroupées. En effet le regroupement successif « Thème » > « Epic » > « user-stories » qu’on a l’habitude de voir ne correspond pas à 100% à la définition de Mike Cohn.Si la user-story vient des travaux de Kent Beck lors du projet Chrysler C3, il était intéressant de voir l’avis de Mike Cohn qui a beaucoup partagé sur le sujet (contributeur du Scrum, fondateur de la Scrum Alliance). Cependant, ils sont tous d’accord avec cette définition pas totalement alignée avec celle qu’on au sein des entreprises.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Il était une fois scrum 2 | pablo pernot

Il était une fois scrum 2 | pablo pernot | DEVOPS | Scoop.it

Voici la suite de cette petite histoire de Scrum, qui je le rappelle est sans ambition : une façon de raconter Scrum, une variation sur un thème.

Nous avons démarré l’itération lors de notre précédente histoire (Il était une fois Scrum #1). Bref nous sommes dans la gadoue, au milieu du maul (car c’est bien d’un maul dont voulaient parler les japonais qui observaient un match de rugby et faisaient une métaphore avec leur dynamique d’équipe, et pas d’une mếlée (scrum)).

Durant cette itération le product owner valide au fil de l’eau quand c’est fini. Fini cela veut dire quoi ?

Mickael Ruau's insight:

Au fait, pas de business value sur les user stories, c’est intenable. Vous devez scinder une user story vous divisez par deux votre business value ou pas ? C’est le genre de questions qui font que je n’ai jamais réussi à maintenir une business value unitaire par user story. Un vrai casse tête chinois, et ce n’est pas franchement utile. Donc pas de business value sur les user stories. Vous pouvez représenter la business value a un niveau plus macro : epic/épopée, fonctionnalités/feature. La valeur aux yeux de product owner, cela sera sa priorisation.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

L'importance de la valeur de l'apprentissage dans la priorisation des fonctionnalités

L'importance de la valeur de l'apprentissage dans la priorisation des fonctionnalités | DEVOPS | Scoop.it
En Agile, la priorisation se fait toujours par rapport à la "valeur d'affaire". Ce terme est souvent un terme vague, ou vaguement défini. Par ailleurs, Mike
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Adopter la facilitation comme style de Leadership

Adopter la facilitation comme style de Leadership | DEVOPS | Scoop.it
Selon Michael Doyle*, Deux leçons ont été apprises dans les dernières décennies concernant le développement et le changement en entreprises : La
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Book review: Code Simplicity by Max Kanat-Alexander – planetgeek.ch

Book review: Code Simplicity by Max Kanat-Alexander – planetgeek.ch | DEVOPS | Scoop.it

A short, simple book about what makes software complex, how to prevent that and therefore keep software simple. This book contains rules and facts about software regarding code simplicity. The problem of the book is that either you probably know most of its content or you think that it doesn’t work anyway (I got this impression while reading through the reviews on Amazon). Anyway, I think it is worth the time and helps to reflect on one’s own way of coding.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Téléchargez Gratuitement la bande dessinée "Nous sommes des développeurs professionnels" !!

Téléchargez Gratuitement la bande dessinée "Nous sommes des développeurs professionnels" !! | DEVOPS | Scoop.it

Voilà! Nous avons fini les principes et le livret de la bande dessinée “Nous sommes des développeurs professionnels” est maintenant disponible à télécharger gratuitement et à partager en masse!
On arrive à la fin de cette Bande dessinée, et le travail peut commencer maintenant!
si vous abordez à ces principes et que vous voulez vous améliorer personnellement et en équipe la dessus. essayez ceci :

  • imprimez le document.
  • ramenez le lors d’une réunion en équipe (retro ou autre)
  • discutez du sujet portant sur le professionnalisme
  • si l’equipe aborde, faites un premier pas en considérant les principes un à un.
  • donnez vous du temps pour pratiquer
  • posez des questions, challengez et adaptez votre vision

cela me ferait plaisir d’avoir du retour de votre experience la dessus! envoyez moi un message sur anis.berejeb@gmail.com et je serai content d’en discuter avec vous!

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

What Color is your Backlog?

At the recent SDC conference in Wellington Prof Philippe Kruchten delivered a talk titled “What Color is Your Backlog”. The thrust of his talk is about bringing a focus on architecturally significant aspects of software into Agile projects, along with delivering the functional components of the system. He uses a color metaphor to illustrate the importance of addressing four types of work.
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Dealing with combinatorial explosions and boring tests

This presentation explains parameterized tests, theory tests, and generative testing. It also explains single mode faults and double mode faults and shows how …
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Core Protocols - A workshop

The core protocols are a set of attitudes and simple behavioral rules that help teams work better together. It's especially suited to help foster great meeting…

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

User Story Workshop

Slides supporting a User Story workshop I used at Spotify
Mickael Ruau's insight:

La différence entre des users stories et des spécifications, et comment des user stories ouvertes se révèlent plus adapatées pour satisfaire les utilisateurs.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Book review: Effective Debugging – 66 Specific Ways to Debug Software and Systems by Diomidis Spinellis – planetgeek.ch

Book review: Effective Debugging – 66 Specific Ways to Debug Software and Systems by Diomidis Spinellis – planetgeek.ch | DEVOPS | Scoop.it

The recipes are neatly grouped into chapters. Every recipe has a Things to Remember section at the end which wraps up the described technique.
Some of the recipes are very basic and should be in every developer’s arsenal; at least after having read the book. Some recipes are meant for the hard to crack cases while some may seem very obvious. I like the completeness of Diomidis Spinellis’ approach. It reminds us that successful debugging starts with mastering the basics. If you’re already familiar with a technique, you can always jump ahead to the Things to Remember section and continue with the next technique.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

10 ScrumMaster's failures | ScrumDesk, Scrum correctly

10 ScrumMaster's failures | ScrumDesk, Scrum correctly | DEVOPS | Scoop.it
Are you good ScrumMaster? Check typical 10 ScrumMasters's failures. ScrumDesk, the easiest scrum project management tool made for Wanna be great teams.
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Epopée ?

Epopée ? | DEVOPS | Scoop.it

Mike Cohn, dans sa bible des "user story", évoque le terme "epic" lorsqu'une story est trop importante pour être intégré dans un sprint. Elle doit être décomposée en user stories plus fines. Par exemple "En tant qu'internaute, je souhaite réserver un voyage en ligne" est une "epic". Il parle aussi d'epic à propos de user stories très complexes, ou qui nécessitent de plonger dans l'inconnu, sans vraiment avoir la possibilité d'une décomposition simple en stories plus petites. Il faut alors tâcher de les décomposer en story d'investigation d'un côté, et de mise en oeuvre, de l'autre.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Cessez de jouer à Tetris avec votre temps

Cessez de jouer à Tetris avec votre temps | DEVOPS | Scoop.it
La surcharge est mère de tous les vices dans la philosophie Lean (Muri). C'est une plaie qui afflige la plupart des travailleurs intellectuels que je croise. La surcharge est tellement perverse que si vous en souffrez, vous ne vous en rendrez compte que trop tard. Voici quelques exemples de ce à quoi vous vous exposez:…
Mickael Ruau's insight:

Sans être une règle ferme, de manière générale, avant de commencer une semaine, votre agenda ne devrait pas être rempli à plus de:

  • 10% à 20% si vous êtes un producteur dans la chaîne de livraison de valeur;
  • 30% à 50% si vous êtes dans un poste de gestion ou de soutien à une équipe de livraison de valeur;
  • 50% si vous considérez que votre métier, c’est d’avoir des rencontres (courtier, coach, médecin, etc.);
  • Presque vide si vous êtes un CEO ou à un haut niveau exécutif.

Ne vous inquiétez pas, la vie fera en sorte que tout ce vide se remplira de lui-même en cours de route. Il ne s’agit ici que d’activités « planifiées ».

Maintenant, assurez-vous de contrôler l’accès à votre précieux temps. Avant d’accepter une invitation à une rencontre:

  • Assurez-vous de savoir pourquoi elle a lieu;
  • Si c’est une rencontre de suivi, offrez de transmettre un état des lieux par courriel;
  • Demandez toujours si vous êtes requis;
  • Demandez si vous êtes requis pour la totalité de la rencontre;
  • Si c’est moins formel, offrez d’accompagner la personne prendre un café au lieu de réserver une plage horaire;
  • Demandez autour de vous si quelqu’un partageant votre expertise a plus de disponibilité que vous et déléguez;
  • Si vous êtes simplement requis pour valider une décision, faites confiance à vos experts.

Ne dites pas non à tout! Mais choisissez prudemment. Même quand il s’agit de votre gestionnaire qui vous convoque. Une demande ne signifie pas nécessairement une commande.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Appreciative Inquiry Commons

Appreciative Inquiry Commons | DEVOPS | Scoop.it

The “AI Commons” is a worldwide portal devoted to the sharing of resources and practical tools on Appreciative Inquiry and the rapidly growing discipline of positive change. This site is a resource for everyone– whether you are a leader of change, a manager, a scholar, a student, or a simply curious mind. You are invited to discover as well as share your own resources on positive change.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Agile 91

Les points-clés du rapport "The 21s Century 
Manufacturing Enterprise Strategy" de Nagel, Dove 
et al.. Écrit en1991 il décrit une agilité organisationnelle que nous cherchons encore à atteindre aujourd'hui…
"L’agilité est la caractéristique qui permet à une organisation de prospérer dans un environnement de changement constant et imprévisible."
Synthèse originale : https://esc.lehigh.edu/content/agility

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Téléchargez gratuitement le livret "Les tests d'acceptation"!

Téléchargez gratuitement le livret "Les tests d'acceptation"! | DEVOPS | Scoop.it


Le livret des "tests d'acceptation" reprenant les 3 articles Les tests d’acceptation – 1 – la Définition du Done!, Les tests d’acceptation – 2 –
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Un chausson avec cela?

Un chausson avec cela? | DEVOPS | Scoop.it
J’entre dans un restaurant. Le serveur poliment me demande : - « Qu’est-ce que ce sera aujourd’hui, pour monsieur? » - « Le plat du jour » lui demandais-je. Quelques minutes plus tard, le serveur me présente la recette. Je le regarde un peu perplexe et je réponds « Oui, c’est bien ce que j’ai…
Mickael Ruau's insight:

Comprenez bien qu’un restaurant fonctionne de façon itérative. À chacune des itérations, je reçois de la valeur « nutritive » ou autre. On m’apporte un verre d’eau, suivi d’un apéro, avec une entrée, ensuite vient le plat principal et pour finir un dessert. Je peux à tout moment dire que j’en ai assez et je paie pour ce que j’ai reçu. Lorsque j’ai donc assez de valeur.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Valeur Acquise Agile ?

Valeur Acquise Agile ? | DEVOPS | Scoop.it
Les divers modèles et cadres de travail Agile (DAD, SAFe, etc) contribuent à apporter beaucoup de rigueur à l'application de l'Agilité, mais on se retrouve quelques fois dans des contextes de grand projets ou dans des organisations qui utilisent et diffusent des concept de gestion de projet plus traditionnels bien ancrés dans leur culture. La Valeur Acquise…
Mickael Ruau's insight:

Est-ce souhaitable de suivre la valeur acquise Agile? Absolument. Par contre, personnellement, je n’y vois pas de pérennité souhaitable. Pour moi, la valeur acquise n’est qu’une mesure intérimaire que les projets devront utiliser pendant un bon bout de temps. Alors pourquoi l’utiliser en « Agile »?

  1. Parce que c’est familier et rassurant;
  2. Parce que c’est comptable;
  3. Parce que c’est facile;
  4. Parce que ça facilite la transition;
  5. Parce que ça génère quand même de superbes discussions, riches en contenu très concret.

On va l’avoir encore longtemps parce que nos organisations et la profession ne sont pas encore prêts ou pas encore équipés à migrer vers une conversation orientée sur la valeur d’affaires et le rendement.  Selon moi, une vraie reddition c’est une notion de rendement et non de progression, de coût ou d’épuisement de budget. Pourquoi? Parce que le rendement commande deux choses:

  1. Un choix sur la bonne valeur qui s’exprime par le choix des bonnes stories par le PO. Le facteur bénéfice attendu doit être limpide, et;
  2. Une rigueur d’exécution qui s’exprime non seulement par la livraison à haute vélocité des équipes, mais qui doit aussi interpeller toute l’organisation à les supporter dans la livraison de la valeur (le facteur moindre coût).

Les modèles de reddition devront évoluer vers ces réalités. Le vrai rendement est l’affaire de toute l’organisation et pas seulement celle des équipes de développement.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Release or be damned

Release or be damned | DEVOPS | Scoop.it
Back when I was still paid to code I had a simple question I posed to troubled development efforts: “Why can’t we release tomorrow?” This short simple question turns out to be amazingly powerful. I remember one effort I was involved with in California where a new CEO took over and started cutting jobs. I … Continue reading Release or be damned
more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Book review: Lean Architecture – for Agile Software Development by Jamey O. Coplien & Gertrud Bjornvig – planetgeek.ch

Book review: Lean Architecture – for Agile Software Development by Jamey O. Coplien & Gertrud Bjornvig – planetgeek.ch | DEVOPS | Scoop.it

This book claims a lot, and delivers little. There are several good tips in this book, but overall I simply don’t like it. I don’t like the “tone” it is written in.
There are only few books about Agile and Lean software architecture, therefore I cannot really give a better alternative covering the same topic.
Ultimately, that means you have to read it in case you are in any kind responsible for the architecture in an Lean/Agile set-up.

more...
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Business Patterns

Business Patterns | DEVOPS | Scoop.it
Business Patterns for Software Developers “Wow, the best reference set I have seen for people working on business issues” Mark P. McDonald review on Amazon.com “Essential reading for anyone new to the world of business software design!” Reuben Gathright review on Amazon.com “Best software creation and marketing book I’ve ever read!| Chen Sun review on … Continue reading Business Patterns
Mickael Ruau's insight:

Almost all the patterns in the book can be downloaded here in their post-conference form. The patterns were collected and re-edited for the book Business Patterns for Software Developers published in 2012.

Methods and Tools carried an article about software business patterns in 2013.

EuroPLoP 2011 (Irsee, Germany) – Two More Business Patterns (Business Strategy Patterns for Software Companies)

  • Customer Understanding
  • Customisable Product

EuroPLoP 2009 (Irsee, Germany) – Pattern vocabulary for Product Distribution (Business Strategy Patterns for Software Companies)

  • Branded Shops
  • Named Sales People
  • Internet Store
  • Independent Retail
  • Local Guide
  • White Label
  • Wholesaler

EuroPLoP 2008 (Irsee, Germany) – Business Patterns for Product Development

  • Single Product Company
  • Whole Product
  • Product Portfolio
  • Product Roadmap

VikingPLoP 2007 (Bergen, Norway) – Design Patterns for Software Companies (Product development)

  • Packaged Services
  • Account Management
  • Sales/Technical Double Act

EuroPLoP 2007 (Irsee, Germany) – Design Patterns for Software Companies (Product development)

  • Homogenous Customers
  • Same Customers, Different Product
  • Segmented Customers
  • Poacher Turned Game Keeper
  • Customer Co-created Product
  • Simpler Product

EuroPLoP 2006 (Irsee, Germany) – Design Patterns for Technology Companies

  • Products with Services
  • Corporate Certified Experts
  • Also: Situating Business Patterns – A paper exploring the relationship of patterns to other theories.

VikingPLoP 2005 (Espoo, Finland) – Business Strategy Design Patterns for Technology Companies

  • Start-up Services for Products
  • Continuing Services for Product
  • Complementor, Not Competitor
  • Services Trump Products
  • Services Before Product

EuroPLoP 2005 (Irsee, Germany) – A few more business design patterns

  • Self-Service
  • Core Product Only
  • Personal Service
  • Common Parts
  • Simple Product Variations

VikingPLoP 2004 (Uppsala, Sweden) – Business Strategy Patterns for the Innovative Company from Corporate Imagination and Expeditionary Marketing
(Hamel and Prahalad, 1991).

  • Innovative Products
  • Expeditionary Marketing
  • Separate Imaginative Teams

EuroPLoP 2004 (Irsee, Germany) – The Porter Patterns

  • Cost Leadership
  • Differentiated Product
  • Market Focus
  • Sweet Spot
  • One True Strategy
more...
No comment yet.