Kuulake selle artikli heliversiooni

Olenemata sellest, kas töötate väikeses idufirmas või uue toote kallal suures ettevõttes, jõuate tõenäoliselt hetkeni, kui teil on ühes meeskonnas liiga palju inimesi. Varakult märkide tuvastamine säästab teid meeskonna kõige ebaefektiivsema etapi saavutamisest.

Iga toode on erinev ja seda teevad ka meeskonnad. Seega nõuab meeskonna lõhestamine ka teie olukorda kajastavate otsuste tegemist. Mõned asjad, mida tuleks kaaluda, on:

• Kuidas säilitada oskusteabe terviklikkus, kui meeskonnakaaslased enam koostööd ei tee
• Kas peaksite jagama funktsioone (nt esi- ja tagatiimi meeskonnad)?
• Kas uutel meeskondadel peaks olema eraldi mahajäämus?
• Kas tootehaldustiim peaks vastavalt kasvama?

Millal peaksite alustama teise meeskonna loomist?

Kõige ilmsem näide meeskonna jaotuse peale mõtlemisest või uue meeskonna lisamisest on eelarve suurenemisel. See võib juhtuda uue idufirma investeerimisvooru või teie toote uute eesmärkide saavutamiseks ettevõttes. Kui eelarve suurenemine on nii märkimisväärne, et teie meeskond kasvab 3x või enam, pole mõistlik, et oskusteabe levitamiseks peate oma praeguse meeskonna jagama. Otsused ei muutu aga nii selgeks, kui eelarve suurenemine on järk-järguline ja lõpuks lisate nimekirja paar uut inimest. Kui teil on, näiteks, plaanis oma meeskonda kasvatada 7-lt inimesele, kas see nõuab lahutamist? Agile reklaamib väikesi meeskondi, kuid edendab ka üksikisikuid ning suhtlemist protsesside ja tööriistadega. Kahe või enama meeskonna olemasolu loob paratamatult rohkem protsesse, et oleks võimalik sünkroonis töötada.

Mida ütlevad eksperdid?

Amazoni asutaja Jeff Bezos on kasutanud kahe pitsa reegel nii koosolekute kui ka meeskondade jaoks. See tähendab, et kummalgi peaks olema ainult nii palju inimesi, kui kaks pitsat saavad lõuna ajal süüa.

The Scrumi juhend soovitab omada kolme kuni üheksa meeskonnaliiget, kes tegelevad sprindi mahajäämusega. See tähendab, et te ei kaasaks toote omanikku ega scrum masterit, kui kumbki neist ei rakenda sprindi mahajäämuse üksusi.

Nendel arvudel on intuitiivne mõte, kuid selle taga on ka matemaatika. Kui mõelda meeskonnale, on iga inimene nagu sõlm ja nad ühendavad end teiste sõlmedega. Need on meeskonnakaaslaste omavahelised suhted. Nad võivad olla sõbralikud, konkurentsivõimelised, pahatahtlikud või hoolivad. Ükskõik, mis suhe on kahe inimese vahel, on see ikkagi seos, mis nõuab igalt inimeselt teatud vaimset võimekust. Meeskonna kasvades ei kasva nende linkide arv lineaarselt. Sõlmedevaheliste linkide valem on (n (n-1) / 2 ). Siin on lingi kasvu graafik:

Diagramm illustreerib matemaatiliselt selgelt, miks meeskonnad kõige tõhusamalt tegutsevad, kui nad pole liiga suured. Kui võtta Scrum Guide soovitatud 3–9 meeskonnaliiget, siis jõuame lõpuks 3–36 lingini. Kui me kasvaksime 15 inimeseni, oleks meil üle 100 lingi. Selle meeskond saaks tõhusalt tegutseda ainult siis, kui nende ülesanded oleksid väga täpselt määratletud ja harva kattuvad või kui oleks mõni mitteametlik alamrühm. Samuti pole see nii ega soovitav ka Agile põhimõtetel töötades.

Märgid, et meeskond läheb liiga suureks

Daily Scrum

Mõnikord nimetatakse seda igapäevaseks püstijaoks, igapäevane ülevaade on kogu meeskonna kokkutulek, et arutada sprindi edenemist ja takistusi. Scrumi juhend soovitab need ajastada 15 minutiga ja see on hea lakmuspaber meeskonna suuruse jaoks. Kui hakkate märkama, et teie meeskond ületab 15-minutilise riba, võib see viidata kahele:

kuidas päisefaile c++-s kompileerida

