3 saastumist ja kuidas neid parandada

Vabanegem kohutavatest eraldiseisvatest koosolekutest, põrgulistest hinnangutest ja kasutajaväärtuse pakkumisest ning ehitame selle asemel suurepäraseid tooteid.

Foto autor Randy Fath saidil Unsplash

Tarkvarainseneride tööpakkumisi sirvides on peaaegu alati üks universaalne oskus, mille potentsiaalne kandidaat peaks omandama. See oskus on “Scrum”. Sõltumata sellest, kas Scrum on tegelikult oskus samamoodi nagu vaipade kirjutamine või koodi kirjutamine, on mul alati olnud huvitav, et valdav enamus ettevõtteid on Scrumi teinud oma de facto tööviisi.

Agiilse töötamise eelised - mis tähendab peaaegu alati Scrumi teatud rakendamist - on juhtkonna seisukohast ilmsed. Selle asemel, et end kvartalite kaupa kaardistada, otsustate, mis on väärtuslik töö, regulaarselt ja töö on jaotatud nii, et teoreetiliselt peaksid kõik saama seda teostada.

Juba 2018. aastal kirjutasin artikli, milles ta kirjeldas, mida ma toona arvasin Scrumi kasutamise eest tarkvaratehnikas. See artikkel pälvis pettunud arendajatelt palju kiitust ning ka päris palju kriitikat neilt, kes väidavad, et minu kirjeldatu oli võlts Scrum.

Pärast seda läksin reisile, et teada saada, mis moodustab selle “halva” saast. Selle asemel, et Scrum täielikult maha kirjutada kui midagi, mis tarkvaraarenduse jaoks tõenäoliselt ei tööta, keskendusin halbade elementide tuvastamisele ja püüdsin leida viise, kuidas muuta need tähendusrikkateks, produktiivseteks elementideks.

Selles artiklis mõtlen sellele, mida olen eelmise artikli kirjutamisest alates õppinud, ja kuidas minu arvates võiks Scrum aidata teil ja teie meeskonnal paremat tarkvara üles ehitada.

Viige läbi kasulikke igapäevaseid eraldiseisvaid kohtumisi

See on huvitav teema. Stand-up koosolekud on Scrumi nurgakivid. Idee on see, et projektimeeskond saab varahommikul kokku, tõuseb püsti ja teavitab üksteist oma edusammudest ja kõigist takistustest, mille suhtes nad võiksid abi kasutada. Need kohtumised on teoreetiliselt suurepärased. See viib kõik samale lehele ja kuna need ilmnevad päeva alguses, saavad kõik oma päevad produktiivselt veeta.

Kuid ma leidsin, et juhid kuritarvitavad neid kohtumisi sageli selleks, et teha kindlaks, kas kõik teevad oma tööd õigesti ja kas projekt on endiselt ajakavas. Kui te pole kindel, kas see nii on või mitte, siis on hea näpunäide, kas kõnelev isik võtab ühendust oma juhi või mõne oma kolleegiga. Kui nad suunavad oma juttu peamiselt oma mänedžerisse, on tõenäoline, et see on varjatud reportaažikoosolek.

Kui stand-up on juhile orienteeritud, kipub see olema minu jaoks harjutuseks, keegi ei kuula. Kõik jõllitavad lihtsalt kaugusesse, neil on igav meele järele ja ootavad, et kohtumine oleks läbi. Iroonilisel kombel kipub seda tüüpi stand-up sisaldama ka tarbetuid detaile, millest tuleb lihtsalt haldurile teada anda, muutes selle vastuvõtmise palju pikemaks kui tegelikult peaks.

Õnneks saab seda tüüpi stand-up'i lahendada lihtsalt. Kõigepealt eemaldage haldur stand-upist. Force töötab, kuid võite neid veenda seda tegema, kui räägite lihtsalt ka nendega. Eeldusel, et kõik, kes jäävad koosolekule, töötavad sama projekti kallal, muutub kohtumise toon mõne aja pärast.

Selle asemel et tõestada, et olete eile teinud tähendusrikka töö ja teete seda ka täna, on kohtumisel probleemide lahendamise iseloom. Te saate kohapeal otsustada, millist ülesannet järgmisena täita, ja kui teie tee takistab midagi, saate selle lahendada just seal ja seal.

PS Kui olete selles loos mänedžer, siis tean, et on keeruline ennast kohtumisest maha tõmmata. Meeskonna liikmetel on veelgi keerulisem teie puudumist taotleda. Võib-olla on see hea viis mõõta, kas koosolek muutub ilma teieta produktiivsemaks või mitte, arutage seda oma meeskonnaga ja proovige lühikese aja jooksul haldurita koosolekuid.

Rob Hampsoni foto saidil Unsplash

Ärge kinnisidee kasutaja väärtuse üle

Üks põhjus, miks ettevõtted rakendavad selliseid raamistikke nagu Scrum, on see, et nad soovivad oma lõppkasutajatele kiiresti väärtust pakkuda. See paaristub kenasti nii üksikute sprindite lühikesest kestusest kui ka võimalusest nende vahel fookusi reguleerida.

Suurim viga, mida siin teha saate, on kinnisideeks pakkuda väärtust ainult oma lõppkasutajatele. Nii nagu pole mõtet mädanevate tugitaladega hoonele lisapõrandat lisada, on väga vähe mõtet lisada funktsioone projektile, mis mureneb oma raskuse all.

