Mois : avril 2012

FrenchSUG@Google

Le par addinquydans Compte-renduLaisser un commentaire

Avant-propos

J’ai mis du temps a écrire ce compte-rendu. Ce genre de travail est toujours plus long qu’on ne s’y attend en premier lieu. Anne gabrillagues m’a devancé de presqu’une semaine et a rédigé un excellent compte-rendu que vous retrouverez sur le blog Ippon. Anne est également présente sur Tumblr.

Dans le même ordre d’idées, je vous recommande aussi la lecture du Blog de Jean-Charles Meyrignac. Nous différons sur l’analyse de certains points et c’est d’autant plus intéressant, d’autant que le post est d’excellente qualité !

Google, c’est toujours un peu l’actualité en permanence. Si la présence de Petra Cross en France attire notre attention sur la place des femmes chez Google, je vous recommande aussi l’article sur Marissa Mayer sur IEEE Spectrum.

Vous retrouverez des photos de l’évènement sur Meetup. Place aux orateurs !

L’évènement

Le Scrum User Group Français était accueillis ce 17 Avril par Google, pour nous faire partager la pratique de l’agilité dans leurs équipes de développement. Un accueil excellent par ailleurs, avec beaucoup de gentillesse de la part de notre hôte, Martin Görner et un petit déjeuner offert. Nous étions certainement un peu serrés dans les locaux de l’avenue de l’Opéra, mais il faut dire que cet évènement a créé un engouement sans précédent, nous avions élargi le plus possible le nombre de places disponibles, mais malgré cela, toutes les places sont parties en une journée créant une liste d’attente assez conséquente sur Meetup.

Martin Görner

Après un (rapide) mot d’ouverture de votre serviteur, Martin Görner nous a servi en guise d’introduction un portrait savoureux d’une équipe de développement sur la base des personnages d’héroïc fantasy ! Avec dans l’ordre:

  • Les Barbares, à savoir l’équipe de développement.
  • Le Clerc, l’ancien qui a la connaissance et la sagesse.
  • Le Mages, capable d’opérer une magie que lui seul sait faire … mais qu’hélas aussi lui seul détient !
  • Le Maître, celui qui enseigne à l’équipe, diffuse sa connaissance et sa sagesse.
  • Les Amazones (si, si) Symbole de la diversité de l’équipe.
  • La Bête, celui qui va mettre dans vos projets un nouveau langage chaque jour. On n’en veut pas.
  • Le Scout, qui va explorer des territoires inconnus,
  • Le “dragon rider” qui comprend les aspects métier complexes.

Petra Cross : Behind the day to day at Google

Petra Cross en Bref

Petra travaille chez Google depuis 7 ans. Elle a débuté sa trajectoire sur le moteur de recherche, avant de rejoindre l’équipe GMail. Depuis cette année elle fait partie de l’équipe Google Wallet localisée à San Francisco.

Les équipes Google en quelques faits

  • L’engagement des membres des équipes ? “Achieve mission ! Whatever we’re doing !”
  • Les équipes: 10000 développeurs, répartis dans plus de 40 bureaux à travers le monde.
  • 20 “check in” par minutes
  • 50% de la base de code est modifiée chaque mois.

Les rôles

  • VP (vice-president) : Un par grand domaine de Google: Search, Social, etc…
  • Engineering Director 
  • Engineering Manager : Il gère les ressources et les personnes. Il n’opère pas de “micro-management”, mais opère selon le principe du “servant manager” cher à nos principes agiles.
  • PM (Product Manager) : C’est la personne qui a la vision client sur un projet. Il joue en gros le rôle du PO de Scrum
  • SWE (Software Engineer) : Ce sont les développeurs.
  • SWE / TL (Team Leaders) : Ce sont des développeurs comme les autres, mais ils jouent le rôle d’interface avec les autres équipes et avec le PM quand c’est nécessaire. Leur rôle est de faire gagner du temps aux autres développeurs en leur épargnant des tâches annexes. Il sont plus ou moins l’équivalent du Scrum Master de Scrum. Petra a joué ce rôle au sein des équipes Google Mail.
  • SET (Software Engineer in Tests) : Ce sont des développeurs dont le travail est spécifiquement focalisé sur l’intégration continue et les tests unitaires.
  • TE (Testers) : Leur travail est spécifiquement dirigé vers l’écriture de tests d’acceptante.

Chaque Engineering Manager gère un ensemble d’équipes formés typiquement de 6 personnes : 5 SWE et 1 SWE/TL. Les équipes ne sont pas complètement fixes dans le temps, le manager crée un peu de mouvement entre les équipes. On eut dire que ce concept se rapproche quelque peu des Feature Teams de Scrum.

Au niveau de l’agencement des locaux, Petra nous a montré quelques photos des locaux de San Francisco. Outre son propre poste simplement situé près d’une fenêtre donnant directement sur le Golden Gate Bridge, on voit que les développeurs sont regroupés en de larges open-spaces. Chaque poste de travail comporte typiquement une station de travail, souvent un PC fonctionnant probablement sous Linux, équipé de 2 écrans 24 pouces, et un portable qui peut être un MacBook ou un PC. Certains disposent l’affichage de leurs écrans 24’’ verticalement !

Le workflow du développement

Le développement est plutôt “orienté Kanban”, bien qu’il ne semble pas y avoir de limite de WIP explicite. C’est ce que Petra nomme “Features Development as a Queue”. Le workflow est le suivant:

  1. Idée
  2. Décliné en Feature
  3. Planifié
  4. En cours de travail
  5. En revue de code
  6. En test
  7. En beta test “Canary”
  8. En production Live !

