Sadržaj:
Biti okretan tim za razvoj softvera za različite ljude sigurno znači različite stvari. Postoje stupnjevi usvojenosti u vrlo širokom spektru, s očito vrlo malo organizacija koje misle da to čine dobro. Prema Anketi o stanju agilnosti tvrtke VersionOne (objavljenoj u travnju 2017.), 80% njihovih ispitanika kaže da su „na ili ispod razine koja još sazrijeva“. Nažalost, razvojni timovi često ne ulažu puno truda u dio "ponavljanja" ponavljanja. Želimo požuriti i završiti Scrum ceremonije kako bismo se mogli vratiti pisanju koda. Napokon, toliko je posla! No, je li stvarno problem nedovoljno vrijeme kodiranja?
Za mnoge od nas vatrogastvo bi moglo biti posebno navedeno u našem opisu posla. Svakodnevno idemo na posao znajući da trebamo biti spremni na trenutak skliznuti niz stup, zgrabiti šešire i skočiti na kamion. Prihvaćamo to onako kako stvari stoje i pretpostavljamo da tu ne možemo ništa učiniti. Ali, što ako je glavni uzrok naših borbi ozbiljan nedostatak učinkovitosti? Svi znaju koliko je važno to učiniti bolje od one druge tvrtke tamo. Čini se da jednostavno ne možemo doći tamo - čini se da nemamo propusnost. Menadžeri dodaju više ljudi i povećavaju veličinu svojih organizacija i još uvijek imaju iste borbe. Čini se da ne možete preboljeti grbu jer vaši timovi ne razvijaju softver učinkovito (i niste sami).
Načela u učinkovitom razvoju
Pixabay
Pa što uzrokuje da budemo neučinkoviti? Većini nas prvo padne na pamet nedostatak automatizacije (automatizirane gradnje, postavljanja, testiranja). "Jednom kad imamo dovoljno automatizacije, život će postati bolji." Nažalost, to je samo dio rješenja. Razmotrite učinak prerade na vaš projekt. Najučinkovitiji način izrade značajke je pravilno jednom izgraditi i nikada se više ne vraćati i ne dodirnuti je. Bug, refaktoriranje i druge slične aktivnosti u osnovi ponovno otvaraju pacijenta nakon što napusti operacijsku salu i s tim je povezan rizik. Ne možemo eliminirati preradu, ali svakako bismo je trebali nastojati smanjiti.
"Ali zar agilni ne prihvaća preradu (npr. Refaktoriranje)?" To zapravo čini na neki način, jer su tvorci agilnih sustava shvatili da su dva ključna uzroka prerade nepredviđene okolnosti i promjena poslovnih zahtjeva. Ispada da su ljudi strašni u predviđanju budućnosti. Agilni kreatori također su shvatili da ogroman doprinos neučinkovitosti ono što programeri nazivaju "pozlaćivanjem" - upakiranjem funkcionalnosti za koju mislimo da će je netko koristiti, iako je krajnji korisnici zapravo nisu tražili. To je poput svinjskog mesa za vaš softverski proizvod - potpuno gubljenje vremena. "Ne gradite svemirsku stanicu kad je sve što traže Volvo." Dakle, tvrtke su pametno počele izostavljati svinjetinu i prihvaćati refaktoriranje, dodajući funkcionalnost samo kada postoji jasna potreba. Ali životna nepredvidljivost nije jedini pokretač prerade, zar ne?
Propušteni detalji u bilo kojoj fazi razvoja značajke u konačnici će izgubiti vrijeme i novac. Učinkovita prethodna suradnja s vremenom će vam uštedjeti tonu prerade (rješavanje propuštenih zahtjeva, kratkovidni dizajn, itd.). Svi imamo slijepe točke i svi trebamo dodatne setove očiju. Mnogi razvojni timovi prihvaćaju to sa stražnje strane tijekom pregleda koda, ali ulažu mnogo manje energije u suradnju rano kada se problemi mogu riješiti jeftino i nakon minimalnih ulaganja.
Koliko ste puta implementirali značajku i pri kraju pronašli značajne nedostatke koji su trebali biti uhvaćeni tijekom rasprava o zahtjevima / dizajnu? To je kao da pokušate voziti od Atlante do Montgomeryja i shvatiti nekoliko sati putovanja da ste se slučajno odvezli do Birminghama. Koliko je vremena utrošeno pokušavajući dobiti šifru samo kako bi se pacijent kasnije ponovo otvorio jer su propušteni značajni zahtjevi? Iskorištavanjem kolektivne inteligencije apsolutno bi se uštedjelo vrijeme i novac, ali umjesto toga programeri često rade na značajkama izolirano.
Tradicionalno rojenje
Pixabay
Tradicionalno rojenje znači da tim surađuje na pričama s nekoliko ljudi istodobno koji rade na maloj značajci, skraćujući petlju povratnih informacija i smanjujući ukupno vrijeme dovršenja značajke (tj. Podijeli i osvoji). Ovo se u osnovi roji unutar svake discipline (pozadinski programeri, programeri korisničkog sučelja, itd.). Prije nego što razvoj započne, programeri korisničkog sučelja rade na identificiranju neovisnih zadataka koji se mogu istodobno izvoditi. Oni raspravljaju o točkama sučelja kako bi svaka osoba znala kako se njezin dio uklapa u cjelinu. Članovi tima tada mogu nastaviti s izvršavanjem dodijeljenih zadataka i na kraju sve spojiti tijekom integracije. Česta predavanja i povremeni pregledi koda pomažu u osiguranju da sve ostane na tračnicama. Ovaj pristup zahtijeva suradnju između programera,što ionako pomaže u postizanju boljeg krajnjeg rezultata. Često dajemo prednost vremenu provedenom u pisanju koda (bilo kojeg koda) i trošimo se računajući da ne napišemo pogrešan kod. Kad uzmete u obzir vrijeme koje je potencijalno spremljeno, vrijednost postaje jasna.
Deblokiranje
Pixabay
Sljedeći vrijedan pristup rojenju je usredotočiti tim na rano ublažavanje ovisnosti kako bi se olakšao istodobni razvoj u svim disciplinama. Razmotrite prirodni razvojni tok značajke korisničkog sučelja. Ispitivači automatizacije (SDET) ovise o radnom korisničkom sučelju protiv kojeg se testiraju, programeri korisničkog sučelja ovise o radnom pozadinskom API-ju, a pozadinski programeri ovise o konfiguraciji, ažuriranju baze podataka i automatiziranim gradnjama / implementacijama. Dakle, programeri korisničkog sučelja možda neće započeti svoj posao dok API-ji ne završe, a SDET-ovi možda neće započeti svoj rad dok značajka ne završi. Svaka disciplina radi izolirano, što koči suradnju jer su ljudi s kojima trebate komunicirati zauzeti radom na drugim stvarima.Ali što ako biste mogli ranije ublažiti ovisnosti i dopustiti disciplinama da istovremeno rade na istoj značajci?
Evo nekoliko primjera:
1. Postavljeno funkcionalno korisničko sučelje sa žljebovima
Da bi deblokirali SDET-ove, programeri korisničkog sučelja mogu im dati funkcionalno korisničko sučelje koje radi taman toliko da im dopušta pisanje testova. Integracija backend API-ja i CSS stilovi još uvijek mogu biti na čekanju, jer automatizirani testni okviri poput Selenium-a neće mariti jesu li te stvari nedovršene. Sve to mogu biti dim i ogledala. Iako se mogu dogoditi promjene koje uzrokuju neke prerade, korist od ranog pokretanja testova nadilazi taj rizik.
2. Primijenjeni Backend API-ji (nepropusni, kodirani podaci)
Pružanje pozadinskih API-ja na kojima programeri korisničkog sučelja mogu testirati omogućuje rano otkrivanje problema s integracijom između prednjeg kraja i API-ja. Ponekad otkrijete da ponuđeni API ne udovoljava potrebama front end programera. Mogli bi nedostajati čitavi pozivi, potpis mogao biti pogrešan ili bi struktura podataka mogla imati problema. Ako postoji prekid veze, možda biste to mogli saznati i prije nego što se bilo što stvrdne.
3. Stvorite HelloWorld verziju novih aplikacija i usluga.
Ako je potrebna nova usluga (npr. Mikro usluga), stvorite repo i izradite verziju usluge "hello world". To omogućuje razvojnim resursima pokretanje Jenkinsovih poslova i skripti za postavljanje prije nego što se usluga stvarno razvije.
Te optimizacije olakšavaju ranu povratnu spregu u kojoj netko može reći "Trebam nešto drugo" prije nego što se završi razvoj komponente koja zahtijeva promjenu.
Umotavanje
Nevjerojatno je važno da smislimo kako skratiti vrijeme izlaska na tržište značajki na kojima radimo. Posao nema koristi od gomile značajki koje su u tijeku, a programeri očajnički trebaju značajke za brzu implementaciju kako bi se nedostaci mogli riješiti što bliže točki ubrizgavanja. Programeri također očajnički trebaju međusobno komunicirati iako je sve što stvarno žele pisati kod. Bolje je za sve uključene, uključujući krajnjeg korisnika koji samo želi bolji proizvod. Ako im ne date, oni će otići negdje drugdje da ga pronađu.
Rojenje je izuzetno vrijedan alat u alatu vaše organizacije ako ljudi odvoje vremena da nauče kako se to radi. To nije okvir ili čak aktivnost - to je način razmišljanja. Za svaku korisničku priču članovi tima postavljaju si dva pitanja:
- Kako organizirati zadatke za ovu priču kako bi odjednom pridonijelo nekoliko ljudi?
- Koji je minimum koji moram učiniti da bih deblokirao nekoga tko me čeka?
Što ako vaš tim brzo izgradi značajke, a ne polako samostalno gradi hrpu značajki? Oni bi zapravo mogli odgovoriti na promjenjive poslovne zahtjeve i udovoljiti potrebama poduzeća kada ih posao treba ispuniti. Natjecatelji bi se bojali vas - kupci bi vas voljeli. To je recept za uspješno poslovanje.
© 2017 Mike Shoemake