• Igapäevased vaevused pole tõhusad. Inimesed uurivad liiga palju üksikasju. Või puudub selge esinemiskord ja meeskonnakaaslaste esinemine võtab aega. Võib-olla kasutab toote omanik või scrum master igapäevast scrumit võimalusena pakkuda erinevaid värskendusi, mis pole seotud sprindiga.
• Meeskond on liiga suur. Kui igapäevased skummid on tõhusad, kuid ületate siiski 15 minutit, võib teil olla meeskonnas lihtsalt liiga palju inimesi. Samuti peaksite märkama, et inimestel on huvi kadumas, kuna inimesel on piiratud teave. Kui liiga palju inimesi pakub värskendusi, on raske jälgida kõigi edusamme ja mõista meeskonna olekut . See paneb inimesi pöörduma sissepoole ja mõtlema ainult oma edusammude üle, mitte otsima võimalusi teiste aitamiseks.

Trimmimine ja sprindi planeerimine

Nii peibutamine kui ka sprindi planeerimine on tegevused, mis on seotud kasutajate lugude purustamisega ning nende tarneaja või suuruse hindamisega. Ehkki rohkemate inimeste olemasolu aitab meeskonnal jõuda paremate otsuste tegemiseni, võib liiga paljude inimeste olemasolu viia meeskonna ummikusse. Sama ülesande täitmiseks on alati erinevaid viise ja argumentide arv mõlemal poolel suureneb koos meeskonna inimeste arvuga.

Nagu igapäevase vaatluse puhul, ärge segage ebaefektiivset planeerimisseanssi liiga suure meeskonnaga. Lõppkokkuvõttes on scrum-kapteni ülesanne muuta scrum-tseremooniad tõhusaks ja mõjusaks.

Tagantjärele

Tagantjärele saavad meeskonnaliikmed lahendada kõik argumendid või konfliktid ja välja mõelda, kuidas oma tööprotsessi parandada. Retrospektiivid õpetavad meile kompromisside kunsti, kuna see paneb meid otsima ühisosa erinevate osapoolte vahel. Meeskond on sama võimas, kui selle liikmed on nõus oma erimeelsuste osas kompromisse tegema.

Kuid nagu sprindi planeerimisel, loovad liiga paljud meeskonnaliikmed liiga palju linke, mis kõik on potentsiaalsed konfliktid. Hakake märkama, kui leiate retrospektiivide käigus üha vähem ühisosa. See võib olla märk sellest, et meeskond on liiga suur ja lõhestumisest oleks kasu.

Kuidas meeskonda jagada

Oma nägu on meeskonna lõhestamine suhteliselt lihtne ülesanne. Jagage meeskonnaliikmed kahte rühma, veenduge, et mõlemal oleks sarnaselt kogenud inimesed, ja määrake uute meeskondade eesmärgid. Siiski tuleb kaaluda üsna paljusid asju, millel võib olla suur mõju uute meeskondade edule tulevikus.

Meeskonna moraal

Tõenäoliselt on üks olulisemaid asju, mida meeles pidada, meeskonnamoraal. Päeva lõpuks peavad uues koosseisus töötama meeskonna inimesed. Kui meeskond on agiilsete põhimõtete osas küps, peaks ta suutma lõhenemise ise teha. See on kõige soovitavam tulemus, sest meeskonnaliikmed teavad oma sisemisi suhteid kõige paremini - kes kellega kõige paremini töötab ja kellele võiks olla kasulik olla eraldi meeskondades.

Funktsionaalsed meeskonnad

Scrum reklaamib funktsionaalseid meeskondi, kellel on kõikvõimalikud oskused, mis on vajalikud toote juurdekasvu loomiseks. See kehtib kahe või enama meeskonna skaleerimisel. Paljude arendajate jaoks, eriti kui nad on Agile'i jaoks uued, on loomulik tendents mõelda tehniliste joonte kõrval. Näiteks soovivad meeskonnad sageli jagada end taga- ja esiotsa meeskondadeks. Mõnel harval juhul võib see olla mõttekas, kuid a tootejuht , peaksite enamasti selle vastu soovitama. Esiostjaid täis meeskond ei suuda ise toote juurdekasvu toimetada ja hakkab loomulikult rohkem mõtlema tehnilisele võimekusele, mis neid ühendab. Selle asemel peaksid nad keskenduma kliendile ja sellele, kuidas oma vajadusi rahuldada.

Teine huvitav kaalutlus on meeskonnas mittearendavad rollid. Erinevates olukordades võib meeskonda kuuluda disainer, ärianalüütik või kvaliteedi tagamise spetsialist. Kui olete meeskonna jaganud, eriti kui te ei võta tööle liiga palju uusi inimesi, tekib dilemma, mida nende rollidega peale hakata. Kas nad peaksid oma aega meeskondade vahel jagama? Kas peaksite palkama uusi inimesi, kes oleksid pühendunud ainult ühele meeskonnale? Kas nad peaksid tegema koostööd arendusmeeskondadega või kuuluma tootemeeskonda?

