processus

Le cycle de vie d'un produit

Le cycle de vie d'un produit

Un pattern fractal basé sur l'approche scientifique

On peut suivre une approche agile de bout en bout en commençant par explorer le produit avec du Lean Startup avant de l’exploiter avec Scrum.

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, le chapitre 12 de mon livre présente plus en détail les attributs permettant de caractériser le contexte et l’impact sur les pratiques en particulier au niveau d’un projet, le chapitre 18 s’intitule la transition à Scrum, au niveau de l’organisation.

Fiches et guides Scrum

Je veux des fiches pour la méthode agile

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, et beaucoup.

Des sprints pour une release

Ce chapitre deux parle de cycle de vie pour développer un produit

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. J’utilise maintenant, pour suivre la tendance, le terme sprint 0 pour désigner cette période.

L'Agilité oui, la chienlit non !

L'agilité favorise le changement, mais ne le rend pas gratuit ni permanent

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.

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

Des restes de l'influence du RUP

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.