Archive

Archive for the ‘Scrum’ Category

#PSD

10 novembre 2013 2 commentaires

Ca y est, j’ai moi aussi un calendrier de formations. Je me concentre sur les formations techniques.

Dans le programme scrum.org, il y a deux versions officielle de la PSD, une .Net et une Java. Dans mes cours, vous pouvez décider de jouer avec l’environnement technologique de votre choix. Il se pourrait que des équipes différentes travaillent avec des langages différents. C’est votre choix. Le seul requis technique est que vous ameniez votre portable équipé d’un environnement de développement. Cela peut être le tout dernier Visual Studio, le tout dernier né de JetBrains ou notre ami Vim.

Dans une PSD, on joue pendant 3 jours avec les différents outils de Scrum, on écrit des tests, on voit du rouge, on voit du vert, on remanie du code sans peur, on étudie différents modèles de code, on lance des débats, on décide ensemble, on demande de l’aide, on fait attention à soi, on apprend à livrer du logiciel dont on est fier. Moi, je suis là pour vous aider à en tirer profit et joie.

Publicités
Catégories :Journal, Scrum, TDD, The Core Protocols Étiquettes : ,

Javascript TDD n°2

Aujourd’hui j’ai envie de commencer à code un nouveau site web. J’ai déjà en tête plusieurs fonctionnalités, et une première stratégie incrémentale émerge dans mon Backlog. Il est temps d’éprouver ces idées avec du vrai code. Je voudrais piloter mon développement par les tests et mon premier test va décrire que je voudrais un site qui se déclare lui même en construction.

Ce que j’aime dans ce premier test c’est qu’il va me permettre d’explorer plusieurs éléments complémentaires. Du côté des tests, comment écrire un test qui simule l’accès à une page par un navigateur et contrôle le contenu de la page servie ? Du côté du code de production, comment écrire un serveur web en Javascript ? Côté tests, je vais explorer l’outil Zombie. Côté code de production, je vais explorer les outils disponibles nativement dans Node.

L’utilisation de Zombie se révèle assez facile et j’ai rapidement mon premier retour de test.


Sans surprise car notre test ne démarre pas encore de serveur capable de répondre à la requête faite par Zombie. Notons au passage que cette façon d’écrire le test ne conduit pas à recevoir un code d’erreur 404 auquel on pourrait s’attendre dans ces conditions. Avec le 404, j’aurais eu deux étapes. Une première pour répondre, ce qui aurait changé mon message d’erreur et produit le message d’erreur ci-dessus. Et une seconde pour implémenter la réponse attendue. Là où nous sommes actuellement.

Aujourd’hui je veux faire passer ce test en utilisant Node. J’oublie ici les serveurs écrits par dessus Node qui existent car je voudrais jouer à en apprendre plus sur Node lui même et ses possibilités natives. La bonne nouvelle c’est que dès la page d’accueil de Node, on nous présente une manière de faire.

En gardant juste le code nécessaire pour faire passer mon test, j’obtiens mon premier vert. J’ai enlevé le code qui met des choses dans l’en-tête parce que je n’en ai pas besoin pour faire passer ce test.

Je suis content de ce premier vert. Qu’est-ce que j’ai appris ? Démarrer un serveur http avec Node semble facile. Avec le code que j’ai enlevé j’apprends que je vais pouvoir contrôler les codes de retour, le type du contenu. Cela me rend confiant que je vais éventuellement pouvoir servir des feuilles de styles, des scripts, des images, bref tout ce que je sens que je vais bientôt avoir envie de servir.

Pour l’instant, je n’ai rien à déployer car tout le code se trouve dans les tests. Pour pouvoir pousser ce code en production quelque part, je dois extraire du test cette fonctionnalité de serveur. J’ai l’habitude de commencer par des ExtractMethod. J’en fais deux de suite en essayant de me concentrer sur les deux intentions disjointes que j’identifie. Mon test et mon presque-code-de-prod se séparent un peu.

