processus

Préface de Kanban pour l'IT, deuxième partie

Suite de la préface de Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition. Cette deuxième partie évoque les approches processus pour montrer en quoi Kanban est différent. Représentation de processus Il y a une quinzaine d’années, je m’intéressais de près aux notations, langages, modèles et méta-modèles (UML, SPEM, BPMN) pour représenter les processus. On retrouve dans Kanban les mêmes notions de rôle, activité et élément de travail, mais avec une approche bien différente :

Un guide pour l'adoption et la transformation agile

La transformation, pour être agile, passe par la culture. InfoQ publie régulièrement des minilivres. J’ai d’ailleurs participé à la traduction en français de l’un d’entre eux, celui d’Henrik Kniberg[1] Fin juillet, InfoQ a publié An Agile Adoption and Transformation Survival Guide de Michael Sahota. Avec 2 préfaciers comme Jurgen Appelo et Henrik Kniberg, ça donne envie de lire. Et puis le sujet m’intéresse : lors de la présentation, avec Philippe Kruchten, l’Agilité en situation, à l’Agile tour Toulouse 2008, nous abordions les problématiques de transition en fonction du contexte,

Fiches et guides Scrum

La semaine dernière, une participante à ma formation m’a demandé des fiches résumant les rôles et les pratiques Scrum. C’est quelque chose qu’on ne me demande pas souvent en formation ou accompagnement. Il faut dire que cette participante n’avait pas reçu mon support de cours; elle n’avait pas encore lu mon livre non plus. Des descriptions de rôles et de pratiques, j’en ai écrites, qui pourraient aller sur des fiches. Il y en a même sur ce blog, dans une catégorie dédiée, puisqu’elle s’appelle Guides Scrum.

Des sprints pour une release

Chapitre 2 Mon éditeur (Dunod) m’a demandé de commencer à réfléchir à une deuxième édition de Scrum, le guide pratique de la méthode agile la plus populaire. Oh, on a le temps, c’est pour une publication au printemps en automne 2011. Une 2ème édition peut inclure un éventuel nouveau chapitre, mais le plus usuel est d’améliorer et d’ajouter des paragraphes à ceux existant. Je commence par le chapitre 2 : Des sprints pour une release.

Une story doit être prête pour entrer dans un sprint

Pour avoir de bonnes chances d’être finie finie à la fin du sprint, la story doit être prête prête au début du sprint. J’aime bien décrire les comportements avec des états. En 2007, j’avais écrit un billet sur les états significatifs d’une story. On y voit la vie de la story, en particulier que : La story doit être prête pour entrer dans un sprint, et, si tout va bien, elle sera finie en sortie du sprint.

Présentation de Scrum pour l'Agile Tour à Toulouse

Des racines à la ScrumMania Je fais de nombreuses présentations de Scrum. Rien que pour les séminaires SigmaT organisés à Toulouse (et à Montpellier), j’ai fait une introduction à Scrum presque à chaque fois. Cette fois pour l’Agile Tour, j’ai fait une nouvelle présentation, intitulée Scrum : des racines à la ScrumMania. Comme Scrum est maintenant beaucoup plus connu, j’ai préféré revenir sur les racines et montrer l’évolution plutôt que d’expliquer la mécanique, comme je le fais d’habitude[1].

Sprint zéro

Attention ce n’est pas un vrai sprint, c’est l’échauffement. Avant de commencer le premier sprint, il y a une période de temps utilisée à préparer ce qui est nécessaire au lancement des sprints dans de bonnes conditions. Jusqu’à récemment, je désignais cette période sous le nom de phase, pour la distinguer de la phase des sprints. Je disais simplement phase de préparation et c’est que j’ai utilisé dans le plugin Scrum pour EPF.

L'Agilité oui, la chienlit non !

Des utilisateurs brimés depuis longtemps pas les DSI découvrent que l’agilité peut accueillir et même favoriser les changements, ce qui les amène à penser qu’ils peuvent tout changer tout le temps. Des managers se disent qu’avec l’agilité, il sera plus facile de demander de traiter une urgence ou du travail supplémentaire non prévu à leurs équipes de développement. Ben non. L’agilité favorise le changement, mais ne le rend pas gratuit ni permanent.

Guide Scrum

Pour apprendre Scrum, la façon la plus efficace est probablement de suivre une formation et d’appliquer aussitôt. D’autres choisiront l’apprentissage individuel avec les quelques livres et les nombreux articles disponibles sur Internet. Les livres imposent une approche séquentielle et les articles ne forment pas un tout cohérent, ce qui n’est pas l’idéal pour accéder à un processus, même simple comme Scrum. La présentation d’un processus sous forme de site Web est une bonne solution pour pallier ces inconvénients.

Le plugin Scrum pour EPF, version 2008

Il y a presque 2 ans, j’avais développé un plugin Scrum avec le Composer d’Eclipse Process Framework. J’avais l’objectif d’ajouter des tool mentors pour IceScrum (j’ai commencé avec la version 1 de IceScrum, maintenant abandonnée). La communauté EPF s’était montrée intéressée par mes travaux et je leur ai fait une donation en décembre 2006, qui avait été publiée sur le site EPF. Depuis mon plugin en français a été traduit en anglais.
Un petit retour sur le SigmaT4

