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!).
- Enumerate all NEW issues in Bugzilla, we had about 60 issues.
- 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).
- Set ASSIGNED for the issue in Bugzilla, so we remember that the issue has already been processed.
- 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.
- 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.
- Split stories with high priority (business value). Go to step 1.
- Decide iteration length. Being the first time, we try with 2 weeks.
- 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.
- 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.
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.
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.
The beginning (thanks ESSAP 2008)
Ok, here I am too to contribute at the multitude of blogs!
Yeah... like if someone finds interesting a drop of water in the ocean.
I've always wondered what kind of immense ego one has to have to think that his diary is worthy. I thought things like "Who are you? Don't you have anything better to do!?". Is my stream of consciousness really relevant to someone else?
But I found me reading the posts of my friends for just curiosity, to learn new things and know but they really think. Stuff that is more elaborate and intimate than the face to face talk. It's deeper feedback on the world around me. To improve the quality of my job or life. That is what is really all about.
Feedback, feedback, feedback. And sharing, sharing, sharing.
These are the leading principles of Agile methodologies. I find it interesting to have connections with control system theory. Systems with feedback can have the most controllable and stable (i.e. sustainable) performance.
Wait! This is not the new Scientology. This is the real stuff.
It's just one year that I'm digging to understand what Web 2.0, Enterprise 2.0 and Agile/XP are preaching. I've just attended the fantastic 3rd European Summer School on Agile Programming (ESSAP: http://essap.dicom.uninsubria.it/) and in one way or the other this blog post is the first public consequence of it. One might say that we never talked about blogs during ESSAP. Right. Whatever.
I really recommend this course to any coder out there. I really appreciated the techniques to reduce redundant discussions during meetings using mind maps, wikis and simple stickers on a blackboard. That's pretty non-obvious in certain places like the one I come from...
And now expect more posts! About anything, from coding to computer graphics. From music to travels. You are warned!
