Interesting thread about extending the TestEventListener interface of google test.
Test Event Listeners and list tests
Paolo.
Friday, November 13, 2009
Thursday, June 18, 2009
Agile Coaching
My friend Rachel has published a book about Agile Coaching.
I have worked with Rachel back in 2000 for a couple of years.
In this book she's put 10 years of experience in helping teams.
I'll write more on this as soon as I'm finished reading it.
The book is available through the PragProg's site: http://pragprog.com/titles/sdcoach/agile-coaching
Paolo
...yes, it's been quite a while since my last post ;).
I have worked with Rachel back in 2000 for a couple of years.
In this book she's put 10 years of experience in helping teams.
I'll write more on this as soon as I'm finished reading it.
The book is available through the PragProg's site: http://pragprog.com/titles/sdcoach/agile-coaching
Paolo
...yes, it's been quite a while since my last post ;).
Wednesday, February 07, 2007
Do it because it works.

As agile coaches, we recently helped a small team of skilled developers divided on two projects to share their knowledge so that they could all work on both projects.
We had 4 developers:
dev1+dev2 on Project A (had worked in pair already)
dev3+dev4 on Project B (no pair programming)
Now, these guys work in highly paced environment with one week iterations. They have to release every week (and they do).
Hence our goal was to make them pair without reducing their velocity.
Devs on project A know project B, but only as users. They'd never seen a line or code. Viceversa, devs on B don't know much of the code behind project A, except - of course - part of the (common) company framework.
We did the planning game on monday, which took the whole day as it was the first cross-project planning where knowledge about both A and B had to be shared across the team.
During the planning every user story was estimated and "designed".
The team agreed on how to best implement the stories (not without a few design fights ;)).
Tuesday through friday we allocated 10 minutes each day for the stand up meeting to track how the week was going, whether there were issues, or if we were on time or not. We also managed to squeeze in a half-day spike (tuesday) on a big refactoring which eventually made us have a two hour planning on wednesday to decide whether it was feasible to do the big refactoring that week or it had to be scheduled later on. We decided to go ahead with the big refactoring.
At the end of the week, every programmer had worked with everybody else in the team (including me and Gerri). The software patterns used to implent the stories were shared, for the planning game had not left much to imagination ;), hence the code was "cleaner" and more refactored.
We released, on time.
What has the management gained?
They used to have 2 people on project A and 2 on project B. Now - in a way - they have 4 on A and 4 on B, at least in terms of knowledge.
Velocity was mainted.
We can actually foresee an increase in velocity by the next 10 iterations.
So, this post is really for all the managers out there...
Move to agile.
It works :-)
We had 4 developers:
dev1+dev2 on Project A (had worked in pair already)
dev3+dev4 on Project B (no pair programming)
Now, these guys work in highly paced environment with one week iterations. They have to release every week (and they do).
Hence our goal was to make them pair without reducing their velocity.
Devs on project A know project B, but only as users. They'd never seen a line or code. Viceversa, devs on B don't know much of the code behind project A, except - of course - part of the (common) company framework.
We did the planning game on monday, which took the whole day as it was the first cross-project planning where knowledge about both A and B had to be shared across the team.
During the planning every user story was estimated and "designed".
The team agreed on how to best implement the stories (not without a few design fights ;)).
Tuesday through friday we allocated 10 minutes each day for the stand up meeting to track how the week was going, whether there were issues, or if we were on time or not. We also managed to squeeze in a half-day spike (tuesday) on a big refactoring which eventually made us have a two hour planning on wednesday to decide whether it was feasible to do the big refactoring that week or it had to be scheduled later on. We decided to go ahead with the big refactoring.
At the end of the week, every programmer had worked with everybody else in the team (including me and Gerri). The software patterns used to implent the stories were shared, for the planning game had not left much to imagination ;), hence the code was "cleaner" and more refactored.
We released, on time.
What has the management gained?
They used to have 2 people on project A and 2 on project B. Now - in a way - they have 4 on A and 4 on B, at least in terms of knowledge.
Velocity was mainted.
We can actually foresee an increase in velocity by the next 10 iterations.
So, this post is really for all the managers out there...
Move to agile.
It works :-)
Labels:
agile,
pair programming,
planning game,
process
Monday, February 05, 2007
How do you recognise an Agile company? (fwd)
Nice post by Rachel Davies about how to recognise an agile company
Wednesday, January 10, 2007
New York

My first business trip to New York.
This city is absolutely amazing! Buildings, architecture, museums, art...
One (geek) thing that shocked me is the number of wireless networks available. I did a few network scans with my laptop (in different areas of the city) and never found less than 20 (twenty!) networks. wow.
Monday, December 04, 2006
Italian Agile Day 2006
Thanks to Marco Abis the 3rd Italian Agile Day has been a success with almost 200 participants!
I was there with my team (webshell) to present a workshop on database refactoring and to run an XP Game.
Thursday, November 23, 2006
Simple Refactoring Example (follow up)
Matteo pointed out that code presented in the simple refactoring example could be even simpler.
as a matter of fact the line
myHashtable==null && anItem.myHashtable==null
could be removed as there is no way to create a RealItem with a null hashmap.
Very true.
Thanks!
P
as a matter of fact the line
myHashtable==null && anItem.myHashtable==null
could be removed as there is no way to create a RealItem with a null hashmap.
Very true.
Thanks!
P
Subscribe to:
Posts (Atom)