Le code de test est ainsi plus concis. Je suis confortable à ne pas pousser plus loin pour l’instant. J’anticipe que j’aurai bientôt envie d’extraire ce code html dans un fichier .html séparé, de rendre mon serveur plus intelligent pour qu’il sache servir ce fichier, qu’il sache servir des fichiers statiques en général. Bien sûr je ne suis pas le premier à faire ça et une recherche rapide me donne plusieurs pointeurs sur des modules Node qui font déjà tout ça et que je pourrais utiliser. Mais où serait le plaisir ?

Pour l’heure, il me reste à déplacer ce code dans des fichiers séparés du code de test pour pouvoir les déployer. Quelque chose qui ressemble à un ExtractClass mais pour une application Node. La chose amusante c’est qu’une façon de faire fonctionner cette extraction en modifiant le  code le moins possible consiste à mettre en place le formalisme ci-dessous qui justement emprunte la sémantique O-O ; ce qui est cohérent avec une extraction de classe.

httpserver.js

site.spec.js

Notez que le new est inutile ici mais je le conserve car je trouve qu’il illustre mieux mon intention. Inutile c’est à dire que si je l’enlève, le test passe toujours.

Comme vous vous y attendez certainement, ce code ne donne pas le résultat souhaité lorsque qu’on l’exécute en production. En effet, le navigateur manque d’information et affiche le code html renvoyé.

La directive Content-Type que j’ai supprimé est finalement très utile ;). Jouons le jeu et ajoutons le test qui nous invite à l’ajouter.

Bien sûr il suffit ici de positionner correctement le Content-Type et le tour est joué.

Pour déployer sur Heroku, quelques ajustements sont nécessaires. Pour les curieux, notez que je déploie à partir de la branch deploy-heroku. Dans la prochaine étape, je prévois d’extraire le code html dans un fichier maintenance.html qui sera servi par défaut. Tout cela piloté par des tests bien sûr.

stay tuned! 😉

Le site: http://work-equals-play.herokuapp.com/

Le code: https://bitbucket.org/ericminio/work-equals-play

Le Backlog: https://trello.com/board/work-play/5140ca7e6abb829939000135

 

Catégories :Journal, Scrum, TDD Étiquettes : , , ,

Scrum Master vs. Scrum trainer

19 décembre 2011 2 commentaires

Bonjour,

Depuis l’été dernier j’ai changé un truc qui me semble significatif dans mes formations Scrum et je voulais aujourd’hui le partager.

La version courte : pendant mes cours PSM, j’utilise maintenant le terme Scrum trainer en lieu et place de Scrum Master.

La communauté agile a largement, il me semble, décrit les inconvénients du nom « Scrum Master », et surtout de cette étiquette « Master ». J’ai donc souhaité chercher une alternative. Et comme je souhaitais surtout essayer autre chose et mesurer sur le terrain ce que cela changeait, je n’ai pas attendu le résultat d’un éventuel long débat pour faire un essai.

Voici ce que j’ai cru mesurer:

  • L’étiquette « trainer » véhicule mieux la partie « enseignant de Scrum » du rôle
  • L’étiquette « trainer » supprime toute relation de hiérarchie avec l’Equipe

La façon dont je mesure ces améliorations est fort simple : d’une part les discussions pendant le cours ne sont plus les mêmes. D’autre part, une proportion beaucoup plus grande de participants me semblent comprendre comment tirer le plus avantage de ce rôle, et au delà du rôle, de l’ensemble de Scrum.

Un exemple ?

Avant, j’avais systématiquement la question « Est-ce que le Scrum Master fait les burndown charts ? « , et nous débattions un long moment sur les conséquences de le faire ou non. Maintenant cette question n’apparaît plus en ces termes et les participants explorent plutôt les conséquences pour une équipe de faire un burndown d’itération ou non.

Un autre exemple ?

