Tere, sõbrad. Tihti, eriti välitööde puhul, näen ma sama pilti. Selgete tööprotsesside puudumine meeskondades erinevates projektides.
Peamine probleem on selles, et arendajad ei mõista, kuidas suhelda kliendiga ja omavahel. Kuidas luua pidev kvaliteetse arenduse protsess. Kuidas planeerida oma tööpäeva ja sprinte.
Ja kõik see viib lõpuks toimetamata tähtaegade, ületundide, pideva süüdistamise ning klientide rahulolematuse – kuhu ja kuidas kõik liigub. Üsna sageli toob see kaasa arendajate vahetuse, isegi terve meeskonna lahkumise. Kliendi kaotuse, maine halvenemise ja nii edasi.
Oma ajal sattusin just sellisesse projekti, kus olid kõik need probleemid.
Keegi ei tahtnud võtta vastutust projekti eest (suur teeninduslik turuplats), rotatsioon oli hirmus, klient lihtsalt murdis ja vihastas. CEO tuli kord minu juurde ja ütles, et sul on vajalik kogemus, nii et siin on sulle osad. Võta projekt endale. Kui sa eksid, siis me lõpetame projekti ja kõik saavad kinga. Kui saab hästi, siis arenda seda edasi, nagu vajalik. Lõpuks sain ma projekti tiimijuhiks ja kõik langes minu õlgadele.
Esimene asi, mida ma tegin, oli töötuba protsessi väljatöötamine nullist, mis vastas tolle hetke nägemusele, ja koostasin meeskonnale ametijuhendi. Selle rakendamine oli keeruline. Aga kuu jooksul kõik paika loksus, arendajad ja klient harjusid ning kõik läks juba rahulikult ja mugavalt. Näitamaks meeskonnale, et see ei ole lihtsalt "torm klaasis", vaid reaalne väljapääs olukorrast, võtsin endale maksimaalsed kohustused, vabastades meeskonna ebameeldivast rutiinist.
Poolteist aastat on möödunud ja projekt areneb ilma ületundideta, ilma 'rousia kestade' ja erinevate stressideta. Keegi vanast meeskonnast ei tahtnud nii töötada ja lahkus, mõned jälle leidsid, et selged reeglid on väga head. Aga lõpuks kõik, kes on meeskonnas, on väga motiveeritud ja tunnevad suurt projekti täielikult, nii frontendi kui ka backendiga. Sealhulgas võtme- ja kogu äri loogikaga. Oleme jõudnud isegi sinnani, et me pole lihtsalt "koormused", vaid ise leiame välja palju äri protsesse ja uusi funktsioone, mis on ettevõtjale meeldinud.
Kuna meie lähenemine oli selline, otsustas klient tellida meie firmalt veel ühe turuplatvormi, mis on suurepärane uudis.
Kuna minu projektis see töötab, võib see kedagi teistki aidata. Seega, protsess, mis aitas meil projekti päästa:
Meeskonna tööprotsess projektis "Minu lemmikprojekt"
a) Siseriklik protsess (arendajate vahel)
- Kõik ülesanded luuakse süsteemis Jira
- Iga ülesanne peab olema võimalikult detailselt kirjeldatud ja täitma kindlat ühte tegevust
- Iga funktsiooni, kui see on piisavalt keeruline, jagatakse paljuks väikesteks ülesanneteks
- Meeskond töötab funktsioonide kallal kui ühtse ülesande. Esmalt teeme kõik koos ühe funktsiooni, anname selle testimiseks ning siis võtame järgmise.
- Iga ülesanne märgitakse, kas see on serveripoolselt või kliendipoolselt
- On olemas ülesannete ja vigade tüübid. Need tuleb õigesti märkida.
- Pärast ülesande täitmist kantakse see koodi ülevaatuse staatusesse (selle käigus luuakse oma kolleegile pull request)
- Küsimuse täitnud isik jälgib koheselt oma aega selle ülesande jaoks
- Pärast koodi kontrollimist kiidetakse PR heaks ja seejärel, see kes ülesande täitis, liidab selle iseseisvalt põhiharusse, muutes seejärel selle staatust valmis deploimiseks arendusse server.
- Kõik ülesanded, mis on valmis arendusse deploimiseks, deploib tiimijuht (tema vastutusala), mõnikord meeskonna liige, kui midagi on kiire. Pärast deploimist muudetakse kõik ülesanded, mis on valmis arendusse, staatusesse - valmis testimiseks arenduses
- Kõiki ülesandeid testib klient
- Kui klient on ülesande arenduses testinud, muudab ta selle staatust valmis deploimiseks toodangusse
- Toodangusse deploimiseks meil on eraldi haru, kuhu liidame põhiharuga ainult enne deploimist
- Kui testimise ajal leiab klient vigu, tagastab ta ülesande täiendamiseks, määrates sellele staatuse tagastatud täiendamiseks. Sellega eraldame need uued ülesanded, mis ei läbinud testimist.
- Kokkuvõttes läbivad kõik ülesanded tee loomisest lõpetamiseni: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- Iga arendaja testib oma koodi iseseisvalt, sealhulgas ka kui veebisaidi kasutaja. Põhiharuga ei lubata liita haru, kui ei tea, et kood töötab.
- Igaühel ülesandel on prioriteedid. Prioriteedid määrab kas tellija või meeskonna juht.
- Arendajad täidavad esmalt prioriteetsed ülesanded.
- Arendajad võivad ülesandeid omavahel jagada, kui süsteemis on leitud erinevaid vigu või üks ülesanne koosneb mitme spetsialisti tööst.
- Kõik ülesanded, mida tellija loob, jõuavad meeskonna juhile, kes neid hindab, ja palub kas tellijal neid täiendada või määrab need ühe meeskonnaliikme peale.
- Kõik ülesanded, mis on valmis arenduskeskkonda või toodangusse väljastamiseks, jõuavad samuti meeskonna juhile, kes ise määrab, millal ja kuidas väljastamine toimub. Pärast iga väljastamist peab meeskonna juht (või meeskonnaliige) tellijat sellest teavitama. Samuti tuleb muuta ülesannete staatust valmis testimiseks arenduskeskkonnas/toodangus.
- Igal päeval samal kellajal (meil on see kell 12.00) korraldame kohtumise kõigi meeskonnaliikmete vahel.
- Igaühel on kohtumisel võimalus arvestada, sealhulgas meeskonna juhil, mida ta eile tegi, mida plaanib täna teha. Miks midagi ei õnnestu. Nii on kogu meeskond teadlik sellest, kes millega tegeleb ja mis etapis projekt on. See võimaldab meil prognoosida ja vajadusel kohandada meie hinnanguid ja tähtaegu.
- Kohtumisel kuulutab meeskonna juht välja kõik projekti muudatused ja hetke vigade taseme, mis ei olnud tellija poolt leitud. Kõik vead analüüsitakse ja määratakse igale meeskonnaliikmele nende lahendamiseks.
- Kohtumisel määrab meeskonna juht igale ülesande, arvestades arendajate praegust koormust, nende professionaalse ettevalmistuse taset ning samuti arvesse võttes, kui lähedal on see või teine ülesanne sellele, millega arendaja hetkel tegeleb.
- Kohtumisel arendab meeskonna juht välja üldise strateegia arhitektuuri ja äriloogika osas. Pärast seda arutab kogu meeskond seda ja otsustab, kas teha muudatusi või järgida antud strateegiat.
- Iga arendaja kirjutab koodi ja ehitab algoritme iseseisvalt ühtse arhitektuuri ja äriloogika raames. Igaühel on võimalus väljendada oma nägemust rakenduse teostamiseks, kuid kedagi ei sunnita tegema just niimoodi. Iga otsus on põhjendatud. Kui on olemas parem lahendus, kuid hetkel pole sellele aega, luuakse JIRA-s ülesanne, et tulevikus mingit koodiosasit refaktoorida.
- Kui arendaja on ülesande enda jaoks võtnud, muudab ta selle arenduse staatuseks. Kõik kommunikatsioon, mis puudutab ülesande täpsustamist kliendilt, langeb arendaja õlule. Tehnilise plaaniga seotud küsimusi võib esitada tiimijuhile või kolleegidele.
- Kui arendajale ei ole ülesande sisu selge ja klient ei suuda seda piisavalt selgelt selgitada, siis asub ta järgmist ülesannet lahendama. Praegune ülesanne võtab tiimijuht ning arutab selle ise kliendiga.
- Iga päev peab arendaja kliendi vestluskanalis kirjutama, millega ta eile töötas ja millega ta täna töötab.
- Tööpõhimõte põhineb scrambil. Kõik on jagatud sprinditeks. Iga sprint kestab kaks nädalat.
- Sprinte loob, täidab ja lõpetab tiimijuht.
- Kui projektil on ranged tähtaegad, siis püüame kõikidesse ülesannetesse umbkaudu hinnangud anda. Kogume need sprindiks. Kui klient proovib sprindi lisada veel ülesandeid, siis seame prioriteedid ja mõned muud ülesanded lükkame järgmisse sprindi.
b) Tööprotsess kliendiga
- Iga arendaja võib ja peab suhtlema kliendiga.
- Ei tohi lubada kliendil peale suruda oma mängureegleid. Tuleb sõbralikul ja viisakal viisil anda kliendile mõista, et me oleme oma ala spetsialistid ja ainult meie peame korraldama tööprotsessid ning kaasama sellesse klienti.
- Ideaalis, enne kui alustada mingisuguste funktsioonide rakendamist, tuleks luua funktsiooni kogu loogilise protsessi plaan (workflow). Ja saata see kliendi heakskiitmiseks. See kehtib ainult keerulise ja mitte ilmselge funktsionaalsuse puhul, näiteks maksesüsteem, teavitussüsteem jne. See aitab täpsemalt mõista, mida klient tegelikult vajab, säilitada funktsiooni dokumentatsiooni ning kaitsta end selle eest, et klient ütleb tulevikus, et me tegime mitte nii, nagu ta palus.
- Kogu skeemid/diagrammid/loogika jne salvestame Confluence'i/Jira'sse, kus palume kliendil kommentaarides kinnitada tulevase elluviimise õigust.
- Püüame klienti mitte koormata tehniliste detailidega. Kui on vaja aru saada, kuidas klient soovib, joonistame primitiivseid algoritme diagrammide kujul, mida klient suudab mõista ja ise kõik parandada/täiendada.
- Kui klient leiab projektis vea, palume tal selle väga detailselt Jira'sse kirja panna. Millistes oludes see juhtus, millal, millist tegevuste järjestust klient testimise käigus jälgis. Palume lisada ekraanipildid.
- Püüame igapäevaselt, maksimaalselt igal teisel päeval teha deploy'd arendusserverisse. Kliendil on siis võimalus alustada funktsionaalsuse testimist ja projekt ei seisa. Samuti on see kliendile märk, et projekt on täies arenduses ja keegi ei räägi talle muinasjutte.
- Väga sageli juhtub, et klient ei mõista täielikult, mida ta üldse vajab. Kuna ta loob endale uut äri, mille protsessid pole veel välja kujunenud. Seetõttu on väga tavaline olukord, kus viskame prügikasti tükke koodi ja ümber kujundame rakenduse loogikat. Sellest tulenevalt ei tasu absoluutselt kõike katsetada. On mõistlik katsetada ainult kriitilist funktsionaalsust ja seda teatud tingimustel.
- On olukordi, kus meeskond mõistab, et me ei mahu tähtaegadesse. Sel juhul teeme kiire audit ülesannete osas ja informeerime klienti kohe. Probleemi lahendamiseks pakume välja tähtsa ja kriitilise funktsionaalsuse käivitamise õigeaelset teostamist, ülejäänud võib jätta järgnevaks väljaandmiseks.
- Kui klient hakkab välja mõtlema erinevaid ülesandeid, hakkab fantaasiama ja seletama sõrmedega, siis palume tal esitada meile lehe maketi ja voogu koos loogikaga, mis peab täielikult kirjeldama kogu maketi ja selle elementide käitumist.
- Enne kui võtame ette ühegi ülesande, peame veenduma, et see funktsioon kuulus meie lepingu tingimustesse. Kui see on uus funktsioon, mis ületab meie algseid kokkuleppeid, peame kindlasti selle funktsiooni hindama ((ekvivalentne täitmise aeg + 30%) x 2) ja teatama kliendile, et selleks kulub meil nii palju aega, lisaks lükatakse tähtaeg edasi ajaga, mis on korrutatud kahega. Kui saame ülesande kiiremini tehtud — suurepärane, sellest võidavad kõik. Kui ei, siis oleme end kaitsnud.
b) Mida me meeskonnas ei aktsepteeri:
- Ükskõiksus, segadus, unustamine.
- Juttude edasilükkamine. Kui sa ei suuda ülesannet täita, ei tea kuidas, tuleb sellest kohe teavitada tiimijuhti, mitte oodata viimaseni.
- Ülemäärane enesekehtestamine inimeselt, kes pole veel oma võimeid ning professionaalsust tõestanud. Kui on tõestanud, siis võib, kõike muud silmas pidades 🙂
- Petmine igas selle väljendusvormis. Kui ülesanne pole täidetud, ei tohiks selle staatust muuda täidetuks ja kirjutada kliendi vestluses, et see on valmis. Arvuti purunes, süsteem lagunes, koer näris sülearvutit — see kõik on lubamatu. Kui juhtub tõeline force majeure, peab tiimijuht sellest kohe teadlik olema.
- Kui spetsialist on pidevalt offline ja temaga on tööajal keeruline ühendust saada.
- Toksilisus meeskonnas ei ole lubatud! Kui keegi on millegagi mittenõus, kogunetakse koos koosolekule, et arutada ja lahendada see probleem.
Ja veel mõned küsimused/teesi, mida ma mõnikord oma kliendile esitan, et kõik arusaamatused eemaldada:
- Millised on teie kvaliteedikriteeriumid?
- Kuidas määrate, kas projektis on probleeme või mitte?
- Rikkudes kõiki meie soovitusi ja nõuandeid süsteemi muutmiseks/parandamiseks, kannate kõik riskid ainult teie.
- Iga olulised muudatused projektis (nt kõikvõimalikud eksta vood) võivad põhjustada bugide tekkimist (mida me loomulikult parendame).
- On võimatu mõne minutiga aru saada, mis probleem projektis tekkis, rääkimata selle kohesest lahendamisest.
- Töötame konkreetse toote voogude järgi (Tööd Jiras — Arendamine — Testimine — Paigaldamine). See tähendab, et me ei saa reageerida kogu voogude hulgale palvetele ja kaebustele vestluses.
- Arendajad on tõeliselt arendajad, mitte kutselised testijad, ja nad ei saa tagada projekti kvaliteetset testimist.
- Lõpliku testimise ja ülesannete vastuvõtmise vastutus lasub täielikult teil.
- Kui oleme juba ülesande kallale asunud, ei saa me kohe teisele üle minna, enne kui jooksva ülesande lõpetame (muudab see probleemide hulka ja pikendab arendusaega).
- Meeskonna liikmete arv on vähenenud (puhkuste või haiguste tõttu), kuid töö maht on suurenenud ja me ei suuda füüsiliselt reageerida kõigile teie soovidele.
- Teie palve teha tootmises deploy testimata ülesannete jaoks arenduse keskkonnas on ainult teie risk, mitte arendajate.
- Kui esitate ebamugavaid ülesandeid, ilma selgete voogudeta ja kujundusmustriteta, nõuab see meilt palju rohkem pingutust ja aega, kuna peame teie asemel tegema täiendavat töökoormust.
- Igasugused vigade ülesanded, ilma detailse kirjelduse ja ekraanipiltideta, ei võimalda meil mõista, mis läks valesti, ja kuidas saame seda viga reprodutseerida.
- Projekt vajab pidevat täiustamist ja uuendamist, et parandada jõudlust ja turvalisust. Seetõttu kulutab meeskond osa oma ajast nendele täiustustele.
- Kuna meil on tunnitasudes ületunde (hädaolukordade lahendamine), peame neid kompenseerima teistel päevadel.
Reeglina mõistab klient kohe, et tarkvara arendamine pole nii lihtne, ja pelgalt soovimisest ei piisa.
See on kõik. Jätan kõrvale hulga läbirääkimisi ja protsesside esialgset häälestamist, kuid tulemus on, et kõik on sujunud. Võin öelda, et see protsess on olnud meie jaoks omamoodi „Hõbepealne” lahendus. Uued inimesed, kes projektiga liitusid, said kohe tööle asuda juba esimesel päeval, kuna kõik protsessid olid kirja pandud, ja dokumentatsioon ning arhitektuur diagrammi vormis andsid kohe ülevaate, millega me tegeleme.
P. S. Soovin täpsustada, et meie poolel ei ole projektijuhti. See on tellija poolel. Üldse mitte tehniline. Projekt on Euroopa projekt. Kogu suhtlus toimub ainult inglise keeles.
Soovin kõigile edu projektides. Ärge väsige ja püüdkem oma protsesse parandada.
Algne tekst on minu. .
Allikas: habr.com
