Retour sur la première session Open Space praticiens agiles

Le praticien agile, c’est qui  ?

Il a lu « Scrum & XP from the trenches » un soir, il l’a gardé 2 semaines comme livre de chevet, il l’a rangé, et il a participé à un ou plusieurs projets agiles au sein de sa DSI. il a atteint un certain niveau de maturité sur les projets agiles et a pris du recul sur la méthode. Il se pose aujourd’hui des questions comme « Peut-on vraiment concilier TMA et agilité? »ou alors « Comment pérenniser la dynamique d’amélioration continue au sein de mes équipes » ou bien encore « Comment fluidifier les process en amont et en aval de mon équipe Scrum? », etc.

Le format Open Space c’est quoi ?

C’est un format ouvert sur une demi journée, où les participants proposent et choisissent eux-mêmes les sujets sur lesquels ils vont ensuite travailler par petits groupes lors de sessions de 40 minutes. A l’issue de chaque session, chaque groupe présente à l’ensemble de l’assemblée un compte-rendu des échanges. La philosophie de l’exercice est très bien décrite ici.

Et pourquoi un Open Space pour praticiens agiles ?

Parce que la communauté de praticiens agiles est de plus en plus grande et que nous, OCTO, constatons que les questions qui reviennent chez nos clients Agiles sont souvent focalisées autour des mêmes problématiques.

Après avoir organisé plusieurs ateliers découvertes de l’agile sur le format Open Space ces dernières années, nous avons donc organisé et animé une première session dédiée au praticiens agiles le 24 Novembre dernier, à laquelle ont participé des acteurs comme Médiametrie, FigaroCMS, Viadeo, Danone et Allocine.

(Lire la suite…)

DevOps ou le Lean appliqué aux activités IT du développement à la production

On a maintenant l’habitude de voir des principes du Lean Management derrière beaucoup des pratiques Agiles. Par exemple :

  • Les tests unitaires et l’intégration continue, sorte de Andon et de Poka Yoke à la fois ;
  • Les rétrospectives, support privilégié du Kaizen, sorte de cercle de qualité des équipes de développements ;
  • Les taskboards, « kanban boards » et autres radiateurs d’information comme outil de management visuel ;
  • etc.

Plus intéressant est l’exercice de voir les bonnes pratiques DevOps comme des instanciations du Lean Management aux activités de livraison, intégration, tests, déploiement, suivi du run.

Les analogies et principes sous-jacents du Lean pouvant alors nous aider à mieux comprendre la « magie » des pratiques DevOps ou même à en imaginer de nouvelles !

(Lire la suite…)

A la recherche de nouveaux vaccins

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

  • La personne propriétaire du portable l’éteint rapidement
  • Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? (Lire la suite…)

Animer une rétrospective projet

Le but d’une rétrospective projet est de prendre le temps de revoir quels ont été les moments importants du projet, les résultats qui ont été accomplis pour en dégager des observations, des leçons apprises et des bonnes pratiques pour les autres projets. Cet article fait suite à l’article animer une rétrospective d’itération. Couramment, la rétrospective projet se déroule en deux étapes, la première qui permet la construction de la timeline projet, la deuxième qui en permet l’exploitation. La durée d’une rétrospective projet est variable, de 3 jours à 1/2 journée, moins de 3 heures est irréaliste et inutile. Je constate que les équipes passent couramment 1/2 journée ou 1 journée.

(Lire la suite…)

Animer des rétrospectives d’itération

La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: « À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». Ritualiser cet événement permet de mettre en place un processus d’amélioration continue. Même si parfois, l’équipe a l’impression qu’il ne s’est rien passé, il s’est passé quelque chose, le plus important étant de garder cet espace de prise de recul.

Couramment, deux types de rétrospectives sont faites dans les projets agiles: les rétrospectives d’itération et les rétrospectives de release/projet. Cet article parlera des rétrospectives d’itérations et présentera 2 outils simples, le Keep Drop Start et la note d’itération.

Pour une rétrospective d’une itération de deux semaines, il est recommandé de faire une rétrospective de 2 heures, pour une itération d’une semaine, 1h.

(Lire la suite…)

ITIL v3: La gestion du cycle de vie de services

 

En 2007 ITIL (IT Infrastructure Library), a lancé sa version V3 en devenant le référentiel le plus répandu de bonnes pratiques pour le management de services informatiques (ITSM). Il se focalise sur le « comment » gérer chaque phase d’un service, en contraste par rapport à des autres référentiels qui se focalisent sur le « quoi », ce qu’on doit gérer.

ITIL v3 élargit le périmètre en donnant une vue “cycle de vie” des services, par rapport à sa deuxième version (v2) qui se focalisait sur les processus pour le Soutien de Services (Service Support) et la Fourniture de Services (Service Delivery)[i],

Cet article vous présente d’une façon globale ITIL à l’égard de la version 3 en montrant son but, les bonnes pratiques proposées pour gérer chaque phase d’un service et ce dont il faut tenir compte pour l’adoption de ce référentiel.

 

(Lire la suite…)

Le déploiement continu par Thoughtworks : Go!

Thoughtworks, le cabinet de conseil spécialisé dans les pratiques de développement agile et XP, faisait figure de pionnier de l’intégration continue lors de la sortie de leur outil d’automatisation de build CruiseControl il y a quelques années.
Cependant, la concurrence fut rude ces dernières années, notamment grâce à Hudson ou TeamCity, et CruiseControl apparaît aujourd’hui comme un outil fonctionnel mais sans plus.

La réponse de Thoughtworks ne s’est pas faite attendre longtemps: la sortie de Go, un outil de gestion du cycle de vie des applications exprime leur volonté de remplacer leur outil historique CruiseControl et de passer de l’intégration continue au déploiement continu ou continuous delivery: déploiement continu dans tous les environnements, y compris la production.

Nous allons aborder dans cet article ce qui caractérise cet outil, ses points forts et ce qu’on aurait aimé y voir.
(Lire la suite…)

Petit-déjeuner « Agilité et ERP » avec le témoignage de Danone, le 22 mars

OCTO organise un petit-déjeuner avec Danone et Open ERP sur le thème « Agilité et ERP » le mardi 22 mars 2011 de 9h à 11h à l’atelier BNP Paribas.

Vous pouvez vous inscrire directement sur notre site internet.

OCTO partage ses bonnes pratiques dans le livre Partageons ce qui nous départage

Y’a-t-il une clinique dans votre société ?

Est-ce que votre patron, comme dans le film Inception, lance une extraction pour vous récupérer en mission ?

En fin de réunion, organisez-vous un ROTI avec les participants ?

Un One on One avec votre manager relève-t-il nécessairement du harcèlement sexuel ?

« Typiquement » est-il réellement le mot le plus prononcé par les informaticiens ?

Une aventure collective : un livre, des auteurs

Partageons ce qui nous départage est un ouvrage collaboratif, écrit par une trentaine d’OCTOs, sur les petites recettes et les meilleures pratiques qui font la différence au quotidien, au sein-même de notre société et également chez nos clients. Et qui répond, accessoirement mais non sans humour, à ces multiples questions liminaires. (Lire la suite…)

Vers une supervision IT de la performance métier du SI (2/2)

Dans la première partie de l’article, nous avons vu comment la supervision pouvait apporter de la valeur à court terme au SI. Dans cette seconde partie, nous verrons comment la supervision peut permettre d’établir des services répondant à des besoins à plus long terme.

Pour cela on va utiliser la supervision pour capitaliser et modéliser.

(Lire la suite…)