Kanban: mis see on? Kas plaanite Kanbani oma äriprotsessidesse juurutada? Siin on, kust alustada

Kavatsen kirjutada mitmeid artikleid uuest agiilse arendusmetoodikast Kanban (Kanban Development), et valmistuda Scandinavian Agile Conference 2009-ks, kus annan ühe ettekande (muide, kutsun kõiki ka konverents).
Täna avaldan esimesed artiklid.
Esimese artikli põhieesmärk on kirjeldada võimalikult lihtsalt Kanbani põhitõdesid: mis see on, kuidas see erineb teistest paindlikest metoodikatest ja miks seda vaja on.
Samuti sooviksin kommentaaridesse koguda võimalikult palju küsimusi ja kahtlusi, et neile tulevastes artiklites vastata, nii et kirjutage kõik, millest te aru ei saa, või midagi muud, mida soovite Kanbani kohta teada.
Ma ei ole selle uue metoodika alal just suur ekspert, kuid meeskonna sees jõudsime Kanbanini iseseisvalt ja läbisime järjekindlalt kõik mutatsioonietapid SCRUM-ist Kanbanini, seega on meil praktiline kogemus.

Kõigepealt kirjutan termini päritolust Kanban.

See termin jõudis meile Jaapanist tänu kitsastes ringkondades laialt tuntud Toyota tootmissüsteemile. Soovin, et võimalikult paljud inimesed loeksid sellest süsteemist ja sellesse põimitud põhiprintsiipidest - lean tootmine, pidev areng, kliendikesksus jne. Kõik need põhimõtted on kirjeldatud Taiichi Ohno raamatus Toyota tootmissüsteem, mis on tõlgitud vene keelde.

Mõistel Kanban on sõnasõnaline tõlge: "Kan" tähendab nähtavat, visuaalset ja "bann" tähendab kaarti või tahvlit.
Toyota tehastes kasutatakse Kanbani kaarte kõikjal, et vältida laod ja tööalade risutamist eelnevalt loodud varuosadega. Kujutage ette näiteks uste paigaldamist Toyota Corollale. Teil on teie töökoha lähedal 10 uksest koosnev pakk. Paned need üksteise järel uutele autodele ja kui pakki on jäänud 5 ust, siis tead, et on aeg uued uksed tellida. Võtad Kanban kaardi, kirjutad sellele tellimuse 10 uksele ja viid uste tegijale. Teate, et ta teeb need õigel ajal, et saaksite ülejäänud 5 ust tühjaks saada. Ja täpselt nii juhtubki – viimase ukse paigaldamisel saabub pakk 10 uut ust. Ja seda juhtub kogu aeg – tellite uued uksed ainult siis, kui neid vajate.
Kujutage nüüd ette, et selline süsteem töötab kogu tehases. Kusagil pole ladusid, kus varuosad nädalaid ja kuid istuvad. Kõik töötavad ainult nõudmisel ja toodavad täpselt nii palju varuosi kui soovitakse. Kui järsku on tellimusi rohkem või vähem, kohaneb süsteem ise muudatustega kergesti.

Kanbani kaartide põhieesmärk selles süsteemis on vähendada “käimasolevate tööde” hulka.
Näiteks võib kogu tootmisliinil olla täpselt 10 uksekaarti. See tähendab, et ühel hetkel ei ole liinil rohkem kui 10 valmis ust. Millal uusi uksi tellida ja kui palju on nende paigaldaja ülesanne. Ainult tema teab oma vajadusi ja ainult tema saab teha tellimusi uksetootjale, kuid ta piirdub alati 10-ga.
See Lean tootmismeetod leiutati Toyotas ja nüüd on paljud tootmisettevõtted üle maailma seda rakendamas või juba rakendanud.

Kuid see kõik on seotud tootmise, mitte tarkvaraarendusega.
Mis on Kanbani arendus seoses tarkvaraga ja mille poolest see erineb teistest paindlikest metoodikatest, olgu selleks siis SCRUM või XP?

Esiteks peate kohe aru saama, et Kanban ei ole konkreetne protsess, vaid väärtuste süsteem. Täpselt nagu SCRUM XP-ga. See tähendab, et keegi ei ütle sulle, mida ja kuidas samm-sammult teha.
Teiseks saab kogu Kanbani kirjeldada ühe lihtsa fraasiga - "Praegu pooleliolevate tööde vähendamine (käimasolevad tööd)".
Kolmandaks on Kanban veelgi “agiilsem” metoodika kui SCRUM ja XP. See tähendab, et see ei sobi kõigile meeskondadele ega kõikidele projektidele. Ja see tähendab ka seda, et meeskond peab olema veelgi rohkem valmis töötama agiilselt kui isegi SCRUM-i ja XP-d kasutavad meeskonnad.

Erinevus Kanbani ja SCRUMi vahel:
- Kanbanis pole millegi jaoks ajakaste (ei ülesannete ega sprintide jaoks)
- Kanbanis on ülesandeid rohkem ja neid vähem
- Kanbanis on ülesande tähtajad valikulised või üldse mitte
- Kanbanis pole "meeskonna kiirust" ja arvestatakse ainult ülesande täitmise keskmist aega

Vaadake nüüd seda nimekirja ja mõelge – mis jääb agiilsest metoodikast järele, kui eemaldame spurdid, suurendame ülesannete suurust ja lõpetame meeskonna kiiruse mõõtmise? Mitte midagi?
Kuidas saame üldse rääkida arenduskontrollist, kui võtame ära peamised kontrollivahendid – tähtajad, töökiirus ja spurdid? Minu jaoks on see küsimus peaaegu kõige olulisem.
juhid mõtlevad alati kontrollile ja püüavad seda saavutada, kuigi tegelikult pole neil seda kunagi. Arengu kontroll juhi poolt on väljamõeldis. Kui meeskond ei taha töötada, siis ükskõik kuidas te seda kontrollite, ebaõnnestub see projekt.
Kui meeskond naudib tööd ja töötab täie pühendumusega, siis pole kontrolli vaja, vaid ainult segab ja suurendab kulusid.
Näiteks SCRUM-i üldtuntud probleem on suured kulud aruteludele, koosolekutele ja suured ajakadud sprindi ristmikel (kui vähemalt päev kulub ühe sprindi lõpetamisele ja siis päev uue avamisele. Ja kui sprint on 2 nädalat, siis 2 päeva 2 nädalast on 20%, pagana palju). Seetõttu kulub SCRUM-i kasutamisel peaaegu 30-40% ajast protsessi enda ülalpidamisele - igapäevastele koosolekutele, 5% töötubadele, sprindi retrospektiividele jne. kolmkümmend%!

