Cuprins:
A fi o echipă agilă de dezvoltare software înseamnă cu siguranță lucruri diferite pentru oameni diferiți. Există grade de adopție într-un spectru foarte larg, aparent foarte puține organizații care cred că o fac bine. Potrivit sondajului VersionOne State of Agile Survey (lansat în aprilie 2017), 80% dintre respondenții lor spun că sunt „la sau sub un nivel încă de maturizare”. Din păcate, echipele de dezvoltare nu depun eforturi deseori în partea „învăța” din iterație. Vrem să ne grăbim și să terminăm ceremoniile Scrum, astfel încât să putem reveni la scrierea codului. La urma urmei, sunt atât de multe lucruri de făcut! Dar este problema cu timpul de codare insuficient?
Pentru mulți dintre noi, lupta împotriva incendiilor ar putea fi la fel de bine menționată în descrierea postului nostru. Mergem la lucru în fiecare zi știind că trebuie să fim gata să alunecăm pe stâlp la un moment dat, să ne luăm pălăriile și să sărim pe camion. Acceptăm așa cum stau lucrurile și presupunem că nu putem face nimic în acest sens. Dar, ce se întâmplă dacă cauza principală a luptelor noastre este o lipsă severă de eficiență? Toată lumea știe cât de important este să o faci mai bine decât acea altă companie de acolo. Pur și simplu nu putem ajunge acolo - nu pare să avem lățimea de bandă. Managerii adaugă mai mulți oameni și ridică mărimea organizațiilor lor și încă au aceleași lupte. Se pare că nu poți trece de cocoașă, deoarece echipele tale nu dezvoltă software eficient (și nu ești singur).
Principii în dezvoltarea eficientă
Pixabay
Deci, ce ne face să fim ineficienți? Pentru majoritatea dintre noi, primul lucru care ne vine în minte este lipsa automatizării (versiuni automate, implementări, testări). „Odată ce vom avea suficientă automatizare, viața se va îmbunătăți”. Din păcate, aceasta este doar o parte a soluției. Luați în considerare efectul relucrării asupra proiectului dvs. Cel mai eficient mod de a construi o caracteristică este să o construiești corect o dată și să nu te mai întorci și să o atingi din nou. Bug-uri, refactorizare și alte activități similare sunt în esență redeschiderea pacientului după ce a părăsit sala de operație și există un risc inerent asociat cu aceasta. Nu putem elimina relucrarea, dar cu siguranță ar trebui să ne străduim să o reducem la minimum.
„Dar nu este o replicare agilă (ex. Refactorizare)?” De fapt, într-un fel, deoarece creatorii de agile au înțeles că două cauze cheie ale relucrării sunt circumstanțe neprevăzute și cerințe comerciale în schimbare. Se pare că oamenii sunt teribili când prezic viitorul. Creatorii agili au înțeles, de asemenea, că un contribuție imensă la ineficiență este ceea ce dezvoltatorii numesc „placare cu aur” - ambalarea funcționalității pe care credem că o va folosi cineva, chiar dacă utilizatorii finali nu au cerut-o niciodată. Este ca porcul pentru produsul dvs. software - o pierdere completă de timp. „Nu construiți o stație spațială atunci când tot ce cer este un Volvo”. Deci, companiile au început cu înțelepciune să renunțe la carnea de porc și să adopte refactorizarea, adăugând funcționalitate doar atunci când există o nevoie clară. Dar imprevizibilitatea vieții nu este singurul motor pentru reluare, nu-i așa?
Detaliile ratate în orice etapă a dezvoltării funcției vor pierde în cele din urmă timp și bani. Colaborarea eficientă în avans vă va economisi, în timp, o grămadă de lucrări (tratarea cerințelor ratate, un design miop etc.). Cu toții avem pete oarbe și cu toții avem nevoie de seturi suplimentare de ochi. Multe echipe de dezvoltare acceptă acest lucru în timpul revizuirii codului, dar pun mult mai puțină energie în colaborarea timpurie atunci când problemele pot fi rezolvate ieftin și după investiții minime.
De câte ori ați implementat o caracteristică și ați găsit defecte semnificative aproape de final care ar fi trebuit surprinse în timpul cerințelor / discuțiilor de proiectare? Este ca și cum ai încerca să conduci de la Atlanta la Montgomery și să-ți dai seama de câteva ore în călătorie că ai condus accidental la Birmingham. Cât timp s-a petrecut încercând să obțină codul corect doar pentru a deschide pacientul din nou mai târziu, deoarece au fost ratate cerințe semnificative? Folosirea inteligenței colective ar economisi absolut timp și bani, dar în schimb, dezvoltatorii lucrează adesea pe caracteristici în mod izolat.
Roi tradițional
Pixabay
Roirea tradițională înseamnă că echipa lucrează în colaborare la povești cu mai mulți oameni care lucrează la o caracteristică mică în același timp, scurtând bucla de feedback și reducând timpul total de finalizare a caracteristicii (adică împarte și cucerește). Acest lucru este în esență roit în cadrul fiecărei discipline (dezvoltatori de backend, dezvoltatori de interfețe, etc.). Înainte de începerea dezvoltării, dezvoltatorii UI lucrează pentru a identifica sarcini independente care pot fi efectuate concomitent. Discută punctele de interfață, astfel încât fiecare persoană să știe cum se potrivește piesa lor în ansamblu. Membrii echipei pot apoi să finalizeze sarcinile atribuite și să reunească totul la sfârșit în timpul integrării. Recomandările frecvente și revizuirile periodice ale codurilor vă asigură că totul rămâne pe șine. Această abordare necesită colaborare între dezvoltatori,ceea ce ajută la obținerea unui rezultat final mai bun oricum. Deseori acordăm prioritate timpului petrecut scriind cod (orice cod) peste timpul petrecut asigurându-ne că nu scriem codul greșit. Când luați în considerare timpul potențial salvat, valoarea devine clară.
Deblocarea
Pixabay
O altă abordare valoroasă a roiurilor este concentrarea echipei la începutul procesului de atenuare a dependenței, pentru a facilita dezvoltarea simultană între discipline. Luați în considerare fluxul natural de dezvoltare a unei caracteristici UI. Testerele de automatizare (SDET) sunt dependente de o interfață de lucru funcțională pentru a testa, dezvoltatorii de interfață sunt dependenți de un API backend de lucru, iar dezvoltatorii de backend sunt dependenți de configurație, actualizări de baze de date și construcții / implementări automatizate. Deci, dezvoltatorii de interfețe ar putea să nu-și înceapă activitatea până când API-urile nu sunt terminate, iar SDET-urile ar putea să nu-și înceapă activitatea până când funcția nu este completă. Fiecare disciplină funcționează izolat, ceea ce împiedică colaborarea, deoarece oamenii cu care trebuie să interacționați sunt ocupați cu alte lucruri.Dar dacă ați putea atenua dependențele mai devreme și permiteți disciplinelor să lucreze simultan pe aceeași caracteristică?
Aici sunt cateva exemple:
1. UI funcțională implementată cu butoane
Pentru a debloca SDET-urile, dezvoltatorii UI le pot oferi o UI funcțională, care funcționează suficient pentru a le permite să scrie teste. Integrarea API-ului backend și stilurile CSS pot fi încă în așteptare, deoarece cadrele de testare automate precum Selenium nu vor avea grijă dacă aceste lucruri sunt neterminate. Toate pot fi fum și oglinzi. Deși pot apărea modificări care cauzează o anumită reprelucrare, beneficiul începerii devreme a testelor depășește acest risc.
2. API-uri de backend implementate (date stubbed, codificate hard)
Furnizarea de API-uri backend pe care dezvoltatorii de UI le pot testa permit detectarea timpurie a problemelor de integrare între front-end și API-uri. Uneori aflați că API-ul furnizat nu satisface nevoile dezvoltatorilor front-end. Apelurile întregi ar putea lipsi, semnătura ar putea fi greșită sau structura datelor ar putea avea probleme. Dacă există o deconectare, s-ar putea să aflați mai devreme despre aceasta înainte ca ceva să se întărească.
3. Creați o versiune HelloWorld de noi aplicații și servicii.
Dacă este nevoie de un serviciu nou (de exemplu, un microserviciu), creați repo-ul și construiți o versiune a serviciului „hello world”. Acest lucru permite resurselor dev-ops să înceapă pe joburile Jenkins și scripturile de implementare înainte ca serviciul să fie dezvoltat efectiv.
Aceste optimizări facilitează o buclă de feedback timpurie, în care cineva poate spune „Am nevoie de ceva diferit” înainte ca dezvoltarea să fie completă pe componenta care necesită schimbarea.
Înfășurându-l
Este incredibil de important să ne dăm seama cum să scurtăm timpul de introducere pe piață pentru funcțiile la care lucrăm. Compania nu are nici o valoare din faptul că are o grămadă de caracteristici care sunt în curs de desfășurare, iar dezvoltatorii au nevoie disperată de caracteristici pentru a fi implementate rapid, astfel încât defectele să poată fi rezolvate cât mai aproape de punctul de injectare. De asemenea, dezvoltatorii au nevoie disperată de a interacționa unii cu alții, chiar dacă tot ceea ce își doresc cu adevărat este să scrie cod. Este mai bine pentru toți cei implicați, inclusiv pentru utilizatorul final care dorește doar un produs mai bun. Dacă nu le dai, vor merge în altă parte să o găsească.
Roirea este un instrument extrem de valoros în cutia de instrumente a organizației dvs., dacă oamenii își iau timpul pentru a afla cum să o facă. Nu este un cadru sau chiar o activitate - este o mentalitate. Pentru fiecare poveste a utilizatorului, membrii echipei își pun două întrebări:
- Cum organizăm sarcini pentru această poveste pentru a determina mai multe persoane să contribuie simultan?
- Care este minimul pe care trebuie să îl fac pentru a debloca pe cineva care mă așteaptă?
Ce se întâmplă dacă echipa ta a construit rapid funcții împreună, mai degrabă decât să construiască încet o grămadă de caracteristici independent? De fapt, acestea ar putea răspunde la schimbarea cerințelor afacerii și ar putea satisface nevoile afacerii atunci când afacerile vor avea nevoie să fie îndeplinite. Concurenții s-ar teme de tine - clienții te-ar iubi. Aceasta este o rețetă pentru o afacere de succes.
© 2017 Mike Shoemake