Friday, November 13, 2009

Test Event Listeners in google test

Interesting thread about extending the TestEventListener interface of google test.

Test Event Listeners and list tests

Paolo.

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 ;).

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 :-)

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