Lið vaxa með Agile Scrum

QueryPie Development # 3: Kynning á þróunarferli

한국어: https://medium.com/p/cfaa4b71c263/

Það eru engin silfurkúlur í heiminum. Engu að síður eru menn viðkvæmir fyrir alls konar löngunum og eru alltaf að leita að silfurskothylki.

Þegar tilkynnt var um Agile Manifesto árið 2001 var Agile frambjóðandi fyrir að vera silfurskothríð í hugbúnaðarþróunargeiranum. Sautján árum síðar er Agile ekki lengur silfurkúlan sem við höfum verið að leita að. En það hefur orðið hagnýtt og frábært tæki til að auka lið þitt og knýja fyrirtæki þitt til árangurs.

Ég hóf feril minn sem vefur verktaki árið 2004. Síðan 2011 hef ég verið háttsettur verktaki sem starfaði sem leiðandi í mörgum þróunarsveitum. Eftir að ég varð liðsstjóri hafði ég stöðugt áhyggjur af því hvernig ég gæti náð öllum markmiðum í þróunarverkefnum mínum: markmið eins og tímasetningar, samræmi, gæði og teymisaukning.

Sem afleiðing af þessum áhyggjum fann ég Agile. Þannig að þessi forritaraskrá mun útlista reynslu mína af lipurri þróun.

Lipur: Áframhaldandi endurbætur með málamiðlun

Helst væri aðferð hugbúnaðarþróunar að þróa fullbúinn hugbúnað tímanlega sem myndast á fullkominni áætlanagerð og spá. Þetta er þekkt sem áætlun drifin þróun, og hugbúnaðurinn er þróaður í samræmi við ferli sem kallast Fosslíkanið. Til þess að þetta nái árangri verður að uppfylla allar kjöraðstæður. En í raun er erfitt að spá fyrir um hvað muni gerast í framtíðinni og óhjákvæmilegt að óvæntar breytingar muni eiga sér stað. Ennfremur er þróun hugbúnaðarins fljótandi, opin og óútreiknanlegur.

Svo, hvað er lipur?

Lipur er málamiðlun. Agile gerir ráð fyrir raunverulegum aðstæðum í stað fullkominna og hugsjóna. Það rúmar stöðugar breytingar og nýtir takmarkað fjármagn til að bæta verkefnið. Þannig getur þróunarteymið hugleitt besta málamiðlunina og útfært það saman.

Það eru til margs konar lipur þróunarferli. Scrum, Kanban og Extreme Programming (XP) eru aðeins nokkrar. Hver hefur mismunandi eiginleika og mismunandi umfang, en er hægt að nota í samsetningu hver við annan.

Ný reynsla og leiðtogi liðsstjórans við fyrsta lipur skrum

Árið 2011 varð ég liðsstjóri eigin hóps þróunaraðila og fór að hugsa um hvernig teymi átti að vinna. Að læra aðferðafræði við þróun hugbúnaðar vakti áhuga á Agile. Ég hreifst mest þegar ég las bókina Scrum og XP úr skurðunum.

Scrum og XP úr skurðunum, How we do Scrum eftir Henrik Kniberg

Útfærslan sem Scrum notar er tilvalin og aðlaðandi. Liðið stýrir verkefni sem bakslagi, skipuleggur og leysir það út frá stuttum endurtekningarþróunarferli sem kallast Sprint og skapar stöðuga þróun og endurbætur.

