Kuidas jaapani tootmine mõjus?: Lühike seletus teemal Scrum vs Kanban

Toodetest rääkides mõtleme neile kahel erineval viisil - kas füüsiliste toodetena, mida toodetakse, või tarkvaratoodetena, mille on välja töötanud tarkvaraarendajad. Hoolimata sellest, et tootmissektoril ja tarkvaraarenduse sektoril on täiesti erinevad struktuurid ja protsessid, on need kaks teineteist juba pikka aega üksteise vastu õppides toitnud ja ma tahan rääkida ühest sellisest juhtumist.

Kaks suurt ideed: vilgas ja lahja

Agiilne tarkvaraarendus tõusis esile 1990. aastate lõpus tarkvara arendamisega, kasutades rakendusi Rapid Application Development (1991), Scrum (1994) ja Extreme Programming (1996). 2001. aastal seadis rühm silmapaistvaid arendajaid agara metoodika kivisse, avaldades Agiilse tarkvaraarenduse manifesti, mida saate praegu näha Agile Manifestos. Filosoofia keskendus toimiva tarkvara pakkumisele klientidele tihedas iteratsioonis, mis parandas arendajate ja klientide vahelist koostööd. Praegu juga taga kasutatavaim tarkvaraarenduse filosoofia Agile on Scrumi juht, metoodika, mis keskendub „sprintidele“, mida arutame hiljem.

Lahja tootmine toodi välja 20. sajandi lõpus, tuginedes Jaapani filosoofia Just-in-Time õpetustele, mille teerajajaks oli Jaapani autohiiglane Toyota.

Seda filosoofiat, mis tõstis esile muda (jäätmete) kõrvaldamise, juhtis Toyota Production System, mis andis Jaapani tootjatele tohutu konkurentsieelise, mis ületas USA tootmist “kaizeni” kaudu (pidev täiustamine). Toyota käsitles jäätmeid kui kõike muud, mis ei andnud kliendi jaoks väärtust, seetõttu keskendus tootmisahel mitteväärtust lisavate tegevuste kõrvaldamisele. Selle süsteemi tootmisprotsesside ajastamiseks kasutati Kanbanit (silti).

Agiilne tarkvaraarendus

Agiilsuse mõistmiseks mainin selle mõningaid jooni, mis eristab seda konkreetselt tavapärasest jugameetodist.

Agile heidutab rasket planeerimist, kuna eeldatav on tulevaste sündmuste ebakindluse tõttu igal juhul ebatäpne. See hõlmab muudatusi, mida kliendid kogu tootearenduse vältel nõuavad, mitte ainult nõuete kogumist alguses. Metoodika edendab rohkem isiklikku suhtlust ilma e-kirjade, sõnumite jms kasutamiseta, mis aeglustab tööd ja heidutab ka dokumenteerimist, julgustades samal ajal kliente sagedamini tutvustama.

Agiilset metoodikat eelistatakse tarkvaraarenduse kasutamisjuhtudel, kus on suurem sallivus vigade ja vigade suhtes, ning valdkondades, kus tarkvara ei pea olema esmakordne.

Agiilse manifesti põhimõtteid näete siit.

Scrum

Scrum on paindlik metoodika, kus keskendutakse sprintidele, mis hõlmavad etteantud ajaperioode.

Scrum võib olla 1 nädal, kuid seda võib pikendada ka rohkem kui kuuks, sõltuvalt tarkvaratoote tüübist.

Üsna sarnane ragbiharjaga, kus tegevus põhineb itereeritud liigutustel.

Sprindi alguses on planeerimiskoosolek, mida juhib “Scrum Master”, samal ajal kui “Tooteomanik” valib välja funktsioonid, mida tuleb välja töötada, ja kavandab selle sprindiks. See valimine põhineb tavaliselt eelnevalt kindlaksmääratud kriteeriumidel, nagu kiireloomulisus või kriitilisus, ja tooteomanik koos arendusmeeskonnaga peaks hindama, kui palju aega selle väljatöötamiseks ja testimiseks vaja läheb. Prindi tegemisel kasutatakse sprindi plaanimiseks Scrum Boardit ja kõiki arendatavaid funktsioone käideldakse pileti abil.