Kanbani arendus erineb SCRUM-ist eelkõige ülesannetele keskendumise poolest. Kui SCRUMis on meeskonna põhirõhk spurtide edukal läbimisel (peame tunnistama, et see on tõsi), siis Kanbanis on ülesanded esikohal.
Sprinte ei toimu, meeskond tegeleb ülesandega algusest lõpuni. Ülesande juurutamine tehakse siis, kui see on valmis. Valminud tööde esitlus - ka. Meeskond ei tohiks hinnata ülesande täitmiseks kuluvat aega, sest sellel on vähe mõtet ja see on peaaegu alati alguses vale.
Kui juht usaldab meeskonda, siis milleks teha ajaprognoosi? Juhataja ülesanne on luua prioriteetsete ülesannete kogum ja meeskonna ülesanne on täita sellest kogumist võimalikult palju ülesandeid. Kõik. Kontrolli pole vaja. Haldurilt pole vaja muud, kui lisada sellesse kogumi ülesanded või muuta nende prioriteeti. Nii juhib ta projekti.

Meeskond kasutab töötamiseks Kanbani tahvlit. Näiteks võib see välja näha selline (võetud):

Veerud vasakult paremale:

Projekti eesmärgid:
Valikuline, kuid kasulik veerg. Siia saate paigutada kõrgetasemelised projekti eesmärgid, et meeskond näeks neid ja kõik teaksid neist. Näiteks „Suurendage kiirust 20%” või „Lisa tugi Windows 7 jaoks”.

Ülesande järjekord:
See on koht, kus ülesanded salvestatakse ja need on alustamiseks valmis. Ülemine, kõrgeima prioriteediga ülesanne võetakse alati täitmiseks ja selle kaart liigutatakse järgmisse veergu.

Disaini arendamine:
See ja ülejäänud veerud kuni „Lõpetatud” võivad muutuda, kuna see on meeskond, kes otsustab, milliseid samme ülesanne läbib, et jõuda olekusse "Lõpetatud".
Näiteks võib see veerg sisaldada ülesandeid, mille kood või liidese kujundus pole veel selge ja mida arutatakse. Kui arutelud on lõpetatud, liigub ülesanne järgmisse veergu.

Areng:
Siin jääb ülesanne rippuma, kuni funktsiooni arendus on lõppenud. Pärast lõpetamist liigub see järgmisse veergu.
Või kui arhitektuur pole õige või täpne, saab ülesande tagasi eelmisesse veergu.

Testimine:
Ülesanne on testimise ajal selles veerus. Kui leitakse vigu, tagastatakse see arendusse. Kui ei, siis läheb edasi.

Kasutuselevõtt:
Kõigil projektidel on oma kasutuselevõtt. Mõne jaoks tähendab see toote uue versiooni postitamist serverisse ja teiste jaoks lihtsalt koodi hoidlasse sisestamist.

Valmis:
Kleebis läheb siia alles siis, kui kõik tööd ülesandega on lõpetatud.

Igas töös on kiireloomulisi ülesandeid. Plaanitud või mitte, aga need, mis tuleb kohe ära teha. Selliste jaoks saate eraldada spetsiaalse koha (pildil märgitud kui "Kiirendamine"). Saate Expedite'i panna ühe kiireloomulise ülesande ja meeskond peaks selle kohe täitma hakkama ja võimalikult kiiresti lõpule viima. Kuid sellist ülesannet saab olla ainult üks! Kui ilmub mõni teine, tuleb see lisada „Task Queue“-sse.

Ja nüüd kõige tähtsam. Kas näete iga veeru all numbreid? See on ülesannete arv, mis võib nendes veergudes korraga olla. Numbrid valitakse eksperimentaalselt, kuid arvatakse, et need peaksid sõltuma arendajate arvust meeskonnas.
Näiteks kui teil on meeskonnas 8 programmeerijat, saate reale "Arendus" panna numbri 4. See tähendab, et programmeerijad ei tee korraga rohkem kui 4 ülesannet, mis tähendab, et neil on selleks palju põhjuseid suhelda ja kogemusi jagada. Kui panna sinna number 2, võib 8 kahte ülesannet täitval programmeerijal tüdineda või raisata liiga palju aega aruteludele. Kui seate selle 8-ks, siis teeb igaüks oma ülesande ja mõned ülesanded jäävad tahvlile pikaks ajaks, kuid Kanbani põhieesmärk on vähendada aega, mis kulub ülesande üleminekuks algusest peale. valmis etapp.
Keegi ei anna täpset vastust, millised need piirid olema peaksid, aga proovi esmalt jagada arendajate arv 2-ga ja vaata, kuidas see sinu meeskonnas toimib. Neid numbreid saab seejärel kohandada vastavalt teie meeskonnale.
“Arendajate” all ei pea ma silmas mitte ainult programmeerijaid, vaid ka teisi spetsialiste. Näiteks veeru „Testimine” puhul on arendajad testijad, kuna testimine on nende kohustus.

Sellisel tahvlil olevad ülesanded ei ole lihtsalt ülesanded, vaid see, mida nimetatakse minimaalseks turundusfunktsiooniks, st funktsiooniks, mida saab klientidele "müüa".
Rahaturufondide jaoks hea test on küsida endalt: "Kas ma kirjutaksin sellest funktsioonist ettevõtte ajaveebis?" Kui ei, siis see pole rahaturufond.

Mida uut ja kasulikku selline limiitidega tahvel annab?

Esiteks, Paralleelsete ülesannete arvu vähendamine vähendab oluliselt iga üksiku ülesande täitmise aega. Pole vaja ülesannete vahel konteksti vahetada, erinevaid üksusi jälgida, neid ajastada jne. - tehakse ainult seda, mida vaja. Sprindiplaneerimist ja 5% töötubasid pole vaja korraldada, sest veerus “ülesannete järjekord” on planeerimine juba tehtud ja detailne töö ülesandega algab AINULT siis, kui ülesannet hakatakse täitma.

Teiseks pistikud on kohe näha. Näiteks kui testijad ei tule testimisega toime, siis täidavad nad varsti kogu oma veeru ja uue ülesande sooritanud programmeerijad ei saa seda enam testimise veergu teisaldada, sest see on täis. Mida teha? Nüüd on aeg meeles pidada, et "me oleme meeskond" ja see probleem lahendada. Näiteks saavad programmeerijad aidata testijatel üht testimisülesannet sooritada ja alles siis uue ülesande vabasse ruumi teisaldada. See täidab mõlemad ülesanded kiiremini.

Kolmandaks saate arvutada keskmise ülesande täitmiseks kuluva aja. Kaardile saame märkida ülesande järjekorda lisamise kuupäeva, seejärel selle alustamise ja lõpetamise kuupäeva. Neid kolme punkti kasutades saab juba vähemalt 10 ülesande puhul arvutada keskmise ooteaja ülesandejärjekorras ja keskmise ülesande täitmise aja. Ja nendest numbritest saab juht või tooteomanik juba välja arvutada, mida tahab.

