Manifestul pentru Dezvoltarea Software cu Metode Agile
Saptesprezece anarhisti cad de acord ca:

Descoperim solutii mai performante in dezvoltarea software realizand-o si ajutandu-i pe altii s-o faca. Prin aceasta munca am ajuns sa pretuim:

TenStep Project Management Process

Persoanele si interactiunile in detrimentul proceselor si uneltelor.

Software-ul functional in detrimentul unei documentatii cuprinzatoare.

Colaborarea cu clientul in detrimentul negocierii contractelor.

Raspunsul la schimbare in detrimentul urmarii unui plan.

Din experienta autorului, sansele de succes ale mai multor proiecte ce se deruleaza concomitent intr-o organziatie cresc daca exista un set flexibil si scalabil de procese logice. Daca aceste procese au mai fost utilizate cu succes in trecut, exista sanse mai mari de a avea si tu succes.

Altfel spus, in timp ce pretuim elementele din dreapta, pe cele din stanga le pretuim mai mult.

Ne ghidam dupa urmatoarele principii:

Cea mai inalta prioritate este sa ne satisfacem clientul livrandu-i mai devreme si permanent software valoros.

Filosofia Agile promoveaza dezvoltarea iterativa, in care cerintele initiale sunt urmate de codul de lucru, de mai multe cerinte si coduri. Este bine, dar dezvoltarea iterativa nu este cea mai buna abordare pentru toate proiectele de dezvoltare software. Totusi, acolo unde poate fi implementata, ar trebui incercata.

Primeste cerintele de schimbare chiar si in fazele avansate ale dezvoltarii. Procesele Agile valorifica schimbarea spre avantajul competitive al clientului.

In dezvoltarea iterativa generala, cerintele nu trebuie stabilite definitiv in fazele incipiente. Totusi, chiar si in cazul dezvoltarii iterative traditionale, la un moment dat, cerintele trebuie inghetate pentru a permite livrarea. In acel punct intervine managementul schimbarii continutului.

In metoda Agile, cerintele de dezvoltare se pot modifica in orice moment. Principiul este ca clientul poate continua sa opereze schimbari in masura in care aceste schimbari sunt prioritizate in iteratia potrivita. Daca, de exemplu, clientul a cerut trei rapoarte si ulterior vrea patru, al patrulea raport poate fi adaugat fara nicio problema listei de cerinte. La un moment dat, clientul va avea nevoie sa prioritizeze acest nou raport, iar atunci, noul raport va fi intocmit. Daca bugetul clientului nu este limitat atunci nu are loc niciun proces formal de schimbare a continutului - clientului ii este livrat orice vrea si isi prioritizeaza. Daca bugetul clientului este fix, atunci prioritizarea unei modificari va determina, in esenta, neexecutarea altor activitati. In acest scenariu, clientul impune managementul schimbarii continutului asigurandu-se ca doar cele mai importante modificari vor fi prioritizate pe cand altele nu.

Abordarea TenStep spune ca echipa de proiect trebuie sa fie pregatita sa raspunda schimbarilor de business, atunci cand apar. Totusi, schimbarile de cerinte au consecinte asupra bugetului si datelor de livrare si acestea trebuie aprobate de catre sponsor. Daca echipa procedeaza astfel, atunci practica managementul schimbarii continutului.

Livreaza software-ul functional frecvent, de la cateva saptamani la cateva luni, de preferat fiind intervalul de timp mai scurt.

Procesul TenStep recomanda descompunerea proiectelor mari intr-o serie de proiecte mai mici care pot fi livrate mai rapid si in mod repetat. Nu toate proiectele au aceasta flexibilitate dar atunci cand este posibil, sunt de preferat proiectele mai mici.

Procesele metodei Agile pot duce ciclul de livrare redus la extrem. Unele proiecte de extreme programming reusesc sa livreze in cicluri foarte scurte, respectiv la fiecare saptamana. Desi poate fi dificil de condus, in mod firesc, nu exista nimic gresit cu aceasta abordare.

Oamenii de afaceri si dezvoltatorii lucreaza zilnic impreuna pe tot parcursul proiectului.

Aceasta este cel mai eficace mod de a fi la curent cu nevoile clientilor.

