Log of the retrospective analysis from Pharo 2.0
Hello happy pharoers Since Pharo2.0 will be released pretty soon, we led a retrospective analysis to learn and improve our process. Here are the notes taken by clement from the meeting led by esteban with all the team here. Pharo 2.0 Retrospective meeting by Esteban Lorenzo The Good BugTracker as Backlog Sprint / mini - sprint / pair programming Locking changes before release Community getting involved Web doc jenkins : the monkey, zeroconf script Smalltalkhub The Bad Trello We need a place to backlog what to do. We should use the FogBugz bug tracker Long development cycle (1 year), Focus problem : most things works but are not finished We should have a 1 to 2 months cycle with a part where we introduce new things and a part where we only fix bugs. At the end of each cycle, Pharo should be stable. Each cycle should have a retrospective meeting. We should pair program every friday afternoons on Pharo improvements. New failing test in Jenkins, Red builds on jenkins stayed forever We need a clear separation between pharo and pharo contribution both on smalltalk hub and Jenkins to have a clean green front end to show to end users In case of a red build, we need a quick meeting to pick someone to fix it. We need to fix the red builds on the friday' mandatory mini sprint Integrator bottleneck More intelligent monkey better tools (spec tool idea from Esteban where you just click accept and the slce is integrated) New features accepted only with tests and comments Only slices accepted no more change sets Pointless discussions on the mailing list Documentation : class comments, ... do not integrate undocumented features add code critics features in the monkey change the template of the class comment The Ugly 2 weeks lost : broken image during ESUG 2 weeks lost : beginning of the year : no VM working, jenkins couldnât test things. -> we will staged development. Communication failed : team and community For new features, send more mails to the Pharo or RMOD mailing list and less to the RMOD mailing list or private mails between few people Infrastructure VM : stability Stability : 1 VM release per Pharo release. 1 official Vm which is not just some VM from a build. Stability : VM not release if an acceptance list does not work with the VM. The acceptance list is for now all the Pharo core, seaside and Moose
Thanks for the report. It's great to see you doing a retrospective. I hope you will do it regularly :). Cheers, Doru On Mar 15, 2013, at 9:49 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hello happy pharoers
Since Pharo2.0 will be released pretty soon, we led a retrospective analysis to learn and improve our process. Here are the notes taken by clement from the meeting led by esteban with all the team here.
Pharo 2.0 Retrospective meeting by Esteban Lorenzo
The Good ⢠BugTracker as Backlog ⢠Sprint / mini - sprint / pair programming ⢠Locking changes before release ⢠Community getting involved ⢠Web doc ⢠jenkins : the monkey, zeroconf script ⢠Smalltalkhub The Bad ⢠Trello ⢠We need a place to backlog what to do. We should use the FogBugz bug tracker ⢠Long development cycle (1 year), Focus problem : most things works but are not finished ⢠We should have a 1 to 2 months cycle with a part where we introduce new things and a part where we only fix bugs. At the end of each cycle, Pharo should be stable. Each cycle should have a retrospective meeting. We should pair program every friday afternoons on Pharo improvements. ⢠New failing test in Jenkins, Red builds on jenkins stayed forever ⢠We need a clear separation between pharo and pharo contribution both on smalltalk hub and Jenkins to have a clean green front end to show to end users ⢠In case of a red build, we need a quick meeting to pick someone to fix it. ⢠We need to fix the red builds on the friday' mandatory mini sprint ⢠Integrator bottleneck ⢠More intelligent monkey ⢠better tools (spec tool idea from Esteban where you just click accept and the slce is integrated) ⢠New features accepted only with tests and comments ⢠Only slices accepted no more change sets ⢠Pointless discussions on the mailing list ⢠Documentation : class comments, ... ⢠do not integrate undocumented features ⢠add code critics features in the monkey ⢠change the template of the class comment The Ugly ⢠2 weeks lost : broken image during ESUG ⢠2 weeks lost : beginning of the year : no VM working, jenkins couldnât test things. ⢠-> we will staged development. ⢠Communication failed : team and community ⢠For new features, send more mails to the Pharo or RMOD mailing list and less to the RMOD mailing list or private mails between few people ⢠Infrastructure ⢠VM : stability ⢠Stability : 1 VM release per Pharo release. 1 official Vm which is not just some VM from a build. ⢠Stability : VM not release if an acceptance list does not work with the VM. The acceptance list is for now all the Pharo core, seaside and Moose
-- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."
On Mar 15, 2013, at 10:24 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks for the report.
It's great to see you doing a retrospective. I hope you will do it regularly :).
Yes we will do that everything cycle. a cycle will be around a month.
Cheers, Doru
On Mar 15, 2013, at 9:49 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hello happy pharoers
Since Pharo2.0 will be released pretty soon, we led a retrospective analysis to learn and improve our process. Here are the notes taken by clement from the meeting led by esteban with all the team here.
Pharo 2.0 Retrospective meeting by Esteban Lorenzo
The Good ⢠BugTracker as Backlog ⢠Sprint / mini - sprint / pair programming ⢠Locking changes before release ⢠Community getting involved ⢠Web doc ⢠jenkins : the monkey, zeroconf script ⢠Smalltalkhub The Bad ⢠Trello ⢠We need a place to backlog what to do. We should use the FogBugz bug tracker ⢠Long development cycle (1 year), Focus problem : most things works but are not finished ⢠We should have a 1 to 2 months cycle with a part where we introduce new things and a part where we only fix bugs. At the end of each cycle, Pharo should be stable. Each cycle should have a retrospective meeting. We should pair program every friday afternoons on Pharo improvements. ⢠New failing test in Jenkins, Red builds on jenkins stayed forever ⢠We need a clear separation between pharo and pharo contribution both on smalltalk hub and Jenkins to have a clean green front end to show to end users ⢠In case of a red build, we need a quick meeting to pick someone to fix it. ⢠We need to fix the red builds on the friday' mandatory mini sprint ⢠Integrator bottleneck ⢠More intelligent monkey ⢠better tools (spec tool idea from Esteban where you just click accept and the slce is integrated) ⢠New features accepted only with tests and comments ⢠Only slices accepted no more change sets ⢠Pointless discussions on the mailing list ⢠Documentation : class comments, ... ⢠do not integrate undocumented features ⢠add code critics features in the monkey ⢠change the template of the class comment The Ugly ⢠2 weeks lost : broken image during ESUG ⢠2 weeks lost : beginning of the year : no VM working, jenkins couldnât test things. ⢠-> we will staged development. ⢠Communication failed : team and community ⢠For new features, send more mails to the Pharo or RMOD mailing list and less to the RMOD mailing list or private mails between few people ⢠Infrastructure ⢠VM : stability ⢠Stability : 1 VM release per Pharo release. 1 official Vm which is not just some VM from a build. ⢠Stability : VM not release if an acceptance list does not work with the VM. The acceptance list is for now all the Pharo core, seaside and Moose
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
participants (3)
-
stephane ducasse -
Stéphane Ducasse -
Tudor Girba