Kogu Kanbani saab kirjeldada vaid kolme põhireegliga:
1. Visualiseerige tootmist
- Jaga töö ülesanneteks, kirjuta iga ülesanne kaardile ja aseta seinale või tahvlile.
- Tootmisülesande oleku kuvamiseks kasutage nimega veerge.
2. Piirata WIP-i( pooleliolev või samal ajal tehtav töö) igal tootmise etapp.
3. Mõõda tsükli aeg(keskmine aeg ühe ülesande täitmiseks) ja protsessi pidevalt optimeerida selle aja vähendamiseks.

Ainult 3 reeglit!
Näiteks SCRUMis on 9 põhireeglit. XP-s - 13 ja klassikalises RUP-is - koguni 120. Tunnetage erinevust.

Siin ma lõpetan esimese artikli Kanbanist.
Ootan teie tagasisidet ja kommentaare, samuti ettepanekuid tulevaste artiklite jaoks.

Finants- ja hangete ekspert, ScrumTreki prioriteetsete projektide arenduse juht Maria Denisenko räägib oma kogemusest meetodi rakendamisel ühe Venemaa ministeeriumi finantsosakonnas. Seda veergu tasub lugeda ka ettevõtete esindajatel, kes kavatsevad metoodikat oma projektides rakendada.

Mida ma tegema pidin?

Olles juba 2013. aastal liitunud Vene Föderatsiooni digitaalarengu, side ja massikommunikatsiooni ministeeriumi hangete talitusega, seisin silmitsi terve struktuuriüksuse tegevuse korraldamise protsessi valikuga. Tööd oli vaja korraldada “nullist” vastavalt uutele seadusenõuetele. Seadus nr 94-FZ asendati uue lepingusüsteemi seadusega - seadusega nr 44-FZ.

Minu ees ootas kaks ülesannet. Ühelt poolt oli vaja selgelt üles ehitada uutele standarditele vastav hangete korraldamise süsteem. Ja see tähendab: uusi protsesse, uusi dokumente, uusi elektroonilisi süsteeme, uusi inimesi. Teisest küljest oli vaja kõik need uuendused organisatsiooni praegusele reaalsusele peale suruda. Organisatsioonis olid ju teatud protsessid juba olemas ja isegi toimisid. Kohalikke tegusid oli mägi (üle kahekümne viie).

Seal oli spetsialistide kollektiiv – terve osakond. Kuid struktuuri ei olnud. Puudus tõhus parendusprotsess. Tegevuse eesmärgist puudus arusaam. Spetsialistid olid ülekoormatud.

Pärast üsna pikka kõigi olemasolevate hankeosakonna tegevust reguleerivate dokumentide (töötajate ametijuhendid ja struktuuriüksuste eeskirjad, hanke-vastuvõtukomisjonide moodustamise korraldused, ostude ja lepingute sõlmimise korraldused) uurimist ja küsitlusi. ministeeriumi töötajad, jõudsin järeldusele, et alustuseks tuleb kogu protsess visualiseerida. Mõista ja mõtesta seda, mis praegu on.

Millised olid probleemid?

Selle tulemusena selgus, et ühelt poolt on palju olulisi protsesse, mis on reguleerimata. Näiteks lepingu allkirjastamiseks üleandmine, kaebuse dokumentide läbivaatamise ajastus, põhjendamise protsess ja hangete planeerimine. Ja iga riigi- ja munitsipaalhangete valdkonna spetsialist teab, et mõnes neist olulistest toimingutest tehtud viga võib kaasa tuua konkreetse töötaja haldusvastutuse.

Teisest küljest on palju protsesse, mis ei ole täielikult seotud ostva struktuuriüksuse tegevusega, kuid mida teostavad selle töötajad. Näiteks tehniliste kirjelduste esmaste nõuete kujundamine, lepingu täitmisel osalemine.

Hangete osakonna töötajad funktsionaalsete klientidega (ministeeriumi struktuuriüksused) praktiliselt ei suhelnud. Ja see asjaolu tõi kaasa mis tahes ühiste või järjestikuste protsesside olulise suurenemise ja keerukuse. Juhtkond oli koormatud paljude mikrojuhtimisfunktsioonidega, mis blokeeris täielikult suuna strateegilise arendamise võimaluse. Pidev tellimuste allkirjastamine, lepingute kontrollimine, probleemide lahendamine ostuosakonna ja teiste hangetega seotud osakondade suhtluses.

Tööülesannete voog oli nii ebasüstemaatiline ja suur, et iga töötaja põhjendas "edukalt" töölepingu punkti, mis sätestas, et riigiametnik töötab "ebaregulaarse tööaja raames".

Mida ma olen teinud?

Teadmata veel, et Kanbani meetod on arenenud maailmas olemas, järgisin intuitiivselt juba selle põhimõtteid ja kasutasin selle praktikaid.

Visualiseeritud protsessid

See oli raske ja piisavalt pikk. Osa protsesse tuli sunniviisiliselt eemaldada seotud osakondade töötajatelt. Mõned said selgeks juba töö käigus. Selleks tuli suhelda töötajatega top 1 tasemest kuni tavalise spetsialisti tasemeni, visuaalselt välja rookida ebavajalik funktsionaalsus ning süsteem struktureerida. Kitsaskohad, mittevajalikud dokumendid ja vajadus uute töötajate järele tulid selgelt nähtavale.

Selgitas juhtkonnale "tõmbesüsteemi" põhimõtteid

Ja samas ehitas ta protsessid üles nii, et ministeeriumi tellimisosakonnad, kelle taotluste alusel hankeid läbi viidi, mõistsid selgelt, mis vahe on võetud ja edasilükatud kohustustel. Iga päevaga muutus “pühendatud sagedusriba” WIP limiit aina mõistlikumaks, kuni saavutas ühe ühiku normi. Me ei liikunud kohe „kõigest kiiremas korras” prioriseerimise ja tõmbamise juurde. Mitte kohe.

Juhtkonnal on raske selgitada, miks nende ülesannet pole veel võetud. Enamiku juhtide jaoks on nädalaid "töös" rippuvad ülesanded paremad kui hetkel tegelikult tehtav töö ja muud kohustuste täitmiseks ootavad ülesanded.

Kõige raskemateks ülesanneteks osutusid minu arvates prioriteetide seadmine ja voolu piiramine. See on ministeerium, nad ütlesid mulle, et siin on kõik oluline. Siin on kõik kiireloomuline. Ja igal telliva struktuuriüksuse juhil ja tollal oli neid umbes kaksteist, on õigus hankeüksusele ülesanne seada. Pärast aastast laiaulatuslikku tegutsemist jõudsime järeldusele, et ostuosakonna prioriteedid olen seadnud mina. Ja harvad kõned tipptasemel juhtidelt (aseministritelt) viisid prioriteedi muutmiseni või ülesannete lisamiseni eraldatud sõidurajale.