Les développeurs sont responsables de la qualité du code qu’ils poussent dans le gestionnaire de version. Le code intégré dans l’intégration continue doit être totalement testé par le développeur qui le considère LGTM (Looks Good To Me).

Le Release Manager  a la responsabilité de prendre régulièrement un snapshot de code qui a passé l’étape “tests” et de le mettre à disposition en “canary build” pour 2 jours, afin que ces évolutions soient pleinement testées en situation réel par des beta testers. A l’issu de ces 2 jours, si le build est accepté, il passe en production !

Ce que Google cherche à faire avec son processus

C’est essentiellement gagner en efficacité, en:

  • Raccourcissant ce temps de cycle
  • Travaillant rapidement
  • En ne développant que ce qui a réellement besoin de l’être !

Ce que Google ne cherche pas à faire :

  • Echouer
  • Gaspiller de l’argent

Le processus de développement est en fait très largement “Kanban”, mâtiné d’itérations, comme on le verra bientôt.

Les User Stories sont définies et écrites par le PM. Sans que cela soit explicitement définit dans Scrum, les deux processus se rapprochent ici. Le PM évalue la taille de ses stories en utilisant des “PM points”. Les  users stories sont découpées en tâches par le PM et le Tech Lead. Oui, vous avez bien lu: l’équipe n’est pas directement impliquée (en tout cas pas en premier lieu) dans le découpage en tâches !

L’équipe fait ensuite, lors des planning meeting, l’estimation des tâches. Le PM n’est pas présent au planning meeting. Les tâches sont estimées par l’équipe, avec le teck lead. Le critère retenu est celui que nous connaissons bien avec Scrum: savoir quand la tâche est “done”. Si ce critère ne peut être clairement déterminé, c’est au Tech Lead de retravailler la tâche avec le PM. J’y vois une faiblesse du processus qui génère du délais dans ces cas, délais qui pourraient être éliminés simplement par la présence du PM lors des planning meetings ! Mais peut-être que ce problème ne se pose que très rarement ?

Tout cela est bien entendu géré. Mais plutôt que d’utiliser un outil de gestion de projet, c’est une simple feuille de calcul (Google Spreadsheet, bien sûr) qui est utilisée. Elle est divisée en 2 onglets :

  • L’onglet “PM” : Utilisé pour lister les users stories.
  • L’onglet “équipe” dans lequel on retrouve le découpage en tâches.

Les User stories suivent aussi un cycle de vie de haut niveau:

  • Icebox: C’est le congélateur. Les US qui ne seront pas prises dans les 2 ou 3 prochaines semaines sont simplement stockées ici sans être analysées plus avant. Pas question de perdre du temps sur des fonctionnalités dont on est pas sûr qu’elles seront implémentées un jour ! Implicitément cela en dit long sur la façon dont Google gère la notion de roadmap : il n’y a pas de roadmap ! Il y a bien une Vision, mais celle-ci n’est pas déclinée en roadmap / releases ! Le congélateur sert à garder trace des idées, à permettre de les exhumer quand ou si on veut les réaliser à un moment donné.
  • Backlog : Seules 2 ou 3 US sont prises dans une itération de 2 semaines (il n’y a pas de durée standard d’itération chez Google, cela est ajusté par équipe). Tout ce qui n’est pas pris pour cette prochaine itération retourne au congélateur. Le PM et le Tech Lead priorisent les tâches lors du travail de découpage.
  • En cours: Il n’y a pas de “limite de WIP” sur les tâches comme il y en a de manière formelle avec Kanban. En pratique, chaque développeur aura au maximum 3 tâches en cours. il peut être amené à prendre une tâche supplémentaire quand:
    • Il est bloqué ou que sa tâche est en cours de revue.
    • Il ressent la besoin de changer pour éviter la saturation !
  • Terminé et vérifié.

En pratique !

Les équipes ont pas mal de l’attitude sur la façon de gérer leur matière première, c’est à dire les tâches. Pour l’équipe GMail, par exemple, c’est l’utilisation d’un tableau de tâches qui a été retenue, chaque “swimlane” représente une des étapes de progression de la tâche.

Le planning meeting est traditionellement court, de l’ordre de 20 minutes pour des itérations d’une ou deux semaines (et on estime toujours un peu plus de tâches que ce qui peut être pris dans l’itération) ! La seule chose qui y est faite est réellement l’estimation des tâches, car leur découpage a déjà été opéré précedemment par le PM et le Tech Lead, comme je l’ai dit précédemment. On ne cherche pas à y reconstruire de “big picture”, on prend juste les tâches les unes après les autres…

L’estimation est faite en points, selon une échelle de Fibonacci modifiée. Le fonctionnement du planning meeting est globalement très codifié:

  • On ne donne pas d’avis ou d’impression sur la tâche du genre: “c’est difficile”, “ça va être facile”, etc.. 
  • On est seulement autorisé à poser des questions fermées auxquelles le Tech Lead peut répondre par “oui” ou par “non”.
  • Il y a un ordre strict de parole !

Un chose importante à noter est que si le planning meeting rythme le travail en permettant d’alimenter le flux de travail, cela ne stigmatise pas le début ou la fin d’un cycle de travail: il est courant d’avoir un reste de tâches ou des tâches en cours au moment du planing meeting !

Comme avec Scrum, les tâches ne sont pas attribuées. On prend les tâches dans l’ordre de priorité qui a été défini. Cela signifie qu’une personne nouvelle sur un sujet prendra plus de temps ou demandera de l’aide pour mener à bien sa tâche. Cela n’est pas considéré comme un handicap, mais comme un aspect positif: les équipes Google ne souhaitent pas créer des ilots de connaissance !

