Ho "qualche" esperienza nello sviluppo del software anche relativamente alla gestione di un gruppo di programmatori e della gestione dei conflitti anche in relazione alle necessità sia del cliente che del committente.
Niente di pauroso, ma le aspettative delle "tre" parti sono sempre diverse, speciali e importanti.
Ho passato diverso tempo a spiegare che la tecnologia "Agile" e l'Extreme programming non sono la soluzione a tutti i problemi, e oggi ho trovato questo. Mi è sembrato utile e interessante, quindi lo riporto.
Sono spiacente per gli eventuali errori di battitura, colpa mia. :)
The Art of Agile Development
James Shore & Shane Warden
O'REILLY - 2008
CHAPTER 1
Please don't get sucked into that mess.
In 1986 [Harold Brooks] famous predicted that there were no silver bullets: that by 1996, no single technology or management technique would offer a tenfold increase in productivity, reliability, or simplicity. None did.
Agile development isn't a silver bullet, either.
In fact, I don't recommend adopting agile development solely to increase productivity. Its benefits -even the ability to release software more frequently- come from working "differently", not from working "faster". Although anedoctal evidence indicates that agile teams have above-average productivity(1), that shouldn't be your primary motivation. Your team will need time to learn agile development. While they learn -and it will take a quarter or two- they'll go slower, not faster. In addition, emphasizing productivity might encourage your team to take shortcuts and to be less rigorous in their work, which could actually "harm" productivity.
Agile development may be the cool thing to do right now, but that's no reason to use it. When you consider using agile development, only one question matters:
--------------------------------------------
(1) Various experience reports at the Extreme Programming and Agile conferences.
James Shore & Shane Warden
O'REILLY - 2008
CHAPTER 1
Why Agile?
Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on. I know of one company that has already changed its name to Agili-something in order to ride the bandwagon. (They called me in to pitch their "agile process" which, upon further inspection, was nothing more than outsurced offshore development, done in a different country than usual.) I fully expect the big consulting companies to start offering Certified Agile Process and Certified Agile Consultant -for astronomical fees, of course- any day now.Please don't get sucked into that mess.
In 1986 [Harold Brooks] famous predicted that there were no silver bullets: that by 1996, no single technology or management technique would offer a tenfold increase in productivity, reliability, or simplicity. None did.
Agile development isn't a silver bullet, either.
In fact, I don't recommend adopting agile development solely to increase productivity. Its benefits -even the ability to release software more frequently- come from working "differently", not from working "faster". Although anedoctal evidence indicates that agile teams have above-average productivity(1), that shouldn't be your primary motivation. Your team will need time to learn agile development. While they learn -and it will take a quarter or two- they'll go slower, not faster. In addition, emphasizing productivity might encourage your team to take shortcuts and to be less rigorous in their work, which could actually "harm" productivity.
Agile development may be the cool thing to do right now, but that's no reason to use it. When you consider using agile development, only one question matters:
Will agile development help us be more successfull?
When you can answer that question, you'll know whether agile development is right for you.--------------------------------------------
(1) Various experience reports at the Extreme Programming and Agile conferences.
Link al sito O'REILLY - direttamente al manuale di cui sopra.
