Mga proseso sa Scrum

Pagpaplano ng sprint

Ang pagpaplano ng sprint ay ang unang yugto sa Scrum sprint. Tinutukoy nito ang saklaw at mga paraan ng paggawa sa panahon ng sprint. Ang buong koponan ng Scrum ay kasangkot sa pagpaplano.

Ang isang sprint ay isang malinaw na tinukoy na yugto ng panahon kung saan ang isang tinukoy na piraso ng trabaho ay dapat makumpleto. Ang isang sprint ay nangangailangan ng pagpaplano bago ito magsimula. Una sa lahat, kailangan mong matukoy ang tagal at layunin ng sprint.

Sa planning workshop, ang listahan ng mga gawain at ang layunin ng sprint ay napagkasunduan. Mahalagang singilin ang koponan ng tamang motibasyon na magtrabaho, upang ang bawat miyembro ay nakatuon sa tagumpay.

Kung ang sprint ay hindi maganda ang plano, maaari itong humantong sa kabiguan ng koponan. Ang mga developer ay hindi makayanan ang mga inaasahan na inilagay sa kanila, dahil ang mga gawain ay naging hindi makatotohanan.

Mga tanong na dapat isaalang-alang kapag nagpaplano ng sprint:

• Inanunsyo ng customer o may-ari ng software ang layunin ng sprint, habang ipinapaliwanag kung paano ito makakamit. Nalaman ng koponan ng Scrum kung anong mga gawain ang maaaring kumpletuhin sa isang sprint sa hinaharap upang makamit ang layuning ito.
• Ang mga developer ay namamahagi ng isang plano sa trabaho sa kanilang mga sarili, na sumang-ayon sa customer ng software.
• Ang customer (may-ari) ng produkto ay palaging nakikibahagi sa pagbuo ng sprint plan. Nagtatakda siya ng isang layunin, at dapat malaman ng pangkat ng programming kung ito ay makakamit sa isang sprint.
• Ang plano ay dapat gumamit ng isang backlog ng produkto, impormasyon kung saan maaaring idagdag sa plano.
• Dapat tapusin ng mga miyembro ng pangkat ang pulong sa pagpaplano nang may malinaw na pag-unawa sa kung ano ang kailangan nila upang makamit ang resulta. Maaari mong ipakita ang pagkakasunud-sunod ng mga aksyon sa hinaharap sa sprint backlog.

Ang pagpaplano ay hindi dapat lumampas sa dalawang oras bawat linggo. Dapat ipaliwanag ng Scrum Master sa lahat na may mga limitasyon sa oras. Kung mabilis na naresolba ang lahat ng isyu sa trabaho, maaaring matapos ang pulong nang mas maaga kaysa karaniwan. Walang minimum na tagal para sa naturang pagpupulong.

Pagsusuri ng gawain

Ang pagtatasa sa pagiging kumplikado ng trabaho ay hindi kailangang lumampas. Ang proseso ng pagpaplano ay hindi nangangailangan ng eksaktong, ngunit hindi bababa sa isang tinatayang pagtatasa ng pagiging kumplikado ng pag-unlad. Ang koponan ay hindi lamang dapat maunawaan ang layunin ng sprint, ngunit ihambing din ang layunin sa mga kakayahan ng kanilang koponan.

Upang masuri ang pagiging kumplikado, maaari mong gamitin ang karaniwang laki ng damit para sa lahat (L, XL, XXL). Siyempre, hindi ito nagbibigay ng garantiya ng katumpakan, ngunit pa rin.

Upang maging mas tumpak ang pagtatasa ng pagiging kumplikado, kailangan ang pag-unawa sa isa't isa. Ang mga miyembro ng koponan ay dapat na hayagang magbahagi ng kanilang mga opinyon at huwag matakot na magtanong sa may-ari ng produkto.

Ang pagpuna sa koponan pagkatapos makumpleto ang trabaho ay maaaring humantong sa katotohanan na kapag nagpaplano ng susunod na sprint, ang mga pagtataya ay hindi gaanong maasahan. Makakatulong ito sa koponan na maiwasang maulit ang pagkakamali at maprotektahan ito mula sa negatibong pagtatasa sa hinaharap.

Pagsusuri ng kahirapan sa mga puntos, puntos at oras

Karaniwan, tinatantya ng mga development team ang pagiging kumplikado ng kanilang trabaho sa paglipas ng panahon. Ngunit pinipili ng ilang Agile team na i-rate ang kahirapan sa mga puntos o puntos. Ito ay isang mas mahusay na indikasyon ng kabuuang gastos na kinakailangan upang ipatupad ang isang backlog item o iba pang nakatalagang gawain.