Töötasime koos juhtkonna ja meeskonnaga, et luua arusaam sellest, mida tähendab „eesmärgile sobiv” meie teenuse jaoks.

See oli süsteemi rike. Inimestel, kes töötasid väikesel alal, mida nad pidasid suure ministeeriumi “tehniliseks” tööks, oli raskusi eesmärgi ja kvaliteedi mõistmisega. Peaaegu kogu meeskond tuli välja vahetada. Pealegi oli spetsialistide valik suuna edasise arendamise edu võti. Seetõttu lähenesin sellele väga tõsiselt, võttes muu hulgas arvesse seaduses 79-FZ standarditud valikufunktsioone.

Töötajate vahetus on üsna tavaline nähtus, kui lähenemised tegevuste korraldamisel muutuvad. Uued ülesanded, töö uued omadused – mitte iga töötaja ei ole valmis kõigele sellele vastu pidama. Umbes aasta pärast töötajate arvu vahetust läksime üle uuele töösüsteemile: suletud kontorist avatud ruumiks pidevate arutelude ja koosolekutega, vastamata kõnedest kliendikesksuseni, dokumentide koostamisel tehtud vigade vabandustest meeskonda. nende kallal töötama. Ja kõik järgnevad töötajad olen ostuosakonda juba uue protsessi paradigma järgi välja valinud.

Töötanud rahulolematuse allikatega praeguses süsteemis ja rakendades tagasisideahelaid

Soovitan teil nendega pidevalt ja tihedalt koostööd teha. See on minu arvates progressi peamine mootor. Evolutsioonilise arengu põhimõtte rakendamine. Enne seda lihtsalt ei aktsepteeritud selle organisatsiooni sidusrühmadelt tagasiside kogumist. Keegi ei kutsunud tagasisidet muuks kui "kaebusteks". Ja kõik need kaebused vajusid igaveseks juhtkonna varju, mille tulemuseks olid töötajatele vaid isiklikud noomimised.

Saime regulaarselt tagasisidet organiseeritud kanalite kaudu (teenusetaotlused juhtkonna tasemele, poolametlikud koosolekud, kvaliteedikontrolli kõned). Muutsime selle süsteemiks. Ja sellise ühistöö tulemusena struktureeriti ministeeriumi lepingulise teenuse protsessid, mis hõlmas viimastel andmetel umbes 80 töötajat.

Samuti on väljakutseks olnud juhtimisoskuste arendamine

Olukorra muutis keerulisemaks asjaolu, et töö spetsiifikat arvestades ei kandnud igal töötajal pelgalt vastutust, vaid vastutust, mida toetas haldusvastutus (kõik hankevaldkonna rikkumised kvalifitseeritakse vastavalt lepingu vastavale artiklile). haldusseadustik). Süsteemis, kus "boonused" sisaldavad ainult ministri tänu ja vastutust 3-50 tuhat rubla iga rikkumise eest, ei tahtnud keegi olla "juht".

Algul andsin väikestes rühmades väikseid ülesandeid. Hiljem suurendasid kolleegid spontaanselt probleemi lahendamisega seotud töötajate arvu. Korraldasime töötubasid ja ajurünnakuid. Korraldanud töötajate sisekoolitusprojekte. Kasvatasime mentorinstituuti, kui ostuosakond täienes uute töötajatega.

Peagi muutus koos töötamine igapäevaseks. Nüüd täitsid peaaegu kõiki ülesandeid (andsid või juhendasid) mitu töötajat. Vigade arv on vähenenud (peaaegu viis korda) ja töö kiirus igal objektil suurenenud. Hakkasime õigel ajal koju minema, jättes välja hooajalised eelarve koostamise ja planeerimise perioodid.

Jõudluse parandamiseks reeglite koostamisel puutusime kokku ka teatud raskustega

Pärast protsessi visualiseerimist ja töö testimist WIP limiite arvestades otsustas juhtkond protsesse reguleerida (no kus oleks riigiasutus ilma selleta). Ja kõik hilisemad muudatused tuli läbi viia kooskõlastuste kaudu. Kuid paindliku lähenemisviisi üldist paradigmat järgides olid sellised heakskiitmised üsna valutud. Ja need said minu tasemel osaliselt lahendatud.

Oleme koostanud lepingulise teenuse reeglid. See on protsessidokument, mis loodi pärast protsesside visualiseerimist ja sidumist seadusandlike normidega, samuti pärast funktsionaalsuse ümberjaotamist. See oli elus, allutati pidevatele muudatustele, mis põhinesid silumisprotsesside tulemustel, samuti seadusandlike normide muutumise korral.

Ülesannete väljatõmbamise printsiibi muutsid algstaadiumis oluliselt keerulisemaks hanke seadusandlikud iseärasused

Nendel protsessidel on seaduses nr 44-FZ sätestatud ranged tähtajad ja selge rakendusprotsess. Kõik on reguleeritud: hankeplaani ja hankegraafiku koostamine ja avaldamine, hanketeate avaldamise ja dokumentatsiooni postitamise aeg, osalejate taotluste läbivaatamise aeg ja lepingu allkirjastamise aeg. Selle kõige korreleerimine WIP-i piirangutega ja ideaalse tarnekiiruse väljatöötamine ei ole lihtne ülesanne. Ja võttes arvesse seadusandluse pidevaid muutusi, ei tööta selline süsteem ilma pideva evolutsioonilise arenguta üldse.

Mis on tulemus?

Aja jooksul õnnestus mul Kanbani meetodi õppimise protsessis süstematiseerida, süvendada ja laiendada kogu teadmiste ja kogutud kogemuste terviklikkust. Selgus, kui oluline on kasutada mõnda varem arvestamata protsessi. Mõõdikute valikut on oluliselt laiendatud. On olemas arusaam meetodi rakendatavuse laiusest. Põhiprintsiipide süsteem oli täielikult üles ehitatud (nüüd ma mitte ainult ei mõistnud neid, vaid võin need hõlpsasti teistele selgeks teha).

Enam kui viieaastase töökogemuse põhjal võin teha selge järelduse, et kanban saab finantsplokis tõhusalt töötada. Lisaks hõlbustab see oluliselt finantsüksuse suhtlemist külgnevate struktuuriüksustega.

Ülaltoodud põhimõtete ja tavade kogumit saab kasutada lühikese juhendina Kanbani rakendamisel finantsosakonnas. Samal ajal juhin teie tähelepanu asjaolule, et selles artiklis me ei puudutanud kanbani (S.T.A.T.I.K.) rakendamise süstemaatilise lähenemise üksikasjalikke aspekte. Seda teemat käsitleme eraldi artiklis.