Construieste proiecte in jurul persoanelor motivate. Ofera-le mediul si suportul necesare si ai incredere ca isi vor face treaba.

Uneori oameni foarte motivati au probleme cu livrarea la timp a proiectelor (Deming a admis acest lucru cu jumatate de secol in urma). Ei se pot axa prea mult pe detaliile privind dezvoltarea software si prea putin pe managementul planului proiectului. Daca toti oamenii motivati ar finaliza intotdeauna proiectele la timp, procentajul proiectelor performante ar fi mult mai mare. Uneori esti nevoit sa plasezi oamenii motivati intr-un mediu mai structurat, unde ei pot fi performanti. Autorul crede ca cea mai buna abordare este de a construi proiecte in jurul oamenilor motivati si apoi de a se asigura ca au uneltele, procesele si abilitatile potrivite pentru a-si executa munca.

Cea mai eficienta si eficace metoda de transmitere a informatiei catre si in cadrul echipei de dezvoltare este conversatia fata-in-fata.

Fara indoiala ca in multe situatii comunicarea personala este cea mai eficace. Totusi, se intampla ca si alte media de comunicare sa fie bune; de exemplu, emailul poate fi eficace cand trimiti situatii actualizate catre 20 de oameni. O documentatie relevanta de asemenea trebuie intocmita - in cazul in care sunt necesare infomatii cand dezvoltatorii originali nu mai fac parte din proiect. Documentatia trebuie intocmita numai  pentru informatiile importante. Arareori echipa de suport actualizeaza documentatia, astfel ca in timp isi pierde din valoare.

Software-ul functional este principalul metric al progresului.

In dezvoltarea iterativa, software-ul functional la finele fiecarei iteratii reprezinta un bun indicator al progresului. Totusi, nu toate proiectele pot fi executate folosind dezvoltarea iterativa, un exemplu fiind, implementarile de pachete software. Asadar, in majoritatea proiectelor poti continua sa monitorizezi planul prin reperele intermediare majore pentru a fi sigur ca te incadrezi in program.

Procesele metodei Agile promoveaza dezvoltarea sustenabila. Sponsorii, dezvoltatorii si utilizatorii trebuie sa poata mentina permanent un ritm constant.

Dezvoltarea de software cu metoda Agile development solicita o saptamana de lucru de 40 de ore si un ritm care poate fi mentinut permanent. Bineinteles, aceasta este cea mai buna abordare, in conditiile unei planificari si ale unui management potrivite.

Atentia continua acordata excelentei tehnice si unei bune proiectari sporeste agilitatea.

Deciziile de excelenta tehnica si de proiectare initiala solida sunt esentiale pentru functionarea proceselor Agile.

Simplitatea - arta de a maximiza volumul de munca neexecutat - este esentiala.

De acord. Dezvoltatorii de software si clientii trebuie sa se concentreze in primul rand pe livrarea cerintelor esentiale. Aceasta "maximizeaza munca neexecutata." De asemenea, permite livrarea mult mai rapida a software-ului.

Cele mai bune arhitecturi, cerinte si proiectari apar in cadrul echipelor care se organizeaza singure.

Ar fi mai usor sa fim de acord cu aceasta idee daca toate echipele ar avea performante ridicate si daca ar fi superioare din punct de vedere ethnic. Totusi, majoritatea echipelor de proiect nu sunt destul de mature sin u au nivelul de abilitati potrivit pentru a dezvolta cele mai bune proiectari si arhitecturi. Arhitecturile trebuie dezvoltate, in mod special, la nivelul organizatiei sau al companiei. Daca aceasta responsabilitate ar fi lasata la latitudinea echipelor, rezultatul ar fi suprapunerea tehnologiilor si haos la nivelul companiei.

La intervale regulate de timp, echipa mediteaza la modalitatile de a deveni mai eficace, apoi isi pliaza si ajusteaza comportamentul in consecinta.

De acord. In mod constant, echipele trebuie sa se chinuie sa isi inteleaga punctele tari si slabiciunile si cum pot fi imbunatatite procesele de management de proiect. Metodologia TenStep mai crede si ca aceste schimbari recomandate ar trebui transmise la nivelul organizatiei astfel incat tot personalul sa poata beneficia de pe urma acestor idei.

-Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
http://www.agilealliance.org/home