Dezvoltare agila

"Bună, Amigo!"

— Bună, Bilaabo!

„Astăzi am să vă spun despre cum sunt dezvoltate de obicei programele”.

„În secolul al XX-lea, când IT-ul modern era la început, toată lumea părea să creadă că programarea este ca construcția sau producția.”

„Lucrurile mergeau de obicei cam așa:”

„ Clientul ar explica tipul de program de care are nevoie – ce ar trebui să facă și cum ar trebui să o facă.”

„ Analiștii de afaceri l-ar asculta și ar face o listă completă a cerințelor programului pe baza a ceea ce a spus el.”

„Apoi, managerii de proiect ar împărți aceste cerințe în sarcini și ar determina, de asemenea, care programator ar face ce sarcină și în ce ordine.”

"Atunci programatorii se puneau la treabă. Uneori lucrau câțiva ani(!)."

„Când au fost terminate, programul a fost dat testerilor”.

„ Testerii au trecut prin fiecare dintre cerințele programului pentru a verifica dacă au fost implementate și că programul a funcționat așa cum trebuia”.

„Dacă ceva nu mergea bine, testerii înregistrau erorile și le trimiteau programatorilor”.

"Apoi programatorii remediau erorile și trimiteau programul corect înapoi la testeri. Și ciclul se repeta."

„Când principalele erori au fost remediate, programul a fost dat clientului”.

— Chiar așa au mers lucrurile?

„Ei bine, bineînțeles, am simplificat mult, dar asta este destul de aproape de modul în care s-au făcut lucrurile”.

„Și un proiect ar putea dura într-adevăr un an și jumătate până la doi ani pentru a fi finalizat?”

„Uneori, dacă dezvoltarea unui proiect era foarte lungă, îl împărțeau în versiuni separate. La fiecare 3-6 luni, dezvoltatorii trebuiau să creeze o anumită parte a funcționalității programului, să o testeze, să remedieze toate erorile și să o arate utilizatorilor. client."

„În primul rând, pentru a-și putea împărtăși impresiile. Și în al doilea rând, și mai important, pentru a continua să plătească pentru dezvoltarea programului”.

— Să plătești în continuare?

„Pe atunci, dezvoltarea dura adesea de 2-3 ori mai mult decât era planificat. Și pentru că programatorii erau plătiți adesea pe oră, programul devenea de 2-3 ori mai scump. În plus, beneficiile s-au redus. La urma urmei, ceea ce își dorește clientul astăzi pentru 100.000 USD poate să nu fie nevoie în 3 ani – mai ales la prețul de trei ori mai mare.”

„Clienții refuzau adesea să plătească?”

"Da. Ulterior au început să adauge penalități la contract, dar acest lucru nu a îmbunătățit situația. Dezvoltarea software a durat și mai departe. Și nimeni nu putea face nimic în privința asta, chiar dacă și-ar dori".

"Dar de ce?"

"Ei bine, în primul rând, se știe prea puțin în timpul etapei de planificare. De cele mai multe ori, la început, nimeni nu putea prezice problemele cu care se vor confrunta programatorii."

„Dar programatorii experimentați ar fi trebuit să fie capabili să prevadă totul, nu?”

„Poți vedea că programarea este o profesie unică.”

"Un muncitor obișnuit îndeplinește adesea aceeași treabă din nou și din nou. Ceasornicarii fac ceasuri, bucătăria gătește, profesorii predau, doctorii tratează etc."

„Fiecare dintre acești profesioniști face practic același lucru zi de zi. Drept urmare, încep să devină din ce în ce mai buni la locul de muncă.”

„În programare, abordarea este diferită. De îndată ce un programator se confruntă cu aceeași sarcină în fiecare zi, el scrie o funcție, un modul sau un program pentru a o îndeplini și nu se mai întoarce niciodată la ea.”

„Fiecare programator rezolvă de obicei fiecare sarcină o dată în viață.”

„Ceva precum oamenii de știință sau inginerii de proiectare care inventează lucruri”.

"Ah. Ei bine, care este cel mai important rol într-un proiect?"

"Hmm, cum ar trebui să răspund la asta. Este ușor de spus care este cel mai important, dar identificarea celui mai puțin important este dificil."

" Sarcina principală a unui tester ( Asigurarea calității  , QA )  este să monitorizeze starea unui program și să raporteze erorile cu promptitudine. Cu cât un tester găsește erori mai devreme, cu atât mai multe pot fi remediate.  Un tester bun influențează calitatea produsului mai mult decât un programator bun o face ."