Scrum Process (heimild: https://en.wikipedia.org/wiki/Scrum_(software_development))

Samt sem áður gat ég ekki kynnt aðferð Scrum fyrir liðinu mínu vegna eðlis deildar minnar á þeim tíma. Við vorum í miðri leiðréttingu margra vandamála og urðum að halda áfram að þróa hugbúnað svo það væri ekkert pláss fyrir nýja aðferð. Þegar ég byrjaði að fella Scrum létt í vinnuferlið okkar tókst það ekki á óvart. Ég komst að þeirri erfiðu leið að vinna með Scrum, liðið og viðskiptavininn þarf að vera tilbúinn ... sem er ekki auðvelt verk.

Svo liðið mitt fór aftur í það hvernig við unnum áður en Scrum. Gamla aðferðin okkar leit svona út:

  1. fá beiðnina í síma eða tölvupóst
  2. skrifaðu beiðnina á seðil eftir póst
  3. setja post-it athugasemdina á vegginn
  4. rekstraraðili grípur eftir honum og tekur hana aftur á skrifborðið
  5. rekstraraðili leysir beiðnina
  6. afgreidd beiðni er flutt í sameiginlega dagbók liðsins

Ég er viss um að þú verður ekki hissa á að heyra að skjáir liðsins míns væru stöðugt fullir af athugasemdum eftir það!

(heimild: https://happytango.com/…what-a-post-it-note-was/)

Kanban var einfaldur og auðveldur en það féll 2% undir ágæti

Árið 2013 skipti ég um vinnu og fékk annað tækifæri til að huga að vinnuflæði liðsins míns. Um það leyti kom út bókin Kanban og Scrum: gera sem mest úr báðum. Ég lærði mikið um Kanban með því að kynna mér þessa bók.

Kanban og Scrum: gera báðir báðir Eftir Henrik Kniberg og Mattias Skarin

Aðferð Kanban er aðeins einfaldari. Það krefst þess að búa til nokkra aðskilda dálka, merkja þá í samræmi við það (þ.e. að gera, gera, gera) og bæta við verkefnum á kortum / athugasemdum eftir dálkana. Þessi verkefni færast síðan frá dálki til dálks eftir stöðu þeirra. Það er ansi auðveld aðferð til að nota og það er frábær leið til að gera sér grein fyrir vinnuferlinu.

einfalt striga borð (fengið: https://en.wikipedia.org/wiki/Scrumban)

Þessi aðferð kann að virðast eins og augljós aðferð, en Kanban bætir nokkrum reglum við ferlið. Sumar grunnreglur Kanban eru að skipta verkefnum í smærri verkefni, forgangsraða þeim og takmarka fjölda samtímis aðgerða. Ef þú ert forvitinn um Kanban aðferðina, vinsamlegast vísaðu til Kanban og Scrum bókarinnar til að fá frekari upplýsingar.

Það er mjög einfalt að stjórna verkefnum liðs með Kanban aðferðinni. Hver sem er getur skilið ferlið og fylgst með því til að hámarka framleiðni og ávinningurinn sem það veitti teymi mínu var mikill.

En ég fann mig mjög sekur um bilun fyrsta Scrum míns. Mig langaði til að vinna á skipulagðari hátt með Scrum aðferðinni.

Afturelding á Agile Scrum með nýjum byrjunarliðinu:

Árið 2015 þegar ég gekk í sprotafyrirtæki var ég í þeim aðstæðum þar sem ég þurfti að leiða alveg ný þróunarsamtök. Ég áttaði mig á því að þetta var fullkominn tími til að koma Agile Scrum aftur inn í vinnuferlið mitt.

Þegar hugmyndin að fyrstu vörunni var ákvörðuð var þróunarvinnunni skipt upp í bestu mögulegu hluti og teknar saman í smáatriðum til að fylla eftirsóknina. Við settum Sprint okkar í tveggja vikna lotu. Ég var ekki fullviss um að eyða mánuði í að skipuleggja það tímabil. Hringrás í viku fannst of stutt. 2 vikna lotan innihélt 1 vikna hlé og ef framvindan var of hæg notuðum við helgina til að bæta upp það.

Fyrstu mánuðina notuðum við töflu og póstsíðu þess fyrir Sprints án hjálpar neins hugbúnaðar. Trello og Jira voru vinsæl á þeim tíma en Scrum menningin var samt ný og framandi fyrir alla hjá mínu fyrirtæki, líka mér. Svo við höfðum ekki efni á tíma til að læra nýja aðferð, og þess vegna treystum við eingöngu á töfluna okkar og eftir hana.

Brenndu töflu niður 3. sprettinn

Hraði Scrum: Stöðug framför í frammistöðu

Mikilvægasta hugtakið í Scrum er einbeiting. Þessi aðferð byrjar með hæfilegri forsendu um að það sé aðeins takmarkaður tími fyrir einn einstakling til að einbeita sér að einu verkefni. Svo það er best að stilla fastan vinnutíma í einn dag og stjórna hlutfalli vinnu sem unnið var á þeim degi. Í þessu skyni köllum við verkgreina verkgreiningarinnar Sögu og úthlutum punktagildi í söguspjaldinu sem kallast sögupunktur.

️ Sagnapunktar eru notaðir til að mæla heildarátak sem þarf til að þróa verk. Ef verktaki einbeitir sér 100% í eina klukkustund við verkefni er það eitt stig. Þegar við skorum sagnapunkta verðum við að passa okkur að ofmeta eða vanmeta. Að finna nákvæma einkunn fyrir stærð verkefnisins er nauðsynleg. Miðað við sögupunkta sem við settum fyrir tiltekinn Sprint getum við reiknað út hraðann eftir að hafa tekið þátt í þeim tíma sem þarf fyrir einn Sprint.

Hraði = Sögupunktar / Raunverulegur tími:

Til dæmis, ef 10 verktaki vinna við sögupunkta í 10 daga, átta tíma á dag, þar sem sögunum er raðað í 528 stig, þá væri hraðinn: 528 stig / (10 manns x 10 dagar x 8 klukkustundir) = 66%

Hraði er reiknaður með því að draga saman allt starfsfólk sem tekur þátt í Scrum. Með því að reikna út hraðann hjá einstaklingum getur liðsmönnum að óþörfu keppt sín á milli, sem til langs tíma litið getur verið skaðlegt.

Athyglisvert er að hraðamarkmið fyrir næsta Sprint eru reiknað út frá meðaltali hraðans sem náðst hafði í fyrri Sprint parinu. Hver Sprint setur alltaf aðeins hærra markmið en meðaltal fyrri niðurstaðna og skapar stöðugt uppfært og krefjandi markmið. Svo þegar lið hefur náð markmiði sínu er mikil tilfinning fyrir afrekum. Ef þeir mistakast, þá er möguleikinn á að setja sér auðveldara markmið vegna lækkaðs meðaltalsgildis fyrir næsta Sprint. Þessi fókusstjórnun gerir Scrum teyminu kleift að bæta stöðugt nákvæmni og frammistöðu áætlunar sinnar.

Sprint-framvindu Scrum:

Scrum teymið deilir sameiginlegu krefjandi markmiði, heldur áfram með verkefnið og heldur stuttan fund á hverjum degi. Þetta er kallað Daily Scrum Meeting, eða Daily Stand-up Meeting vegna þess að mælt er með því að halda fundi eins stuttan og mögulegt er. Í þessum lotum deila Scrum meðlimir framvindu sinni og viðhalda þrýstingi í að ná árangri í liðinu.

Scrum sprints hringrás (heimild: Agile Software Development með Scrum eftir Ken Schwaber og Mike Beedle)

Eftir hvern sprett þarf tíma til umhugsunar og skipulagningar. Það er svo mikilvægt að bæta liðsbandalagið með því að bera saman markmið og frammistöðu, reikna út styrkstyrk og afhenda lof og huggun með ígrundun. Þú ættir aldrei að ásaka neinn. Þetta er liðsókn.

Á skipulagsfundinum fyrir næsta Sprint, byggt á framförum og reynslu, getur þú uppfært innihald söguspjalda í bakslagi og fínstillt gildi sögunnar. Settu síðan styrkur markmiðs fyrir næsta Sprint, sammála um umfang og áætlun Sprint og byrjaðu aftur (sjá bækurnar hér að ofan til að fá frekari upplýsingar um hvernig á að gera þetta).

Ég hef fengið mikla reynslu af því að reka mitt eigið Scrum lið í tvö ár. Scrum einbeitti teymi mínu að verkefninu og leiddi náttúrulega til meiri árangurs og nákvæmrar tímasetningar. En mestu máli skiptir að meðlimir teymisins urðu mjög sjálfstraustir og færir um að byggja djúpt samband hvert við annað. Við ólumst hratt saman sem lið.

Við prófuðum nokkur tæki til að stjórna ferlinu okkar og ákváðum á endanum pallinn Jira. Ég held persónulega að Jira sé öflugasta og þægilegasta tæki bæði fyrir Kanban og Scrum aðferðir.

Skjámynd: Virkir sprettir af Scrum borði (heimild: https://support.atlassian.com/jirasoftware-cloud/)

Verkefnisstjórn Scrum í Jira veitir lögun stjórnunar á bakslagi og Scrum stjórn með margvíslegum skýrslum. Mælaverkfæri eins og Sprint skýrslur, brenna niður töflur, styrkur töflur og útgáfur skýrslur hjálpaði okkur að stjórna árangri okkar.

Festa, viðburðarpallurinn þróaður með árangursríkum Scrum:

Í desember 2017 gekk ég til liðs við þróunarteymi suður-kóresks sölupalls sem kallaður var Festa. Á þeim tíma var Festa að búa sig undir fyrstu vöruskipun sína að lokinni sönnun á hugmyndinni (POC). Varan sjálf var þægileg vefsíða þar sem notendur gátu keypt miða á viðburð með auðveldri greiðsluaðferð.

Vegna þess að þetta var nýtt teymi, þurftum við að tala um vinnubrögð okkar og ferli. Ég lagði Scrum. Eftir að tillagan var samþykkt ákváðum við fyrstu lágmarks lífvænlegu vöru (MVP) og settum upp bakslag.

Áherslan var á áætlun vöruskipta. Útgáfudagur vöru var þegar ákveðinn, svo ég þurfti að klára verkefnið á föstum tímaáætlun. Tímabilið sem mér var gefið var aðeins meira en mánuður.

Gat nýstofnaða Festa teymið klárað og sleppt vörunni á réttum tíma?

Vefsíða Festa (heimild: https://festa.io/)

Þar sem frestur okkar var um það bil mánuður, ákváðum við 1 vikna Sprint hringrás. Með því að stjórna bakstreymi dyggilega við að endurtaka Sprint hringrásina gátum við mjög nákvæmlega sagt fyrir um þann tíma sem það myndi taka að undirbúa undirbúning vörunnar.

Með því að nota sérstakan eiginleika í Jira úthlutuðum við útgáfunúmerum á sögukort og útfærðu útgáfuskýrslur. Með þessum eiginleika, bentum við stöðugt á væntanlegan útgáfudag og lagfærðum hart þróunarsviðið til að ná markmiðum okkar.

Festa.io skrum ver1.0.0 Skýrsla

Festa teymið stóð sig stöðugt vel með Scrum og tókst að gefa út vöruna á markdegi. Ef þú skoðar ofangreinda útgáfuskýrslu geturðu séð að sögutala okkar hækkaði með föstum halla. Þetta er sönnun þess að teymið hefur alltaf þróað vöruna tímanlega með stöðugri frammistöðu.

Ný Scrum Challenge: QueryPie þróun í CHECKER

Árið 2018 hóf ég störf hjá CHECKER, nýjum sprotafyrirtæki í Suður-Kóreu sem þróar öflugt IDE tól sem kallast SQLGate. Í fyrstu einbeitti ég mér eingöngu að því að finna mér stað í nýja umhverfinu og þegar ég var ánægð með nýja stöðu mína byrjaði ég að einbeita mér að því að skila árangri. Eftir nokkra aðlögun fór ég að hugsa um hvernig ég gæti bætt árangur liðsins míns aftur. Það var þegar ég lagði Scrum fyrir liðinu mínu.

Hvað finnst þér vera mikilvægasti þátturinn þegar Agile Scrum ferli er kynnt? Ég tel að það sé orðspor fólks sem tekur þátt í upptöku ferlisins. Traust er grundvöllur samþykkis og vilji til að prófa eitthvað nýtt. Eftir að hafa verið lífsnauðsynlegur meðlimur í CHECKER í meira en hálft ár öðlaðist ég traust stjórnenda minna og liðsmanna. Þökk sé viðleitni allra, stofnuðum við áreiðanlegt lið Scrum.

CHECKER er blómlegt sprotafyrirtæki sem er fljótt að tryggja virka og hæfileikaríka áhafnarmeðlimi með viðleitni mjög hollra stjórnenda. Ég var innblásinn af eldmóði þeirra til að ná árangri og vilji þeirra til að taka á sig nýjar áskoranir. Svo það er mín mesta ánægja að búa til Scrum ferli sem mun auka framleiðni fyrirtækisins og vekja veglega viðskipti okkar.

Núverandi Scrum áskorun CHEQUER er QueryPie, sem þú getur lært meira um í þessari grein.

Ég hef þegar haft mikla reynslu af því að stjórna Scrums í gegnum Jira, þannig að mér hefur tekist að leiða liðið mitt í að framkvæma áætlun mína í fyrsta sprettinum okkar. Upphafleg styrkur markmið okkar var stillt á 64% miðað við reynslu (70% er kjörið markmið í mínum huga). Fjöldi skipverja var fjórir og fyrsti spretturinn var aðeins átta dagar. Miðað við þessa þætti var markmiðið að ná: 4 manns x 8 dagar x 8 klukkustundir á dag x 64% Styrkur = 164 sögupunktar.

QueryPie scrum ver1.0.0 Skýrsla

Á myndinni hér að ofan geturðu séð hvernig ég skipulagði bakslagið og setti markmiðið fyrir útgáfu 1.0.0. Markdagurinn var 1. mars. En þegar ég sá útgáfuskýrsluna nokkrum dögum eftir að Sprint byrjaði var spáð að lokadagur yrði 5. mars. Það tók mig nokkrar sekúndur að átta mig á því að ég hafði ekki tekið þátt í því um helgina. Úps! Laugardagur og sunnudagur eru mikilvægir hvíldardagar!

Í þessari skýrslu bætti ég við að 2. og 3. mars munum við ekki vinna. Áætlaður verklokadagur hefur verið aukinn um helgar og breytt lokadegi í 11. mars. En á þessu gengi værum við 10 dögum á eftir markadeginum, þannig að við þyrftum að laga. Með aðeins nokkurra daga spretti lögðu hæfileikaríkir áhafnarmeðlimir CHECKER sig fljótt að Scrum aðferðinni og gátu fínstillt söguspjöld og söguskor sem upphaflega voru stillt rangt.

Fyrsta Sprint áskoruninni lauk eftir 8 daga. Sprint skýrslan okkar sýnir að áhöfn okkar stóð sig mjög vel í lokin. Vegna mikillar vinnu hefur áætlaðan lokadagsetning verið aðlagað að 22. febrúar. Mismunurinn á bjartsýnnri og svartsýnnri áætlun um lokadagsetningu á línuritinu hefur einnig minnkað. Ég reikna með að við fáum útgáfuskýrslu með mjög mikilli nákvæmni þegar við erum búnir að klára tvo spretti.

Þetta var aðeins 8 daga stuttur sprettur en áhöfn CHECKER lærði að vinna markvisst og skilvirkt. Með því að ná árangri í fyrsta sprettinum öðluðumst við sjálfstraust og styrktum tengslin á milli. Við ólumst saman um Scrum aðferðina og við munum vaxa enn frekar í gegnum Sprints sem munu fylgja.

Agile Scrum Journey Wrap-up:

Mikil endurgjöf kom út úr Agile Scrum ferli. Sumir héldu að gott væri að fylgjast með framvindu áhafnarinnar. En aðrir töldu að það myndi valda óþarfa samkeppni og neikvæðri stigma, svo við ættum að nálgast það vandlega.

Að vinna í teymi ætti ekki að fela í sér samkeppni. Við verðum að byggja upp skuldabréf og halda áfram stöðugt í átt að sameiginlegu markmiði. Ef einhverjir áhafnarmeðlimir eiga í erfiðleikum ættum við að hjálpa þeim að bæta hraðann á Scrum ferlinu og vaxa saman.

Ég vona að löng saga mín hjálpi einhverjum þarna úti. Gefðu Scrum tækifæri og gefðu liði þínu styrk og forystu. Ef þú heldur áfram að vinna saman skaltu vita að árangur verður rétt handan við hornið.