Scrum, Agilité et Rock'n roll - Commentaires

Innovation et jeux à Paris - Liz

Liz — Tue, 14 Feb 2012 10:33:23 +0100

Les méthodes agiles ont toute leur place dans les entreprises aujourd'hui. Et utiliser le jeu est un moyen "prenant" de s'y initier. Merci pour ce compte-rendu.

Scrum, un retour du terrain - Bourse

Bourse — Fri, 10 Feb 2012 20:51:45 +0100

Bonjour,

tombé sur votre blog après une lecture très instructive du Livre Kanban et Scrum de Henrik Kniberg et Mattias Skarin, nous avons basculé dans l'Agility et scrumons depuis plus d'un an déjà en utilisant Redmine.

Je découvre IceScrum et aurais aimé avoir votre avis éclairé d'expert sur cet outil par rapport à Redmine.

Vous en remerciant d'avance
Xavier
(toulousain également

Validation externe pendant un sprint - Yannick

Yannick — Fri, 03 Feb 2012 14:11:42 +0100

C'est ce que nous faisons : il y a une étape "validation équipe" au cours de laquelle un membre de l'équipe valide les stories avant de me les soumettre (validation PO).
Un membre de l'équipe ne prend pas de nouvelle story s'il y a dans l'espace "validation équipe" une story à laquelle il n'a pas participé (principe de validation croisée).

Innovation et jeux à Paris - fierfeu

fierfeu — Thu, 02 Feb 2012 11:31:16 +0100

Un grand merci pour cette journée très enrichissante.
ROTI : 4

Retour à froid : il ne me manque qu'une articulation de ces jeux entre eux si elle existe ...

J'envisage de faire un billet sur le sujet.

Merci a tous, participants et animateurs, pour ce que vous m'avez appris.

Et n'oubliez pas de rêver ...

Stéphane

P.S. : Pour les droits à l'image n'oubliez pas le chèque ...

Merci à toi. Les boites n'ont pas de droits...

Innovation et jeux à Paris - Mathieu

Mathieu — Wed, 01 Feb 2012 10:55:12 +0100

Merci pour cette bonne jouée très instructive ... il ne reste plus qu'à mettre en pratique !

Les billets auxquels vous avez échappé en 2011 - Avangel

Avangel — Sun, 29 Jan 2012 23:42:48 +0100

Ahhh la fameuse page Wikipédia J'y ai jeté un oeil de temps à autre, et je suis également perplexe de voir qu'elle n'a pratiquement pas évolué, si ce ne sont quelques corrections mineures. Pourtant, si les bases sont probablement correctes, je pense que les pratiques ont bien évolué, que l'expérience à confirmé certains points et contredit d'autres, et que cette page mériterait donc une révision en profondeur... Tu voudrais bien nous raconter ce que tu en penses ? Peut-être que ça suscitera de la motivation pour des contributeurs qui ne se sont pas encore révélés ?

Validation externe pendant un sprint - Marco66

Marco66 — Mon, 23 Jan 2012 17:36:29 +0100

Merci pour ce billet tout à fait édifiant sur la phase de validation.
Une question me vient à l'esprit, ne serait-il pas possible de rajouter au ScrumMaster une fonction supplémentaire de "pré"validation de la story. Cela permettrait d'alléger la charge du PO et de s'assurer que les fonctionnalités de base sont correctement implémentées ou qu'il n'y a pas d'anomalie par rapport au backlog de produit ?

Suivi des ventes - Geoffrey Etwein

Geoffrey Etwein — Fri, 20 Jan 2012 10:17:30 +0100

Bravo.
908 sur 1 400 000 !!! Pas mal en rêveraient je pense.

Ca vous apprendra à écrire un livre efficace, utile et accessible !

Validation externe pendant un sprint - Yannick

Yannick — Tue, 17 Jan 2012 11:39:14 +0100

Merci pour le billet, il résume bien l'enjeu de notre développement : être à temps pour la mise à dispo des entrées du sprint (notion de prêt) et avoir les ressources pour vérifier/valider en continu...
Le travail de coordination prend beaucoup de temps, mais petit à petit, le process s'améliore, notamment en organisant les rencontres entre l'équipe et les référents métiers. Affaire à suivre...

Validation externe pendant un sprint - Rémy

Rémy — Mon, 16 Jan 2012 20:36:21 +0100

J'aime l'idée que les conditions de validation fonctionnelle sont dans la définition de Prêt en entrée du sprint. Du coup, la validation finale est beaucoup plus factuelle et on n'attend rien qui vient de l'extérieur.
J'aime l'idée que c'est le PO qui donne le travail à faire, et ces conditions de validation, donc il est le seul à valider SUR LA BASE DE CE QU'IL AVAIT DEMANDE AU DEBUT (et pas des idées que lui ou d'autres ont eu entretemps!).
Charge à lui de bien "capturer" le besoin en amont.
Ceci permet que chacun soit bien dans son rôle.

Mercenaire et bâtisseur - pablo

pablo — Sun, 15 Jan 2012 09:04:18 +0100

Hello,

Il me semble que historiquement les bâtisseurs étaient des personnages itinérants... compagnons, maîtres bâtisseurs, etc...

*nous* sommes donc les bâtisseurs, il est un sénéchal ? :p

Mes (bonnes) intentions pour 2012 - Alexandre C

Alexandre C — Fri, 06 Jan 2012 15:41:38 +0100

Claude, Je te souhaite une bonne année. J'espère que tu trouveras le temps et la force de t'investir dans toutes ces nobles activités !

Bon courage.

Quizz, réponse à la question 14 - dragrubis

dragrubis — Mon, 19 Dec 2011 10:54:40 +0100

Ben ici on a amélioré l'environnement de travail pendant les sprint, certaines personnes devenant dédiées à ces tâches. Ça à été une expérience... Enrichissante.

Quizz, la question 13 sur le burndown chart - Remi

Remi — Thu, 15 Dec 2011 16:37:04 +0100

Merci jef , je n'avais pas pensé à la contrainte de l'équipe par le PO .

Matrice d'adaption de l'agilité au contexte - pablo

pablo — Thu, 15 Dec 2011 08:35:58 +0100

intéressant Claude.
C'est la réflexion que je cherche à appronfondir en ce moment. Je vais aussi faire une ou deux prez sur le sujet. Cela vaudra le coup de comparer nos approches même si je le vois ton premier article à 4 ans d'avance !
Je suis has been (comme en musique :p )

Quizz, la question 13 sur le burndown chart - Jef

Jef — Tue, 13 Dec 2011 22:09:44 +0100

@Remi. Pratiquant le SCRUM et XP comme méthode de développement, je pense pouvoir te répondre en te disant que le rythme de travail est primordial (constant et régulier). Le rajout des quelques jours manquants est une mauvaise pratique, car elle a tendance à contraindre l'équipe à finir absolument, qui induit souvent à une mise sous pression de la part du PO et autres managers. Le fait d'être avec une date, une qualité et aussi un coût fixe (l'équipe est fixe en cours de Sprint en général et on ne gagne pas forcément à la faire grossir en cours de sprint), nous jouons sur le périmètre du Sprint. Le rythme est soutenu mais régulier et on réalise les Users Stories sur lequel on s'est engagé. L'agilité est une pratique qui se vit au quotidien et on y apprend les travers de non respect de cette méthode au fils du temps. Voilà le travers que l'on découvre avec ce genre de tentation de rallonger les Sprints.

Quizz, la question 13 sur le burndown chart - Rémi

Rémi — Wed, 07 Dec 2011 09:39:21 +0100

Merci pour votre retour, OK, mais quand je parlais de tâches non prévues, c'etaient des tâches du Sprint Backlog pour réaliser des Stories acceptées par le PO qui n'avaient pas étaient identifiées lors du Sprint Meeting.

il est vrai qu'il est préférable dans la mesure du possible de supprimer des Stories pour présenter un travail finalisé.

Afin de mieux comprendre, quel élément vous dérange dans un décalage de 2j d'un Sprint de 4 semaines , si au final le PO est satisfait du résultat ?

Quizz, la question 13 sur le burndown chart - Remi

Remi — Mon, 05 Dec 2011 18:01:02 +0100

Le timeboxing est intéressant car il donne un rythme de travail , mais typiquement dans le cas de tâches non prévues en début de Sprint et si bien évidement ces tâches sont importantes dans les fonctionnalités à présenter lors de la demo , il me semble intéressant de prologer de quelques jours la durée du Sprint ! Il me semble que c'est toujours mieux que d'arriver devant le PO et de présenter un travail mal fini .

Non, on ne prolonge jamais la durée du sprint. Pour éviter d'avoir du travail mal fini, il est préférable d'enlever une (ou plusieurs) story et de bien faire les autres. Une autre remarque : ce n'est pas une bonne idée "d'arriver devant le PO" à la revue de sprint; à cette revue on ne montre que les stories déjà acceptées par le PO, pendant le sprint.

Quizz, la question 13 sur le burndown chart - Dorothée

Dorothée — Mon, 05 Dec 2011 10:32:59 +0100

Bonjour,
Mais qu'est ce qui fait remonter un burndown ? Qu'il ralentisse, je comprends, mais pas qu'il remonte.
On a ajouté des tâches ? On en a réévalué d'autres ?

oui, ce sont 2 raisons possibles. Une autre est l'ajout d'une story.

Quizz, la question 13 sur le burndown chart - Oaz

Oaz — Sun, 04 Dec 2011 21:10:45 +0100

Je prends la réponse 5 : on supprime les burndown charts car ça ne sert à rien.