Le peer review est systématique, alors que le pair programming ne l’est pas (il peut être pratiqué occasionnellement). Chaque tâche de revue de code est systmatiquement de la plus haute priorité : débloquer ses pairs est considéré comme l’apport le plus important que l’on puisse faire !

Le daily standup n’est pas pratiqué par de nombreuses équipes ! Cet aspect est également laissé au grée de l’équipe. Par exemple:

  • L’équipe GMail pratique le planning meeting, mais pas le stand-up
  • L’équipe Google Wallet fait des stand-up, mais n’a pas de planning meeting.

Petra par ailleurs ne semble pas fan du daily meeting.

Les rétrospectives sont pratiquées de diverses manière mais sont extrêmemnt courtes

  • Si la rétrospective est effectué chaque semaine, sa durée sera d’environ 15 minutes.
  • Pour une rétrospectives mensuelle, on comptera 1 heure.

Une rencontre mensuelle se tient avec le l’équipe, le PM et le directeur de l’ingénierie pour dresser les grandes lignes de ce qui est à venir.

Et l’environnement ?

Les développeurs bénéficient de beaucoup de liberté par rapport aux outils qu’ils peuvent utiliser. Beaucoup utilisent Eclipse, ils peuvent alors bénéficier de l’aide d’une cellule dédié à cet outil.

Pour ce qui est des outils d’intégration:

  • Git est utilisé pour la gestion de version au niveau des développements.
  • Perforce est utilisé par le Release Manager et les équipes de test, pour travailler en terme de “change set”.
  • L’environnement d’intégration continu (désolé, je ne sais pas ce qu’il y a derrière) est standardisé entre les différentes équipes Google à travers le monde.

Ainsi, si chaque développeur peut bénéficier du confort d’un ensemble d’outils qu’il connait, le passage d’une équipe ou même d’un site à un autre est facilité par des outils de travail en équipe qui sont eux standardisés !

En conclusion

Google est-il agile ou non ?

La réponse à cette question ne semble pas avoir d’importance pour eux. Sans doute ont-ils raison !

Ma réponse serait oui, non en regard des pratiques, mais de la mentalité. Tel que l’a dit Petra en début de présentation, c’est “achieve mission, whatever it is !”.

Google suit-il Scrum : non ! Bien que certaines pratiques soit très proches. Encore une fois , cela semble d’une importance secondaire. L’axe prédominant est clairement Kanban, l’importance est sur le flux et l’efficacité de celui-ci, les cérémonies qui vont autour sont réduite au maximum. Cela est aussi probablement dû à la très grande maturité des équipes de développement.

Deux aspects de moyenne ou faible maturité agile m’ont surpris :

  • Une stratification assez importante des fonctions PM / Tech Lead, avec par exemple un découpage en tâche dans lequel l’équipe n’est pas impliqué, et l’absence du PM lors du planning meeting, le travail ayant été “mâché” par le PM et le Tech Lead. Le but semble être de gagner en efficacité et d’éviter de faire perdre du temps à l’équipe ! Mais on perd sur l’aspect participatif et l’implication de l’équipe…
  • Le cycle de release : s’il est plutôt court, on reste en deça des pratiques devops ! Je me serais attedu sà ce que devops fasse partie de l’ADN de Google !

Google a adopté un processus ad hoc, pragmatique. Il est agile de mon point de vue, car focalisé sur l’efficacité, la mis en ligne fréquente et aussi rapide que possible des fonctionnalités développées. Il est très “lean” par nature, avec un focus particulier sur le flux et l’élimination du gâchis (tout ce qui ne participe pas à la création de valeur).

Publicité

Note de lecture : Practical Project Initiation, a handbook with tools, par Karl E. Wiegers

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Moins bien que d’habitude

Karl Wiegers nous a habitué à des ouvrages de qualité, aussi bien par la forme que sur le fond. Cet ouvrage de moins de 200 pages s’avérait donc prometteur car j’apprécie les auteurs qui savent s’exprimer avec concision. Finalement l’ouvrage manque sensiblement de corps. S’il passe bien en revue les différents aspects de la gestion de projet, il nous laisse largement sur notre faim en ce qui concerne le contenu. La plupart des 15 chapitres se concluent par des conseils de mises en pratiques et des templates, mais ni les uns ni les autres ne m’ont paru extrêmement pratiques, du moins pas assez pour que j’ai envie de m’y référer. Le livre se découpe en 5 parties.

La première partie est consacrée aux fondamentaux de la gestion de projets. Les 3 chapitres qui le composent couvrent 35 pages et peuvent être vus comme un survol du reste de l’ouvrage, c’est en tout cas l’objectif du chapitre 1, le « primer ». Le chapitre 2 se focalise sur les principales bonnes pratiques / mauvaises pratiques de la gestion de projet. Très pertinent et une bonne référence quand on veut prendre un peu de hauteur, tandis que le 3ème chapitre nous aide à considérer les priorités.

La seconde partie s’intitule pompeusement « preparing for success » et s’étale sur 65 pages soit 5 chapitres. Cette partie se devait d’être la plus solide mais elle n’est pas ma préférée. Le chapitre 4 s’intéresse aux critères de succès et aux objectifs d’un projet, un sujet important qui aurait pu être mieux traité. Le chapitre 5 considère la mesure de l’avancement (bonne idée). Le chapitre 6 évoque le « risk management », sujet important de l’aveu même de l’auteur mais bien légèrement traité. Le chapitre 7 suggère le développement d’une charte que je trouve bien peu convaincante.

