Discussion :

[Ricky81]

03/05/2010

Bonsoir,

J'ai le plaisir de vous annoncer qu'une version consultable en ligne de Scrum et XP depuis les tranchées est désormais disponible, toujours à la même adresse.

Si vous voyez des coquilles, n'hésitez pas à nous en faire part dans ce sujet.

Bonne lecture

04/12/2008

Bonjour,

Comme l'a fait remarquer Bruno sur son blog, une traduction de Scrum and XP from the Trenches a été faite bénévolement par Guillaume Mathias, Emmanuel Etasse, Christophe Bunn, et Bruno Orsier.

Vous pouvez donc le télécharger gratuitement sur l'hébergement Developpez.com créé à cet effet.

N'hésitez pas à poster à la suite vos impressions sur cet ouvrage.

Et bien sur, un grand merci aux 4 traducteurs pour cette initiative.

[hegros]

Alors voilà c'est un trés bon livre avant cela je me demandais un peu ce qu'était Scrum, il faut dire que je suis tout jeune dans les pratiques agiles et j'ai surtout utilisé (R)UP. Je me rends compte aussi que les pratiques agiles sont souvent interchangeable d'une démarche à une autre, par exemple l'intégration continu ou les tests(pratiques XP) sont utilisables dans Scrum ou même UP. J'ai également apprécié le vocabulaire, le mot sprint est vraiment un message fort. Le style de rédaction du livre est également plaisant et facilite la compréhension.


J'ai retrouvé principalement dans ce livre ce que j'ai retrouvé dans un autre livre qui s'appelle "Les 8 points clés de la conduite de projet" et je dois dire que Scrum est complet à ce niveau et trés moderne.

C'est ce qui me fait penser que Scrum se rapproche complétement d'une méthode de conduite de projet plus qu'une méthode d'analyse, de conception ou d'implémentation (ce que je pensais au départ décoré par de la conduite de projet)d'ailleurs le livre ne parle pas de ses disciplines.


voici mes impressions à chaud d'après les 8 points clés mentionnés ci-dessus


Les objectifs : Ils sont bien présents et abordés assez rapidemment au moment de la réunion de définition du sprint.

Le découpage : Principalement le découpage temporel et structurel, c'était court mais trés dense et intéressant.

Les estimations : C'est un des points qui est le plus remarquable car avec l'expérience cela semble vraiment plus réaliste de ce que je peux connaître. On peut sentir la capitalisation et la réutilisabilité de la démarche

La planification : J'ai apprécié énormément surtout lorsque le découpage revient à la charge pour faire entrer ce qu'il y a à faire dans un sprint

Le suivi et le contrôle : Enorme, les dessins dans le livre sont parlant d'eux même on ne peut qu'encourager

La documentation : Trés axé sur les documents de gestion de projet tandis que pour les documents de production je suis resté sur ma faim, quelques diagrammes uml cités pas de plus.

L'assurance qualité : Les tests et l'intégration continu en sont des exemples c'est un sujet difficile a aborder cependant souvent des allusions en font référence.

La gestion des équipes : Tout simplement génial et le livre insiste énormément dessus avec photos à l'appui, c'est surement le facteur clé de Scrum qui m'a plu le plus car enfin on tends vers du management moins directif et plus collaboratif et c'est d'autant plus un point positif pour la communication qui lui même est un facteur clé de réussite du projet. D'ailleurs dans un profil risque de projet on voit souvent apparaître une estimation pour la criticité de la stabilité de l'équipe. Scrum prends en compte cet aspect en premier plan.


Voilà j'espère ne pas en avoir trop dis ou pas assez mais je le relirais certainement pour mettre en pratique certains éléments

[Ricky81]

Le livre est désormais hébergé sur Developpez.com pour notre plus grand plaisir

[David Gimelle]

Scrum et XP depuis les tranchées est vraiment un excellent livre.

Simple et complet , il montre tres bien le quotidien d un projet Scrum.

On y trouve pleins d idees pour mettre en oeuvre scrum de maniere efficace.

A lire absolument.

[Bruno Orsier]

Scrum et XP depuis les tranchées est vraiment un excellent livre.

Simple et complet , il montre tres bien le quotidien d un projet Scrum.