Un petit retour sur le SigmaT4

C'était le 14 décembre...

Entre 40 et 50[1] personnes ont participé à ce quatrième SigmaT. A noter qu’une seule personne-à part moi- a participé à tous les SigmaT : c’est Frédéric. Pas mal de nouvelles têtes cette fois-ci. Des nouveaux très sympathiques et enthousiastes pour l’agilité et la convivialité : l’apéro a commencé à 18h45 et s’est fini à 20h15 : il ne restait plus que du jus de fruit. Après avoir rappelé l’esprit des SigmaT, j’ai fait une courte présentation de Scrum pour introduire la démonstration d’IceScrum.
Les cycles de vie Scrum et OpenUp

Les cycles de vie Scrum et OpenUp

Une release, c’est toujours une série d’itérations, avec, avant, une phase pour les préparer et, éventuellement, une phase pour les mettre en production après. Le cycle de vie d’OpenUp se présente comme celui du RUP, avec 4 phases successives : Inception, Elaboration, Construction et Transition. Dans chacune de ces phases, il y a une ou plusieurs itérations qui se déroulent toujours en séquence. Avec Scrum, la notion de cycle de vie est moins mise en évidence.

Les patterns d'adoption de l'agilité

La transition à une méthode agile se fait de différentes façons selon le contexte. Les façons de faire les plus fréquentes… Une organisation qui passe d’un processus pas vraiment agile à un processus plus agile doit choisir entre de nombreuses voies possibles. Il y a en effet de multiples pratiques agiles, touchant les différentes disciplines du développement et il faut choisir par lesquelles on va commencer. Au cours de ses expériences de consultant, Mike Cohn a identifié les patterns suivants pour des transitions à l’agilité :

EPF, une initiative de processus 'open source'

Des processus libres… Après avoir présenté il y a quelques jours une vidéo avec une interview de Per Kroll[1], InfoQ publie à nouveau un article sur EPF en mettant l’accent sur l’aspect communautaire du projet et en listant les travaux en cours, notamment les traductions des 3 processus[2] qui ont été publiés. Ils sont disponibles sur le site EPF et j’en avais parlé en son temps : OpenUp, Scrum et XP.

Modélisation agile de processus

Les principes de modélisation agile s’appliquent aux travaux sur les processus J’ai passé ma journée d’hier sur la modélisation d’un processus de gestion des incidents d’un centre de services d’un ministère, dans le cadre d’un alignement avec ITIL. La modélisation de processus, plus encore que la modélisation de logiciel, donne souvent des diagrammes très compliqués si elle ne suit pas les principes de la modélisation agile, en particulier Model with a purpose et Assume simplicity.

Transition aux méthodes agiles à grande échelle

Un big bang agile, c’est possible. La preuve. Par un billet de Agile Executive Blog, je découvre un article qui montre une expérience[1] exceptionnelle sur le passage d’un processus en cascade[2] à un processus agile. Généralement, pour la transition à un nouveau processus, on conseille de commencer par un projet pilote de quelques mois, de faire le bilan et de continuer progressivement. Ici c’est toute la R&D de Salesforce[3] qui est passée à l’Agilité en 3 mois !

OpenUP vs Scrum

On trouve de nombreuses reprises de Scrum dans OpenUP. OpenUP est le processus libre publié par la fondation Eclipse dans le cadre du projet EPF. La version 1.0 d’OpenUp vient de sortir. Cette nouvelle version montre un alignement important avec Scrum[1], au delà du vocabulaire. Ce qui vient de Scrum et qu’on retrouve dans OpenUP : des éléments de gestion essentiels comme : le backlog de produit, appelé Work Item List dans OpenUP, les burndowns, les réunions Scrum pendant l’itération et notamment :

Séminaire ITSMF

ITIL Agile ? J’étais ce matin à un séminaire organisé par l’ITSMF sur ITIL et ISO 20000. Vous allez me dire, quel rapport avec l’agilité, qui est le sujet de ce blog ? On y a bien parlé et abondamment de la roue de Deming, qu’on cite aussi dans les méthodes agiles et dont j’ai parlé dans un billet précédent. On y a bien mis en avant la nécessité de prendre en compte les besoins des clients pour la définition des services, et c’est aussi un des objectifs des méthodes agiles que de se rapprocher des clients.
Classification des processus

Classification des processus

Suite du billet sur les processus Agiles et pas Agiles. Comme le font remarquer avec pertinence Camille et Matthieu dans leurs commentaires, il n’existe pas un processus traditionnel standard, traditionnel pris ici par opposition à Agile. Certains, de moins en moins nombreux, suivent des processus très séquentiels, en tout cas sans livraison intermédiaire. La plupart des processus réellement suivis sont plus ou moins itératifs, comme on le voit dans ce petit sondage que j’avais fait l’année dernière.

Agile vs pas agile

Dans les séminaires ou dans les réunions, quand je présente l’agilité je montre les différences -généralement les bienfaits- par rapport à une approche … pas agile. Cela revient à séparer le monde des processus en 2 parties[1], ce qui est très schématique… De plus comment qualifier la partie non agile ? Par opposition à agile, les américains utilisent souvent waterfall ou classical waterfall. De mon côté, je ne vais pas, pour catégoriser le non agile, parler de cycle en V puisqu’il n’existe pas.