L'Agilitateur - En français - Commentaires

Accusé, levez-vous ! - JM.D

JM.D — Tue, 15 Jul 2008 00:11:25 +0200

Et ce qui me plait encore plus dans le "plaisir" comme objectif c'est que l'on ne peut l'imposer à personne ! Mais cela pourrait-il être suffisamment tentant pour attirer nos "faiseurs d'heures" ??

Accusé, levez-vous ! - JM.D

JM.D — Sat, 21 Jun 2008 12:53:49 +0200

Je suis d'accord, il faut remporter l'adhésion de l'équipe avant de commencer. La proposition de tendre vers un "pur plaisir de coder" (http://www.sigmat.fr/index.php?post...) est-elle envisageable comme moteur ou comme motivation individuelle ?

XP Day France 2008 - Norman Deschauwer

Norman Deschauwer — Wed, 07 May 2008 17:33:04 +0200

Bonjour, j'ai participé à cet évenement et j'en sors assez satisfait des conférences, elles sont de qualités et on y rencontre beaucoup de personnes interressantes.
La france, le Luxembourg, la Belgique, la Suisse et encore d'autres pays étaient présents.

Très encourageant.

MOE et MOA sont dans un bateau - Michel Brack

Michel Brack — Mon, 29 Oct 2007 11:28:54 +0100

Bonjour,

Votre article n'est pas faux dans l'ambiguïté qu'il détecte dans l'utilisation des termes MOA et MOE entre un chantier de BTP et un chantier informatique.

Pourtant, si le béton nécessite un plus grand soucis de conception détaillé et d'organisation, c'est que les engagements diffèrent. Cela dit, la croissance des projets informatiques, l'escalade des budgets requis et la multiplication de prestataires spécialisés intervenant sur un même projet nécessite une organisation de même nature.

Mais je ne comprends pas en quoi l'informatique devrait se garder d'utiliser les expressions et les définitions de maîtres d'ouvrage et de maîtres d'oeuvre. Car au fond, et vous le dites trés bien, c'est de cela dont il s'agit ;
De la relation entre celui qui conçoit des services à partir de l'analyse des besoins et qui est responsable de la bonne fin des travaux (entre autre puisqu'il y a aussi la gestion des différentes parties tiers du client), et de celui qui va réaliser en concevant techniquement et en développant ou en mettant en place les outils nécessaires.

Cela ne nuit en aucun cas aux méthodes agiles, d'avoir un cahier des charges extrèmement précis, voir trés poussé techniquement et d'un autre côté des spécifications techniques intelligibles qui peuvent être validées.

Pour avoir gérer la réalisation de logiciels "on line" en l'occurence sans compilation, je ne crois pas moi que les plans de la maison soit le logiciel terminé. Car s'il s'agissait de cela alors je pourrais reconstruire cent fois par projet le même logiciel sous l'influence du client comme du prestataire ou des équipes techniques. Cela économiquement n'est pas acceptable.
Ce n'est pas une perte de temps que de faire des plans car à la différence du BTP, quand nos plans sont faits, il nous reste la capacité de les faire évoluer, de les "upgrader". Il est nécessaire qu'un "arbitre" puisse définir le sens de l'évolution pour que ce ne soit pas n'importe comment, pas à n'importe quel coût et surtout pas pour intégrer toutes les nouvelles idées glanées ici ou là au fil de l'expérience ou de la mode technologique.

L'agilité sans rentrer dans un débat de méthodes, c'est d'avoir la capacité de se remettre en question tout au long d'un projet, notamment en laissant évoluer les idées à mesure du développement et d'écouter aussi les retours de l'Utilisateur (le client dans ses différentes composantes).

Le rôle d'un MOA et notamment quand il s'agit d'un consultant externe à l'organsisation cliente (là je prêche pour ma paroisse), c'est pour moi, justement, de favoriser la souplesse en conservant la volonté du cadre défini. En somme, une main de fer dans un gant de velour, côté client, comme côté réalisateur.

NETtement votre.

[ping] Deuxième livraison - scrum-france.net

scrum-france.net — Tue, 18 Sep 2007 11:48:44 +0200

Communauté : Septembre 2007

