Articles de éric :
- 5′ introduction
- 15′ présentation du sujet
- 40′ travail libre en binôme
- 10′ pause
- 15′ présentation par un binôme
- 15′ perfection game par le public
- 10′ clôture
- Coder dans le train avec Vincent qui a mis à mal la première version de mon modèle,
- La liste de tests capturée sous la forme de scénarios à venir,
- le refactoring de la liste de test qui précise les intentions des tests quand vient le temps de les écrire. Cette activité est homogène à un travail sur un backlog pendant un planning d’itération.
- binômer avec Xavier
- avoir un fil rouge parmi une foule d’autres activités
Dojo@Pyxis
ATTD avec Cucumber
Je voulais rester dans des temps raisonnable pour l’enregistrement vidéo. Alors j’ai essayé de n’écrire que des tests Cucumber, pour gagner du temps. Je n’étais pas très confortable avec cette idée car j’anticipais que j’allais avoir envie d’écrire des tests plus unitaires en cours de route. Cela m’a incité à écouter les tests avec plus d’attention et à programmer par intention.
J’ai vraiment apprécié cet exercice et plus particulièrement:
Kata .Net
Professionnal Scrum Foundations
Classes ouvertes en ruby
Le kata du mois dernier proposé par @12meses12katas m’a encore appris quelque chose. C’était la première fois que je faisais en Ruby le kata bowling. Comme d’habitude je voulais passer sous les 10 minutes avec un code et des tests avec lesquels je sois confortable, c’est à dire qui communiquent leurs intentions d’une manière que je pourrais encore comprendre l’année prochaine.
J’ai commencé par écrire des tests qui ressemblaient à ceci:
describe Bowling do
specify "spare" do
claire.sheet = "1/------------------"
claire.score.should == 10
claire.sheet = "1/2-----------------"
claire.score.should == 14
end
end
J’ai continué tranquillement avec le kata et lorsque j’ai fait passé les tests avec les cas plus complexes avec des spares et des strikes j’ai regardé mon chronomètre et j’ai pris une baffe: 24 minutes. J’ai recommencé plusieurs fois, j’ai posé mon scénario sur une feuille, pour arrêter de perdre du temps à calculer les résultats attendus, j’ai utilisé un raccourcis clavier de plus pour introduire une variable dans RubyMine, j’ai tapé sur mon clavier comme un fou, j’ai mis une table dans les tests, et j’ai péniblement atteint 18 minutes. Bof.
Puis je me suis rappelé du kata des chiffres romains de @jacegu du mois dernier et j’avais bien aimé ses tests qui utilisaient une extension de la classe Fixnum. Alors j’ai essayé de mettre ça en pratique et cela donnait des tests assez différents:
describe Bowling do
specify "spare" do
"1/------------------".scores(10)
"1/2-----------------".scores(14)
end
end
J’aime mieux cette version des tests qui se concentrent sur le problème à résoudre et supprime le bruit. En plus cela m’a permis de baisser le chrono
.
“a working proposal” : semaine 3/3
C’est toujours émouvant pour moi d’arriver à ce qui semble être la “fin” d’une aventure. Depuis 3 semaines nous avons eu cette journée en point de mire. La construction de cette offre autour d’un logiciel qui fonctionne chaque semaine a été le fil rouge qui m’a guidé dans une foule d’autres activités.
Ce que j’ai aimé dans cette expérience:
Pour que cela soit parfait, faudrait-il que notre prospect décide de poursuivre ou bien est-ce que cela va chercher ailleurs ? Cette idée de “gagner la propale” dans le future rend-elle meilleure l’expérience passée ?
Comme on nous l’a dit souvent, c’est plus l’aventure, le parcours qui nous rend heureux, moins que la destination. Alors je n’ai pas d’idée pour améliorer l’aventure ; le logiciel oui
“a working proposal” : semaine 2/3
Deuxième semaine de notre aventure de construction logiciel en parallèle de la mise au point de notre offre de développement. Bien sûr cette semaine s’achève avec une revue d’itération et une rétrospective.
C’est l’occasion pour nous de faire le point sur notre incrément, le produit dans son ensemble, notre compréhension actuelle d’une stratégie incrémentale pertinente pour atteindre les objectifs visés. Pour cela nous nous sommes retrouvés autour du second incrément déployé sur Heroku, autour de notre Product Backlog et de notre propale.
La semaine dernière nous n’avions pas partagé avec notre prospect l’incrément réalisé. Cette semaine c’est différent. Maintenant que nous avons deux incréments, nous avons de quoi démontrer ce que veut dire “construire un logiciel par incréments successifs”. Il se trouve que notre prospect n’a jamais travaillé de cette manière. La semaine dernière nous avions décidé de déployer certes mais sans le lui dire. Notre sentiment était que la notion d’incrément risquait d’être très théorique à ce stade. Maintenant nous avons deux incréments, avec des adresses distinctes. On peut donc voir concrètement l’ajout de fonctionnalités entre les deux versions. Quel sera son feedback ? Suspence…
« a working proposal » : kick-off
#scrum release burndown chart
PM: I want to see increase the velocity of the Team
PO: I want to see decrease the remaining work
PM: If the velocity increases, the remaining work will decrease
PO: No, new work could be added at the same time
PM: I don’t like when the Team updates an item with a smaller effort estimation because the velocity could decrease
PO: I like when the Team updates an item with a smaller effort estimation because the remaining work decreases
PM: You don’t track the velocity in a velocity chart?
PO: No, I track the remaining work in a release burndown chart


