Tere, sõbrad. Sageli, eriti outsourcingu valdkonnas, näen ma ühte ja sama pilti. Meeskondade ebaselge tööprotsess erinevates projektides.
Oluline on see, et programmeerijad ei mõista, kuidas suhelda kliendi ja omavahel. Kuidas luua pidev kvaliteetsete toodete arendamise protsess. Kuidas planeerida oma tööpäeva ja sprinte.
Ja kõik see lõppeb lõpuks tähtaegade rikkumisega, ületundide, pideva vaidlusega, kes on süüdi, ja klientide rahulolematusega – kuhu ja kuidas kõik liigub. Tihti toob see kaasa programmeerijate või isegi kogu meeskonna vahetuse. Klientide kaotuse, maine halvenemise jne.
Olin ise kunagi sellises projektis, kus olid kõik need probleemid.
Keegi ei soovinud võtta vastutust projekti eest (suur teenuste turuplats), käive oli kohutav, klient lihtsalt kärgatas ja murdis. SEO tuli kunagi minu juurde ja ütles, et sul on vajalik kogemus, nii et siin on sulle võimalus. Võta projekt endale. Kui ebaõnnestud, sulgeme projekti ja anname kõik lahti. Kui kõik õnnestub, on see suurepärane, siis juhata seda ja arenda seda, nagu ise soovid. Lõppkokkuvõttes sain ma projekti tiimijuhiks ja kõik langes minu õlgadele.
Esimene asi, mida ma tegin, oli tööprotsessi väljatöötamine nullist, mis vastas minu tol hetkel visioonile, ja kirjutasin meeskonna ametijuhendi. Selle rakendamine ei olnud kerge. Kuid umbes kuu jooksul sai kõik paika, arendajad ja klient harjusid ning kõik hakkas liikuma rahulikult ja mugavalt. Selleks, et näidata meeskonnale, et see ei ole lihtsalt "torm klaasis", vaid tegelik lahendus olukorrale, võtsin ma enda peale maksimaalse hulga kohustusi, vabastades meeskonna ebameeldivast rutiinist.
On juba poolteist aastat möödas, ning projekt areneb ilma ületöötamiseta, ilma „hiirejooksudeta“ ja igasuguste stressideta. Mõni vana meeskonna liige ei tahtnud niimoodi töötada ja lahkus, teised aga on leidnud, et selged reeglid on väga meeldivad. Lõppkokkuvõttes on kõik, kes meeskonnas on, väga motiveeritud ja tunnevad projekti tervikuna, sealhulgas ka esiplaan ja tagaplaan. Sealhulgas ka koodibaas ja kogu äri loogika. Oleme jõudnud isegi selleni, et me ei ole lihtsalt „aerutajad“, vaid leiutame ise palju äri protsesse ja uusi funktsioone, mis ettevõttele meeldivad.
Tänu meie lähenemisele otsustas klient tellida meie ettevõttelt veel ühe turuplatvormi, mis on kindlasti rõõmustav.
Kuna see töötab minu projektis, võib see aidata ka kedagi teist. Nii et siin on protsess, mis aitas meil projekti päästa:
Meeskonna tööprotsess projektis „Minu lemmikprojekt“
a) Sise meeskonna protsess (arendajate vahel)
- KÕIK ülesanded luuakse Jira süsteemis
- Iga ülesanne peab olema maksimaalselt kirjeldatud ja täitma rangelt ühte tegevust
- Iga funktsioon, kui see on piisavalt keeruline, jagatakse paljudeks väikesteks ülesanneteks
- Meeskond töötab funktsioonide kallal kui ühtne ülesanne. Alustame koos ühe funktsiooni loomisega, anname selle testimiseks üle, seejärel võtame järgmise.
- Iga ülesanne märgistatakse, kas tagaplaanile või esiplaanile.
- On olemas ülesandeid ja vigu. Neid tuleb õigesti määratleda.
- Pärast ülesande täitmist muudetakse selle olek koodiarvustuseks (sellega luuakse kolleegi jaoks pull request).
- See, kes ülesande täitis, jälgib kohe oma aega selle ülesande jaoks.
- Pärast koodi kontrollimist kiidetakse PR heaks ja seejärel liidab ülesande täitja selle iseseisvalt peaharusse, muutes seejärel selle olekut 'valmis tõukamiseks dev-ile'. server.
- Kõik ülesanded, mis on valmiskujul dev serveri tõukamiseks, tõukab tiimijuht (tema vastutusalas), mõnikord ka meeskonna liige, kui midagi on kiiret. Pärast tõukamist muudetakse kõik ülesanded, mis on valmis tõukamiseks dev-ile, olekusse 'valmis testimiseks dev-is'.
- Kõiki ülesandeid testib tellija.
- Kui tellija on ülesande dev-is testinud, muudab ta selle olekuks 'valmis tootmisse tõukamiseks'.
- Produksioonis tõukamiseks on meil eraldi haru, kuhu liidame peaharusse ainult enne tõukamist.
- Kui tellija testimise käigus leiab vigu, tagastab ta ülesande täiendamiseks, määrates sellele staatuse 'tagastatud täiendamiseks'. Nii eraldame uued ülesanded nendest, mis ei läbinud testimist.
- Lõppkokkuvõttes läbivad kõik ülesanded tee loomisest kuni valmimiseni: To Do → Arendus → Koodikontroll → Valmis arendusse saatmiseks → QA arenduses → (Tagasi arendusse) → Valmis tootmisse saatmiseks → QA tootmises → Valmis.
- Iga arendaja testib oma koodi iseseisvalt, sealhulgas ka kasutajana. Peahoone liitmist ei lubata, kui ei ole kindel, et kood töötab.
- Igal ülesandel on prioriteedid. Prioriteedid määrab kas tellija või tiimijuht.
- Arendajad täidavad kõigepealt prioriteetsed ülesanded.
- Arendajad saavad omavahel määrata ülesandeid, kui süsteemis on leitud erinevaid vigu või kui üks ülesanne koosneb mitme spetsialisti tööst.
- Kõik ülesanded, mille tellija loob, jõuavad tiimijuhile, kes neid hindab ja kas palub tellijal teha täiendusi või määrab need mõnele tiimiliikmele.
- Kõik ülesanded, mis on valmis arendamiseks või tootmiseks, jõuavad ka tiimijuhile, kes määrab iseseisvalt, millal ja kuidas arendust läbi viia. Pärast iga arendust peab tiimijuht (või meeskonnaliige) sellest tellijat teavitama. Lisaks peab ta muutma ülesannete staatust arendamise / tootmise testimiseks valmis.
- Igal päeval samaaegselt (meie puhul kell 12.00) korraldame koosoleku, kuhu koguneb kogu tiim.
- Iga liige annab koosolekul aru, sealhulgas tiimijuht, millist tööd ta eile tegi, mida plaanib täna teha, mis ei õnnestu ja miks. Nii on kogu tiim kursis, kes millega tegeleb ja millises etapis projekt on. See võimaldab meil prognoosida ja vajadusel kohandada meie hinnanguid ja tähtaegu.
- Koosolekul teavitab tiimijuht ka kõikidest muudatustest projektis ning praegustest vigadest, mis ei olnud tellija poolt leitud. Kõik vead arutatakse läbi ja antakse igale tiimiliikmele lahendamiseks.
- Koosolekul määrab tiimijuht igaühele ülesandeid, arvestades arendajate praegust koormust, nende professionaalset taset ning ka selle ülesande seotust arendaja hetketegevustega.
- Koosolekul arendab tiimijuht üldist strateegiat arhitektuuri ja äriloogika osas. Pärast seda arutab kogu meeskond seda ja otsustab, kas teha muudatusi või aktsepteerida strateegiat.
- Iga arendaja kirjutab koodi ja loob algoritme iseseisvalt, järgides ühiseid arhitektuuri ja äriloogika põhimõtteid. Igaühel on võimalus väljendada oma nägemust teostusest, kuid kedagi ei sunnita tegema seda teistmoodi. Iga otsus on põhjendatud. Kui on olemas parem lahendus, kuid selleks ei ole praegu aega, siis luuakse ülesanne JIRA-s, et tulevikus teatud koodiosa refaktorida.
- Kui arendaja võtab ülesande tööle, siis muudab ta selle arendusstaatusesse. Kõik suhtlus ülesande täpsustamise osas kliendiga on arendaja vastutusel. Tehnilisi küsimusi võib esitada tiimijuhile või kolleegidele.
- Kui arendajale ei ole ülesande olemus arusaadav ning klient ei suutnud seda selgelt selgitada, siis ta läheb järgmise ülesande juurde. Praegune ülesanne jääb tiimijuhi kätte, kes arutab seda ise kliendiga.
- Iga päev peab arendaja kliendi vestluses kirjutama, millega ta eelmisel päeval töötas ja millega ta täna tegelema hakkab.
- Tööprotsess toimub scrum'i meetodil. Kõik on jagatud sprintideks. Iga sprint kestab kaks nädalat.
- Sprintide loomise, täitmise ja sulgemise eest vastutab tiimijuht.
- Kui projektil on ranged tähtajad, siis püüame kõik ülesanded võimalikult kiiresti hinnata ja nende põhjal sprinti kokku panna. Kui klient üritab sellesse sprinti veel ülesandeid lisada, siis seadistame prioriteedid ja lükkame mõned teised ülesanded järgmisse sprinti.
b) Tööprotsess kliendiga
- Iga arendaja võib ja peab suhtlema kliendiga.
- Kliendil ei tohi lasta seada oma mängureegleid. Peame viisakalt ja sõbralikult andma kliendile mõista, et me oleme oma ala spetsialistid ning vaid meie peame protsesse üles ehitama ja neid kliendiga kaasama.
- Ideaalis tuleks enne mistahes funktsionaalsuse rakendamisega alustamist koostada kõigi loogiliste protsesside plaan (töövoog) funktsiooni jaoks ja saata see kliendi kinnitamiseks. See kehtib ainult keerulise ja mitteilmselge funktsionaalsuse, näiteks maksesüsteemi, teavitussüsteemi jne kohta. See aitab paremini mõista, mida klient täpselt tahab, säilitada funktsiooni dokumentatsiooni ning kaitsta end selle eest, et klient tulevikus ei ütleks, et me tegime midagi muud, kui ta soovis.
- Kõik diagrammid/blokkskeemid/loogika jne salvestame Confluence'i/Jira'sse, kus palume klientidel kommenteerida ja kinnitada tulevase rakenduse õigsust.
- Püüame mitte koormata klienti tehniliste detailidega. Kui me vajame arusaamist, kuidas klient soovib, siis joonistame primitiivseid algoritme blokkskeemide kujul, mida klient seadistada ja vajadusel parandada saab.
- Kui tellija leiab projekti kohta vea, palume tal see väga detailselt Jira-s kirja panna. Millistes oludes see juhtus, millal, milliseid samme tellija testi käigus tegi. Palume kaasa panna ekraanipildid.
- Püüame iga päev, maksimaalselt iga kahe päeva tagant, teha deploy arendusserverisse. Siis hakkab tellija funktsionaalsust testima ja projekt ei seise. Samuti on see tellijale märk, et projekt on täielikult arenduses ja keegi ei räägi talle muinasjutte.
- Sageli juhtub, et tellija ei mõista täielikult, mida ta tegelikult vajab. Kuna ta loob uut äri, millel pole veel välja kujunenud protsesse. Seetõttu on väga sagedane olukord, kus viskame terveid koodilõike prügikasti ja muudame rakenduse loogikat. Sellest järeldub, et ei tasu absoluutselt kõike katsetega katta. On mõistlik katta testidega vaid kriitiliselt olulise funktsionaalsuse ja ka see tingimustega.
- Külastame olukordi, kus meeskond mõistab, et me ei sobi tähtaegadesse. Sel juhul teeme kiire auditi ülesannete osas ja teatame sellest kohe kliendile. Probleemist väljajõudmiseks pakume välja olulisema ja kriitilise funktsionaalsuse käivitamise õigeaegselt, samas jättes muu postitusjärgseks.
- Kui klient hakkab pea kohapealt erinevaid ülesandeid välja mõtlema, hakkab fantaasiat kasutama ja selgitama seda näpuga, siis palume tal esitada meile lehe maketi ja voog, mille loogika peaks täielikult kirjeldama kogu maketi ja selle elementide käitumist.
- Enne, kui võtame ette igasuguse ülesande, peame veenduma, et see funktsioon kuulus meie lepingutingimustesse. Kui see on uus funktsioon, mis ületab meie algseid kokkuleppeid, peame kindlasti hindama selle funktsiooni (ligikaudne täitmisaeg + 30%) x 2 ja teavitama klienti, et selleks kulub meil nii ja nii palju aega, pluss tähtaeg nihkub edasi hinnangu ajaga, korrutatuna kahega. Kui suudame ülesande kiiremini täita — suurepärane, kõik saavad sellest ainult kasu. Kui ei, siis oleme end kindlustanud.
v) Mida me oma meeskonnas ei aktsepteeri:
- Mugavus, hajaliikumine, unustamine
- „Hommikusöögiga toitmine“. Kui sa ei suuda ülesannet täita ega tea, kuidas, tuleb sellest kohe teavitada tiimijuhti, mitte oodata viimase minutini.
- Tuhmameelsus ja kiitlemine inimeselt, kes ei ole veel oma oskusi ja professionaalsust tõestanud. Kui on tõestatud, siis võib, kohati tagasihoidlikult 🙂
- Pettus kõikides selle ilmingutes. Kui ülesannet ei ole täidetud, siis ei tohi muuta selle staatust täidetuks ja kirjutada kliendi vestluses, et see on valmis. Arvuti katki, süsteem kukkus kokku, koer näris sülearvuti — kõik see on lubamatu. Kui toimub tõeline force majeure, tuleb tiimijuhti kohe teavitada.
- Kui spetsialist on pidevalt offline ja temaga on tööaegadel keeruline ühendust saada.
- Meeskonnas ei lubata toksilisust! Kui keegi on millegagi mittenõus, peavad kõik koos kokku saama koosolekule, et arutada ja lahendada.
Ja veel mitmed küsimused/teesid, mida ma vahel oma kliendile esitan, et vältida arusaamatusi:
- Millised on teie kvaliteedikriteeriumid?
- Kuidas määratlete, 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 suuremad muudatused projektis (nt kõikvõimalikud eksta vood) võivad põhjustada vigu (mille me loomulikult parandame).
- On võimatu paari minutiga mõista, mis probleem projektis tekkis, ja veel vähem seda kohe lahendada.
- Me töötame kindla toote voos (Ülesanded Jiras — Arendus — Testimine — Ülesanne). See tähendab, et me ei saa reageerida kõigile palvetele ja kaebustele vestluses.
- Programmeerijad on just programmid, mitte professionaalsed testijad, ja ei suuda tagada projekti nõuetekohast kvaliteeti.
- Lõpliku testimise ja ülesannete vastuvõtmise vastutus on täielikult teie õlgadel.
- Kui me oleme ülesande juba tööks võtnud, siis ei saa me kohe teisele üle minna, kuni praegune on lõpetatud (muutmine toob kaasa veelgi rohkem vigu ja pikendab arendusaega).
- Meeskonnas on inimesi vähem (puhkuste või haiguste tõttu), samas töö on rohkem ja me ei suuda füüsiliselt reageerida kõigile, mida te soovite.
- Teie poolt palutakse teha tootmisse juurutamine ilma testitud ülesanneteta arenduses – see on ainult teie risk, mitte arendajate.
- Kui te esitate ebaselgeid ülesandeid, ilma korrektse töövoo ja disainimudeliteta, nõuab see meilt palju suuremaid jõupingutusi ja pikemaid tähtaegu, kuna me peame teie asemel täiendavat tööd tegema.
- Igasugused veaküsimused ilma põhjalike kirjeldusteta ja ekraanipiltideta ei võimalda meil aru saada, mis valesti läks ja kuidas seda viga simuleerida.
- Projekt vajab pidevat täiendamist ja täiustamist, et suurendada jõudlust ja turvalisust. Seetõttu kulutab meeskond osa oma ajast nende paranduste tegemisele.
- Kuna meil võivad olla ületunnid (kiired parandused), peame neid teistes päevades kompenseerima.
Tavaliselt mõistab klient kohe, et tarkvaraarendus pole nii lihtne ja pelgalt soov nendes küsimustes ei piisa.
Kokkuvõttes on see kõik. Jään kaadrist välja paljusid läbirääkimisi ja algseid protsesside häälestusi, kuid lõpptulemusena kõik toimis. Võin öelda, et see protsess on meile muutunud omamoodi "Hõbekuuliks". Uued inimesed, kes projektiga liitusid, said alustada oma tööd esimesest päevast, sest kõik protsessid on kirjalikult kokku pandud ja dokumentatsioon ning arhitektuur diagrammide kujul andsid kohe ülevaate, millega me siin tegeleme.
P. S. Soovin täpsustada, et meie poolel projektijuhti ei ole. Tema on tellija poolel. Ta ei ole tehniline inimene. Projekt on Euroopa oma. Kogu suhtlus toimub ainult inglise keeles.
Soovin kõigile edu projektides. Ärge põletage end läbi ja püüdkem oma protsesse parandada.
Allikas minu .
Allikas: habr.com
