Nagtatrabaho sa Scrum

Kwento ng Gumagamit

Ang mga kwento ng gumagamit ay isang epektibong paraan upang ipahayag ang mga kinakailangan para sa software sa pagbuo. Ang mga nasabing kwento ay naglalaman ng maikling payo sa ngalan ng gumagamit ng software.

Dahil sa pamamaraan ng Scrum, ang pagtatakda ng mga layunin ay karaniwang prerogative ng customer o may-ari ng software, sila ay itinuturing na pangunahing paraan upang maimpluwensyahan ang proseso ng pagbuo. Ang bawat Kwento ng Gumagamit ay may limitasyon sa dami ng teksto at ang pagiging kumplikado ng presentasyon. Ang kasaysayan ay madalas na nakasulat sa isang maliit na sheet, na sa sarili nitong nililimitahan ang lakas ng tunog.

Salamat sa mga kwento ng gumagamit, maaari mong idokumento ang mga kagustuhan ng kliyente at mabilis na tumugon sa mga kahilingan sa merkado.

Ang Kwento ng Gumagamit ay dapat ituring na isang simplistic na sukatan ng mga kinakailangan dahil wala itong kasamang pamamaraan ng pagsubok sa pagtanggap. Ang compilation ng user story ay dapat sumunod sa admission procedure. Titiyakin nito na makakamit ng Kwento ng User ang layunin nito.

Ganito ang hitsura ng istraktura ng kuwento: “Bilang isang user <uri ng user>, gusto kong magsagawa ng <action> para makakuha ng <result>" (Bilang may-ari ng produkto gusto ko ...). Ang ganitong istraktura ay hindi lamang simple, ngunit naiintindihan din ng lahat.

Mga pakinabang ng paggamit ng Mga Kwento ng User:

• Ang mga kwento ay maliit at madaling gawin.
• Tulungan ang lahat ng stakeholder na talakayin ang gawain sa proyekto at suporta nito.
• Hindi nangangailangan ng patuloy na pagpapanatili.
• May kaugnayan lamang kapag ginamit.
• Pagbutihin ang pakikipag-ugnayan sa kliyente.
• Salamat sa kanila, maaari mong hatiin ang proyekto sa maliliit na yugto.
• Pangasiwaan ang trabaho sa mga proyektong hindi gaanong nauunawaan ang mga kinakailangan.
• Pasimplehin ang pagsusuri ng gawain.

Mga Disadvantage ng Mga Kwento ng Gumagamit:

• Kung walang paunang kasunduan, ang mga pamamaraan ay maaaring maging mahirap na gamitin bilang batayan para sa isang kasunduan.
• Ang kanilang paggamit ay nangangailangan ng malapit na pakikipag-ugnayan sa kliyente sa buong proyekto, na kung minsan ay nagpapahirap sa daloy ng trabaho.
• Mayroon silang mga disadvantages kapag nag-scale sa malalaking proyekto.
• Direktang nauugnay sa antas ng propesyonal ng mga developer.
• Ginagamit upang simulan ang isang talakayan, ngunit maaaring hindi tapusin ang isang talakayan, at hindi ginagamit para sa dokumentasyon ng system.

Backlog

Ang backlog ng produkto ay ang kasalukuyang mga gawain sa anyo ng isang listahan, na pinagsama-sama sa pagkakasunud-sunod ng priyoridad. Ang listahan ay nabuo batay sa roadmap (roadmap) ng proyekto at ang mga puntong itinakda dito. Ang pinakamahalagang gawain ay karaniwang nasa tuktok ng listahan. Ito ay kinakailangan upang maunawaan kung aling trabaho ang dapat gawin muna.

Pinipili ng development team ang bilis ng pagkumpleto ng mga backlog task anuman ang kagustuhan ng customer, ngunit batay sa kanilang mga kwalipikasyon at karanasan mula sa mga nakaraang sprint. Lubhang hindi kanais-nais na "ayusin" ang mga programmer. Ang koponan mismo ang pumipili ng mga gawain mula sa backlog ayon sa sarili nitong mga pagsasaalang-alang at kakayahan. Nagaganap ang pagpapatupad nang walang pagkaantala (Kanban) o ilang mga pag-ulit (Scrum).

