Scrivere un titolo non è così difficile

Pasquale(!) mi ha segnalato questo articolo interessante riguardo come le pratiche agili, male implementate, stiano provocando cattiva fama nell’industria (quale non si sa). A parte i riferimenti inesistenti, alcune osservazioni confermano la mia esperienza limitata:

These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method. […] By leaving out all the other stuff–the stuff that’s really Agile–they’re setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won’t last.

So, unfortunately, a lot of self-described Agile projects are going to fail. They’re failing right now. And eventually Agile will take the blame, and it will pass, as all fads eventually do.

Per il resto, si vedrà. Dopotutto ancora non ho iniziato di persona 😛

Mocks for you

I mock objects sono i test doubles (insieme agli stub) piu’ famosi e servono a fornire dei surrogati che possano anche verificare certe attese dei client. Questo articolo affronta alcuni degli smells piu’ diffusi che si possono presentare durante l’uso dei mocks e le eventuali soluzioni impiegabili per eliminare o minimizzare duplicazioni & C. .

Agile Estimation

Stavo cercando qualche informazione in più su come pianificare, in un progetto agile, le iterazioni e le user story per ogni iterazione e su come stimare i tempi. Ho trovato su YouTube il talk completo di Mike Cohn su “Agile Estimation” fatto a Marzo del 2007. Vale la pena ascoltarlo anche se è lungo 90 minuti.

Parte I
http://www.youtube.com/watch?v=fb9Rzyi8b90

Parte II
http://www.youtube.com/watch?v=jeT0pOVg0EI

Da qui potete scaricare le slide del talk.

Inoltre, molto interessante è anche questo post di Mike Cohn sugli Story Points. Lui ritiene che non dovrebbero essere usati come misura di produttività:

Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point when trying to decide between calling something “two points” or “three points” […]
My view is that points can be used as the best way to estimate and assess progress that we’ve ever had or they can be used as another weapon with which to hit the team […]

E ci sono tanti altri post interessanti sul suo blog, come questo:

A common source of confusion on agile teams occurs when the sprint (“iteration”) backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units.
In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out.
In release planning the team can choose between “ideal days” and “story points”. Regardless of which they choose, they still do sprint planning in hours […]

[…] I don’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term […]