La troisième partie s’intitule « vivre avec la réalité » et n’est longue que de 27 pages représentant 3 petits chapitres. Le chapitre 8 traite de la négociation des objectifs et est particulièrement intéressant. Au chapitre 9 l’auteur nous propose de mettre en place des « buffers » pour contrer les imprévus, ce que je désapprouve, mais c’est une question de point de vue. Le chapitre 11 est une nouvelle source de frustration car il aborde la dualité estimation / réalisation, mais de manière bien plus superficielle que Steve McConnell dans son art de l’estimation (auquel Karl Wiegers se réfère beaucoup, justement).

La quatrième partie évoque la mise en place de métriques. Le « Software metrics primer » du chapitre 12 est encore une fois bien léger ! Le chapitre 13 sur les pièges à éviter est bien plus instructif.

La dernière partie traite du retour d’expérience. Tout d’abord via le chapitre 14 qui évoque les « best practices »… et renvoie vers le « Rapid Application Development » de Steve McConnell ! Le chapitre 15 enfin fait état des rétrospectives, mais ne sert guère que d’introduction au remarquable ouvrage de Norman Kerth !

Mon propos montre pas mal de frustration à la lecture de cet ouvrage ! C’est le lot des bons auteurs que l’on en attende toujours les meilleurs. Cet ouvrage n’est certes pas l’œuvre la plus marquante de Karl Wiegers, mais étant assez condensé, il pourra servir d’ouvrage introductif au chef de projet junior, car il renvoie utilement vers des textes plus complets.

wieger-pract-proj-initiation

Référence complète : Practical Project Initiation, a handbook with tools – Karl E. Wiegers – Microsoft Press 2007 – EAN : 978 0 7356 2521 1

Practical Project Initiation: A Handbook with Tools


http://www.goodreads.com/book/add_to_books_widget_frame/0735625212?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Scaling Software Agility, best practices for large entreprises, par Dean Leffingwell

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Finalement, rien de neuf sous le soleil !

Dean Leffingwell n’est pas un nom inconnu pour moi. Autrefois consultant chez Rational, il est l’auteur d’un livre sur la gestion des exigences plutôt de très bonne facture et en tout cas fort bien écrit. L’autre facette de ce « passif » est que Dean Leffingwell semble plutôt être un opportuniste de l’agilité et qu’il vient de la vieille école ! Mais ne concluons pas trop vite.

Le sujet abordé nous change un peu : comment, avec l’agilité passer de la mise en œuvre au sein d’une équipe de moins de 10 personnes à l’usage au sein d’une organisation ? Le sujet a déjà été effleuré, mais sans que des principes vraiment convaincants soient révélés. Pour aborder cela, l’ouvrage de Leffingwell est divisé en 3 parties.

La première partie est consacrée à une vue générale de l’agilité. Ses 95 pages sont divisées en 8 chapitres. Cette introduction est surtout destinée aux lecteurs ayant éventuellement un verni de connaissance de l’agilité, mais pas une véritable connaissance des principes et des méthodes. Autant le dire, cette première partie est fort bien faite. Les principes sont clairement énoncés et expliqués, les principales méthodes qui sont passées en revues le sont de manière claire et synthétique. Le tout est exemplaire. Mais on n’a pas encore abordé la face « scaling ».

La seconde partie évoque les pratiques connues des méthodes agiles, dont l’auteur va nous montrer qu’elles fonctionnent au changement d’échelle. 7 pratiques sont présentées ici, couvrant 90 pages découpées en 7 chapitres (1 chapitre par pratique, ça coule sous le sens). Il s’agit de :

  • Component team : Il s’agit du « feature team » que l’on rencontre ailleurs, notamment dans Scrum. Rien de nouveau ici. On n’en sait guère plus sur le passage à une échelle supérieure. L’auteur se contente souvent de citer d’autres textes.
  • Two levels of planning and tracking : Ce chapitre est emprunté d’une collaboration avec Rallye Software (mais eux parlent de 4 niveaux de planification, ce que j’approuve). Globalement on y retrouve de manière moins approfondie la matière développée par Mike Cohn dans « Agile Estimating and planning ».
  • Mastering the iteration : Ce chapitre évoque la gestion d’une itération. Un sujet mille fois abordé. J’aurais espéré ici un développement sur la gestion concurrente des itérations entre plusieurs équipes. Rien de cela ici. Ici encore, Mike Cohn vous en dira plus long.
  • Smaller, more frequent releases : Là aussi, il s’agit d’un sujet qui n’a plus rien de neuf. Le volet « multi-teams » est traité en fin de chapitre sur une demi-page. J’arrête là.
  • Concurrent testing : Le chapitre est court, c’est dommage car il commençait bien. Il y aurait fort à dire sur la gestion des tests au sein de larges organisations.
  • Continuous integration : L’intégration continue au sein d’organisations réparties est un sujet à part entière, où plusieurs stratégies de mise en œuvre sont possibles. Il est dommage que l’auteur se cantonne à l’aspect « équipe unique » maintenant bien connu, qui n’a pas de plus value ici.
  • Regular reflexion and adaptation : Si les rétrospectives sont un mécanisme inhérent à l’agilité, pourquoi limiter le volet traité ici à l’aspect « métrique » ? On voit le coté « vieille école » de Dean Leffingwell pointer le bout de son nez. Un aspect de l’agilité mal compris.