Dalawang mahalagang backlog na kondisyon

Ang core ng isang backlog ng produkto ay binubuo ng isang roadmap, mga panukala, at mga kondisyon sa pagpapatupad. Ang mga epiko ay naglalaman ng mga kundisyon at Kwento ng User. Tingnan natin ang isang tipikal na halimbawa ng roadmap.

Ang paglikha ng website na "Mga Koponan sa Kalawakan" ay ang unang panukala mula sa roadmap. Kailangan itong hatiin sa mga epiko (sa figure na ipinapakita ang mga ito sa berde, asul at turkesa na kulay) at isang Kwento ng Gumagamit para sa bawat epiko.

Ang customer ng software ay bumubuo ng isang listahan mula sa ilang Kwento ng User. Kung kinakailangan, maaari niyang baguhin ang pagkakasunud-sunod kung saan isinagawa ang mga kuwento, upang harapin muna ng mga developer ang isa sa pinakamahalagang epiko (kaliwa) o tingnan kung paano gumagana ang may diskwentong pagpapareserba ng tiket. Upang gawin ito, kailangan mong ipatupad ang mga kuwento mula sa mga epiko (kanan). Ang parehong mga pagpipilian ay makikita sa ibaba.

Batay sa anong mga kadahilanan ang dapat unahin ng customer?

• Kaugnayan sa mga gumagamit.
• Ang pagkakaroon ng feedback.
• Pagiging kumplikado ng pag-unlad.
• Ang ugnayan sa pagitan ng mga gawain (upang makumpleto ang "B", kailangan mo munang gawin ang "A").

Ang mga priyoridad sa trabaho ay tinutukoy ng customer, ngunit maaaring ipahayag ng ibang mga partido ang kanilang opinyon tungkol dito. Ang tagumpay ng backlog ay nakasalalay, bukod sa iba pang mga bagay, sa mga opinyon ng mga customer at programmer. Magkasama, makakamit nila ang mas mahusay na mga resulta at matiyak ang napapanahong paghahatid ng tapos na produkto.

Paano panatilihin ang isang backlog

Kung ang backlog ay nalikha na, pagkatapos ay kailangan mong pana-panahong baguhin ito sa kurso ng karagdagang trabaho. Dapat tiyakin ng customer ng software na ang backlog ay maayos na naipon bago ang bawat bagong pagpaplano ng pag-ulit. Makakatulong ito na linawin ang mga priyoridad o baguhin ang isang bagay pagkatapos ng pagsusuri sa huling pag-ulit. Ang pagsasaayos ng backlog sa Agile ay kung minsan ay tinatawag na "grooming" o "refinement" o "backlog maintenance".

Kung ang backlog ay medyo malaki na, kailangan ng customer na pangkatin ang mga gawain sa pamamagitan ng panandalian at pangmatagalang pagpapatupad. Ang mga panandaliang takdang-aralin ay dapat suriing mabuti bago sila ibigay sa katayuang ito. Kailangan mong gumawa ng isang Kwento ng Gumagamit, alamin ang lahat ng mga nuances sa loob ng koponan.

Tulad ng para sa mga pangmatagalang gawain, lubos na kanais-nais na bigyan sila ng mga developer ng kanilang pagtatasa. Mapapadali nito ang pag-prioritize. Marahil ay may magbabago, ngunit pagbutihin ng pangkat ang kanilang pag-unawa sa mga gawain at mas mabilis na matapos ang trabaho.

Ang backlog ay isang mahalagang bahagi sa pagitan ng customer at ng programming team. Maaaring palaging baguhin ng customer ang mga priyoridad batay sa feedback ng customer, mga hula, o mga bagong kinakailangan.

Inirerekomenda na maiwasan ang direktang paggawa ng mga pagbabago sa panahon ng operasyon. Ito ay may masamang epekto sa daloy ng trabaho at emosyonal na estado ng mga programmer.

Sprint

