Friday, March 12, 2010

Linkastro

On a side note, check out my parallel project: Linkastro, associazione culturale teatrale a Brescia, www.linkastro.it !!!

;)

Friday, October 24, 2008

The first release plan, pragmatic

Eravamo io, Paco Gongora, Fidel Castro, l’Uomo Ragno, Maurizio Micheli, Diego Armando Maradona… no, just kidding (I remember the great imitation of Gianni MinĂ  by Fiorello!).

We were just me and the product manager. We haven't a team of developers yet!
I introduced some concepts to my product manager about the planning technique. I started to tell him that in the agile jargon he is not the product manager anymore, but the...product owner! Pronunced "il produttone". I quickly explained him things such as what is the customer proxy, what is a user story, release/iteration planning, buffering stories for uncertainity... basically the outer loop. He seemed to understand and approve! :)
We inserted all the bugs, enhancements and ideas in Bugzilla for weeks, now it's time to plan the next release and protect the team (only me, sigh!) from continuous interruptions for feature requests (grrr).
So, let's write stories to implement ("che storia!"). Ok, these are not real customer stories in the orthodox meaning, but just issues that we have to plan.

Story preparation
  1. Enumerate all NEW issues in Bugzilla, we had about 60 issues.
  2. For each issue, discuss meaning and scope of each one, if there are doubts. Write a stor on a card with only the title and Bugzilla's issue id on the top right corner, and highlight it in red if this is critical (write in the body only some clarification if necessary. We are developers plus the product owner, it's just redundant to write the story in the usual lengthy format, I think that that is useful only for the customer).
  3. Set ASSIGNED for the issue in Bugzilla, so we remember that the issue has already been processed.
  4. Let the product owner prioritize stories. This must be done before the complexity estimation, so the developer knows whether it is important to split a story or wait the next iteration. The prioritization is just done in the way "this comes before than that". Then we numbered the prioritized list to save us from the risk that the cards get out of order. If possible, write the business value (for example using a Fibonacci scale: 100, 200, 300, 500, 800, 1300...), it describes better the order of magnitude of importance.
Complexity estimation
  1. Estimate complexity using relative comparisons. I like story points, but I think they work better in a team environment. For myself I tend to think in ideal days, so I'm using this unit of measure at the moment (using always the good ol' Fibonacci scale). For one developer alone I think that story points and ideal days coincide though. In fact I tried both! To test the story points I tried the following procedure: since we have so many stories and no experience with story points I did a two-pass refactorying of the stories. In the first pass I quickly divided them in S, M, L, XL size. In the second pass I converted the size to a number using the Fibonacci scale, starting from the M size and assiging it a 5, from there it was easy to set S=1,2,3; L=8; XL = 13 or greater. The numerical difference with ideal days was neglectable. 
  2. Split stories with high priority (business value). Go to step 1.
Release planning
  1. Decide iteration length. Being the first time, we try with 2 weeks.
  2. The velocity is unknown yet. This is the total of story points completed in one iteration. I haven't historical values and we are not asked to make a forecast for a customer. Moreover, we decided that the release will be feature driven instead of date driven, so the best way should be to run some iteration and observe the velocity. Let's start by implementing the stories with highest priority first and see how many story points we can complete in 2 weeks.
  3. When the velocity is known after the first iteration (or better the average of the first 2 or 3 iterations), let the product owner decide which stories to implement so that total_story_points <= velocity*number_of_iterations and the total_business_value is maximized.

These steps are mostly inspired by Agile Estimating and Planning.

Thursday, October 2, 2008

Back from Intergeo in Bremen

My first month in the new company is gone. Lots of things to do: move to new the house, set up a minimal development enviroment and sniff around the situation. In fact I just came back from Intergeo in Bremen to see the state of the art in geomatics. 

Lots of planning to do now in order to define development priorities. Find people to hire.
At the moment I have just installed Bugzilla and TWiki for the company intranet. I had to uncover from the dust my skills with Linux... there is my blood on the keyboard!!!
I have switched from Subversion to Mercurial. I have tried also Git, which seems in the trend now, but I found it not as smooth as Mercurial, at least on Windows. Maybe I will post something more detailed about it in the future. 
Back to work now...