Avant, nous débattions longuement autour de l’idée que le Scrum Master, vous savez, « removes impediments ». J’avais coutume d’insister sur le fait que nous parlons ici de blocages mentaux liés à la compréhension de l’étendue des responsabilités de PO et d’Equipe (de dev comme on dit maintenant). Cette idée avait du mal à se frayer un chemin dans les cerveaux tant le vocabulaire ne nous aidait pas. Maintenant c’est beaucoup plus simple et il n’y a presque plus de point dure dans cette discussion.

Il me semble aujourd’hui logique qu’une nouvelle approche ait besoin d’être apprise. Nous disons toujours que Scrum s’apprend en se pratiquant. Logique alors que Scrum prévoit un prof embarqué.

Catégories :Journal, Scrum Étiquettes : ,

Forecast vs. Commitment ?

2 septembre 2011 2 commentaires

Une fois n’est pas coutume, voici un titre en anglais qui me semble dans l’air du temps suite aux mises à jour du Scrum guide cet été.

Parmi les points qui sont clefs à mon avis dans cette mise à jour il y a l’introduction de la notion de prévision faite au début de l’itération. Cela en a interpellé certains qui aimaient bien se raccrocher à cette idée répandue que « ok on fait du Scrum et on ne fixe pas un plan à 6 mois, mais, les gars, quand même, pour ces 3 semaines qui commencent, c’est quoi votre engagement, combien pouvez-vous prendre ? ».

Hmm…

Cette remarque m’inspire deux penseés…

1. … à propos des itérations en cascades :

Peut être avez-vous rencontré des équipes, moi beaucoup, qui reproduisent un processus de développement en cascade dans chaque itération. La plupart ont bien fait leur devoir et bien compris que chaque itération devait livrer un incrément terminé. Ils reproduisent alors à l’intérieur de chaque itération le processus en place pour livrer quelque chose de terminé, soit souvent un processus en cascade. Cela me semble une déduction logique.

Ce que je trouve décevant dans cette approche c’est que, certes l’horizon de planification est passé de plusieurs mois à une itération, mais le modèle mental est resté le même : une demande d’engagement forte sur le triplet date+budget+scope. Rien n’a en fait changé en profondeur dans notre compréhension du caractère émergent de l’activité créatrice du développement logiciel.

Cette interprétation erronée amène d’ailleurs des équipes à s’épuiser rapidement après quelques itérations. C’est écrit d’avance pour ces équipes qui reproduisent à chaque itération le stress de ce type d’engagement.

2. … et à propos de la qualité :

Malheureusement la qualité des logiciels construits dans cet état d’esprit ne s’améliore pas sensiblement dans cette situation. On continue à construire des fonctionnalités inutiles. On continue à avoir de nombreuses anomalies.

Dans un précédent billet, j’avais partagé cette idée de mettre la qualité au coeur de notre engagement. J’ai d’ailleurs eu la chance de mettre en place ces idées chez un client depuis. Ca marche ! Aujourd’hui la nouvelle version du Scrum guide me conforte dans cette idée. L’ensemble des engagements de l’équipe de développement se simplifie et du même coup se concentre :
  • engagement de transparence
  • engagement de respecter la définition de terminé
  • engagement de concentration sur l’objectif du sprint
Il ne s’agit donc pas de substituer un engagement de sprint par une prévision de sprint mais bien de préciser que l’engagement de qualité est au service de l’atteinte d’objectifs itératifs. C’est un message puissant pour les équipes : il est plus utile d’avoir un engagement sur la qualité que d’avoir un engagement sur un contenu.
J’utilisais depuis quelques temps déjà le terme « sélection » pour décrire l’ensemble de PBI que l’équipe sélectionne en planning. Le terme « prévision » est plus puissant car il reconnaît l’incertitude de nos connaissances et ouvre la porte à l’émergence.
« Nous prévoyons d’atteindre cet objectif en construisant ces 3 fonctionnalités. La priorité est l’objectif. Si nous découvrons en cours de route une meilleure idée pour l’atteindre, nous la suivrons. »
Catégories :Journal, Scrum

