Panimula sa Scrum

Kasaysayan ng Scrum

Mula nang mailathala ang ulat ng "Managing the Development of Large Software Systems" ni Winston Royce noong 1970, marami ang sumubok na humanap ng pamamaraan na maaaring mag-alis ng mga disadvantages ng modelo ng pagpapaunlad ng Waterfall. Ang isang alternatibo sa "waterfall" ay ang Scrum method, na tatalakayin ngayon.

Nakuha ng Scrum ang pangalan nito noong 1986 mula sa gawa ni Takeuchi at Nonaki na The New Rules for New Product Development. Ang dokumentong ito ay nangangatwiran na ang pinakaepektibong paraan upang makamit ang layunin ay upang bigyan ang mga developer ng malinaw na plano ng pagkilos.

Noong 1995, lumitaw ang isa pang gabay, "Software Development with Scrum," ni Sutherland at Schweiber. Ilang beses nang na-update ang publikasyong ito. Ngayon ito ay itinuturing na pangunahing gabay para sa pagbuo ng pamamaraang ito. Ang kasalukuyang bersyon ng Scrum Guide ay naglalaman ng impormasyong na-update sa 2020.

Ang mga pangunahing probisyon ng Scrum Guide ay nagmumungkahi na ang template ng pamamahala ng proyekto ay dapat na nakabatay sa katotohanan na ang mga developer ay naghahatid ng tapos na produkto sa loob ng napagkasunduang time frame - mga sprint. Para sa matagumpay na pagpapatupad ng Scrum, inirerekomendang gumamit ng istraktura na binubuo ng ilang elemento: mga tungkulin, kaganapan, panuntunan, at artifact.

Mga tungkulin sa Scrum

Mayroong tatlong tungkulin sa Scrum, na lahat ay bumubuo ng isang koponan ng Scrum:

Ang customer ng produkto ng software ay ang pinakamahalagang tao sa proyekto, dahil siya lamang ang ganap na nakakaunawa sa halaga nito sa negosyo. Ipinapaliwanag ng customer ang mga pangangailangan ng mga gumagamit ng hinaharap na produkto sa mga developer, ngunit hindi siya mananagot para sa teknikal na bahagi ng proseso ng pag-unlad. Tinutukoy din ng customer ang priyoridad kapag lumilikha ng ilang partikular na elemento o function sa produkto.

Ang mga developer ay ipinagkatiwala sa pagpapatupad ng mga teknikal na gawain, ang cross-functionality na depende sa saklaw ng aplikasyon. Ang mga developer ay abala sa paglikha ng sprint backlog, pagsulat ng code, pag-angkop ng proyekto sa layunin ng sprint, at iba pang mga gawain.

Ang Scrum Master ay ang facilitator ng Scrum team. Nagbibigay ito ng tulong sa customer at mga developer. Sa madaling salita, ang Scrum Master ay abala sa pakikipag-usap sa pagitan ng mga hindi kasali sa proyekto at ng mga taong nagsusulat ng code. Minsan ang iba't ibang koponan ng mga coder sa parehong malaking kumpanya ay nakikipag-usap at nag-coordinate sa mga pangkalahatang pagpupulong ng mga scrum master ng mga pangkat na ito.

Mga kaganapan sa Scrum

Mayroong 5 uri ng scrum event:

Ang Sprint ay ang pinakamahalagang bahagi ng Scrum. Kabilang dito ang pagpaplano ng sprint, pang-araw-araw na stand-up (pang-araw-araw na scrum), pagsusuri at retrospective ng sprint.

Pagpaplano ng sprint. Ang lahat ng miyembro ng pangkat ng Scrum ay nakikibahagi sa pagbuo ng isang plano para sa hinaharap na sprint. Dito ipinakita ang ideya ng produkto at maaaring ipahayag ng bawat miyembro ng koponan ang kanyang opinyon, kung ano ang kanyang iniisip tungkol dito. Pagkatapos sa pagpupulong, ang mga priyoridad ay tinutukoy at ang mga deadline ay inihayag.

Ang Daily Scrum ay isang pang-araw-araw na short scrum event, na tumatagal ng hindi hihigit sa 15 minuto. Kadalasan ito ay ginagawa upang planuhin ang gawain ng mga encoder para sa ngayon o bukas. Sa Daily Scrum, maaari mong talakayin ang mga kasalukuyang isyu. Ang lahat ng mga developer na kasangkot sa proyekto ay kinakailangang lumahok sa naturang workshop. Ang pagkakaroon ng isang Scrum Master ay pinapayagan, ngunit hindi kinakailangan.