Ang mga puntos ay iginawad batay sa pagiging kumplikado at dami ng trabaho. Bilang karagdagan, ang mga posibleng panganib ay isinasaalang-alang. Ang pagmamarka gamit ang paraang ito ay nakakatulong upang epektibong hatiin ang gawain sa maliliit na hakbang.

Sa pamamagitan ng regular na paggamit ng paraan ng pagmamarka (mga puntos) kapag nagpaplano, ang mga koponan ay may mas mahusay at mas tumpak na pag-unawa sa kung gaano karaming oras ang kakailanganin nila upang makumpleto ang gawain. Bilang karagdagan, mayroon ding iba pang mga pakinabang.

• Ang pagtatantya ng oras ay hindi isinasaalang-alang ang trabaho na hindi direktang nauugnay sa proyekto, bagama't tiyak na lilitaw ito. Pagtalakay sa mga isyu sa trabaho sa pamamagitan ng isang messenger, pagdaraos ng mga pagpupulong - lahat ng ito ay nangangailangan din ng oras para sa mga miyembro ng koponan.
• Ang mga emosyon ay maaaring makaimpluwensya sa pagpili ng mga petsa. Ang pagmamarka kapag sinusuri ang trabaho ay nag-aalis ng salik na ito.
• Ang pagtatasa ng pagiging kumplikado ng trabaho at, nang naaayon, ang bilis ng pagkumpleto ng mga gawain ay maaaring iba para sa bawat isa sa mga koponan. Ang pagtatrabaho sa mga puntos na ginawa ay hindi maituturing na anumang tagapagpahiwatig ng bilis. Ibig sabihin, walang psychological pressure sa team.
• Sa pamamagitan ng wastong pamamahagi ng mga gastos sa paggawa at pagiging kumplikado, maaari mong mabilis at walang salungatan na hatiin ang mga puntos para sa gawaing isinagawa sa pagitan ng mga kalahok.
• Ang bilang ng mga puntos na natanggap para sa pagkumpleto ng isang gawain ay nakasalalay sa pagiging kumplikado nito, at hindi sa oras na ginugol. Samakatuwid, iisipin ng mga programmer ang tungkol sa pagpapabuti ng kanilang kahusayan, at hindi tungkol sa kung gaano ito katagal.

Ang kawalan ng pagtatantya ng pagiging kumplikado ay madalas itong maling ginagamit. Halimbawa, ang pamamaraang ito ay hindi maaaring gamitin upang suriin ang mga empleyado.

Ang mga koponan ay dapat gumamit ng sistema ng pagmamarka upang mas maunawaan ang dami ng gawaing itinalaga sa kanila at mabigyang-priyoridad nang tama.

Araw-araw na Pagpupulong ng Scrum

Ang mga workshop ay mahalaga: sa kanila, ang mga miyembro ng pangkat ay nagbabahagi ng kanilang mga opinyon, nakikipag-usap at sumang-ayon sa mga karagdagang aksyon. Kailangan din ang mga pang-araw-araw na pagpupulong ng scrum upang itaas ang espiritu ng koponan at ipahayag ang kasalukuyang balita.

Ang stand-up ay isang maikling pulong ng mga pangunahing kalahok sa proyekto: ang may-ari ng software, mga programmer at scrum master. Ang istraktura ng stand-up ay binubuo ng tatlong katanungan.

• Ano ang nagawa natin kahapon?
• Ano ang ginagawa natin ngayon?
• Ano ang pumipigil sa atin na makamit ang mga resulta?

Ang pagtatanong sa mga tanong na ito ay nagpapasigla sa pag-unlad at nakakatulong na matukoy ang mga problema sa loob ng pangkat. Kapag ang bawat kalahok ay nakikipag-usap kung paano siya tumutulong upang makamit ang isang karaniwang layunin, ito ay nagpapabuti sa pagkakaunawaan sa isa't isa sa loob ng koponan.

Mahalagang tandaan na walang iisang template para sa kung paano magsagawa ng mga stand-up. Ang bawat koponan ay nagdaraos ng mga pagpupulong ayon sa sarili nitong modelo, batay sa mga katangian ng pangkat.

At ngayon talakayin natin kung ano ang kailangan para sa perpektong stand-up at pamilyar sa mga halimbawa ng epektibong stand-up.

Una kailangan mong pumili ng oras na nababagay sa lahat. Karaniwan ang mga stand-up para sa mga koponan mula sa parehong opisina ay gaganapin sa simula ng araw ng trabaho - sa pagitan ng 9 at 10 ng umaga. Nagbibigay ito sa iyo ng oras upang mas mahusay na planuhin ang iyong iskedyul para sa araw. Kung nagtatrabaho ang mga miyembro ng koponan sa iba't ibang rehiyon, pipiliin ang isang oras na nababagay sa lahat. Halimbawa, kung nakatira ang ilang miyembro ng team sa California at Sydney, magsisimula ang stand-up sa 15:30 oras ng California. Siyempre, ang stand-up pagkatapos ng hapunan ay hindi maginhawa para sa lahat, ngunit ginagawang posible na makipag-ugnay sa mga kasamahan sa kabilang panig ng karagatan.