Oubliez Scrum !

14 juillet 2011 2 commentaires

Joe: Nous sommes une équipe distribuée sur plusieurs fuseaux horaires. Il est impossible de trouver 15 minutes en commun pour faire un Daily Scrum. Scrum ne marche pas chez nous, il faut l’adapter.

Oubliez Scrum ! Est-ce difficile de se rencontrer rapidement dans la journée lorsque vous en avez subitement besoin ? Le Daily Scrum vous permet de vous entraîner à cela pour que cela ne soit jamais un problème dans la journée.

Dan: Chez nous il y a deux personnes différentes qui gèrent les priorités et le budget. Il est impossible de trouver un Product Owner. Scrum ne marche pas chez nous, il faut l’adapter.

Oubliez Scrum ! Sur quels critères décidez-vous (de continuer) d’investir dans un développement ? Sur quels critères décidez-vous d’arrêter un développement ? Sur quels critères décidez-vous de libérer une version au marché ? Le Product Owner vous permet de vous entraîner à ces questions en se les posant à chaque itération.

Jude: Notre système est extrêmement complexe, inclus des dizaines de modules qui gèrent des centaines de millions de dollars. Il est impossible de livrer chaque itération un incrément potentiellement prêt pour la production. Scrum ne marche pas pour nous, il faut l’adapter.

Oubliez Scrum ! Combien de temps se passe-t-il entre le moment où votre client préféré à une idée géniale et le moment où vous lui livrer un (morceau de) logiciel qui lui permet de tirer profit de son idée ? Que faudrait-il faire pour diviser ce temps par 2 ? La livraison d’incréments terminés à chaque itération vous permet de vous entraîner à diminuer ce temps pour pouvoir être opportuniste, pour pouvoir saisir facilement les opportunités marché.

Oubliez Scrum ! L’objectif n’est pas Scrum. L’objectif est l’amélioration. Scrum vous propose plusieurs axes d’amélioration. Chaque outils de Scrum – Sprint, Product Owner, Equipe, Done, Retro, Revue, Planning, Vision, Product Backlog, etc – se concentre sur un thème précis. Ils sont conçus pour fonctionner ensemble. Ils sont difficiles à comprendre. Votre Scrum Master est là pour vous les enseigner.

Catégories :Journal, Scrum Étiquettes : , , , ,

commitment and #scrum

14 juin 2011 1 commentaire

PM: I get angry when the team does not deliver its commitment because it breaks my plan.

PO: what do you call commitment?

PM: the features they commit to deliver.

PO: how does this understanding of commitment help you?

PM: well actually it doesn’t…

PM: what do you call commitment?

PO: the Team and myself we commit to be transparent.

PM: what do you expect from this commitment?

PO: from the Team, typically two things. First, the Team will ask me if it needs help to clarify requirements. Second, the Team will only deliver done increments.

PM: what if the Team does not deliver anything?

PO: it means we failed to express my vision into product backlog items that the Team can turn into potentially shippable increments

PM: … and it breaks your plan!

PO: my plan is never broken, I change it to maximize the value of my product.

PM: what if you don’t find a better plan?

PO: I’m accountable for maximizing the return on investment. Sometimes the best business decision is to stop investing in a product.

Catégories :Journal, Scrum Étiquettes : , , ,

Après #scrum

Quiconque ayant une idée
peut engager une équipe qui lui livre un logiciel en un mois
pour l’aider à tirer le meilleur de cette idée

Qu’est-ce que tu vois après Scrum ?

De mon expérience, lorsque quelqu’un me pose cette question, il s’attend à ce que l’on parle de la prochaine méthode, de la prochaine approche, du prochain outil. Il a souvent envie d’avoir un avis comparé sur toutes les méthodes ou techniques du moment. Je me souviens par exemple que c’est de cette manière qu’était posé le thème d’une table pendant un world-café Scrum avec l’intention d’étudier le buzz de l’époque sur le Kanban.