Tuesday, August 26, 2008

Phase transition

Sorry for the recent lack of posts, but I actually had no idea of anything relevant to write! I'm in deep study in this period because I'm going to change job at the end of august. After 7 years closed in the JRC spent researching and developing the Reconstructor, I'm going to breathe the sparkling hot air in the battlefield of commercial applications. I hope it won't melt me.
Now I understand that a blog to be successful has to be well focused first and then updated frequently. And I've decided that I'm going the Agile & 3D way, definitely.
So, along with fine tuning my internet marketing skills ;) I'm reading a lot of books to build up my planning and management skills.
Here are the books in my current portfolio. I have rated the books I've already read as: interesting, useful, must have. This is my current rating though...

Books I keep using:
* Design Patterns: Elements of Reusable Object-Oriented Software
* Refactoring: Improving the Design of Existing Code
* The C++ Programming Language
* Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions
* Modern C++ Design: Generic Programming and Design Patterns Applied

Books I've read recently:
* Practices of the Agile programmer
* The Back of the Napkin: Solving Problems and Selling Ideas with Pictures
* How to Mind Map
* Presentation Zen: Simple Ideas on Presentation Design and Delivery
* The Cluetrain Manifesto: The End of Business as Usual
* Who Moved My Cheese? An Amazing Way to Deal with Change in Your Work and in Your Life
* Everything Is Miscellaneous: The Power of the New Digital Disorder
* Screw It, Let's Do It: Lessons In Life
* Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets
* The Goal

Books I'm reading:
* Agile Estimating and Planning
* Ship it! A Practical Guide to Successful Software Projects
* Behind Closed Doors: Secrets of Great Management
* Brain Rules: 12 Principles for Surviving and Thriving at Work, Home, and School
* Wikipatterns

Backlog of books:
* Mastering CMake 4th Edition
* Working Effectively with Legacy Code
* The Art of Agile Development
* Project Retrospectives: A Handbook for Team Reviews
* Refactoring to Patterns
* Producing Open Source Software: How to Run a Successful Free Software Project
* Refactoring in Large Software Projects: Performing Complex Restructurings Successfully
* Dialogue Mapping: Building Shared Understanding of Wicked Problems
* Finance for Non-Financial Managers
* slide:ology: The Art and Science of Creating Great Presentations
* JavaScript: The Definitive Guide

Phew!!! It amazes me to see that list, if you think that at school I was't able to finish a single book! I would have get bored halfway through... but that's another story...

So these are some of my intellectual resources that I rely on to start my new journey. If you have suggestions, you're welcome!
I was thinking about keeping a private diary about my successes and failures in adopting agile and management practices. A sort of retrospective of what i did, in order to force me an objective view. Then I thought, why don't post it in the blog? If someone can find it useful too and contribute with feedback... the better!

Wednesday, July 23, 2008

Pair progamming anyone?

I have some doubts about pair programming. First of all it's expensive for a company to pay two people writing with one keyboard. Some papers tell that they always produce less than separately. Second, it might be difficult indeed to pair them, in terms of matching the personalities. Coders are smart with strong egos...
However I understand that pair programming is a long term investment for collective code ownership and better code design.
Now, I have stumbled in this tool for Eclipse, called Cola, for real time shared coding. I haven't tried it yet, but it is very interesting. To me it seems to unleash all the pair programming power.


Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo.

Tuesday, July 15, 2008

Thanks to Radiohead laser scanning is finally art

Thanks to Federico Gobbo for make me aware of this!
This is exactly what I work on in my company, check JRC 3D Reconstructor



Information on the making of and interactive application here

Wednesday, July 9, 2008

Banish strong beliefs!

The other day, my estimated colleague said "I don't really believe in this Agile stuff, where I used to work we really need to collect all the specifications upfront". His mood was like saying "we NEED a Waterfall approach". Ok. Has him ever done something Agile? No.