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