Sprint Review (Demo) - Ipakita ang mga resultang ginawa sa panahon ng sprint. Karaniwan ang kaganapang ito ay nagaganap sa huling yugto. Lahat ng interesado ay nakikibahagi dito.

Sprint Retrospective - pagtalakay sa mga resulta ng sprint. Ang mga miyembro ng pangkat ay nagbabahagi ng kanilang opinyon kung paano nila nakayanan ang mga gawaing itinalaga sa kanila at kung paano pagbutihin ang mga resulta ng trabaho sa hinaharap.

Bilang karagdagan, minsan ay isinasagawa ang backlog refinement - Backlog Refinement. Tinatalakay nito ang mga backlog item, paghahanda para sa susunod na sprint, at pagbibigay-priyoridad sa mga kasalukuyang gawain.

Mga artifact

Ang mga artifact ng scrum ay ang gawaing nangyayari sa pagtatapos ng isang proyekto o sprint. May tatlong artifact - ang product backlog, ang sprint backlog, at ang increment. Ang bawat isa sa kanila ay kinakailangan para sa napapanahong paghahatid ng software sa mga gumagamit. Mayroon ding mga auxiliary artifacts (burn down chart at higit pa).

Mga bahaging kasama sa sprint artifact:

Backlog ng produkto - mga tampok ng interface at backend.

Ang sprint backlog ay isang listahan ng mga gawain na kailangang gawin sa panahon ng pag-ulit. Napagkasunduan sila bago magsimula ang sprint.

Increment - Ang kabuuang bilang ng mga software backlog item na ginawa sa panahon ng sprint at ang halaga ng mga increment na ginawa bago ito. Ang natapos na bagong increment ay dapat ipakita bago matapos ang sprint. Nangangahulugan ito na mayroon kang gumaganang bersyon na nakakatugon sa mga kinakailangan ng scrum team.

Product backlog item - dapat itong makumpleto sa panahon ng sprint iteration. Bilang isang patakaran, ang elemento ay nahahati sa ilang maliliit na gawain.

Ang layunin ng sprint ay ang mga gawaing kailangang tapusin (gumawa ng backlog item o iba pang gawain).

Ang sprint burndown ay ang gawaing natitira bago matapos ang sprint. Ang burn down na chart ay alinman sa pataas o pababa. Ang lahat ay nakasalalay sa mga paghihirap na kinakaharap ng mga miyembro ng koponan habang nagtatrabaho. Ito ay hindi isang tagapagpahiwatig ng pag-unlad, ngunit isang paraan lamang upang malutas ang mga problema at isang insentibo.

Ang Product Release/Product Burn-Down Chart ay isang chart na iginuhit ng Scrum Master bago matapos ang susunod na sprint. Ang pahalang na axis ay mga sprint, ang patayong axis ay ang dami ng natitirang trabaho.

Mga panuntunan sa balangkas ng scrum

Ang mga tungkulin, kaganapan at artifact ay batayan ng Scrum, ngunit may iba pang mga patakaran bukod dito. Ang lahat ng mga ito ay nagpapahusay sa kahusayan ng proseso ng trabaho. Narito ang isang listahan ng mga panuntunang iyon:

• Kasama sa scrum team ang customer ng software, scrum master, at mga developer.
• Ang lahat ng mga sprint ay dapat na parehong haba.
• Matapos makumpleto ang isang sprint, magsisimula kaagad ang paggawa ng bago.
• Ang isang sprint ay palaging nagsisimula sa isang plano.
• May morning scrum ang mga miyembro ng team sa simula ng kanilang araw ng trabaho.
• Ang bawat sprint ay sinusuri sa bawat sprint. Pinapabuti nito ang komunikasyon sa pagitan ng koponan at mga stakeholder.
• Hindi inirerekomenda na baguhin ang sprint backlog sa panahon ng sprint.

Mga Limitasyon sa Scrum

Kasama ng mga halatang pakinabang, mayroon ding mga disadvantage ang Scrum:

• Ang scrum ay madalas na humahantong sa pagbawas sa dami ng trabahong ginawa dahil sa kakulangan ng karaniwang deadline.
• Sa mababang pakikilahok o ayaw makipagtulungan sa mga kalahok ng proyekto, may malaking pagkakataon na mabigo ang resulta.
• Ang istraktura ng scrum ay mahirap gamitin sa malalaking koponan, ngunit posible pa rin. May mga scaling framework para dito: LeSS, SAFe, Nexus at iba pa.
• Ang pag-alis ng isa o higit pang miyembro mula sa pangkat sa gitna ng proyekto ay hindi masyadong nakakaapekto sa proyekto.