Ang sprint ay isang maikling panahon kung saan ang dating napagkasunduang dami ng trabaho ay dapat makumpleto. Ang mga sprint ay batay sa mga pamamaraan ng Scrum at Agile. Ang pagpili ng mga tamang sprint ay nakakatulong sa isang maliksi na koponan na bumuo ng de-kalidad na software.

"Gamit ang Scrum, maaari kang bumuo ng isang produkto sa ilang mga pag-ulit na may malinaw na tagal - mga sprint. Nakakatulong ito na hatiin ang malalaking proyekto sa mas maliliit na gawain,” sabi ni Megan Cook, Jira Lead sa Atlassian.

Paano nagpaplano at nagsasagawa ng mga sprint ang Scrum?

Ayon sa mga may-akda ng pamamaraan ng Scrum, upang maplano ang hinaharap na sprint, kailangan ng lahat na magkita sa isang hiwalay na pulong. Sa kaganapang ito, dapat mahanap ng mga miyembro ng koponan ang mga sagot sa dalawang pangunahing tanong: ano ang kailangang gawin sa sprint na ito at kung paano ito pinakamahusay na gawin?

Ang software customer, Scrum master at programmer ay kasangkot sa pagtukoy sa listahan ng mga gawain sa trabaho. Ipinapaliwanag ng customer ang layunin ng sprint at mga gawain mula sa backlog.

Pagkatapos ang koponan ay bumuo ng isang plano ayon sa kung saan ang mga gawain sa sprint ay makukumpleto. Ang planong ito, kasama ang mga napiling item sa trabaho, ay tinatawag na sprint backlog. Pagkatapos ng pagpupulong sa pagpaplano, ang pangkat ay magtatrabaho. Pinipili ng mga developer ang mga gawain mula sa backlog, habang nakumpleto ang gawain, ang katayuan ng bawat gawain ay nagbabago mula sa "Isinasagawa" patungong "Tapos na".

Sa panahon ng sprint, ang koponan ay nagsasagawa ng pang-araw-araw na pagpupulong ng Scrum (mga stand-up) upang talakayin ang mga kasalukuyang isyu at pag-unlad. Ang ganitong mga pagpupulong ay kinakailangan upang matukoy ang mga paghihirap na maaaring makaapekto sa pagkumpleto ng sprint.

Kung nakumpleto ang sprint, ipapakita ng koponan ang mga resulta ng kanilang trabaho sa pagsusuri ng mga resulta (demo). Ang bawat kalahok ng proyekto ay maaaring maging pamilyar sa mga resulta. Dapat gawin ang pamilyarisasyon bago isama ang natapos na code sa kapaligiran ng produksyon.

Kinukumpleto ng retrospective ang ikot ng mga sprint. Dito, tinutukoy ng koponan ang mga lugar na kailangang pagbutihin sa isang sprint sa hinaharap.

Ano ang dapat bigyang pansin at kung ano ang hindi dapat gawin

Karamihan sa mga batang koponan ay nahihirapang magpakilala ng mga sprint sa kanilang daloy ng trabaho sa unang pagkakataon. Upang maiwasan ang mga problema, inirerekomenda naming suriin mo ang listahan ng mga aksyon na nangangailangan ng priyoridad na atensyon.

Ano ang kailangan nating gawin:

• Tingnan kung nauunawaan ng koponan ang layunin ng sprint at kung paano ito magtatagumpay. Ito ay kinakailangan para sa bawat isa upang lumipat patungo sa isang matagumpay na resulta nang sama-sama.
• Dapat ay mayroon kang malinaw at nauunawaang backlog. Kung ang backlog ay hindi napanatili nang tama, maaari itong maging isang problema na maaaring makapinsala sa daloy ng trabaho.
• Tiyaking tama ang iyong pagtatantya sa bilis ng trabaho, na isinasaalang-alang ang mga holiday sa tag-araw at iba pang mga kadahilanan.
• Aktibong lumahok sa pagpaplano ng sprint. Hikayatin ang mga miyembro ng team na palawakin ang plano para sa mga kwento, bug, at takdang-aralin.
• Tanggihan ang mga gawain kung saan hindi malulutas ng mga developer ang mga isyu sa dependency.
• Pagkatapos maaprubahan ang plano, magtalaga ng isang empleyado na magiging responsable sa pagpasok ng data sa programa ng pamamahala ng proyekto (Jira card, atbp.).