Iga päev toimub igapäevane stand-up, kus arendajad ja Scrum Master saavad kokku, et arutada, mida tuleks teha ja milliseid pileteid hallata. Sprindi lõpus tehakse “tagasivaade”, kus tehtud tööd vaadatakse üle ja õppetunnid õpitakse. See on peamine punkt, kus tööhinnangu täpsus vaadatakse üle ja seejärel seda parendatakse, et kasutada seda järgmise sprindi kavandamisel.

Trello abil tehtud Scrum Boardi näide

Scrumi metoodika põhijooneks on funktsioonide vabastamine sprindi lõpus. Seal on selgelt keskendutud sprindi planeerimisele, kuna sprindi edukus sõltub täielikult sellest, kui täpne on tööprognoos sprindi alguses. Kui sprindi lõpuks on jäänud pileteid, hinnatakse tõhusust tagasiulatuvalt, et vältida järgmise hinnangu andmiseks ülemäärast pühendumist.

Kanban

Agiilse Kanbani mõistmiseks peate mõistma originaalset Just-in-Time valmistamise metoodikat. Jaapanlased rõhutasid vabanemisest töötamata tööst - pooleliolevatest varudest, mis lõid tarneahelas laovarude taseme. Kuna selles inventaris oli raha kinni, vähendas see eemaldamine kulusid ja rõhutas nende töö käigus olevate vigade eest varjatud tõrkeid. Kui kaks töötajat tegid tootmisprotsessis järjestikust tööd, siis esimene töötaja ei saatnud tükki enne, kui teine ​​töötaja seda nõudis. Selle tulemuseks oli täielik tuginemine nõudmistel põhinevale tootmisprotsessile, mille tulemuseks oli vähe tööd.

Traditsiooniline Kanbani laud.

Agiilses Kanbani-keskkonnas on ülaltoodud filosoofia austatav, kuid väänatud.

Idee on vabastada nii palju kui võimalik, ootamata sprindi lõppu nagu Scrumis.

See keskendumine heitkogustele välistab vajaduse eelnevalt kindlaksmääratud sprintide järele, eemaldades seega sprindi ümber korraldusliku korra, vähendades sellega tarbetuid jäätmeid, nagu jaapanlased nende tootmisel tegid. Sprindiplaneerimist pole, retrospektiivi pole ja Agile Kanban jätkub seni, kuni mahajäämus on tühi, ilma et see kunagi peatuks.

Kiiresti juhitav treener asendab Kanbani metoodikas Scrum Masteri, samal ajal kui tooteomanik valib pileti tagalogist. Niisiis, kuidas nad asendavad hinnangu, mida tehakse Scrumis? Irooniline on see, et nad hoiavad töös oleva töö taset, nii et pole ülemääraseid pühendumusi. Kui WIP-tasemel hoitakse 3 piletit, tõmmatakse pilet ülesande veerust ainult siis, kui käimasolevas veerus on vähem kui 3 piletit.

Kanbani tahvli näide; sarnane Scrum Boardiga, kuid pange tähele WIP taset, mis on märgitud punasega!

Järeldus

Mis on parem?

Sellist asja pole. Scrum vs Kanban on otsus, mille peaks vastu võtma ettevõte pärast seda, kui on arvestatud kultuuriga, mida nad soovivad, ja isiksustega arendusmeeskondades. Minu jaoks, kes on pärit tootmise taustast, tunneb Kanban end koduna, hoolimata sellest, et tal puudub tänapäevane projektitaoline tunne, mida pakub Scrumis asuv sprint.

Lõppude lõpuks, kes ei taha pärast edukat sprinti õnnelikule tunnile minna.