Carlo Pecchia's blog

On Products selection

2011-12-01T17:02:03+01:00

Often we face the problem of selecting a right product for us (middleware, utility programs, COTS, and so on). What should we do in order to make an informed and managed choice? Here I’d like to propose a little no non-sense approach.

Basically we need to know what we want, what are our needs. Then we can collect characteristics and factoids about the solution the market provides. It’s worth noticing that at this point we select only the products that could match our needs, and nothing more (hopefully). Now the question become “how much well do they match our needs?”.

Now, for each selected product, we can study it, prove it and collect data to analyze its behaviour: for each features we can assign a score (eg: from 1 to 5). Using sandboxes can also help us to refine the previously done needs analysis.

Of course features/needs are scored too: we don’t give to all of them the same importance. So each scored features is also weighted.

At this point we have a score for each product: we are able to make an informed choice with a little qualitative analysis. A (little) time worth spent!

To summarize:

features and needs analysis (= WHAT we need)
products gathering (= what COULD match my needs)
products analysis and scoring (= HOW MUCH do they match, and need analysis refinement)
weighted choice (= THE best for us)

Some example of characteristics:

product age (more stable, young, not well tested/adopted)
cost of installation, education, maintenance and operations
how “stable” is the product owner (company or open source community)
available documentation (generally easy to evaluate)

Simple, but often forgotten!

(photo credits Marzacas)

IAD2011 follow up

2011-11-21T18:06:27+01:00

As stated before this year edition of Italian Agile Day was dense of interesting talks. For detailed comments for every talk - and links to slide - see here.

Italian Agile Day 2011

2011-11-11T11:59:32+01:00

On 19.11.2011 there is the 8th edition of the Italian Agile Day, an event rich of interesting talks (26) about Agile, XP, Scrum, UX.

Participation fee? It’s FREE!

Target audience? Managers, Developers, Project leaders, Coaches… everyone!

SCM rules

2011-10-31T12:37:26+01:00

SCM (Software Configuration Management) tools are considered a cornerstone for every good software production environment today. Despite that a lot of problems can be introduced: branches messing, lack of policies and purposes.

In his excellent paper Henrik Kniberg show us some simple rules in order to avoid main problems. Here I don’t want to just repeat the rules, rather I’d like to show how important, appropiate and useful are simple rules.

We have some goals: (1) we want to fail fast so code conflicts and integration problem pops up near the event that caused them; (2) there should be always something releasable (within a good definition of “done”); (3) rules and this “mini process” must be simple, so team(s) can’t avoid them.

Rule: each branch in SCM repository has an owner and a policy.

The owner unsures the policy is applied and the branch is coherent with its purpose. The policy describes what kind of code goes in the branch. That forces also to avoid braches proliferation without any meaning: need a branch? Ok, but what is the purpose, the policy, the owner?

Trunk is the Done branch (can release at any time)

Rule: whoever touch the Trunk is responbile that everything works well (previous functionalities included!)

Development branch: code compiles without errors, all unit test passes, builds happean successfully

This ensure in this branch only tested code is allowed: simple and clean. This forces also to synchronize often with the Trunk in order to lately discover that we have to recode something (interfaces change, new classes, …).

Learn by Doing

2011-10-31T12:35:54+01:00

What about if you are an house builder and you buyer can’t (I reply CAN’T) tell you exactly how she want the house to be made?

Of course she has a simple sketch in her mind: house typology, the usage she will do (single vs family with children) how many floors and rooms… but you can’t have too much details in advance: the buyer simply don’t yet know them.

So, is your interest to promote a “conversation” within both you and her, so you can learn as much as possible. In doing so you should also build “something” and - of course - you can’t build a real house, but you can experiment with sketches, prototypes or you can take and propose ideas from other houses.

you have to learn as much as possible.

This is - in my opinion - a primary building block for every (software) project manager: learn as you go.

After all if you apply some iterative/incremental approach (Scrum) you do exactly that: you gain a little more knowledge of your evolving problem step-by-step.

I found a related article (sorry, only in Italian) by Gabriele Lana here about estimation in Agile environments. It’s a really interesting elevator pitch where I can clearly see the concept of “learn by doing”.