La troisième partie, « creating the agile entreprise » est le cœur de l’aspect « changement d’échelle » du livre. C’est aussi la plus importante avec ses 130 pages séparés en 7 chapitres. Les 7 « pratiques complémentaires qui y sont abordées sont :

  • Intentional architecture.
  • Lean requirements at scale.
  • System of systems and the agile release train.
  • Managing highly distributed teams.
  • Impact on customers and operations.
  • Changing the organization.
  • Measuring the business performance.

Si l’auteur est dans le vrai sur les sujets abordés, le traitement de ceux-ci est quand même décevant. En effet, la solution proposée ici est bel est bien de réduire la voilure de l’agilité et de remettre un peu plus de principes « top down ». On notera aussi au passage l’aspect gestion des exigences, largement inspiré des écrits précédents de l’auteur. Ce n’est d’ailleurs pas le plus mauvais chapitre.

En bref, j’ai été frustré par ce livre. J’ai de plus largement l’impression qu’il est le fruit d’une unique expérience chez BMC, ce qui est un peu léger pour justifier un livre. Je déconseille donc cette lecture.

scaling-soft-agility-Leffingwell

Référence complète : Scaling Software Agility, best practices for large entreprises – Dean Leffingwell – Addison Wesley / ASD series 2007 – ISBN : 0-321-45819-2 ; EAN : 978 0 321 45819 3

Scaling Software Agility: Best Practices for Large Enterprises


http://www.goodreads.com/book/add_to_books_widget_frame/0321458192?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : DSDM, Business focused development, 2nd edition, par Jennifer Stapleton edt.

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; L’agilité, vue par nos voisins anglais.

Tout comme le « XP explained » de Kent Beck, cet ouvrage peut être vu comme l’argumentaire de DSDM que comme la synthèse de la méthode qui est plutôt montrée en filigrane ! N’hésitons pas à le dire, cela nuit beaucoup à la qualité de l’ouvrage (sans préjuger de la qualité de la méthode). Je pense que la raison principale de ce choix est de ne pas empiéter sur les documents du consortium DSDM réservés aux adhérents. Ce genre de choix est toujours délicat, mais un peu malheureux ici, en l’occurrence. Au niveau de la qualité du texte, on remarquera que pour un ouvrage collectif, celui-ci est agréable à lire, il n’est pas trop long, comme c’est souvent le cas dans ce genre de situation, les chapitre sont courts et l’on ne perçoit ni redondance ni différence de style, hormis dans la partie dédiée aux retours d’expérience.

Car l’une des originalités intéressantes de ce livre est de consacrer une moitié de l’ouvrage à des retours d’expérience, judicieusement choisis afin d’éclairer des aspects particuliers de la méthode. Une bonne idée qui devrait être plus souvent reprise.

Si vous vous intéressez à DSDM, ce livre est tout simplement incontournable, car c’est le seul qui existe. Il ne saurait suffire toutefois, et c’est bien dommage, à la compréhension de la méthode. Il faudra pour cela aller surfer sur le site Web ci-dessous, ce qui était probablement un des buts inavoués. Mais cela est franchement un peu pusillanime.

DSDM

Référence complète : DSDM, Business focused development, 2nd edition – The DSDM consortium, Jennifer Stapleton edt. – Addison Wesley / ASD series 2003 – ISBN: 0-321-11224-5

DSDM: Business Focused Development


http://www.goodreads.com/book/add_to_books_widget_frame/0321112245?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Scrum Night II : l’appel du 19 Avril

Le par addinquydans ArticlesLaisser un commentaire

C’est parti !

Ca y est, l’évènement est en ligne depuis une petite semaine. Assez longtemps pour que l’on se retrouve avec un évènement complet et une liste d’attente digne des bouchons du 15 Août !

Alors je sais, c’est chez Google. Ce nom magique éveille tous les intérêts, anime toutes les passions ! Hé ! Vous avez bien remarqué qu’il n’y a encore aucun programme ?

Avoir un programme dépend de vous ! Si personne ne propose d’atelier, nous écouterons du Rap pendant 3 heures. je vous le dit tout net, je n’y survivrais pas.

Qui peut proposer un atelier ?

Tout le monde ! Si les innovation games sont un sujet qui vous passionne et que vous êtes aguerri(e) à la pratique de l’un d’entre eux, alors n’hésitez pas plus longtemps : proposez votre sujet !

Bien sûr, il est mieux d’avoir un peu d’expérience de son sujet. Mais les expérimentations seront aussi bienvenues. Nous porteront une attention particulière aux ateliers qui n’ont pas été proposés pour la 1589ème fois. Ah, c’est vrai: nous ne serons pas seul à décider, vous en serez aussi. J’y reviens dans 2 minutes.

Et si je veux participer à l’animation, mais que je ne me vois pas proposer un atelier moi-même ?

Oui, cela sera possible ! La méthode que nous avons retenu pour les propositions va permettre cela. Il est temps d’en parler.

Une nouvelle façon de proposer les sujets

Nous innovons pour cette Scrum Night II : Les sujets devront être proposés Sur IdeaScale : 

Dans la catégorie “Scrum Night II” (si vous avez suivi le lien, vous y êtes déjà), vous soumettez simplement votre sujet avec le bouton Idoine. Il vous faudra préciser:

  • Le titre de votre atelier, bien entendu
  • Le nom des animateurs
  • L’objectif de l’atelier
  • Un petit descriptif de celui-ci

Chaque sujet ouvre un fil de discussion. Vous pouvez poser des questions, ou proposer votre aide à l’animateur. Pourquoi pas ?

C’est jusqu’à quand ?

