Mipango ya sprint: mbinu bora za Agile

Misingi ya upangaji

Upangaji mzuri wa sprint unahitaji utaratibu: kuchambua sprints zilizopita, kupima timu inaweza kubeba kiasi gani, na kufafanua malengo waziwazi. Maelezo zaidi: Programu ya Usimamizi wa Miradi ya IT kwa Timu za IT.

1. Maandalizi ya upangaji yanapaswa kuanza mapema. Product Owner huandaa backlog na kupanga vipaumbele vyake angalau siku moja kabla ya mkutano. Timu ya maendeleo inahitaji nafasi ya kusoma user story mapema na kuuliza maswali ya kufafanua.
2. Kanuni ya kawaida ya mgawanyo: saa mbili za upangaji kwa kila wiki ya sprint. Kwa sprint ya wiki mbili, hiyo ni saa nne — ingawa mara nyingi ni bora kuugawa muda huu katika vikao kadhaa vifupi badala ya mkutano mmoja mrefu.

Awamu ya maandalizi

Bila maandalizi mazuri, upangaji wa sprint hauwezi kuboreka. Awamu hii mara nyingi hupuuzwa na timu nyingi. Hata hivyo ndiyo huamua kama mchakato mzima wa upangaji utafanikiwa au la.

• Definition of Ready (DoR) huweka vigezo ambavyo user story lazima ivitimize kabla ya kuingizwa katika sprint. Kila hadithi inapaswa kuwa na vigezo wazi vya kukubalika, makadirio ya utata, na utegemezi wake kwa kazi nyingine uliotambuliwa tayari. DoR isipofuatwa, upangaji huvurugika na timu hutumia muda kufafanua hadithi badala ya kupanga utekelezaji.
• Backlog refinement inapaswa kufanyika mara kwa mara, sio tu kabla ya upangaji wa sprint. Kutenga 10% ya muda wa sprint kwa kazi hii ni desturi ya kawaida. Timu inaweza kufanya vikao vifupi vya refinement mara kadhaa kwa wiki na kuandaa kidogo kidogo hadithi za sprints zijazo.
• Uchambuzi wa Velocity huipa timu picha sahihi ya kiasi inachoweza kuwasilisha kweli. Velocity ya wastani ya sprints 3-5 zilizopita ina uzito, lakini pia mambo yanayoweza kugusa tija katika sprint ijayo: likizo zilizopangwa, sikukuu, deni la kiufundi lililolimbikizwa, au utegemezi wa nje.

Vikao vya upangaji

Upangaji wa sprint una awamu mbili. Kwanza timu huamua nini kitawasilishwa katika sprint, kisha jinsi kazi iliyochaguliwa itakavyotekelezwa. Kila awamu inahitaji pembejeo tofauti na hutoa matokeo tofauti — ukizichanganya, zote mbili hudhoofika.

1. Timu, pamoja na Product Owner, hufafanua lengo la sprint linalounganisha user story zote zilizochaguliwa. Lengo linapaswa kuwa mahususi, linaloweza kupimwa, na lenye maana kwa kila mshiriki. Lengo dhaifu: "Boresha uzoefu wa mtumiaji." Lengo zuri: "Watumiaji wataweza kujisajili kupitia mitandao ya kijamii kwa bonyeo moja."
2. Timu ya maendeleo hugawa hadithi zilizochaguliwa katika kazi na kuzikadiria kwa saa. Hapa ndipo utata na utegemezi uliojificha, usioonekana katika kiwango cha hadithi, hujitokeza. Hakuna kazi inayopaswa kuchukua zaidi ya saa 8 — kazi ndefu zaidi hugawanywa tena kuwa kazi ndogo.

Majukumu na wajibu

Upangaji wa sprint hufanikiwa pale kila mshiriki anapoelewa jukumu lake na kubaki ndani yake.

• Scrum Master huendesha mchakato, husimamia mipaka ya muda, na husaidia timu kufikia maamuzi. Scrum Master halazimishi suluhisho lake mwenyewe. Badala yake huuliza maswali sahihi na kuweka majadiliano kwenye mambo ya msingi.
• Product Owner anawajibika kwa vipaumbele vya backlog na kwa kuamua vipengele vipi vitekelezwe kwanza. Lazima aweze kueleza thamani ya kibiashara ya kila hadithi na kujibu maswali ya timu ya maendeleo kwa undani wa kutosha ili makadirio yawezekane.
• Timu ya maendeleo hujifunga kuwasilisha matokeo. Ahadi hii lazima itoke kwa timu yenyewe, isipewe kutoka nje — ahadi ambayo timu imejiwekea huleta motisha na uwajibikaji wa aina tofauti kabisa na malengo yaliyolazimishwa.

Makosa ya kawaida