Selle jaoks pole tõesti üht head nõu, sest iga toode on nii erinev. Need otsused tehakse kõige paremini koos meeskonnaga, pidades meeles, et peate võib-olla teekonnal korrigeerima.

Kas meeskondadel peaks olema eraldi mahajäämus?

Kui meeskond jaguneb, on loomulik küsimus, kas neil peaks töötama sama mahajäämus või peaksid nad eraldi olema. Me võime vaadata Skaleeritud vilgas raamistik juhendamiseks.

[meiliga kaitstud]

[meiliga kaitstud] on Scrum Guide'i looja poolt välja töötatud metoodika. [meiliga kaitstud] ei ole eriti ettekirjutav ega anna konkreetset ülevaadet toodete mahajäämuse käsitlemisest. Selles märgitakse siiski kahte punkti:

• Meeskonnatasandi protsess on sama, mis on sätestatud Scrumi juhendis.
• Tooteomanikud moodustavad tooteomanike meeskonna, kus nad loovad ühe ühtse mahajäämuse. Seda tehakse töö dubleerimise vältimiseks ja ettevõttes nähtavuse loomiseks. Samal ajal on meeskondadel eraldi mahajäämused, mis toidavad ühtse mahajäämusest üksusi.

Nii et sisuliselt [meiliga kaitstud] pildistab uusi meeskondi oma vastavate tootjate ja mahajäämustega. See lihtsalt lisab meeskondade vahelise töö koordineerimiseks mõned täiendavad struktuurid. [meiliga kaitstud] töötab kõige paremini mitme, kümne või saja meeskonnaga, kuid see võib anda väärtuslikku teavet isegi siis, kui töötate kahe meeskonnaga.

Suuremahuline kaal (LeSS)

LeSS reklaamib huvitavat lähenemist toodete mahajäämusele. LeSSis töötab tooteomanik kahe kuni kaheksa meeskonnaga. Võib tunduda võimatu, kui üks PO teeb koostööd nii paljude meeskondadega. LeSSi filosoofia on see, et PO töötab abstraktsel tasemel ja delegeerib meeskondadele toote mahajäämuse üksuste täiustamise kohustused. Sel juhul peaksid funktsionaalsed arendusmeeskonnad sisaldama ka ärivaldkonna teadmisi, et oleks võimalik toote juurdekasvu pakkuda. LeSS-is on ainult üks mahajäämus.

Kuidas end kursis hoida

Tootejuhi jaoks tähendab mitu meeskonda rohkem tööd edusammude jälgimisel ja päringutele vastamisel.

mis on jõu puudutuse tehnoloogia

Pange prioriteediks koosolekud

Kui osalesite ühe meeskonna igapäevases skooris, on selle harjumuse jätkamine tõenäoliselt ebaproduktiivne. Mõelge igapäevasele skeemile kui võimalusele osaleda, et saada meeskondadest pulssi, ja tuletage neile meelde, et olete aruteludeks saadaval.

Teie osavõtt sprindi planeerimise sessioonidest sõltub meeskondade küpsusest. Kui meeskondades on palju värskeid nägusid või kui nad pole Agilega pikka aega töötanud, on vaja teie juhendamist. Isegi kui tunnete end meeskonnas ilma teie osalemiseta plaani andes kindla peale, veenduge, et küsimuste tekkimisel oleksite meeskonnale plaanitustööde ajal sisse logida või häälega vestelda.

Sprindi ülevaatused peavad jääma teie esmatähtsaks prioriteediks ja kõigil neist peaks osalema. Sprindi ülevaated on võimalus saada kõigilt praegustelt sidusrühmadelt ja meeskonnalt endalt tagasisidet. See on aeg, mil eeldused kinnitatakse ja seda ei tohiks mööda lasta.

Kaasake Scrum Mastersiga rohkem

Ehkki vähendate osalemist mõne scrum tseremooniaga, peaksite kahekordistama oma partnerlust scrum masteriga. Pärast meeskonna jagunemist võib neid olla rohkem kui üks, sellisel juhul peaksite nendega kõigiga tihedat koostööd tegema.

Veenduge, et saaksite neid usaldada, et anda aus ülevaade meeskonna edusammudest ja sprintide ajal tekkivatest probleemidest. Need suhted võimaldavad teil end kursis hoida, ilma et oleks vaja osaleda kõigis tseremooniates.

Tutvustage Scrum of Scrums

Mõnikord nimetatakse meta scrumiks, scrum of scrums on uus tseremoonia, mida tavaliselt tutvustatakse scrum protsesside skaalana. See on kõrgema taseme igapäevase koputuse koopia. Iga meeskond määrab suursaadiku, kes kõik kohtuvad iga päev tõrjumaja juures, et arutada edusamme ja takistusi. Seda tseremooniat kasutatakse ka meeskondadevaheliste tehniliste probleemide esiletoomiseks, mis võivad vajada lahendamist.