Aujourd’hui, ce n’est pas cet aspet de la question qui m’interpelle. Considérant Scrum comme un outil que l’on utilise pour découvrir ce que l’on a besoin de changer pour devenir meilleurs à développer des logiciels, la question de l’après Scrum m’incite à imaginer le monde lorsqu’effectivement nous serons devenus meilleurs à développer des logiciels.

Est-ce que tu imagines qu’alors nous n’aurons plus besoin de Scrum ?

Non car d’une part on peut toujours progresser, et d’autre part il faudra toujours former la relève.

Cette question de la formation des jeunes m’amène à considérer l’intégration de Scrum à l’enseignement universitaire non pas comme l’outil à apprendre mais comme un outil à utiliser au cours de la formation pour construire des équipes performantes. Ces universités, ou plutôt ces académies du logiciel, ne formeront plus des individus mais des équipes complètes capable de livrer un logiciel utile en un mois.

Le mouvement du software craftmanship qui étudie des modèles autour du compagnonnage nous donne des pistes pour repenser la formation continue autour du parrainage actif de ces nouvelles équipes par des professionnels d’expérience.

De son côté le lean startup explore des modèles de recherche de valeur en se basant sur des cycles d’apprentissage très rapide.

Plusieurs questions se bousculent. Que veux-tu dire par livrer un logiciel utile en un mois ? Pourquoi un mois ? J’ai en tête des systèmes qui ont mis des années à être construits, imagines-tu pouvoir les construire en un seul mois ?

Lol. Allons-y doucement.

Plusieurs pièces du même puzzle s’emboîtent pour moi très naturellement.

Une première pièce concerne la formation que l’on vient d’évoquer. Une autre concerne le mode de financement.

Le passage du Waterfall à Scrum a des impacts importants sur de nombreux aspects. Néanmoins, sur le terrain, le mode de financement est souvent resté le même. Je rencontre de nombreux cas dans lesquels des projets démarrent pour 12 ou 18 mois tout en disant qu’ils vont utiliser Scrum. Plusieurs éléments m’interpellent dans ces situations. Par exemple on parle alors souvent de projets, et non de produits. Ou encore, plus évident, on a déjà un plan et un financement pour plusieurs mois, ce qui me semble contradictoire avec une approche empirique, c’est à dire une approche qui considère que l’humain ne sait pas identifier ce qui sera une bonne idée dans 6 mois.

Imaginons maintenant une rupture plus nette. Un mois, un seul.

Cela nous invite à considerer un mode de financement différent. Dans ce mode, je ne finance que le premier mois et je mets en production l’incrément construit. Cet incrément ensuite génère lui même les bénéfices pour financer un autre incrément.

Cela suppose que l’on sache trouver de la valeur en un seul mois.

Oui. Et que l’on sache livrer un incrément terminé en un mois. C’est une invitation à aller au delà du potentially shippable, c’est une invitation à shipper.

Scrum est un outil pour être meilleur. Un outil pour s’entraîner à livrer un logiciel utile en un mois. S’entraîner à trouver la fonctionnalité utile. S’entraîner à construire un incrément terminé. Les deux.

Shipper plutôt que potentially shippable me semble puissant car dans sa recherche de ROI, le Product Owner doit mettre en production pour effectivement avoir accès au ROI. Sinon, ce ROI n’est que potentiel.

N’as-tu pas peur de perdre les avantages de l’empirisme dans cette idée de faire des itérations d’un mois ?

Je n’ai pas dit ça.

Vous vous rappelez sans doute que dans la première description de Scrum, Ken et Jeff parlaient de sprints d’un mois, plus exactement de 30 jours. On a tous interprété cela comme des itérations d’un mois. Et on continue d’ailleurs à traduire sprint par itérations et de parler de sprints ayant des tailles comprises entre 1 et 4 semaines. Il faut dire que cela a des côtés pratiques dans nos calendriers.