Kahjuks ei saanud ma protsesse laiemale teenustevalikule skaleerida. Kuid finantsosakondadega külgnevates plokkides on kanbani meetodi kasutamine ka avaliku sektori iseärasusi arvesse võttes võimalik ja efektiivne. Ja peagi jagame teiega sellise juhtumi tulemusi.

Kambani juhtimine tähendab majanduspraktikas sellist äritegevuse korraldamist – olgu selleks siis tootmine, logistika või jaemüük –, mida võib iseloomustada kui just-in-time süsteemi. Mõiste "Kanban" ise, mis on jaapani keelest tõlgitud kui "nähtav kaart", sisaldab lähenemist äri optimeerimisele, jagades toiminguteks ja visualiseerides tööprotsessi. Ja kuigi Toyota kasutas Kanbani filosoofiat esmakordselt rohkem kui pool sajandit tagasi, töötas selle meetodi selle tänapäevases tähenduses välja ja pakkus välja majandusteadlane David Anderson.

Mis on Kanbani süsteem?

Majandusteadlane David Anderson jõudis 2005. aasta kevadel Tokyos keiserliku palee idapoolsetes aedades jalutuskäiku tehes järeldusele, et turistidele mõeldud korduvkasutatavad mitmevärvilised plastpiletid, nimega Kanban, võivad saada majandustegevuse vahendiks. ebakindluse tingimused. Jalutuskäiku tehes ja Kanbanis turnides lõpetas ta sisuliselt "mõttelise töö". Kontrollerid tegid spetsiaalsele veergudega tahvlile märkmeid külastajatele kaartide väljastamise ja tagasisaamise kohta.

Anderson jõudis järeldusele, et kaartide ja veergude kaudu on võimalik näiteks kontrollida laoseisu või kauba tarnimist. Tänu just-in-time kontseptsioonile on võimalik minimeerida materjalikulusid ja optimeerida müüki. Midagi sarnast kasutati Toyota masinaehituse tootmises juba eelmise sajandi 60ndate lõpus, kuid siis oli samaaegselt sooritatud ülesannete arv minimaalne, töö tehti range algoritmi järgi.

Seega nägi Anderson Kanbani tahvlit väärtusliku tootmisvahendina, mida ta kirjeldas raamatus Kanban: Successful Evolutionary Change for Your Technology Business.

Mida teeb Kanban tootmiseks?

Seega on David Andersoni sõnastatud Kanbani metoodika evolutsiooniline ülesannete haldamise protsess, mis hõlmab töö (tarnete) täpset korraldamist.

"Peamine põhimõte on see, et igasugune töö ei tohiks olla asjatu," ütleb majandusteadlane Maxim Yurkin. - Kanban võimaldab ärimehel optimeerida projekti etappe juba enne selle algust, lähtudes tema käsutuses olevast visuaalsest teabest sarnase töö lõpetamise kohta. See on see, millele "lahja tootmine" on üles ehitatud.

Kui võrrelda tootmisprotsesse enne ja pärast Andersoni metoodika juurutamist, näeme, kuidas materjalikulud päevast päeva vähenevad. Samas juhinduvad töötajad Kanbani kaardil olevast kirjest “Tehtud” (“tehtud”) “just in time”. Andersoni meetodit rakendanud ettevõtjad teatasid oma äri kasumlikkuse kasvust 25-30% – ilma suuremate investeeringuteta. Aja jooksul muutub Kanbani meetod keskmise ja väikese suurusega ettevõtetes laialdasemalt ja nõudlikumaks.

Kuidas Kanbanit ettevõttes tutvustada?

Venemaa meedias ilmunud publikatsioonide analüüs näitab, et paljudel juhtudel tähendab Kanbani juurutamine „just-in-time“ tarnesüsteemi integreerimist, mis kasutab spetsiaalseid tahvleid veergudega „to do“ (algas tööd), „in“. edusammud” (töötamine), “ülevaatus”” (töö läbivaatamine), “test” (tulemus), “tehtud” (lõpetatud). Seega kontrollitakse kõigi töötajate tegevust ja ei tohi tekkida olukorda, kus ühel töötajal on kogunenud tohutult palju täitmata ülesandeid, teine aga istub jõude.

Andersoni raamatu venelasest lugeja võib arvata, et Kanban on intuitiivne. See on nagu vankri hobuse ette panemine, sest traditsiooniline planeerimine käib nullist. See meetod julgustab "lõpetama alustamist ja alustama lõpetamist".

4 Kanbani põhimõtet

JIT-süsteemi mõistmiseks ja edukaks juurutamiseks oma ettevõttes peate tähelepanu pöörama üheksale Kanbani põhiasjale: 4 põhimõttele ja 5 reeglile. Alustame põhimõtetega:

Hinda alati seda, mida teed.
Olge valmis evolutsioonilisteks muutusteks.
Austage rolle, kohustusi ja tiitleid.
Julgustage mitteametlikke juhte.

Fakt on see, et Kanbani kontseptsioon ei paku "raua" seadeid, veel vähem ette "terapeutilisi" protseduure. Seetõttu soovitab Anderson olemasolevale töövoogudele lisada reegleid, mida tuleb tootmises igapäevaselt järgida. Pange tähele, et Kanbani meetod hõlmab vähima takistuse tee järgimist. Teisisõnu julgustab see praeguses süsteemis pidevaid järkjärgulisi ja evolutsioonilisi muudatusi, kuna revolutsiooniline muutus seisab silmitsi märkimisväärse vastupanuga – nii töötajate kui ka klientide poolt.

David Anderson julgustab väärtustama olemasolevaid äriprotsesse, aga ka töötajate rolle, ametinimetusi ja kohustusi. Teisisõnu, kui mõned protsessid protseduuri sees on õigesti sooritatud, siis tasub need salvestada. Nende moderniseerimise juurde saate naasta hiljem, kui muid protsesse täiustatakse. Oluline on mõista, et järkjärguline muutus ei tohiks tekitada hirmu, mis takistaks edasiminekut. Vajalik on kokku panna meeskond, mis võimaldaks ärimehel uusi tooteid laialdaselt tutvustada ja seeläbi hõlbustaks Kanbani kontseptsiooni elluviimist.

Samuti märgitakse, et igas meeskonnas on inimesi, kes naudivad autoriteeti, isegi kui neil pole kõrgeid positsioone. Neid aga kuulatakse ja austatakse. Nende karjääri kasvu on mõistlik edendada. Selliste mitteametlike juhtide julgustamine avaldab positiivset mõju ettevõtte kui terviku tervisele.

5 Kanbani reeglit

Lisaks neljale põhimõttele kirjeldas David Anderson oma raamatus “Kanban: Successful Evolutionary Changes for Your Technology Business” 5 põhireeglit, millest edukad ärimehed kinni peavad:

Töövoo visualiseerimine.
Pooleli tööde piirang (WIP – Work-In-Progress).
Töövoo juhtimine.
Muudatuste selgus ja läbipaistvus.
Koostöö parandamine (mudeleid ja teaduslikku meetodit kasutades).

Räägime reeglitest üksikasjalikumalt. Kuna Kanbani eesmärk on järjepideva optimeerimise kaudu töövoogu positiivselt muuta, tuleb ennekõike vastata põhiküsimusele: mis on ettevõtte evolutsiooni eesmärk? Seda saab teha alles pärast protsessi toimimise mõistmist. Alles siis on soovitatav proovida integreerida just-in-time kontseptsiooni.

Äriprotsesside visualiseerimine on väga tõhus meetod. Visualiseerida saab nn Kanbani tahvli või LeanKiti platvormi abil. Pange tähele, et LeanKit toetab säästliku tootmise põhimõtete juurutamist, et luua tingimused äriprotsesside pidevaks täiustamiseks ja uuenduste integreerimiseks.

"Visualiseerimismeetodid on sama mitmekesised kui optimeeritavad töövood," selgitab Maxim Yurkin. "Lisaks töövoogudele ja täitmisajale võib tegevuste klassifitseerimisel kasutada muid kriteeriume, nagu tururisk ja viivituskulud."

Kui visualiseerite oma töövoo õigesti, leiate hõlpsalt WIP-i fragmente, mida nimetatakse "ärimõrvariteks".

"See tähendab, et võitlus poolelioleva töö vastu peab jätkuma kogu tööprotsessi vältel," kirjutab David Anderson. - Kuna õigel ajal tegemata töö „viib“ negatiivse järgmisse etappi ja seejärel kahekordistab negatiivse järgmisele sammule. Ja see on nagu lumepall. WIP-i vähendamine nullini on Kanbani nurgakivi.

Tagasiside on väga oluline. Kui olete muudatused teinud, peate veenduma, et olukord on tõepoolest paranenud.

„Kanbani meetod on põnev teekond, kui sa ei tea, kuhu sa välja jõuad,“ tuletab David Anderson meelde. "Ühe probleemi lahendamine võib teise halvendada."

Et muudatuste elluviimise protsess ummikseisu ei satuks, peab see olema arusaadav kõigile projektis osalejatele. Sellega seoses on loogiline tsiteerida teist Andersoni tsitaati: „Ilma selge arusaama, kuidas asjad peaksid toimima, kipub igasugune probleemide arutelu olema emotsionaalne, anekdootlik ja subjektiivne. See on sama tõsi kui põlvnemisreaktsioon."

Kanbani meetodi puhul on võtmemõisteks Kaizen, mis tähendab pidevat, järkjärgulist ja positiivset muutust.

"JIT-i integreeriv ärimees peab mõistma, mis Kaizen on," ütleb Anderson. "Kui te ei ole pühendunud täiustamisele, pole Kanbani rakendamisel mõtet."

Kanban vs. Agiilne

On selge, et Kanbanil on oma halvustajad, väites, et teised mõisted on paremad. Samal ajal soovitavad eksperdid mitte segi ajada Andersoni meetodit teiste tunnustatud juhtimissüsteemidega – nende sõnul on see nagu õunte võrdlemine apelsinidega. Kõige sagedamini on Kanbani kontseptsioon vastu:

Agiilne;
Scrum;
lahja;
Kuus Sigma;
PRINTS2.

Samal ajal on Kanban ja Agile sarnased nagu vennad, ainsa erinevusega, et Anderson pakkus välja laiema meetodi, samas kui Agile keskendub rohkem IT-projektidele. Mõlemad meetodid hõlmavad evolutsioonilisi muutusi, kuigi esimesel juhul on ärimehe roll Agile Manifesti järgi võrreldamatult olulisem kui töötaja staatus.

Kui Kanban hõlmab lepitamatut võitlust poolelioleva töö vastu, siis agiilne filosoofia on selles osas liberaalsem, kuna seab esikohale paindlikkuse – valmisoleku muudatusteks, mis on “tähtsamad kui algne plaan”.

Programmeerijad vaatavad tõenäolisemalt "mahajäetud alamprojekte", kui leitakse optimaalsem tarkvaraarhitektuur. Ettevõtted Dostaevsky, Chernika, uKit Group ja teised võivad teile öelda, et Kanban on Venemaal tõhus meetod.

Järeldus

Kanban on intuitiivne viis töövoo korraldamiseks, mis aitab ärimehel teha rohkem ja töötada kiiremini. Kuid süsteem “just in time” ei ole imerohi kõigi probleemide jaoks, vaid tööriist, mida tuleb osata õigesti kasutada, tehes iga päev tööprotsessis peeneid muudatusi, mis koos annavad tulemusi.

Pange tähele, et Kanban on ebaefektiivne keerukates mitmetasandilistes tehnoloogilistes süsteemides, kuid on peaaegu ideaalne väikestele ja keskmise suurusega ettevõtetele.

Mis on kanbani metoodika ja kuidas see aitab teil ülesandeid õigeaegselt täita?

Pideva multitegumtöö ja suure klientide arvu tingimustes saab iga süsteem varem või hiljem ülekoormatud. Tähtajad hakkavad mööda minema, ootused ei täitu ja süsteem muutub kaoseks. Täna teen ettepaneku tutvuda sellise metoodikaga nagu kanban. Selline lähenemine lubab tõhusalt eraldada ressursse ja lahendada kõik meie probleemid. Kontrollime.

Hetk kanbani ajaloost

Kabani idee aluse leiutas Toyoyta Motors. Autotootja kandis suuri kahjusid tootmisliini varude ja võimsuse ebaõige jaotamise tõttu. Mõned tootmisetapid võisid olla jõude ja mõned olid ülekoormatud.

1959. aastal pakuti välja tootmisjuhtimissüsteem, mis võimaldas tasakaalustada kõiki liini sektsioone. Põhiprintsiip oli see, et igas etapis postitasid töötajad vajaliku arvu osadega kaardid, mis edastati järjest edasi. Iga tootmisliinil järgmine töötaja võttis eelmisest täpselt nii palju osi, kui talle kaardil oli ette nähtud.

Nii oli igal osal kaart ja ülejääki ei saanud lihtsalt tekkida. Seetõttu ei kasvanud varud piirkondades ja iga järgnev töötaja sai täpselt nii palju osi, kui vaja.

Sõnastame, mis on kanban ja rakendame seda Interneti-toodete arendamisel.

Kanban on lean tootmise juhtimissüsteem (jaapani keeles "signaal"/"kaart"), mis kasutab teabekaarte tellimuste edastamiseks kõigis tootmisetappides. Lihtsamalt öeldes jälgime toote kogu teekonda ideest kuni poeriiulile jõudmiseni.