Sarnaselt sellele, et autojuhtimise võimalus ei tähenda, et inimene teaks, kuidas autot ehitada, ei tea arendusmeeskonnaga “sõitev” inimene tingimata tarkvara ehitamise parimat viisi. Kui teie auto mehaanik ütleb, et teie autoga pole enam turvaline sõita, siis teate, et võtate järgmine kord puhkusel olles tohutu riski. Peaksime võtma sama ettevaatusabinõu, kui kogenud insener ütleb meile, et midagi, mida kasutaja meeleheitlikult soovib, on meie koodialuse kvaliteedile suur mõju.

Tarkvarainsenerid, kes töötavad iga päev koodialusega, on ka selle kõige intensiivsemad kasutajad. Erinevalt teie tavakasutajatest ei järgi nad lihtsalt õnnelikku rada; nad käivad igal teel. Kui toote juurutamine muutub keeruliseks, on inseneridel järk-järgult keerukam sisulist tööd teha. Suure osa oma päevast veedavad nad pigem asjade ümber töötamise asemel.

Ehkki funktsioonide loomine meie lõppkasutajate jaoks on kahtlemata väärtuslik, on pikaajaliselt palju tõenäolisem, kui toode omab nii lõppkasutajaid kui ka arendajaid pikema aja jooksul. See tähendab, et mõnikord võib olla hea mõte kavandada ka suured sprinditööd või üldine majapidamine sprintides. Mitte teisejärgulisena, vaid esmaklassilisena - käsitlege seda tööna, mis on sama oluline kui uute funktsioonide loomine.

Ärge tehke hinnanguid evangeeliumi jaoks

Sprindis tehtava töö hulga kindlaksmääramiseks eelistatakse mahajäämuse iga üksikut ülesannet ja selle tööd hinnatakse. Mõnikord tehakse selleks ülesande täitmiseks kulunud tegelikke tunde, teisiti ebamääraseid asendajaid, näiteks punkte, või isegi t-särkide suurust.

Sprindi ajal tehtavate tööde hindamine on vaieldamatult Scrumi üks keerulisemaid osi. Tundub, et arendajad ei jõua kokkuleppele selles, kui palju konkreetse ülesande täitmiseks kulub, ja see eeldab, et on isegi ilmselge, millega alustatakse. Hinnanguid ei saa kunagi täpselt täpsustada mitmel põhjusel.

Üks neist põhjustest on eelnev kogemus. See võib olla üksikisiku eelnev kogemus või meeskonna kogemus, kuid see ei kehti kunagi kõigi meeskonna üksikute kohta. Oletame, et meeskonnaliikmel on pikaajaline kogemus autentimismehhanismide rakendamisel, järgides teatud norme. Nad võivad kalduda hindama autentimise teostamist palju vähem vaevaga kui keegi, kes on antud teemal vähem teadlik. Kuid hinnang peab olema täpne kõigi meeskonna liikmete seas, sõltumata sellest, kes selle töö tegelikult lõpetab.

Teine põhjus on see, et hinnanguliselt hinnatavat tööd ei tehta peaaegu kunagi selgelt. Pagariäri puhul on üsna lihtne prognoosida, kui kaua kulub neil saja leiva küpsetamiseks. Nad teavad, kui kaua võtab aega, kui palju nad saavad korraga küpsetada, ja siis teete lihtsalt mõne lihtsa matemaatika.

Nagu teab iga tarkvarainsener, ei tööta see koodiga töötamisel niimoodi. Iga kord, kui sukelduda mõnda konkreetsesse koodi, peate seda mitte ainult analüüsima ja mõistma, vaid mõistma ja analüüsima ka kavandatavaid muudatusi ja ka nende võimalikke tagajärgi. See on äärmiselt keeruline ülesanne, rääkimata hinnangust.

Võite arvatavasti leida veel hulga põhjuseid, miks töö hindamine on keeruline, kuid mõte on selles, et te ei peaks evangeeliumina mingit hinnangut võtma. Oletame, et meeskond teeb parimal juhul haritud arvamise inimestega, kellel nad sel ajahetkel on.

Kuigi meeskonnad saavad aja jooksul tööd paremini hinnata, pidage alati meeles, et väikseimad asjad võivad selle hinnangu täielikult ära visata. Tegelik väärtus on tegelikult tehtud töös, mitte selles, kas hinnang oli õige või mitte.

Järeldus

On ilmne, et Scrum on midagi enamat kui selle osade summa. Tseremooniate kirurgiline elluviimine ja Scrumiks nimetamine jätab teile lihtsalt hulga tseremooniaid, kus inimestel äkki tuleb osaleda, kuid see ei muuda tingimata teie arendusprotsessi tõhusamaks ega veelgi paindlikumaks.

Scrumi rakendamist tuleb pidevalt parendada. Kui miski teie meeskonna heaks ei tööta; kohandada seda. Scrum ei tohiks olla muutumatu tseremooniate ja kohtumiste komplekt - see peaks olema sujuv asi, mis kasvab teie meeskonnas ja annab teile juhiseid, mis aitavad teil produktiivsemaks ja tõhusamaks saada.

Ma pole kaugeltki innukas entusiasm ja tõenäoliselt ei saa ma kunagi selliseks. Kuid erinevalt artiklist, millest ma 2018. aastal kirjutasin, võin vihjata, ei usu ma, et Scrum kui institutsioon on tarkvaraarendusmeeskondadele olemuselt halb asi.

Kui Scrum ei pea teie meeskonda sobivaks, avage vestlus. Vaadake, kas teie meeskonna teised inimesed tunnevad sama moodi, ja kui nad seda teevad, proovige täpselt kindlaks teha, mis täpselt end produktiivsena tunneb, ja tehke koos järk-järgult muudatusi.

Parim tarkvara arendamise viis on viis, mis töötab teie meeskonna jaoks. Keskenduge sellele. Unusta ülejäänud.