A l'occasion du lancement de la coupe du monde de rugby, Claude Aubry nous rappelle les valeurs communes de Scrum avec ce sport d'équipe. Restons ouverts grâce à jc-QualityStreet qui suit de près les relations entre Scrum et CMMI. Suite de la......

[ping] Nouveau scénario - scrum-france.net

scrum-france.net — Tue, 11 Sep 2007 16:02:37 +0200

Communauté : Septembre 2007

A l'occasion du lancement de la coupe du monde de rugby, Claude Aubry nous rappelle les valeurs communes de Scrum avec ce sport d'équipe. L'agilitateur Olivier Azeau continue sa démonstration de TDD avec le développement de son podcast......

Les exigences non satisfaites, le cancer du logiciel - Vickoff

Vickoff — Thu, 12 Jul 2007 16:06:31 +0200

Comme je ne vois pas comment vous joindre, je me permets de poster ici que je développe une vision haute de l'agilité dont la première communication globale pour l'Agile Alliance se trouve sur http://www.entreprise-agile...

[ping] Les exigences non satisfaites, le cancer du logiciel - Frédéric Monjo weblog

Frédéric Monjo weblog — Wed, 27 Jun 2007 09:04:52 +0200

Prévenir le syndrôme du client qui en veut toujours plus

Olivier Azeau, alias l'Agilitateur, fait un parallèle sur son blog entre la quantité d'exigences croissante de la part d'un client le long du projet et la prolifération de cellules cancéreuses pendant un traitement radiothérapiqu...

SIGMAT 2.0 - Camille Bloch

Camille Bloch — Mon, 19 Mar 2007 09:33:26 +0100

J'ai personnellement été très content d'y participer (je venais de montpellier) et si ma société est OK pour que j'y retourner, je participerais au prochain!

Merci de diffuser votre présentation, elle sera appréciée au sein de mon équipe et de mes "supérieurs"

MOE et MOA sont dans un bateau - oaz

oaz — Thu, 08 Mar 2007 22:19:13 +0100

Le plus drôle dans tout ça, c'est que ceux qui font cette mode sont probablement ceux qui en savent le moins sur la fabrication de voitures.

Le système de production de Toyota, qui est en passe de devenir le 1er constructeur mondial de voitures, est quand même une des racines principales du mouvement des méthodes agiles dans le logiciel...
http://fr.wikipedia.org/wik...

MOE et MOA sont dans un bateau - Aurélien Pelletier

Aurélien Pelletier — Thu, 08 Mar 2007 07:48:39 +0100

pas faux. Et pourtant le mot à la mode est industrialisation... On voudrait fabriquer des logiciels comme on fabrique des voitures dans une usine, de manière "industrielle".

Scrumification - claude

claude — Mon, 22 Jan 2007 13:43:06 +0100

Sur la plupart des projets on manque de présence des clients. Vous avez la chance d'en avoir 3 presque à plein temps, c'est positif. En contrepartie cela nécessite une couche d'organisation supplémentaire pour s'assurer qu'ils sont sur la même ligne. Ce que j'essaie de dire c'est que pendant un sprint il peut y avoir besoin de réagir vite et que cette couche supplémentaire peut ralentir l'avancement. Mais vous verrez bien dans votre contexte à vous.
Merci pour la police !

Scrumification - oaz

oaz — Sun, 21 Jan 2007 22:03:44 +0100

Mais alors que faire quand une seule personne n'a pas l'ensemble des compétences nécessaires pour :
- décider des priorités des diverses exigences ?
- connaître les besoins détaillés des utilisateurs ?
- connaître les contraintes techniques et organisationelles du terrain ?
- ....