Ülal on kanbani tahvel. See on peamine tööriist ülesande oleku kuvamiseks. Peamine põhimõte: näeme, millises tootmisprotsessi etapis konkreetne ülesanne asub. Lisaks jälgitakse aega kõigis valdkondades, see tähendab, et saate alati süsteemist leida “ ” ja nendega töötada.

Veergude arvu määrate ise, lähtudes oma projekti omadustest. On oluline, et need on peamised etapid, mille teie toode läbib. Ülaltoodud näide on pluss või miinus peamised etapid, mille veebitoode läbib.

Metoodika rakendusala on väga lai. Kanbanit kasutatakse projektide elluviimiseks, müügijuhtimiseks, tootmisliinideks, IT arendamiseks ja isegi oma elu korraldamiseks.

Vabandust lugemise katkestamise pärast. Liituge minu telegrammi kanaliga. Värsked teadaanded artiklite, digitaalsete toodete arendamise ja kasvu häkkimise kohta – see on kõik olemas. Ootan sind! Jätkame...

Kanbani põhimõtted

Ülesannete visuaalne kuvamine. Kõik ülesanded tuleb esitada kaartidena ja kajastada tahvlil. Väga oluline on ülesannete oleku värskendamine. Näiteks kui arendajad valmistasid koodi ette ja esitasid selle testimiseks, siis peaks ülesandekaart minema vastavasse veergu. Seega näeb iga meeskonnaliige igal ajal, millises etapis ülesanne on.
WIP-i (käimasolevad tööd või samaaegselt tehtud tööd) veergude piirang igas tootmisetapis. Tagamaks, et süsteem varem või hiljem ei lämbuks ülesannete voost, on vaja seada piirangud. Näiteks ülaltoodud kanban-tahvlil veerus Analüüs (analüütika) töötab meil 2 inimest ja nad saavad hakkama mitte rohkem kui 2 ülesandega, pole mõtet neid rohkem laadida, kuna süsteemi järgnevad etapid on jõude. Veergude piirangud valitakse empiiriliselt.
Keskenduge täitmata ülesannetele. Ülesannetega tahvlit vaadates pöörake ennekõike tähelepanu nendele ülesannetele, mis ühes või teises veerus “ripuvad”. Kui mõni etapp võtab teie jaoks kõige rohkem aega, proovige võimalusel ressursse ümber jagada või inimesi lisada.
Pidev täiustamine. Kui olete süsteemi koormuse tasakaalustanud, on teil lihtsam kogu protsessi jälgida. Mõõtke tsükli kestust (kui kaua ülesanne ripub eraldi veerus ja kui kaua see jõuab hetkest Teha kuni valiku Valmis avaldamiseni). Muutke süsteemi koormusi ja vähendage kõigi etappide läbimiseks kuluvat aega.
Pöörake tähelepanu detailidele. Näiteks kui kood, mida arendajad perioodiliselt kirjutavad, ei läbi testimist ja see tagastatakse ülevaatamiseks, siis võib-olla on võimalusi arenduse kvaliteedi parandamiseks, et testida saaks kvaliteetsemat toodet?

Kanbani lähenemisviis võib tunduda idealistlik, kuid ma kinnitan teile, et selle põhimõtted annavad tulemusi. Kõigepealt peate metoodikat oma olukorraga kohandama ja seejärel süsteemi lihvima.

Kanbani tööriistad

Või kus kanbani tahvlit hooldada.

Exceli tabelid
Tahvel kleebistega
Veel üks fantaasia...

Tegelikult on võimalusi palju, võid googeldada ja inspiratsiooni ammutada. Peaasi, et sul oleks see tahvel ja kõik protsessis osalejad näeksid, mis ülesannetega hetkel toimub.

Kanban-plaatide näited

Siin on seinal rippuv tahvel, kus iga ülesanne kajastub kleebistel.

Või võib see olla pilveteenus nagu Trello.

Selle kohta, milliseid vahendeid ja võimalusi oma töös kasutada, on mitmeid arvamusi, kuid see on enamasti maitse küsimus. Proovige lihtsalt erinevaid lahendusi ja leppige sellega, mis teile kõige rohkem meeldib. Mõte on alustada kanbani kasutamist ja mitte jääda toppama võimalikult ilusa plaadi kasutamisele.

Minu arvamus on järgmine: ajurünnakuks või võrguühenduseta juhtumitega töötamiseks sobib hästi tavaline kleebistega tahvel. Aga igapäevaseks tööks tuleb loomulikult kasutada pilvelahendust nagu Jira, Kanbantool, Trello jne. Nendes saab kogu meeskond ülesannetele kommentaare lisada, neid veergude kaupa liigutada ja palju muud.

Nüansid/mõtted

Kui rääkida internetitoodetest, siis kanban toimib, aitab ja täiustab, kuid siin on mitmeid murekohti või nüansse, millega tuleb arvestada.

Tõenäoliselt võib WIP-i piirangute kehtestamine veerule projektijuhtimise meeskonda veidi ehmatada. Lõppude lõpuks, kuidas saab kindlaks teha, kui palju ülesandeid arendaja või näiteks testija suudab paralleelselt lahendada? Mis siis, kui kehtestame piirangud ja need lihtsalt rahunevad?

Näete, kui inimene pole täielikult koormatud, pole see halb. Ta oskab uurida ja analüüsida tehtud tööd, leida puudusi ja neid parandada ning isegi puhata. Lisaks saate aidata oma kaaslasi protsessi teistest osadest (veerud), täpsemalt allpool.

Kanabani gurude sõnul töötab süsteem ideaalselt ristfunktsionaalsetes meeskondades. No midagi sellist, et kui midagi teha pole, mine kaastöölist appi. Tõsi, selleks, et panna kokku meeskond, kus arendajad saavad olla testijad ja vastupidi ning süsteemiarhitekt aitab disainerit, tuleb välja käia palju raha ja kas see on seda väärt?

Muidugi on tore, kui meeskonnaliikmed üksteiselt õpivad ja saavad kuidagi aidata, kui midagi juhtub. Kuid selleks, et see tingimus oleks täidetud, on vaja väikseid meeskondi, kes eelistatavalt istuvad kuskil läheduses ja suhtlevad pidevalt. Suurte projektide puhul on sellist kogemustevahetust raske korrata.

Seetõttu kaldun rohkem oma oskusi lihvima, kui mul on mõni vaikne hetk. Vaadake, mida tegite, mõelge, kuidas saate seda parandada, lugege kasulikke artikleid. Inimene on elusorganism, mitte hammasratas konveieril.

Kokku

Vaatasime kanbani metoodikat ja nüüd loodan, et saate aru, kuidas seda oma projektis rakendada. Proovige jagada oma protsessid põhietappideks ja optimeerida süsteemi saadud teadmiste põhjal.