Subaybayan ang stand-up productivity. Huwag hawakan ang pulong nang masyadong mahaba - ang konsentrasyon ng atensyon ay dapat manatili sa pinakamainam nito. Kung maaari, humawak ng stand-up nang hindi hihigit sa 15 minuto.

Gamitin ang bola. Maaari itong ihagis sa isa't isa. Kaya lahat ay magiging kasangkot sa talakayan. Ang larong ito ay nakakatulong upang mapanatili ang atensyon sa grupo. Gumamit ng team retrospective. Ang mga stand-up ay ginagamit sa maraming Agile methodologies, hindi ito pumipigil sa amin na talakayin ang pagiging epektibo ng mga stand-up sa retrospectives. May nagkikita araw-araw, ibang mga koponan - ilang beses sa isang linggo. Kung mahirap para sa koponan na makinabang mula sa stand-up, hanapin ang mga dahilan para dito at baguhin ang isang bagay.

Pagsusuri ng Sprint

Ang pagsusuri sa tagsibol ay isinasagawa sa huling yugto ng sprint. Kinakailangang suriin ang pagtaas ng produkto at iangkop ang backlog. Ang buong scrum team at lahat ng stakeholder ay lumahok sa pagsusuri ng mga resulta ng sprint. Ang pulong ay gaganapin sa isang nakakarelaks na format upang mapabuti ang pakikipag-ugnayan ng mga kalahok sa proyekto.

Kasama sa Pagsusuri ng Mga Resulta ng Sprint ang mga sumusunod na elemento:

• Ipinapakita ng may-ari ng software kung ano ang nakumpleto mula sa backlog at kung ano ang hindi.
• Tinatalakay ng mga programmer kung ano ang naging maayos, kung saan lumitaw ang mga paghihirap, at kung paano sila naalis.
• Ipinapakita ng development team ang mga resulta ng kanilang trabaho sa panahon ng sprint, at kung anong pagtaas ng produkto ang kanilang natanggap.
• Ibinahagi ng May-ari ng Produkto ang kanyang mga saloobin sa kasalukuyang backlog. Nagbibigay din ito ng pagtataya para sa susunod na layunin at ang deadline para sa pagpapatupad nito.
• Tinatalakay ng lahat kung ano ang pinakamahusay na susunod na gawin batay sa pagtatasa sa merkado at mga interes ng gumagamit.
• Mayroong pagpapalitan ng mga pananaw sa timing, badyet at mga prospect para sa pagdaragdag sa backlog.

Ang resulta ay isang na-update na backlog na may mga bagong layunin para sa mga kasunod na sprint. Maaaring baguhin ang backlog kung kinakailangan ito ng sitwasyon.

Sprint Retrospective

Ang Sprint Retrospective ay isang workshop na tumatalakay kung paano pahusayin ang iyong workflow. Lumilikha din ito ng plano sa pagpapabuti para sa susunod na sprint. Karaniwang nagaganap ang pulong pagkatapos ng sprint review at hindi hihigit sa tatlong oras. Nangunguna sa pulong ang Scrum Master.

Ang mga pangunahing layunin ng Sprint Retrospective ay kinabibilangan ng:

• Pagsusuri ng Sprint (gawa ng mga kalahok, mga resulta at mga problema).
• Talakayin ang mga posibleng solusyon upang mapabuti ang daloy ng trabaho sa mga susunod na sprint.
• Paglikha ng isang plano para sa pagpapatupad ng mga pagpapabuti ng mga miyembro ng koponan sa panahon ng pagpapatupad ng proyekto.

Iniimbitahan ng Scrum Master ang mga miyembro ng koponan na gumawa ng mga mungkahi kung paano pagbutihin ang kahusayan sa pag-unlad. Tinatalakay ng pangkat ang mga panukala at nagmumungkahi ng ilang mga paraan at pamamaraan para sa kanilang pagpapatupad.

Sa pagtatapos ng Sprint Retrospective, dapat i-highlight ng team ang ilang mungkahi sa pagpapahusay na ipapatupad sa susunod na sprint. Maaaring ipatupad ang mga suhestyon anumang oras, ngunit ang Sprint Retrospective ay nagbibigay ng pagkakataon na tingnan nang mas malalim ang kanilang posibleng adaptasyon mula sa pananaw ng koponan.

Dito namin tinatapos ang aming pagtalakay sa pamamaraan ng Scrum. Maaari kang matuto nang higit pa tungkol dito sa thematic na dokumentasyon o sa iyong unang lugar ng trabaho.