Tänapäevased tarkvarameeskonnad on vähemalt oma protsessides agaramad! Nad on valmis mõtlema väljapoole seatud parameetreid, et jälgida, mis nende jaoks sobib. Nad soovivad õppida ja rakendada uusi projektijuhtimise ja projektiprotsesside tehnikaid.
Projektijuhtimismeetod nimega Kanban on tarkvaratööstuses ümarlaiku teinud juba üsna mitu aastat ja viimase viie aasta jooksul on see raha omandanud. Koos Agile metoodikaga on Kanbani meetodi kasutuselevõtt andnud ettevõtetele palju tähistamist.
Kuid on ka kriitikat, et Kanban pole midagi muud kui ülistatud ülesannete loend. Mis sellest siis saab? Uurime välja.
Mis on Kanban?
Kui teie ettevõte on valmis üle minema tavapärasest tarkvaraprojektide juhtimise lähenemisviisist, pole täna projektijuhtimise tehnikatest puudust.
Ühe jaoks on olemas Agile Project Management süsteem, mis keskendub mittelineaarsele, iteratiivsele tarkvaraarenduse meetodile. Agiilsete meetodite kasutamine on ilmne Scrumis, mis keskendub paindlikumale lähenemisele projektijuhtimisel.
Agile'il on ka lingid teiste projektijuhtimisraamistikega, näiteks Kanban ja Extreme Programming. Neist on Kanban saavutanud palju populaarsust. Lõppude lõpuks, kes ei taha jaapanlaste välja töötatud protsessi?
Kanban on kontseptsioon, mis arenes Toyota tootmisettevõttes välja just õigel ajal (JIT) tootmiseks, mis vähendab kulusid ja võimaldab vähem ressursse kasutada. Oma südames järgib see töö „tõmbamise“ põhimõtet, mis tähendab, et ülesanded või tooted tuleb nõudmiste ja nõudmiste järgi „tõmmata“, mitte ülalt alla suruda. See töötati välja selleks, et tagada Toyota tehastes autokomponentide parem varumine vastavalt nõudlusele. See tähendas, et nõudluse suurenedes täideti taotlused.
Kontseptsioon kohandati tarkvaratööstusele mõne muudatusega, mille autor oli David Anderson oma 2010. aasta raamatus Kanban . Sellest ajast alates on seda kasutatud mitmesuguste projektide jaoks, millel on olnud suur edu. See võib olla tohutult abiks keerukates projektides, mis võivad arendustsükli ühel küljel kannatada ülekoormamise all.
Põhimõtteliselt käsitleb Kanbani süsteem tarkvaraprojekti protsessi torustikuna. Oletame, et tarkvaraprotsessil on kolme tüüpi ülesandeid: analüüs, arendamine, testimine ja lõpuks juurutamine. Oletame, et täita on kakskümmend ülesannet.
Traditsioonilise projektijuhtimissüsteemi korral näiteks
- Kokku on 25 lugu
- Analüütikud saavad nädalas hakkama viie looga
- Arendajad saavad nädalas hakkama viie looga
- Testijad piirduvad kolme looga nädalas
Sellises olukorras tehke töö testijate otsas lihtsalt üles. 1. nädala lõpus on olukord järgmine:
- Ainult kolm lugu on liikunud kasutuselevõtu juurde.
- Arendajad ja analüütikud töötavad kolme loo kallal, kuna testijad ei suuda arendajate väljundit võtta ja sama katsetada.
- Töö kuhjatakse, jättes arendajad ja analüütikud ning projektijuhi parandusse.
Analüütikud ja arendajad võivad nüüd lihtsalt pöialt tõmmata! Või võib nende juht aru saada, et nad on jõudeolekus, ja suunata nad mõnele teisele projektile, kus võib tekkida sarnane olukord. Seega on kaks projekti, mis on katsetamisjärgus kinni jäänud!
Probleeme pole sellises olukorras raske näha. Mis mõte on kümme lugu (või bitti tarkvara) välja töötada, kui neid ei kavatse peagi testida?
Nüüd aga Kanbani meetodi juurde.
Kanbani meetod on äärmiselt lihtne mõiste. Järgneb lihtne tõmbamismeetodi kasutamise loogika, et esmalt kõrvaldada kitsaskohad ja piirata käimasolevaid töid (WIP) paremate tööprotsesside jaoks.
Kanban aitab lihtsal kujul sõna-sõnalt visuaalset tahvlit, tõmmates üksused ülesandeloendist maha, mitte ajakavadega töötades. Kanbani meetod aitab kitsaskohti tuvastada, et protsessivoogu oleks paremini hallatav.
Kanbani põhitahvlil on nimekiri teostatavatest, pooleliolevatest ja lõpetatud ülesannetest.
Tarkvarahalduses võivad ülesanded olla aga pisut keerukamad. Enamikul Agile projektidel on ka sarnane juhatus. Kanbani tahvlil on juurutamise etapid koos iga veeru numbriga selgelt tähistatud. See arv tähistab maksimaalset arvu toiminguid või lugusid, millega konkreetne samm hakkama saab.
Meie näide Kanbani tahvlil näeks teise nädala alguses välja umbes selline. See tähendab, et arendajad ja analüütikud ei tööta sel nädalal optimaalse arvu lugudega. On ilmselge, et testija otsa saab tööd kuhjaga. Ja organisatsioonid saavad tagada, et meeskonnad teeksid testide tegemiseks koostööd. Teise võimalusena saavad nad vaadata muid protsessivoo mudeleid, nii et seda ei juhtuks.
Kui projekte käsitletakse Kanbani süsteemi kaudu, on kuhjamiseks vähem võimalusi. Lood võetakse üles vastavalt maksimaalsele saadaolevale ribalaiusele.
Tüüpilises Kanbani seadistuses võetakse töö vastu vastavalt saadaolevale ribalaiusele ja meeskonnad tõmbavad selle tööle nii, et nad on alati maksimaalses mahus. Süsteem võimaldab kiiret lahendamist kiireloomuliste ülesannete jaoks, nii et need liiguvad minimaalse vaevaga lauast läbi.
Vaadake seda Kanbani tahvlit.
On selge, et kõik sammud töötavad maksimaalse efektiivsusega. Ja ka ülesandel, mis on “Kiirel teel”, võetakse arvesse.
Kanban pole kaugeltki ainus meetod, mida kasutatakse WIP-i piiramise kaudu tõhususe suurendamiseks. On ka teisi süsteeme, mis saavutavad sama tulemuse - näiteks CONWIP (Constant Works in progress) ja DBR (Drum-Buffer-Rope) süsteemid, mis on mõeldud peamiselt töötleva tööstuse jaoks.
Kanban on aga süsteem, mida on kõige paremini muudetud tarkvaratööstusele sobivaks.
Mille poolest erineb Kanban Agile metoodikast?
Kanban on oma südames metoodika, mis kasutab mõnda Agiilse projektijuhtimise elementi. Paljud Agile raamistiku projektid on juurdunud Lean-lähenemistesse. Erinevus Kanbani metoodika ja Agiilse projektihalduse vahel ei ole nii mustvalge, nagu kahe meetodi pooldajad usuksid. Neil on rohkem ühist kui erinevusi.
Agiilne raamistik pole absoluutne. Küsimus pole selles, kas meeskonnad on agarad või mitte. Tiimidel on sageli erineval määral paindlikkust . Üks meetoditest tarkvara arendusprotsessis suurema paindlikkuse saavutamiseks on Kanbani kasutamine.
Kanbani ja Agile metoodika vahel on mõned erinevused. Mõned Kanbani arendamise funktsioonid, mis pisut erinevad Agile'ist, on:
- Aja read ei ole oluline tegur . See on keeruline mõte oma pea ümber mässimiseks, kuna see tundub väga mitteinimitiivne. “Kuidas te ilma tähtaegadeta töötate?” Küsivad inimesed sageli. Kuid kui iga meeskonna liige tegeleb oma maksimaalse efektiivsusega, siis aeg ei lange enam faktoriks.
- Lood (ülesanded) on suuremad kui tüüpilistes Agile süsteemides. Tavaliselt on lugude pikkus ja keerukus pikem kui tüüpilise Scrum-projekti puhul. Kuna tähelepanu keskmes pole aja hindamine, vaid lihtsalt protsessi kulgemine, saab Kanban endale lubada suuremate lugude kallal töötamist.
- Olemasolevates protsessides olulist muutust pole. Kanbani tarkvara arendamise põhimõtted, mille on sõnastanud selle asutaja David Anderson oma blogis, sisaldavad järgmisi põhiprintsiipe:
-
- Alustage sellest, mida teete nüüd
- Nõustuge astmeliste, evolutsiooniliste muutustega
- Austage praegust protsessi, rolle, vastutust ja ametinimetusi
- Iga lugu mõõdetakse tsükli aja järgi . Projekti hinnatakse mitte traditsioonilise kiiruse kiiruse arvutamise (etteantud aja jooksul valminud lugude arvu) järgi, vaid tsükliaja järgi. See tähendab, et Kanban paneb rõhku sellele, kui kaua ülesande täitmine aega võttis. Võite sageli näha paljudel Kanbani tahvlitel linnuke, kus on mainitud, mitu päeva meeskonnal loo lõpetamiseks kulub. Seda hinnangut kasutatakse järgmises tsüklis.
Kanban: juhatus, aga mis veel?
Niisiis, Kanban on tahvel, mis näitab meile, kuidas lood on korraldatud - see on nii suur asi, paljud küsivad. Tegelikult on palju arutelu selle üle, mis Kanban on ja mida teha saab.
Kas Kanban on lihtsalt meetod töövoo haldamiseks? Või on see midagi, mida saab maksimaalse efektiivsuse saavutamiseks kasutada koos Agile metoodikatega? Või kas see võib olla täiesti uus viis töövoogude haldamiseks?
Iga meeskond kasutab Kanbanit vastavalt olukorrale sobivaks. Vaatamata sellele on Kanbanil potentsiaali töötada tarkvara arendamisel eluviisina, kui seda optimaalsel tasemel kasutada.
Kas seda kasutatakse töövoo haldamiseks või uue paradigmana tarkvaraarenduses, ei saa eitada, et see aitab WIP-e hallata.
Kanbani parima töö tagamiseks on oluline mõelda sellele mitte ainult WIP-ide haldamise, vaid ka projektihaldusraamistikuna. Teatud põhisuunised aitavad seda protsessi edasi viia.
- Optimeerige meeskondi nii, et ükski meeskond ei alustaks midagi, mida nad ei saaks lõpetada. See aitab protsessi kaasa.
- Ärge pange vastu algse Kanbani süsteemi muudatustele. Kui teie projekt saab tähtaegade ja ajakavadega hästi hakkama, lisage see samamoodi nagu teeksite. See loob tervislikuma ja kindlama arengukeskkonna.
- Ärge hoidke meeskonnatööst. Kanban võib tunduda, kuid ei ole mudel, mis põhineb isoleeritud inimestel. Meeskonnatöö peab olema Kanbani tarkvaraarenduse lahutamatu osa.
- Mõelda väljaspool kasti. Mõelge muudatustele töövoogudes. Paljud meeskonnad valivad nüüd testimispõhise arenduse koos aktsepteerimistestipõhise arendamisega, kus aktsepteerimistestid viiakse kõigepealt läbi kasutusjuhtudega, mis seejärel juhib vajalikke funktsioone ja arenduse olemust.
Hübriidid
Kuna üha enam ettevõtteid kasutab projektijuhtimise tööriistu, mis sobivad nende olukorraga kõige paremini, pole üllatav, et kaks parimat projektijuhtimise metoodikat: Scrum ja Kanban on integreeritud suure eduga.
Hübriid nimega Scrumban on jõudmas paljudesse projektidesse.
Kui organisatsioon juba kasutab Scrumit, kuid on keeruline projekti koos hoida, kasvõi juhul, kui sprindid ei tööta hästi, kuni testimiseni, mis pole õhukindlad, võib olla aeg kaaluda Scrumbani kasutamist.
Selle lihtsamaks selgitamiseks võttis Scrumban kaasa luubi sprintidele. See ei puuduta ainult sprinti kui projekti osa, vaid seda, mis toimub sprintides. Scrumban aitab uurida, kuidas lugu sprindis töödeldakse ja see võib muuta kõik.
Scrumban või mõni selle variant on olemasolevatest tavadest minimaalne muudatus. Kanbani kasutamise ilu seisneb selles, et seda saab kasutada praktiliselt igasuguste projektijuhtimismudelitega: juga, Agile või ükskõik mis nende vahel.
Kanbaniga alustamine
Kanbani süsteemiga on lihtne alustada. Samuti on Kanbanit võimalik minimaalselt rakendada projekti konkreetse osa prooviversioonina.
- Kaardistage tarkvara arendamise protsess. Tehke kogu protsessi jaoks selge kaart. Kuidas projekt - alates algsest kavandamisest kuni väljatöötamiseni, testimiseni, funktsioonide muutumiseni - reaalselt töötab?
- Loetlege sammud, kus Kanbanit kasutatakse. Kasutage täielikult teie kontrolli all olevaid samme. Tavaliselt hõlmab see analüüsi-, arendus-, ülevaatus- ja testimisfaase.
- Töötage selliste oluliste punktidega nagu:
- Pooleliolevate tööde limiidid igal sammul.
- Kiirendatud / blokeeritud töö protsessid
- Ümbriku tagakülje hinnangud tsükli aja kohta
- Kanbani juhatuse / protsessi / kalkulatsiooni ülevaatuse sagedus
- Ostke tahvel ja hunnik Post-It märkmeid.
- Alustama
- Vaadake vastavalt vajadusele üle.
- Korda
Niisiis, minge edasi ja alustage Kanbani kasutamist!
Ärge kartke, kui see ei osutu nii, nagu te algselt olite kavatsenud. Agile metoodikate mõte on kohandada muutusi inimestes ja protsessides! Andke meile teada oma kogemustest Kanbani meetodil.
Soovitatavad artiklid
- 6 parimat kasulikku projektijuhtimisbürood (PMO)
- 8 kasulikku sammu oma projekti jaoks keerukate lugude kaartide koostamiseks
- Äärmise programmeerimise 5 olulist väärtust (võimas)