On y trouve pleins d idees pour mettre en oeuvre scrum de maniere efficace.

A lire absolument.

Merci pour ce retour. C'est en effet un livre à lire et relire !

C'est ce livre qui m'a encouragé à travailler sur les dojos agiles dont je parle dans mon blog

Bruno

[Antoine_935]

Très bon bouquin, qui m'a réellement donné envie d'en découvrir plus sur cette méthode de travail.

Merci beaucoup !

[sironimo]

J'étais un néophyte en ce qui concernait les méthodes agiles quoique je pratiquais déjà une forme de XP. Cet ouvrage m'a permis de découvrir le SCRUM et les possibilités d'organisation qu'il offre.

Le gros avantage qui ressort de cet ouvrage est la transposition dans des cas concrets que l'on rencontre au quotidien et ça c'est vraiment ludique, la théorie d'accord mais de pouvoir poser ça sur des exemples concrets et détaillés, ça fait la différence pour moi.

L'auteur précise bien et c'est aussi important que c'est son approche du SCRUM, chacun doit donc l'adapter à sa "sauce" dirons-nous.

Cet ouvrage est donc pour moi une vraie référence, j'en remercie d'ailleurs l'auteur ainsi que les traducteurs pour leur travail.

Seul petit bémol, il y a quelques points où je reste un peu sur ma faim suite aux nombreuses lectures, notamment sur l'organisation : en effet, les méthodes agiles prônent l'aplanissement de la hiérarchisation or dans un cas de choix technique sur un développement à faire, qui est en charge d'arbitrer la décision si les discussions mènent à une impasse ? au SCRUM master, au chef de produit ? une tierce personne ?
De plus, il y a le côté un peu "exécutif" réservé aux développeurs. En effet, ces derniers sont soumis à des sprints durant lesquels ils doivent produire et la place à la réflexion est minime, si ce n'est lors des fameuses journées "labo".

Tout cela pour répéter à nouveau que l'approche de M. Kniber est la sienne et ne peut être transposée telle quelle à n'importe quelle société et n'importe quel service de développement.

En tant que SCRUM master débutant, je continue chaque jour à apprendre, à essayer d'améliorer et d'adapter le SCRUM à notre fonctionnement pour que chacun y trouve son compte.

Enfin pour les réunions de début de sprint ou de debriefing, je conseille aux futurs utilisateurs de bien se préparer car le temps passe très vite et notamment pour la réunion de début de sprint, une réunion "expédiée" peut avoir de graves répercussions sur le sprint en lui-même.

ps : je suis un peu comme M. Kniber en ce qui concerne les différents supports : backlog de produit, histoires et tâches, courbe de burndown, etc. à savoir je fais tout à la main. Peut être est-ce une perte de temps mais cela me permet de chaque jour bien contrôler l'avancée des développements.

[Bruno Orsier]

Seul petit bémol, il y a quelques points où je reste un peu sur ma faim suite aux nombreuses lectures, notamment sur l'organisation : en effet, les méthodes agiles prônent l'aplanissement de la hiérarchisation or dans un cas de choix technique sur un développement à faire, qui est en charge d'arbitrer la décision si les discussions mènent à une impasse ? au SCRUM master, au chef de produit ? une tierce personne ?

L'équipe a la responsabilité dans un tel cas d'identifier et d'inviter toute personne compétente pour les aider. Au ScrumMaster de se débrouiller pour faire en sorte que cela se passe.

De plus, il y a le côté un peu "exécutif" réservé aux développeurs. En effet, ces derniers sont soumis à des sprints durant lesquels ils doivent produire et la place à la réflexion est minime, si ce n'est lors des fameuses journées "labo".

Au contraire je trouve que les sprints comportent une part de réflexion très importante, dans le pair-programming, les sessions impromptues de conception devant le tableau blanc, les discussions continuelles avec les représentants des clients...

Sinon, merci pour le retour positif sur la traduction.
Bruno

[batataw]

Merci pour la traduction, ca m'a aidé a améliorer certains points.

Petite Reflexion:
Les taches qui sont trop abstraites ne peuvent etre inscrites dans le scrum.
On ne peut pas écrire de story pour le Product Owner car elles ne sont pas liées au business.
Exemple: Modéliser la base de données ou effectuer un benchmark...

