Ca Scrum !

Le projet marguerite a commencé, mais nous devons toujours faire vivre le projet précédent : le projet Chardon (Oui, Marguerite et Chardon sont dans le même pré d’application :p) Comme son nom le sous-entend, le projet Chardon est un projet critique pour l’entreprise, mais c’est un aussi un projet épineux ;) Avec le P.O, nous nous sommes posés la question suivante : Le projet Marguerite va nous occuper pendant plusieurs mois. Il ne nous parait pas possible de ne rien livrer pendant cette période sur le projet Chardon : son Backlog contient une centaine d’item, certaines importantes d’un point de vue business ! Alors comment s’organiser ? (suite…)

On continue le Sprint 0 ! Notre objectif est toujours d’avoir un Backlog, plus ou moins affiné selon les thèmes, mais valorisé et priorisé.

Nous avions, la semaine dernière, une collection de MindMap où chacun a présenté sa vision, ce qu’il avait retenu de nos visites. Pour arriver au Backlog, la première étape va être de synthétiser la contribution de chacun. Pour cela, l’équipe a proposé que l’on utilise des outils ultra modernes : Brown Paper, Post-it ! (suite…)

Ca Scrum ! va essayer d’être moderne. On va pouvoir piailler en utilisant les outils à la mode. Pour moi, ce sera une découverte … Il n’est jamais trop tard ;) http://twitter.com/cascrum

Aujourd’hui se termine le Sprint 0. (Durée du Sprint 1 semaine).

Quel était l’engagement de ce Sprint ? Obtenir 7 MindMap décrivant le projet Marguerite.

Quels étaient les critères d’acceptation ? Chaque MindMap devait être numérisé pour être projetable lors de la démo (ce matin) et imprimable afin de le mettre au mur pendant quelques jours encore.

Qu’avons nous livré ? Seulement 5 des 6 MindMap répondaient aux critères d’acceptation (pourtant très très simples :p). (suite…)

Cette semaine, j’ai découvert avec plaisir une nouvelle pratique, que l’on peut considérer comme agile : le FishBowl.

Dans Scrum, il existe 3 réunions : le daily StandUp (mélée quotidienne de l’équipe), le Sprint Planning Meeting (réunion de début de Sprint) et le Sprint Review (Revue de fin de Sprint). Cette semaine, nous avions en plus notre réunion annuelle (comme dans beaucoup d’entreprise) où les équipes se rassemblent, présentent leur travail, … En général, cela se déroule avec 3 heures de Slides projetés.

Cette année, la formule a changé ! (suite…)

Aujourd’hui, nous avons commencé le projet « Marquerite ». Comme je l’ai expliqué, ce projet commence par une phase de rencontre de nos utilisateurs sur leur lieu de travail. Objectif : découvrir leur manière de travailler et leur utilisation de l’outil actuel.

Sur le fond, la journée s’est bien déroulée. La première équipe était dans les Hautes-Alpes et nous dans la Drôme. Pour certains développeurs qui travaillent avec nous depuis plusieurs années, c’était leur première rencontre avec les utilisateurs ! Il était plus que temps !! (suite…)

Pour le nouveau projet (en cours de démarrage), les équipes techniques et les équipes métier vont ensemble se déplacer à la rencontre des utilisateurs pour faire émerger les besoins. Pour synthétiser ce que les équipes auront découvert, nous allons utiliser une MindMap.  L’objectif est d’obtenir rapidement (et visuellement) un retour, un échange construit dans le partage ! Cette démarche est une évidence pour nous car elle reprend quelques éléments de l’agilité :

• Toute l’équipe est acteur à tous les moments du projet. En effet, pourquoi se limiter à seulement 2-3 cerveaux (uniquement l’équipe métier) alors que l’équipe entière en possède 7 !
• MindMap : un outil visuel ! Le management visuel existe dans les pratiques agiles sous différentes formes : DashBoard, Kanban, Burndownchart, post-it, … Le MindMap paraît alors comme une évidence pour présenter et structurer de l’information … Mais surtout la communiquer ! (suite…)

Au démarrage d’un nouveau projet, il est toujours bon de se rappeler les dépendances des différents concepts et l’ordre dans lequel il faut les appréhender.
Pour cela, voici le schéma que j’ai en tête :

Que signifie cette roue ? (suite…)

Ahhhh, les outils ! Voilà LE sujet qui fait le plus souvent discuter ! Entre les « geek », prêts à tester tous les derniers outils en version béta et les frileux — on peut aussi dire « puriste » :) — ; on est sur d’avoir des discutions animées dans l’équipe !
Nous développons des applications web, avec une technologie J2EE.

Mais quels sont les outils qui nous aident à être agile ?
Pour ce qui est de la partie « Suivi de projet » (backlog, burndownchart et autres indicateurs) nous utilisons pour le moment un joli fichier Excel : simple, efficace.

Pour ce qui est de la partie intégration continue (et déploiement automatisé en recette et production), nous utilisons Hudson et des scripts Ant. Dans un prochain article, je détaillerai notre organisation, les difficultés et les solutions que nous avons trouvés ! (Nous avons réduit de 90 % le temps passé à la construction et l’installation des applications et sensiblement amélioré notre qualité de livraison).

Enfin, ce qui est une nouveauté dans nos équipes, nous faisons des tests automatisés ! Pour cela, nous utilisons JUnit et Selenium pour la gestion des tests automatisés. Là aussi, différents articles sont prévus. Il existe de nombreux très bons tuto pour « installer » Sélenium and co. En revanche, peu de retour d’expérience sur la rédaction (et le lien avec les User Stories), la maintenance et l’organisation des tests ! Je vais modestement essayer d’apporter ma contribution :)

La construction d’une équipe est, pour moi, l’un des moments les plus intéressant mais aussi l’un des plus critiques.  J’ai toujours pensé qu’il y avait plus de chance qu’une équipe arrive à produire du logiciel si l’équipe « fonctionne » bien (même si elle manque de compétence) plutôt qu’une équipe d’expert ou de Geek mais qui sont incapables de travailler ensemble.

Dans notre entreprise, nous avions jusque là 2 équipes : une équipes MOE (une dizaine d’informaticien répartis sur différents projets) et une équipe MOA (5 experts métiers, eux aussi sur différents projet). Comment s’organiser lorsque l’on met Scrum en place ? Comment faciliter la transition ? Parmi les experts métier, un seul Product Owner (Facilement identifié, c’est déjà une très bonne nouvelle !). Mais que deviennent les autres membres de l’équipes ? Pour cela, j’ai proposé que l’on considère les anciens membres de la MOA comme des membre de la Team ! Certes, ils sont un peu spécialisés (ce qui est une entorse à Scrum, ce sera la seule). (suite…)