Ano ang dapat iwasan:

• Huwag gumamit nang labis ng isang malaking bilang ng mga kuwento, maingat na suriin ang bilis ng trabaho at huwag magtalaga ng mga gawain na mahirap makumpleto sa isang sprint.
• Maging maingat sa kalidad ng iyong trabaho. Suriin kung mayroon kang sapat na oras para sa kontrol sa kalidad at pag-aayos ng mga bug sa code.
• Tiyaking malinaw na nauunawaan ng lahat ng miyembro ng koponan ang nilalaman ng sprint. Wag mong habulin ang bilis. Ang buong koponan ay dapat kumilos nang sama-sama.
• Huwag pabigatin ang mga developer ng dagdag na trabaho. Malapit na ang isa pang sprint.
• Kung ang pangkat ay nagpahayag ng pag-aalala tungkol sa workload o ang deadline, dapat mong isaalang-alang ang kanilang opinyon. Harapin ang mga problema at itama ang mga ito kung kinakailangan.

scrum board

Ang Scrum Board ay isang tool na nagpapakita kung paano ginagawa ang gawain ng Scrum Team. Maaari kang magpakita ng impormasyon sa naturang board sa papel, sa dingding o sa electronic form (JIRA, Trello).

Ang isang Scrum board ay may hindi bababa sa tatlong column: Gagawin, Kasalukuyang Isinasagawa, at Tapos na. Narito ang isang halimbawang board:

Ang Scrum board ay naglalaman ng lahat ng impormasyon mula sa backlog, na dating naaprubahan para sa pagpaplano. Bilang panuntunan, ang mga business task card ay naka-pin sa board ayon sa priyoridad mula sa itaas hanggang sa ibaba. Maaari mong hatiin ang mga ito sa mga partikular na uri ng trabaho (trabaho sa code, disenyo, at iba pa).

Matapos makumpleto ang bahagi ng gawain, ang card ay ililipat sa buong pisara sa susunod na hanay. Para ipakita ang visibility ng pag-usad ng trabaho ng team, nakakatulong ang "natitirang gawain" sa araw sa Burndown Chart.

Maaari ka ring gumamit ng flipchart board. Dito, ang mga pangalan ng mga gawa ay nakasulat sa mga sticker ng papel at nakakabit sa board. Sa sandaling makumpleto ang trabaho, ang mga sticker ay inilipat sa isa pang column.

tsart ng pagkasunog

Ipinapakita ng burndown chart ang dami ng gawaing ginawa at ang dami ng natitirang trabaho. Ito ay ina-update araw-araw at magagamit sa lahat ng mga interesadong partido. Ang graph ay kailangan upang ipakita ang pag-unlad sa gawain sa sprint.

Mayroong dalawang uri ng mga tsart:

• Burndown chart na nagpapakita ng progreso ng trabaho sa isang sprint.
• Burndown chart na nagpapakita ng progreso ng trabaho hanggang sa paglabas ng produkto (ang data ay ibinubuod mula sa ilang mga sprint).

Halimbawa ng tsart:

Ang halimbawang ito ay gumagamit ng sikolohiya: hindi ipinapakita ng tsart ang bilang ng mga natapos na gawain, ngunit ang bilang ng natitira (hindi tapos).

Iyon ay, kung ang koponan ay nakagawa ng 90 mga gawain sa 100, kung gayon maaaring mayroong maling pakiramdam na handa na ang lahat. Pagkatapos ng lahat, ang pag-unlad mula 90 hanggang 100 na gawain ay hindi talaga nagbabago ng anuman.

Kung ipapakita mo ang bilang ng mga natitirang gawain, hindi mo maaaring maiwasang mapansin kung paano sa bawat oras na sila ay nagiging mas kaunti. Ito ay hindi sinasadya na nag-uudyok sa mga kalahok sa proyekto na mas mabilis na makamit ang layunin - hindi dapat magkaroon ng mga hindi natapos na gawain sa board.