Kaaluge tootemeeskonna laiendamist

Kui teie scrumi seadistamine nõuab tootejuhilt meeskonnaga aktiivset suhtlemist, kaaluge tootepoolele veel inimeste lisamist. Sellele lähenemiseks on paar viisi.

Nooremad tootejuhid. Üks võimalus on võtta enda jaoks strateegilisem roll, lisades samal ajal nooremate tootejuhid mõne igapäevase tööga toime tulema. Nad võiksid võtta mõned ülesanded, näiteks kvaliteedi tagamine (QA), kasutajalugude spetsifikatsioonide kirjutamine või uute funktsioonide jaoks kõrgetasemeliste makettide loomine.

Ärianalüütikud. Teine võimalus on lasta üks või mitu ärianalüütikut töötada meeskondades või nende kõrval. Tootejuht saab teha koostööd ärianalüütikutega, et tuvastada toote eeldused ja lasta seejärel ärianalüütikutel leida võimalusi nende kinnitamiseks kas uuringute või uute funktsioonide abil.

Järeldus

Kui teie meeskond kasvab, hakkate tõenäoliselt märkama mõningaid märke selle kohta, et see on liiga suur, eriti järgmistes valdkondades:

• Igapäevane rämps. Kui ületate igapäevaste vaatluste ajal 15-minutilise ajakava ja näete, et inimesed hakkavad huvi kaotama.
• Sprindi planeerimine. Kui jõuate sprindi planeerimise käigus üha sagedamini ummikusse.
• Tagantjärele. Kui hakkate märkama, et tagantjärele on üha raskem kompromissidele jõuda.

Kõik need viitavad asjaolule, et teil võib olla vaja meeskonda jagada. Meeskonna jagamine on pealtnäha lihtne ülesanne, kuid sellel on ka püsivad tagajärjed ja igal tootejuhil on seda tehes arvestada mõne asjaga:

• Meeskonna moraal. Ideaalis peaksite laskma meeskonnal otsustada, kuidas nad soovivad lahku minna, et minimeerida lammutatud heade töösuhete arvu.
• Funktsionaalsed meeskonnad. Võistkondadel peaksid olema kõik toote juurdekasvu loomiseks vajalikud oskused.
• Toote mahajäämus. Otsustage, kas teie meeskondadel on eraldi või üks ühtne mahajäämus.

Kahe või enama meeskonna jälgimine nõuab prioriteetsust. Tõhus tootejuht peaks kavandama, kuidas nad uute meeskondadega kursis püsivad:

• Pange kokkusaamised tähtsuse järjekorda. Mõelge läbi, millised agiilsed tseremooniad on teie aega väärt ja mida saab ignoreerida.
• Tehke koostööd scrum-meistridega. Kasutage oma meeskonna volikirjana scrumi meistreid ja koguge neilt teavet.
• Laiendage tootemeeskonda. Lisage inimesi teiega töötama ja aidake igapäevaste korduvate ülesannete täitmisel või viige läbi kasutajauuringuid ja turuanalüüse.

Neid soovitusi kasutades peaksite saama meeskonna puhta jaotuse. Kui teie meeskonnad pidevalt kasvavad ja lisate tulevikus veelgi rohkem meeskondi, peaksite sellest lugema Skaleeritud vilgas raamistik , mis pakub Agile'i mastaapset struktuuri ja protsessi ettepanekuid.

Põhitõdede mõistmine

Mitu arendajat on scrumi meeskonnas?

Scrumi juhendi järgi peaks arendusmeeskond olema kolme kuni üheksa inimese vahel ning tal peaks olema kõik toodete osade edastamiseks vajalikud oskused. Arendajate arv on tavaliselt dikteeritud toote vajaduste järgi ja tavaliselt jääb see scrumi meeskonnas kahe kuni viie arendaja vahele.

Kes on scrumi meeskonna liikmed?

Scrumi meeskond on funktsionaalne ja hõlmab kõiki inimesi, kes on vajalikud toote juurdekasvu edastamiseks. Enamikul scrumi meeskondadel on spetsiaalne tooteomanik ja scrum master. Ülejäänud meeskonda võivad kuuluda arendajad, disainerid, testijad või analüütikud.

Mis on hea scrumi meeskond?

Hea scrum-meeskond on funktsionaalne ja omab kõiki oskusi, mis on vajalikud toote juurdekasvu loomiseks. See peaks hõlmama arendajaid, disainereid, testijaid, analüütikuid jne.

Mis on scrumi meeskonna soovitatav suurus?

Scrum Guide soovitab, et ühes meeskonnas oleks kolm kuni üheksa meeskonnaliiget.