Jusqu’au 13 Mai ! C’est vrai, ça fait peu de temps avant la date fatidique de ladite Scrum Night, donc tenez-vous prêt. Visiblement, cela ne conditionnera pas l’affluence qui est déjà … euh … affluente !

Cette date tardive nous permettra d’intégrer des propositions d’atelier faisant suite à Agile Games France qui se sera terminé la veille. Autant dire qu’il ne faudra pas tarder pour les joyeux participants à cet évènement (j’en serais).

Soyez acteur du choix des ateliers

Vous l’avez certainement vu en allant sur IdeaScale, vous pouvez voter positivement (en accord) ou négativement (en désaccord). Les tendances qui émergeront seront prises en compte dans le choix des ateliers, mais on ne sait pas encore vous dire comment. Nous même d’avons pas encore décidé…

Bref, allez de temps en temps sur IdeaScale, voir les ateliers qui seront proposés d’ici le 13 Mai pour donner votre avis. Attention, d’expérience le gros de la troupe arrive à la fin, mais nous ferons le vote dans les 2 ou 3 jours qui suivront, donc ça va aller assez vite à ce moment là !

J’comprend rien !

Si vous êtes un lecteur assidu du “Guide du Routard Galactique” de Douglas Adams, vous savez que sur cet illustre ouvrage figure en première page ces mots magiques: “Pas de Panique !”. Je vais donc les répéter ici:

Pas de panique !

  • D’une part, vous pouvez contacter le bureau en envoyant un mail à orateur@frenchsug.org
  • D’autre part, vous pouvez poser une question ou faire un commentaire ici même !

Nous espérons vous voir nombreux à proposer des ateliers !

Note de lecture : More about Requirements, par Karl E. Wiegers

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Karl Wiegers n’a pas tout dit !

Comme son nom l’indique, ce petit opuscule (185 pages) est un complément au classique « Software Requirements » du même auteur, et plus précisément à la seconde édition de cet ouvrage. Plus que d’être un livre par lui-même, ce texte fait un peu l’effet d’être un complément d’information. Aussi je déconseille fortement de plonger dans cette lecture si vous n’avez pris d’abord le temps d’étudier le premier ouvrage. Si vous l’avez fait et l’avez apprécié (ce qui est mon cas), cette lecture poursuit le plaisir.

Le format du livre est réellement inhabituel, il rappelle celui, un peu déconcertant, de Kent Beck : l’ouvrage compte 23 chapitres répartis en 7 parties. Pour un livre de 185 pages. Faites le calcul, la moyenne de chacun d’entre-eux se situe aux alentours de 8 pages ! En fait, je trouve cela fort agréable, car on a le sentiment que chaque chapitre a un objectif « tactique » et que celui-ci doit être atteint le plus efficacement possible. Et cela rythme bien la lecture. Par contre, on a aussi l’impression que chaque chapitre est traité assez superficiellement. En fait les renvois vers le livre principal sont assez nombreux, on est parfois aux limites de la FAQ.

La première partie est consacrée aux concepts : ce qui est vrai ou faux concernant la gestion des exigences et aussi la « big picture » des types d’exigences vue par Karl Wiegers, que j’aime particulièrement.

La seconde partie se focalise sur la partie management des exigences : comment peser le retour sur investissement ? Comment en estimer l’effort ? Comment planifier ce travail et le répartir tout au long du projet ?

L’interaction avec les utilisateurs est abordée dans la troisième partie. Ici c’est l’élément humain qui est décortiqué, et l’on s’intéresse à la meilleure façon de collaborer avec un utilisateur.

La quatrième partie est dédiée aux cas d’utilisation : que sont-ils, quels sont les concepts importants et quand est-il utile de compléter ce formalisme par un autre ou tout simplement de l’abandonner au profit d’un autre !

La rédaction des exigences est un problème crucial, car elle détermine la qualité et l’utilisabilité effective du produit final. La cinquième partie est dédiée à ce sujet.

Karl Wiegers reste un homme de processus, et la sixième partie recadre la gestion des exigences dans un processus projet : définition de la portée du projet, gestion du changement, etc..

Enfin la dernière partie aborde le volet « gestion » : de quels indicateurs peut-on avoir besoin ? Comment gérer les exigences à travers plusieurs releases d’un projet ou comment aborder le choix d’un outil de gestion des exigences.

Cet ouvrage n’est certainement pas un ouvrage de référence, comme peut l’être le « Sotware Requirements, 2nd edition », mais c’est une bonne lecture complémentaire. Le propos de Karl Wiegers fait souvent mouche et apporte grandement au sujet. Je vous engage donc à poursuivre la lecture du premier ouvrage cité par celui-ci !

more-about-requirements

Référence complète : More about Requirements – Karl E. Wiegers – Microsoft press 2006 – ISBN: 0-7356-2267- 1

More About Software Requirements: Thorny Issues and Practical Advice: Thorny Issues and Practical Advice

http://www.goodreads.com/book/add_to_books_widget_frame/0735622671?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Scaling Lean & Agile Development, par Craig Larman & Bas Vodde

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 9 ; Enfin un ouvrage sur le Lean développement qui renouvelle les idées ! Book of the year 2010 !

Le problème des ouvrages sur le Lean développement, c’est qu’ils ne savent guère que tourner en rond, exposer et (dans le meilleur des cas) développer les idées sous-jacentes aux principes Lean. Bien que le Lean soit à la mode, chaque lecture d’ouvrage sur ce domaine tend à se transformer en ennui annoncé.