Dans mon contexte actuel (et même ceux que j'ai connus dans le passé), une seule personne ne peut pas fournir l'ensemble des réponses dont ont besoin les membres de l'équipe au quotidien. Il en faut obligatoirement plusieurs. C'est la raison pour laquelle, d'une manière ou d'une autre, il faut que ces personnes qui constituent collectivement la "direction de produit" soient sur la même ligne de pensée.
Une solution serait de mettre une seule personne en point d'entrée unique sur la gestion de produit pour l'ensemble des membres de l'équipe de développement mais un tel choix me fait surtout penser à un goulot d'étranglement qui ne va pas du tout dans le sens "Individuals and interactions over processes and tools".

Scrumification - Claude

Claude — Sat, 20 Jan 2007 13:14:11 +0100

Ma première phase est pas finie (les petits caractères ne facilitent pas la relecture).
Je voulais dire :
On fait une séance en groupe (Planning poker) pour estimer le coût avec un consensus de l'équipe et de façon symétrique on peut faire un workshop pour définir les priorités avec les différentes personnes intéressées par le produit (stakeholders).

Scrumification - Claude

Claude — Sat, 20 Jan 2007 13:10:40 +0100

On fait une séance en groupe (Planning poker) pour estimer le coût avec un consensus de l'équipe et de façon symétrique on peut faire un workshop pour définir les priorités avec les. Mais dans la vie de tous les jours il y a des décisions à prendre sur le produit (ou des tests à spécifier) qui ne peuvent pas attendre la tenue d'une réunion . C'est pour éviter de retarder le travail d'un sprint que je préconise un seul directeur de produit.
Euh, la police est toujours aussi minuscule.

Scrumification - oaz

oaz — Fri, 19 Jan 2007 23:29:39 +0100

J'ai modifié la taille de la police dans la boite de saisie des commentaires. Cela devrait être plus lisible.

Scrumification - oaz

oaz — Fri, 19 Jan 2007 23:28:42 +0100

J'ai surtout l'impression que l'on dit plus ou moins la même chose avec un angle de vue différent. Quand je parle de "non-unicité du directeur de produit", c'est pour justement mettre en avant que plusieurs personnes (un petit groupe), avec ce qu'elle peuvent apporter par rapport à leur vécu du produit participent à sa définition et, en ce sens, toutes ces personnes peuvent légitimement dialoguer avec les développeurs.
Dire que les membres de l'équipe ne doivent entendre qu'une voix ne signifie pas forcément que cette voix soit celle d'une seule personne ! On peut considérer la situation symétrique : il est préférable que la direction de produit entende une seule voix quand il s'agit de donner un coût à une exigence (sans cela, impossible de prioritiser). Pourtant, cela n'implique pas qu'un seul membre de l'équipe soit habilité à estimer ce coût !

Scrumification - Claude

Claude — Fri, 19 Jan 2007 12:00:20 +0100

C'est une bonne chose que plusieurs personnes du côté client (produit) participent au projet. Cela n'est pas contradictoire avec un directeur de produit unique. Il reste comme argument l'autre raison que j'évoquais.
J'arrête mon commentaire ici parce que cette boîte pour l'écrire est vraiment trop petite et avec des caractères minuscules !

Scrumification - oaz

oaz — Thu, 18 Jan 2007 21:47:08 +0100

Sur les 3 personnes évoquées, une seule n'est pas à temps plein (marketing produit) mais va approcher, je pense, les 50%. Les 2 autres sont à temps plein.
A mon avis, dans mon contexte (édition de produit logiciels pour plusieurs dizaines voire centaines de clients), un directeur de produit unique est une illusion si l'on considère le besoin d'interaction avec le terrain (les clients, les commerciaux, les field engineers, ...) que doit gérer une direction de produit pour faire ses choix.
Le 'client sur site' présenté comme personne unique était une des critiques majeures de XP à ses débuts et cette notion a d'ailleurs plus ou moins disparu dans XPE2E.

J'en arrive même à me demander si l'esprit de Scrum ne serait pas applicable à une activité de gestion de produit : plusieurs personnes collaborant sur un travail dont le but est de produire un 'backlog de produit'. Pourquoi ce que l'on considère possible pour du développement logiciel ne serait pas possible pour cela ?

Scrumification - Claude

Claude — Tue, 16 Jan 2007 20:44:39 +0100

On pourrait discuter du groupé pénétrant...
Mais parlons Scrum. J'ai une réserve : avoir un comité de 3 personnes au lieu d'une seul directeur de produit ne me paraît pas une bonne idée, pour 2 raisons :
- il est préférable que l'équipe n'entende qu'une seule voix quand il s'agit d'avoir une réponse à une question
- un directeur de produit devrait être à plein temps ou presque sur le projet ce qui est probablement incompatible avec les fonctions évoquées