Si on cantonne la notion de sprint au container de 30 jours dans lequel l’équipe se dote d’un objectif de sprint, le sprint goal, et s’impose un niveau de qualité production, rien n’empêche l’équipe de faire des itérations à l’intérieur de ce sprint, par exemple d’une semaine.

Cela ouvre l’idée de livrer un logiciel en un mois, puis de s’arrêter pour attendre d’avoir de nouvelles idées. Ne penses-tu pas que les clients continueront à avoir envie d’ajouter immédiatement d’autres fonctionnalités ?

On parle de clients dans un futur avec des équipes capables de leur livrer en un mois un logiciel pour les aider à tirer profit de leur idée. Ce ne sont pas les clients que l’on connait aujourd’hui. Leurs états d’esprit n’est plus le même. Ils valorisent le feedback d’utilisateurs qui ont utilisé le logiciel en situation réelle. Parfois plusieurs semaines, plusieurs mois peut être seront nécessaires pour un feedback pertinent. Pour ceux qui sont dans ce cas, s’ils ont envie d’ajouter une fonctionnalité, ils ne voudront certainement pas l’ajouter immédiatement, ce serait trop risqué.

Reprendre un développement plus tard représente un risque, comment être sûr que l’on trouvera une équipe capable d’ajouter une fonctionnalité ?

Aujourd’hui on est déjà dans cette situation. Il n’y a pas de raison de penser que le monde va devenir plus simple. Il y aura toujours des incertitudes, elles ne feront que changer et probablement que nous ne pouvons pas aujourd’hui anticiper de quelles natures elles seraient dans ce futur.

On peut néanmoins anticiper que les équipes continueront à avoir des spécialités. Certaines choisiront par exemple les énormes systèmes à modifier en un mois pour ajouter une fonctionnalité clef. D’autres se spécialiseront sur les nouveaux logiciels sans héritage à inspecter et un nouveau domaine à explorer.

L’industrie continuera à progresser. Les techniques et les outils continueront à s’améliorer et les prochaines promotions feront en une semaine ce qui prenait un mois aux précédentes. Le parrainage permettra d’enrichir mutuellement les mondes universitaires et professionnels.

Le point clef est d’apprendre à livrer un logiciel utile en un mois. Les équipes ont l’embarras du choix pour s’entraîner. Le monde regorge d’associations caritatives qui pourraient bénéficier de leur travail. Un seul critère d’évaluation : que le logiciel soit utilisé.

Tu parles d’académies, de mettre au placard les développements de plus d’un mois, mais tu vois ça pour quand ?

Les progrès accomplis dans les 10 dernières années tels que je les comprends me font penser que cela mettra plus de 10 ans. J’aimerais que cela prenne moins de 20 ans pour pouvoir en profiter.

Cela semble ambitieux. Par où commencer ?

C’est la troisième pièce de mon puzzle : le chemin pour nous y rendre. Pour l’instant je n’en connais que le début bien sûr. Et encore, un début qui fait du sens pour moi.

Evidemment il faut continuer à s’entraîner car nous sommes loin de ce monde. Cela veut dire enseigner tout ce qui peut aider une équipe à livrer un logiciel utile en un mois. Je contribue à cette effort en donnant des formations sur les pratiques agiles.

S’entraîner cela veut dire aussi aider les équipes à mettre en place ce qui fonctionne pour nous et que nous enseignons. Je me concentre aujourd’hui sur deux activités clefs qui maximisent selon moi cette transmission. D’une part l’animation de dojos dans les équipes. D’autre part l’immersion dans ces équipes : un mois avec une équipe avec l’objectif de lui transmettre le plus de savoir-faire et savoir-être possible.

S’entraîner enfin c’est livrer des logiciels utiles en un mois. De nombreuses personnes ont des idées et voudraient trouver une équipe pour leur livrer un logiciel rapidement pour tirer profit de leur idée.

Donc si je comprend bien, ils n’ont qu’à te contacter.

Exactement :).

Catégories :Journal, Scrum Étiquettes : ,