Cluj München 1140km

Gânduri clujene din Bavaria

München - Munich - Monaco di Baviera

15. septembrie 2013 09:50
by skorpionking
0 Comentarii

SCRUM / Agile are nevoie de specificatie? // Does Agile need requirements?

15. septembrie 2013 09:50 by skorpionking | 0 Comentarii

Versiunea in romaneste (for english scroll down please):

In ultimii ani am inceput sa lucrez tot mai mult in cadrul proiectelor de software utilizand o abordare mai agila, incercand sa utilizez SCRUM, dar si alte abordari agile: managementul proiectului, cicluri de release mai rapide (SCRUM le numeste sprint), testare automata, integrare continua, DevOps. Aceasta trecere la o abordare mai agila a implicat discutii cu colegii, citirea unor carti, articole, bloguri, experimente proprii in proiecte de genul one-man-show.

In ultimii ani am lucrat intr-un proiect unde am incercat sa avem o abordare cat mai agila. Si asa am ajuns la “specificatie” si proiecte agile. Am remarcat ca aceste specificatii sunt pur si simplu “uitate” sau nu li acorda importanta necesara in aceste lume IT agila. Toata lumea stie ca un proiect agil se deosebeste de cel waterfall si elimina necesitatea colectarii si creerii unei specificatii complete de la inceput. A fi agil inseamna a nu astepta pana ai o specificatie complete, dezvoltarea incepe aproape imediat ce avem o documentatie, specificatie ce ne permite sa incepem munca si sa livram cod functional in timp de cateva saptamani. Aceasta idee este subliniata clar de documentatia SCRUM ce sustine codul functional mai presus de o documentatie completa. Si de aici incepe problema: toata lumea sau majoritatea are impresia ca in modelul agil nu avem nevoie de specificatie, de o documentatie clara. Daca vrei sa ai un soft bun, ai nevoie de o specificatie buna, indiferent cat esti de agil cu proiectul tau: garbage in, garbage out! Faptul ca ai schimbat felul in care livrezi softul si produsul tau, in bucati mai mici si cicluri dese, nu inseamna ca nu trebuie sa intelegi ceea ce dezvolti! Care este avantajul in a livra repede, dar  produsul tau nu implementeaza corect specificatia functionala?

De asemenea, consider ca atunci cand dezvolti sisteme complexe, care depinde de alte sisteme, e absolut necesar ca specificatia sa aiba un grad de maturitate si sa fie validata.

Eu sunt de acord sa fim agili si abordez proiectele soft intr-un mod cat mai agil, dar cu o specificatie, documentatie cat mai solida si mai corecta. Daca e posibil, nu pierde timpul creand o specificatie completa. Administreaza, controleaza, dezvolta specificatia ca si cum o faci cu codul: sprint dupa sprint, agil. Dar nu uita niciodata sa creezi o specificatie care corespunde cererilor, sa o validezi si sa o documentezi corespunzator!

English Version:

Throughout the last few years and especially during my last big software project, I have slowly transitioned to a more agile software development approach as part of my daily work. By agile approach I am referring to project management, faster release cycles (i.e. sprints as they are called in SCRUM), some testing automation, and hopefully soon even more advanced DevOps techniques. Facilitating this transition involved reading online blogs, articles, books, experimenting, as well as many conversations with peers.

But what do “requirements” have to do with all this? I noticed that one of the most left out topic in the context of agile discourse is requirements. Everyone knows that agile is breaking the rigid waterfall development cycle and eliminates the need for lengthy requirements gathering efforts. Agile doesn't wait for complete requirements to be collected and documented; agile starts delivering production ready code within weeks (depending on the duration of the sprints). This is even stated in the agile manifesto as “working software over comprehensive documentation” or something like that. The whole agile discourse leaves the impression that if you are agile you don’t need requirements! In my opinion that is false. If you want to build good software you will need good requirements, agile or not; garbage in / garbage out applies here as well. The fact that you are changing the way you deliver the whole software product end to end, i.e. in smaller pieces and much faster and regular cycles, does not mean you don’t need to properly understand what you are building. What is the use in delivering functionally incorrect features really fast?

Also, I believe it is worth mentioning here that there are cases when the complete set of requirements has to be collected and documented beforehand. Think about building an accounts receivable system (AR) that handles billings to vendors, money received, payment terms policies, general ledger balances, etc. The degree of interdependency between the different functions of such a system requires comprehensive requirements to be documented and validated first.       

That being said, I am all for agile but with proper requirements management. If applicable, don’t waste time collecting all the requirements upfront. Manage the requirements collection the same way you manage the development – i.e. agile, sprint by sprint. But make sure to collect, validate, and document the requirements!