J’ai donc une excellente nouvelle pour vous : ici, il n’en est rien ! Cet ouvrage de 330 pages est complété d’un « companion book » plus imposant, écrit par les deux mêmes auteurs. Mais nous allons nous concentrer sur celui-ci pour l’instant. Si l’ouvrage est écrit par deux auteurs, l’un des deux au moins, ne m’est pas inconnu : Craig Larman est « chief scientist » de mon employeur précédent, mais aussi un auteur émérite. Bref, il sait écrire, et je n’ai jamais été déçu par ses textes jusqu’à présent. Et disons que la série se poursuit.

Avant d’attaquer le contenu, je vous livre une de mes petites manies permettant d’avoir des indices sur la qualité du livre, avant et après lecture. Avant de commencer la lecture, je regarde les 1ère et 4ème de couverture. Une proportion importante des meilleurs ouvrages y propose des schémas ou des tableaux récapitulatifs du livre, ou même des aides mémoire. On a ça ! Après lecture, je compte le nombre de post It que j’ai placé sur le livre : ici j’en ai posé 22, c’est très très bon.

Après la forme, le fond. Le livre se découpe en 3 parties constituées de 12 chapitres, ce qui fait donc une moyenne de moins de 30 pages par chapitre. Ca va.

Autant nous occuper tout de suite de la 3ème partie, « miscellany » essentiellement constituée du dernier chapitre « Scrum Primer », qui n’est en fait pas écrite par les auteurs, mais par des auteurs du site http://www.scrumprimer.com ; Pour distinguer ce texte de celui des auteurs, le corps de la police utilisée est différent, plus petit. Il s’agit d’un bon « Scrum primer » qui présente l’avantage d’être assez direct et succinct et de bien recadrer ce qui fait partie du corpus de la méthode et ce qui n’en fait pas partie mais est généralement utilisé ! En plus de ce chapitre, on trouve les annexes habituelles (index et bibliographie), accompagné d’un « recommanded readings » assez sympa.

La première partie est consacrée aux « thinking Tools ». Il est long de 140 pages découpées en 5 chapitres (je n’ai pas compté le chapitre d’introduction, qui précède cette première partie). Le chapitre 2 (system thinking) est essentiellement un tutorial aux « causal loop diagram », même si les « fishbone diagrams » sont aussi évoqués. Le diagramme de boucles causales sera d’ailleurs utilisé ultérieurement dans le livre. Très réussi. On poursuit au chapitre 3 (Lean thinking) où l’on présente « Lean thinking house ». Les principes sont déclinés en pratiques. Les pratiques sont développés et illustrées. Impeccable là aussi. La théorie des queues est un volet important du Lean thinking. Le chapitre 4 qui lui est consacré est assez ardu à suivre. Mais on coupe court aux idées fausses de manière abrupte et l’on en a pour son argent ! Le chapitre 5 (false dichotomies) est sans doute l’un des plus abstraits par sa nature. Il s’agit là aussi de couper court aux idées fausses et de réfuter certaines idées prétendument opposées. Enfin le chapitre 6 (be agile) termine cette première partie en promouvant l’idée « d’être agile », donc de s’adosser aux valeurs, plutôt que de « faire de l’agilité » et donc de ne voir que les pratiques.

La seconde partie est dédiée aux « organizationnal Tools ». De taille égale à la premier (5 chapitres pour 150 pages), il focalise chaque chapitre sur une pratique Scrum inspirée de Lean, et adaptée aux projets de grande taille. Le chapitre 7 (feature team) met en exergue l’idée d’équipes pluridisciplinaires, par opposition aux organisations orientées composant. Le chapitre 8 (teams) est la poursuite de cette idée, avec une emphase sur le caractère auto organisée des équipes et sur la gestion des dépendances externes. Le chapitre 9 (requirements area) introduit une idée nouvelle sur la gestion de très gros backlogs. Dommage que ce chapitre de seulement 9 pages n’ait pas été plus développé ! Le chapitre 10 évoque l’extension de l’organisation agile au niveau de l’organisation de l’entreprise. J’y ai surtout aimé la distinction projet / produit, souvent incomprise et source de problème, tandis que les aspects ressources humaines sont du déjà vu et hélas une appréhension bien trop idéaliste du sujet. Enfin le chapitre 11 (large scale Scrum) évoque une partie du sous-titre de l’ouvrage et dit en substance que l’adaptation de Scrum aux grands projets … n’existe pas en tant que tel !

Finalement, j’ai retardé la lecture de cet ouvrage ne me sentant pas tellement concerné par le « large scale Scrum ». C’était une erreur, car en fait pu de choses dans ce livre sont vraiment dédiées spécifiquement aux grandes équipes. Au contraire, la littérature agile qui me semble rabâcher les mêmes propos depuis quelques années retrouve un peu de fraicheur ici. J’ai hâte de lire la suite, et bien sûr je recommande chaudement, sans aucune réserve !

scaling-lean-agile-dev-Larman

Référence complète : Scaling Lean & Agile Development, Thinking and organizational Tools for large-scale Scrum – Craig Larman & Bas Vodde – Addison Wesley 2009 – ISBN : 978 0 321 48096 5

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

http://www.goodreads.com/book/add_to_books_widget_frame/0321480961?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Succeeding with Use Cases, Working smart to deliver quality par Richard Denney

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Excel à la rescousse des cas d’utilisation, ou comment les colorier au-delà du trait.

Ce livre ne va pas vous apprendre à modéliser avec les cas d’utilisation, mais il va vous apprendre à les utiliser plus avant, notamment dans une optique qualitative. Ce livre est découpé en 4 parties indépendantes, qui constituent autant de facettes d’utilisation améliorée des cas d’utilisation.