Kas olete kunagi proovinud gruppi inimesi kokku kutsuda toote loomiseks või projekti käivitamiseks? Boonusteks: pingeline tähtaeg, mahukas tehniline ülesanne ja lahendamatu klient. Juhtus? Kui jah, siis ei pea te rohkem lugema.

Meeskonna juhtimine pole lihtne. Eriti digitaalselt. Tööd on vaja korraldada nii, et toote kvaliteet oleks kõrge, tähtaegadest kinni peetud, meeskonnas mugav, klient rahul. Oluline on vältida konflikte ja pidevalt arendada meeskonda.

Pole olemas võlupilli, mis lahendaks kõik probleemid korraga. Kuid on meetodeid ja süsteeme, mis aitavad protsessi lihtsustada. Üks neist on Kanban.

Mis on Kanban

Kanban on arendusprotsesside täiustamise meetod ja osa agiilse filosoofiast. See põhineb Agiilse tarkvaraarenduse manifestil.

Agiilse tarkvaraarenduse manifest

Kanbani eesmärk on saada valmis kvaliteetne toode õigeaegselt. Mõtleme välja, kuidas seda saavutada.

Kanban alustab visualiseerimisest, et tööprotsess oleks meeskonnale nähtav. Selleks kasutage spetsiaalset tahvlit ja kaartide või kleebiste komplekti.

Tahvel on agiilse metoodika jaoks kohustuslik element. See on Scrumis, see on ka Kanbanis. Igal meeskonnaliikmel on sellele juurdepääs igal ajal ja ta näeb, millises etapis ülesanne on.

Tahvel võib olla reaalne või virtuaalne: saate kasutada lihtsat korktahvlit või selliseid programme nagu Trello.

Kanbani tahvel on universaalne tööriist, mida saab kohandada mis tahes protsessiga ja rakendada igas valdkonnas. Näiteks koostage ülesannete nimekiri.

Kõigepealt peate analüüsima tööprotsessi ja jagama tahvli veergudeks, mis kajastavad toote loomise etappe. Näiteks IT-projekti loomise protsessi etapid võivad olla järgmised:

Veergude nimed võivad olenevalt projektist muutuda, kuid on oluline, et need oleksid järjepidevad. Tahvel peaks täielikult kajastama väärtuse loomise protsessi, mida Kanbanis nimetatakse vooluks.

Kanbani kaardid on ülesanded, mida meeskond vastavalt oma staatusele laual liigub. Kaartide arvu saab muuta. Kirjutage kaardile või kleebisele ülesande nimi ja kinnitage see tahvli algusesse.

Kanban tahvli abil saab meeskond juhtida mitut projekti korraga, kasutada erinevat värvi kaarte: üks värv - üks projekt.

Kuidas visualiseerimine aitab

Koormust kontrollides on võimalik tulemusi saada täpselt õigel ajal. Selleks peate piirama ülesannete arvu.

Kanbani tahvli üks veerg sisaldab samaaegselt nii palju ülesandeid, kui palju meeskond tegelikult määratud aja jooksul täidab. Näiteks olekus "Disain" pole korraga rohkem kui kaks ülesannet ja veerus "Testimine" on ainult üks. Meeskond valib arvu vastavalt oma võimalustele.

Näide

Praeguse ülesandega pole arendaja veel lõpetanud, kuid järgmise on ta juba saanud. Tal pole aega ja ta pidurdab kogu tööd.

Lahendus: Lõpetage ülesannete arendusse andmine ja andke programmeerijale aega töö lõpetamiseks.

Oluline on leida tasakaal: valida töötempo, mis on meeskonnale mugav ega kahjusta projekti tähtaegu. Selleks arvestab Kanban iga ülesande täitmise aega. Nii saab meeskond aru, mis võtab rohkem aega ja mis vähem aega ning oskab tööd õigesti korraldada.

Näide

Toote testimise etapis on tekkinud raskusi ja selleks on vaja rohkem aega.

Lahendus: saate teada, millise osa tööst saab kiiremini teha ilma kvaliteeti kaotamata. Või töötaja, kes on vaba ja aitab testijat.

Kõik protsessid kajastuvad tahvlil ning meeskond analüüsib neid ja kõrvaldab nõrgad kohad. Kanbanis nimetatakse seda voolu juhtimine.

Kanbani kasutamiseks ei piisa ainult kaartidega laua riputamisest. Meeskond peab teadma reegleid, mille järgi ta töötab.

See puudutab ka protsessi läbipaistvust: kui töö on nähtav ja tulemus kõigile selge.

Oluline on ühtsus, pidev tootearendus ja töötajate arendamine. Kanbani meeskond on üks mehhanism. Kui keegi ebaõnnestub, siis kannatab ühine põhjus. Töö on planeeritud tahvlile, kogu protsess on nähtav, nii et igaüks näeb oma panust ja väärtust projekti.

Kanban ühendab endas agiilse metoodika ja lahja mõtlemise põhimõtted. Siin pole karme reegleid ega drastilisi muutusi, kuid on põhimõtteid, millele saate toetuda.

Kuidas mitte segi ajada Kanbanit ja Scrumit

Kanban on sageli segaduses või segamini agiilse metoodikaga Scrum. Et teiega seda ei juhtuks, vaatame, millised on peamised erinevused.

Scrum on paindlik projektijuhtimise metoodika ja Kanban- meetod mis tahes metoodika täiustamiseks.

Ei mingeid koosolekuid

Vaja on lähtepunkti

Kitsa profiiliga meeskonnad saavad töötada

Järjepidevad ja sujuvad muutused

Meeskonnas rollideks jaotust ei ole

Toimuvad koosolekud

Lähtepunkti pole vaja

Meeskond on Scrumi juba juurutanud, kuid soovib protsessi täiustamist jätkata. Siin tuleb taas kasuks Kanban.

Vahet pole, millist arendusmetoodikat meeskond kasutab, kuid Kanbani juurutamiseks on vaja lähtepunkti.

Kuidas Kanbanit rakendada

Kui otsustate Kanbani kasutada, peate olema kannatlik ja õppima enesedistsipliini. Te ei tohiks häälestuda radikaalsetele muutustele ja rakendada kõiki tavasid korraga. Kanbani eesmärk on järjepidev ja sujuv täiustamine. Võimalik, et soovitud tulemuse saavutamiseks ei pea te kõiki tööriistu kasutama.

Võtame selle kokku

Nüüd teate, mis on Kanbani süsteem, mille poolest see Scrumist erineb ja kuidas seda kasutada saab. Ja oleme valmis kontrollima kõike, mis toimib. Teooria on hea, aga praktikat on vaja. Ja parem on harjutada, kartmata, et üks vale liigutus võib teie praktikat kahjustada. Seega, mis uuendab teid projektijuhtimises. Suudad oma töösse rakendada mis tahes agiilseid süsteeme ja olla tulemustes kindel.