• Kukadiria uwezo kupita kiasi ni kosa la mara kwa mara la upangaji wa sprint. Timu mara kwa mara huchukua kazi nyingi kuliko zinavyoweza kumaliza, hasa mwanzoni mwa mradi au baada ya sprint iliyofanikiwa. Kanuni ya vitendo ni kuahidi kidogo na kuwasilisha zaidi. Ahadi zisizotimizwa hudhoofisha imani ya wadau na hushusha motisha ya timu katika sprints zinazofuata.
• Kutokuwepo kwa bafa za muda ni kosa muhimu la kimuundo. Mpango wa sprint unapaswa kuacha 10-20% ya muda kama akiba kwa kazi zisizotarajiwa, hitilafu, na maombi ya msaada wa kiufundi. Akiba hii isijazwe mapema kwa hadithi za ziada — kazi yake ni kupokea kazi isiyopangwa inayojitokeza katika kila sprint.
• Kupuuza utegemezi huunda vizuizi katikati ya sprint. Utegemezi wote wa nje lazima utambuliwe na kutatuliwa wakati wa upangaji. Kazi ikitegemea timu nyingine au muuzaji wa nje, tarehe za mwisho hukubaliwa mapema na uthibitisho hupatikana kabla sprint haijaanza.

Ufuatiliaji wa mchakato

Katika Agile iliyokomaa, hata mchakato wa upangaji wenyewe huboreshwa kila wakati. Wakati wa retrospectives, timu inapaswa kuangalia matokeo ya sprint na, kando, ubora wa upangaji, ikiuchukulia kama pembejeo ya kujitegemea.

Vipimo vya uchambuzi:

• Usahihi wa makadirio — kulinganisha muda uliopangwa na muda halisi uliotumika kwa kila hadithi na kazi
• Asilimia ya hadithi zilizokamilika — sehemu ya hadithi zilizoahidiwa katika sprint ambazo ziliwasilishwa sprint ilipoisha
• Idadi ya mabadiliko katika sprint baada ya upangaji — kipimo cha jinsi mpango ulivyo thabiti na mahitaji yalivyo wazi
• Muda uliotumika katika upangaji — hulinganishwa na mgawanyo wa kawaida ili kuona kama muda unaowekezwa ni mwingi au mchache kupita kiasi mara kwa mara

Chati za Burndown hufuatilia maendeleo katika sprint nzima na huonyesha matatizo mapema, wakati bado kuna nafasi ya kurekebisha. Chati ikionyesha kwamba timu haitamaliza kazi iliyopangwa, hatua za kurekebisha zinahitajika mara moja. Timu hupanga upya vipaumbele vya kazi zilizobaki au huondoa kwenye sprint user story zenye kipaumbele cha chini zaidi.

Kuandaa upangaji

• Timu za mbali zinahitaji marekebisho maalum kwa upangaji wa sprint. Zinahitaji zana zinazofaa za ushirikiano, na kila mshiriki aliye mbali lazima apewe nafasi sawa ya kuchangia. Katika timu zilizotawanyika, vikao kadhaa vifupi badala ya mkutano mmoja mrefu kwa kawaida huleta ushiriki zaidi na matokeo bora.
• Programu kubwa zenye timu kadhaa zinahitaji uratibu katika kiwango cha programu. Scrum of Scrums au SAFe (Scaled Agile Framework) hutoa utaratibu wa kusawazisha upangaji wa sprint kati ya timu zinazotegemeana.
• Miradi ya matengenezo — ambapo sehemu kubwa ya sprint huenda kwenye msaada na kurekebisha hitilafu — inahitaji uwezo uliotengwa waziwazi kwa kazi isiyopangwa. Mgawanyo wa kawaida wa 30-50% ya uwezo wa sprint kwa kazi ya msaada, na sehemu iliyobaki kwa vipengele vipya, huzuia kushindwa kuwasilisha kunakotokea pale msaada unapochukuliwa kama gharama ya ziada badala ya uwezo uliopangwa.

Makala zinazohusiana:

Kwa mifumo ya usimamizi wa miradi na kusawazisha vikwazo, soma Pembetatu ya usimamizi wa miradi: Kusawazisha wigo, muda, na gharama.

Kwa muhtasari wa vitendo wa bao za Kanban na usimamizi wa mtiririko wa kazi wa kuona, soma Bao la Kanban ni nini? Mwongozo wa usimamizi wa mtiririko wa kazi wa kuona.

Kwa jinsi timu za Agile zinavyotumia personas kubaki karibu na mahitaji halisi ya watumiaji, soma Personas za Agile: Kuongeza maendeleo yanayoelekezwa kwa mtumiaji katika miradi ya Agile. Soma zaidi: Ubao wa Kanban.

Hitimisho

Kupanga sprint vizuri kunahitaji utaratibu na uboreshaji wa kila mara, unaofanywa kwa makusudi na sio baada ya mradi kwisha. Retrospectives ndizo chombo kilichopangwa cha kufanya hivyo. Humo timu huchambua matokeo ya sprint na pia maamuzi ya upangaji yaliyoyazaa. Hivyo upangaji wenyewe huingia katika mzunguko uleule wa uboreshaji ambao Agile hutumia katika kuendeleza bidhaa.