E foarte posibil să începem din Ianuarie 2010 un proiect destul de mare ca să se justifice trecerea la unelte profesionale pentru tot ceea ce înseamnă managementul procesului de dezvoltare software. Stăteam zilele trecute și dezbăteam cam ce am folosi. Idei, sunt de tot felul, și încerc să le înșir mai jos.

Analiza cerințelor

În faza asta, de obicei există două tipuri de probleme:

1). Nu reușești să captezi corect cerințele. Ori sunt ambiguități, ori sunt conflicte – ele trebuie detectate cât mai rapid, pentru că mai târziu costă mult. Aici nu ajută prea mult uneltele, ci mai degrabă proceduri și un mod de lucru structurat, plus discuții multe cu clientul. Unii spuneau ca analiza cerințelor durează cam 20-30% din întreaga durată a dezvoltării produsului (sigur, împarțită pe toată perioada). Ceea ce sigur ne-a ajutat pe noi, a fost un curs de la Trilex, respectiv câteva cărți de la Microsoft Press, printre care ”Software Requirements, Second Edition”. Ca o paranteză, începem și noi ca firmă să înțelegem cu adevărat că e bine să cumperi un training sau o carte dacă vrei să înveți repede.

2). Întotdeauna când ecranele aplicației erau specificate de la început, am avut senzația că ne este clar la ce lucrăm. Chiar dacă nu poți la inceput să detaliezi 100% interfața, măcar prototipuri cu toate ecranele și navigările între acestea este obligatoriu să ai. Nu neapărat pentru tot proiectul, dar cel puțin pentru primul release.

Revenind la unelte, cochetăm cu BluePrint (http://www.blueprintsys.com/) sau CaseComplete (http://www.casecomplete.com/) pentru un management mai bun al cerințelor, respectiv cu Balsamiq (http://www.balsamiq.com/) pentru prototipuri. De asemenea, pentru estimarea și planificarea respectiv urmărirea task-urilor, Excel s-a dovedit o unealtă foarte utilă.

Colaborare

Prin colaborare înțeleg cel puțin 2 lucruri:

1). Management de proiect. Aici unelte sunt foarte multe, de la unele făcute custom (intern, foarte multe firme de soft am observat că au propriile unelte de tot felul – ceea ce mie mi se pare uneori o risipă de resurse), respectiv Excel, până la Team Foundation Server.

2). Integrare continuă. Adică să te asiguri că ce a lucrat azi fiecare dezvoltator nu strică nimic din ce e deja făcut. Și nu mă refer doar la a te asigura că nu face un ”check in” în sistemul de versionare care implică să nu compileze aplicațiile – dacă ai înca problema asta, nu are sens să povestim despre integrare continuă. Ci mă refer la a face zilnic un build la toată soluția, după care rulate toate testele (evident, totul să fie automat), și constatat că nu s-a stricat ceva făcut ieri sau de altcineva. Deci, aici cuvintele cheie sunt: daily build, automated build, unit testing, automated testing, source control.

În zona asta, unelte iar sunt multe: Ant, NAnt, MSBuild, Make – pentru build automat; SourceSafe :-), SVN, etc pentru source control; MSTest, nUnit pentru unit testing; respectiv putem ajunge la CruiseControl sau Team Foundation Server dacă trecem la nivelul superior.

Dezvoltarea propriu-zisă

În funcție de metodologia de lucru (dacă e agilă în special), trebuie acordată atenție la aspecte ca: code review / refactoring, pair programming, test – driven development, mocking, dependency injection, etc. În firma noastră deja folosim code review (cam puțin, e drept), dar vom începe să acordăm mai multă atenție la acest aspect cu tot cu refactoring, respectiv la pair programming (această metodă de lucru este foarte utilă inclusiv pentru creșterea rapidă a nivelului programatorilor mai tineri, iar noi avem intern un document care scrie ce trebuie să știe un programator la H.P.C. Consulting). De asemenea, folosim uneori și de acum vom folosi mai des (în special în proiectele în care merită dpdv al dimensiunii) Unit Testing, dar nu TDD.

Ca unelte, Unity http://www.codeplex.com/unity, RhinoMocks http://www.ayende.com/projects/rhino-mocks.aspx, MSTest, nUnit, Resharper (sau Visual Studio pentru refactoring).

Scriu aceste rânduri după ce am văzut la TechEd câteva prezentări / workshop-uri despre Team Foundation Server 2010. Acum 10 zile aveam o discuție cu un client, care ne spunea că ar fi bine să trecem la TFS iar eu eram foarte sceptic din două motive: unealta mi se părea complicată – aspect ameliorat mult acum după ce am vazut la Berlin, respectiv faptul că o unealtă de acest gen nu are sens decât dacă vine peste o serie de proceduri / mod de lucru bine structurate în echipa de dezvoltare. Cu acest al doilea aspect încă mai avem de lucru, dar voi insista foarte tare în următoarea perioadă pentru a ajunge la nivelul de maturitate în care TFS să aibă sens, și să ajute, să îmbunătățească ceea ce noi facem deja.

Legat de proceduri / mod de lucru structurat, am reușit până acum să avem câte ceva, chiar dacă - dupa cum spuneam – mai avem de lucru:

• procedură de release. Scrisă, cu un checklist care se listează la imprimantă și se semnează de cel care face release-ul.
• document care descrie procesul de dezvoltare. Va fi modificat, odată cu trecerea la TFS – dar ideea e că avem ceva în acest moment.
• document de Change Request – util atunci când clientul modifică cerințe care au fost deja estimate și asupra cărora s-a căzut de acord.
• document care specifică în detaliu ce trebuie să știe un programator de la H.P.C. Consulting, și în cât timp, și cine îl ajută să învețe.

Voi reveni în perioada următoare, pe măsură ce reușim să avansăm cu implementarea de TFS.