La première partie est consacrée aux « QFD » ou Quality Function Deployment, qui permet non seulement de tracer les cas d’utilisation vers les « business drivers » ou vers les exigences, mais permet d’en calculer les priorités. La méthode est simple et adaptable, et si l’on considère que l’auteur va jusqu’à montrer concrètement comment la matrice QFD se construit avec Excel, on ne voit guère ce qui empêche d’exploiter cette technique.

Excel est également utilisé dans la seconde partie dédiée aux SRE (Software Reliability Engineering), dont le but est d’adapter l’effort de développement et de test à la « qualité perçue » et à l’usage opérationnel réel des cas d’utilisation, ces ratios d’usage réel étant construit d’après les étapes de UC effectivement parcourues, et d’après la nature des relations entre cas d’utilisation lorsqu’il y en a. Si l’usage opérationnel réel est utile, entre autre pour se fixer des objectifs de disponibilité opérationnel et de fiabilité, les méthodes de calcul liées à l’effort de test sont complexes et la pertinence de leur mise en œuvre limitée à certains types de projets.

La troisième partie est dédiée aux préconditions, postconditions et invariants. Elle emprunte beaucoup aux méthodes formelles, ce qui explique probablement un certain désintérêt de ma part. Hélas, l’exemple appuyant cette partie n’aide pas à rendre le propos plus clair.

La quatrième partie est dédiée à la gestion de la configuration, dont un chapitre est dédié au calcul du ROI, et un autre au « project portfolio management ». Si ce dernier chapitre ne m’a guère convaincu, par contre celui dédié au ROI est particulièrement concret et utilisable.

Cet ouvrage se démarque clairement des autres livres consacrés aux cas d’utilisation, car il est dédié à « ce que l’on peut faire avec les cas d’utilisation ». Bien que certaines parties s’appuient sur un formalisme très poussé, une grande partie est directement utilisable sur pratiquement beaucoup de type de projet.

succeeding-use-cases

Référence complète : Succeeding with Use Cases, Working smart to deliver quality – Richard Denney – Addison Wesley / O.T. series 2005 – ISBN: 0-321-31643-6

Succeeding with Use Cases: Working Smart to Deliver Quality


http://www.goodreads.com/book/add_to_books_widget_frame/0321316436?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Agile Product Management with Scrum, Creating products that customers love par Roman Pichler

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Vraiment très léger, et pas si bien avisé que ça.

Plutôt qu’un livre, il s’agit d’un opuscule. D’abord par son nombre réduit de pages (118) et par son format à mi-chemin du livre de poche, ce qui est inhabituel. Tant mieux si le texte y gagne en pertinence et en efficacité. Hélas, ce n’est pas trop le cas, on frôle même parfois le hors sujet sans traiter en profondeur le sujet principal du livre ! Justement, effeuillons le texte. Celui-ci est découpé en 6 chapitres, donc avec une moyenne de 20 pages par chapitre.

Le premier chapitre rentre directement au cœur du sujet : qu’est-ce que le product owner ? On y énumère les qualités attendues de celui-ci et on évoque son rôle au sein de l’organisation, y compris celle d’un groupe de PO. Je dirais que globalement le propos est intéressant mais qu’on y apprends pas grand chose, le traitement me paraissant abstrait voir un peu théorique.

J’ai été intéressé de voir un chapitre consacré au développement de la vision, qui est l’un de mes thèmes favoris. Si on y reprends des bonnes idées largement connues par ailleurs (elevator statement, vision box ou modèle de Kano), je vois plutôt ce chapitre comme une introduction au sujet. Et je reste gentil.

Le troisième chapitre consacré au backlog est naturellement un des points majeurs du livre. Le principe de granularisation progressive des items de backlog est je pense un sujet connu d’un certain nombre de praticiens, il est bien de le voir évoqué là. Hélas une fois encore j’en trouve le traitement superficiel. Ce chapitre joue un double rôle en évoquant le volet recueil des besoins. Ce sujet aurait mérité son propre chapitre. Cet aspect est important et j’en trouve le traitement bien léger, voir bâclé. Un exemple du genre est l’évocation des exigences non fonctionnelles. La comparaison entre ce qui est dit ici et ce que l’on retrouve dans les meilleurs ouvrages traitant de l’ingénierie des exigences fait mal, très mal.

Les chapitres 4 et 5 sont consacrés au rôle du PO au sein des différentes pratiques de Scrum. Il s’agit à mon avis d’ajouts inutiles. Ces aspects sont déjà traités dans les ouvrages classiques traitant de Scrum. Et même si le propos est centré sur le product owner, je n’y trouve ni créativité ni apport de l’expérience de l’auteur.

Le sixième chapitre conclut sur les façons de monter en compétence sur le rôle de product owner. Dommage qu’il ne fasse que 7 pages, la prose y est forcément superficielle.

Clairement ce livre a été une grosse frustration pour moi. Il ne mérite pas la « signature series ». Peut-être mes attentes étaient-elles trop élevées, mais je pense qu’il y a plus et mieux à dire sur le rôle du product owner que ce qui est évoqué ici. Je n’estime pas la note trop sévère. Il reste que le texte satisfera peut-être de nouveaux venus à Scrum ?

agile-product-mgt-scrum

Référence complète : Agile Product Management with Scrum, Creating products that customers love – Roman Pichler – Addison Wesley / Signature series 2010 – ISBN : 978 0 321 60578 8

Agile Product Management with Scrum: Creating Products That Customers Love


http://www.goodreads.com/book/add_to_books_widget_frame/0321605780?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on