Le probleme est que ces taches consomment beaucoup d'energie. J'ai choisi de les lisser. C'est a dire que si elle prennent 4 unité. Je répartis ces 4 unité sur 4 story qui dépendantent de cette tache.

Dans le livre il préconise d'essayer de les insérer dans le scrum comme une story a part entiere mais il faut batailler avec le PO.

Quelle est la meilleur pratique pour inserer ces taches indispensables mais beaucoup trop abstraites ou inutiles pour le PO?

[Bruno Orsier]

Dans le livre il préconise d'essayer de les insérer dans le scrum comme une story a part entiere mais il faut batailler avec le PO.

Quelle est la meilleur pratique pour inserer ces taches indispensables mais beaucoup trop abstraites ou inutiles pour le PO?

C'est vrai que c'est difficile, et plus généralement c'est difficile pour toutes les contraintes non fonctionnelles. Mais il faut tout de même parvenir à convaincre le PO. Ne pas oublier non plus que le scrummaster a assez explicitement la mission d'éduquer le PO sur les aspects qui sont difficiles pour lui, soit sur la méthode, soit sur ces aspects qui semblent ne pas avoir de valeur.

Toute tâche devrait être reliée à quelque chose qui a de la valeur pour le client, donc à une user story.

Par exemple, pourquoi veux-tu faire un benchmark ? Peut-être pour étudier la performance. Dans ce cas c'est que la performance a de l'importance pour les clients, donc pour le PO. Si ca n'a de l'importance que pour toi, eh bien en effet il n'y a pas de place pour cette activité dans Scrum !

Modéliser la base de données ? Peut-être que le schéma de la base fait partie des livrables (le client l'exige) ? Donc dans ce cas ca fait partie de ta définition de "DONE", et il faut simplement l'inclure dans tes estimations, ie chaque story pour être terminée doit comporter une tâche de mise à jour du schéma.

J'espère que ca te donne des pistes.
Bruno

[batataw]

Merci pour tes precieux conseils, j'ai essayé et ca a plutot bien marché.

Chaque story non fonctionnelle en creusant bien a une relation avec une story fonctionnelle. Quand c'est vraiment impossible de trouver une relation je créé une story quand meme et je prends du temps pour l'expliquer au PO.
Le PO comprenant plutot bien la technique ca passe comme une lettre a la poste. L'important au final c'est qu'il sente que c'est utile pour le projet et que ce n'est surtout pas un caprice de développeur.

[Bruno Orsier]

J'ai remarqué que le livre traduit apparaît dans cette vidéo, ca fait plaisir !

(lisez aussi le reste du billet qui est un excellent retour d'expérience Scrum).

Bruno

[Ricky81]

Bonsoir,

J'ai le plaisir de vous annoncer qu'une version consultable en ligne est désormais disponible, toujours à la même adresse.

Si vous voyez des coquilles, n'hésitez pas à nous en faire part dans ce sujet.

Bonne lecture

Eric

[kenji_getpowered]

Merci pour ce document. Très instructif et vivant.

Un point qui n'est pas assez développé à mon gout et qui est (toujours à mon gout) très important est : comment bien intégrer les exigences du client? Comment les formuler? Que faire quand ça change? Comment le gérer?

En tout cas, tout ces conseils, ces retours d'expériences sont bons à prendre et vont directement intégrer ma façon de gérer un projet Scrum.

[apieum]

Merci pour ce document. Très instructif et vivant.

Un point qui n'est pas assez développé à mon gout et qui est (toujours à mon gout) très important est : comment bien intégrer les exigences du client? Comment les formuler? Que faire quand ça change? Comment le gérer?

En tout cas, tout ces conseils, ces retours d'expériences sont bons à prendre et vont directement intégrer ma façon de gérer un projet Scrum.

Il y a cet article sur les changements pendant un sprint
et ce livre sur Scrum et Kanban

Sinon je suis d'accord c'est un must have.

[kenji_getpowered]

@Apieum : Merci pour ces liens.
J'ai mis le blog de claude Aubry dans mon blog roll

Je me suis inscrit à SigmaT et j'ai assisté à l'atelier "Cucumber".

Merci pour les infos.

[thierryler]

A lire et à relire.