"De ce nu pot programatorii să-și testeze propriile programe. La urma urmei, nu știu ei mai bine decât testerii ce funcționează și ce nu?"

„Un programator bun este pur și simplu incapabil să fie un tester bun. Un programator știe cum funcționează programul foarte bine, așa că îl folosește întotdeauna într-un anumit fel. Spre deosebire de utilizatorii obișnuiți care folosesc programul așa cum doresc. "

"În plus, testerii nu testează ceea ce nu funcționează încă. Testerul testează funcționalitatea sau părțile programului despre care programatorul spune că funcționează deja aproape perfect."

„Și când testerul găsește o mulțime de erori în această funcționalitate, iar programatorul le remediază, atunci produsul se apropie de perfecțiune.”

" Sarcina principală a unui programator ( S oftware  Developer Ingineer ,  Dezvoltator ,  SDE ) este să implementeze noi funcționalități. Sau, mai simplu, să realizeze sarcinile care i-au fost atribuite. Când programatorilor li se atribuie sarcini cu noi  caracteristici , le execută. Când li se atribuie erori, remediază erori."

„Dar uneori există sarcini mai provocatoare, de exemplu, să vină cu arhitectura pentru program sau părți ale acestuia. Cu cât arhitectura propusă este mai bună, cu atât va fi mai ușor să faci lucrurile în viitor.”

„Problema este că arhitectura trebuie aleasă chiar de la început, dar abia când sunteți în mijlocul dezvoltării, este clar dacă ați ales arhitectura potrivită”.

„În plus, dacă arhitectura are succes și programul se dovedește grozav, atunci clientul va dori probabil să o folosească ca bază pentru noile versiuni ale programului.”

— Iată la ce ajung.

„Orice arhitectură ai alege, vor exista întotdeauna o mulțime de modificări, completări și caracteristici noi pe care arhitectura nu le ține seama.”

— Iată un exemplu bun.

„Un client vă cere să construiți o clădire cu 5 etaje, astfel încât să proiectați o arhitectură și să construiți casa”.

„Apoi clientul cere să adauge o altă poveste, apoi alta și așa mai departe”.

„Dar pereții de la primul etaj nu au fost proiectați pentru atât de multă greutate și nici fundația nu a fost. Deci totul trebuie refăcut”.

„Dar după ce clădirea cu 5 etaje este terminată, ce se întâmplă dacă clientul decide imediat că vrea o clădire cu 50 de etaje?”

„Ar fi mai ușor să demolați structura existentă și să reconstruiți totul de la zero...”

— Dar am un sfat pentru tine în ceea ce privește arhitectura.

„Arhitectura unei aplicații trebuie, în primul rând, să fie flexibilă, ceea ce înseamnă că nu va trebui să porniți de la zero dacă decideți să refaceți jumătate din aplicație. Acest tip de arhitectură este de obicei numit flexibil și modular . ”

" Slujba principală a managerului de proiect este să ia decizii. Managerul de proiect este cel care vede imaginea de ansamblu și ia decizii bazate pe această perspectivă."

„Să presupunem că în timpul dezvoltării devine clar că o anumită sarcină nu va fi finalizată conform planificării. Managerul de proiect poate:”

„ a)  încercați să negociați cu clientul pentru a modifica sarcina”

„ b)  alocați mai mult timp sarcinii”

" c)  aduceți programatori mai experimentați din alte proiecte."

„Și există multe alte posibilități”.

„Fiecare opțiune presupune să sacrifici ceva, iar treaba managerului este să minimizeze pierderile totale din aceste sacrificii. ”

„De exemplu, să presupunem că concurenții îl fură pe programatorul principal oferindu-i de două ori mai mulți bani.”

„Managerul de proiect poate:”

" a)  nu face nimic. Programatorul va pleca, iar proiectul va rămâne probabil în urmă și va primi penalități."

" b)  să-și dubleze salariul. Atunci toți ceilalți din echipă vor dori și măriri. Dacă le dai tuturor mai mulți bani, atunci costurile proiectului vor crește și ar putea deveni neprofitabil."

" c)  altă opțiune la care te gândești."

"Înțeleg."

„Cu un manager de proiect prost, o echipă bună de obicei prelungește un proiect, dar nu întotdeauna”.

„Un manager bun cu o echipă de programatori obișnuiți va finaliza aproape întotdeauna un proiect mai repede decât un manager prost cu o echipă de programatori excelenți.”

"Înțeleg."

— Bine, hai să facem o scurtă pauză și apoi vom continua.