Nykypäivän ohjelmistoryhmät ovat ainakin prosessissaan ketterämpiä! He ovat valmiita ajattelemaan asetettujen parametrien ulkopuolella seuraamaan sitä, mikä heille sopii. He ovat innokkaita oppimaan ja omaksumaan uusia projektinhallinnan tekniikoita ja projektiprosesseja.
Kanban-niminen projektijohtamismenetelmä on tehnyt ohjelmistoalalla kierroksia jo useita vuosia, ja se on saanut valuuttaa viimeisen viiden vuoden aikana. Kanban-menetelmän omaksuminen on yhdessä Agile-menetelmien kanssa antanut yrityksille paljon juhlia.
Mutta on myös kritiikkiä siitä, että Kanban on vain kunnioitettu tehtävälista. Joten mistä siinä kaikki on kyse? Otetaan selvää.
Mikä on Kanban?
Jos yrityksesi on valmis siirtymään perinteisen ohjelmistoprojektinhallinnan lähestymistavan ulkopuolelle, projektihallinnan tekniikoista ei tänään ole puutetta.
Yksi niistä on Agile Project Management -järjestelmä, joka keskittyy epälineaarisiin, iteratiivisiin ohjelmistokehitysmenetelmiin. Ketterien menetelmien käyttö näkyy Scrumissa, joka keskittyy joustavampaan lähestymistapaan projektinhallintaan.
Agilella on myös linkkejä muihin projektinhallintakehyksiin, kuten Kanban ja Extreme Programming. Näistä Kanban on saavuttanut suuren suosion. Loppujen lopuksi kuka ei halua japanilaisten kehittämää prosessia?
Kanban on konsepti, joka kehittyi Toyota-tehtaalla saavuttaakseen juuri oikea-aikaisen (JIT) tuotannon, joka vähentää kustannuksia ja mahdollistaa vähemmän resurssien käyttöä. Sydämessään se noudattaa työn vetämisperiaatetta, mikä tarkoittaa, että tehtävät tai tuotteet on "vedettava" vaatimusten ja vaatimusten perusteella, eikä niitä "työnnettävä" ylhäältä alas. Se kehitettiin varmistamaan autokomponenttien parempi varastointi Toyota-tehtaissa kysynnän perusteella. Tämä tarkoitti, että kysynnän kasvaessa pyynnöt täytettiin.
Konsepti mukautettiin ohjelmistoteollisuudelle muutamalla muutoksella, jotka David Anderson teki vuoden 2010 kirjassaan Kanban . Siitä lähtien sitä on käytetty useissa projekteissa, joilla on ollut suurta menestystä. Se voi olla valtava apu monimutkaisissa hankkeissa, jotka saattavat kärsiä ylikuormituksesta kehityssyklin toisella puolella.
Pohjimmiltaan Kanban-järjestelmä käsittelee ohjelmistoprojektiprosessia putkilinjana. Oletetaan, että ohjelmistoprosessissa on kolmen tyyppisiä tehtäviä: analysointi, kehittäminen, testaus ja lopulta käyttöönotto. Oletetaan, että on olemassa 20 tehtävää, jotka on suoritettava.
Perinteisen projektinhallintajärjestelmän tapauksessa, jos esimerkiksi
- Tarinoita on yhteensä 25
- Analyytikot pystyvät käsittelemään viittä tarinaa viikossa
- Kehittäjät pystyvät käsittelemään viittä tarinaa viikossa
- Testaajia on rajoitettu kolmeen tarinaan viikossa
Tässä tilanteessa työ yksinkertaisesti paalutetaan testaajan päähän. Viikon 1 lopussa tilanne on seuraava:
- Vain kolme tarinaa on siirtynyt käyttöönottoon.
- Kehittäjät ja analyytikot työskentelevät kolmen tarinan parissa, koska testaajat eivät pysty ottamaan kehittäjien tuotantoa ja testaamaan samaa.
- Työ kasaantuu, jolloin kehittäjät ja analyytikot ja projektipäällikkö saavat korjauksen.
Analyytikot ja kehittäjät saattavat nyt vain kääntää peukalonsa! Tai heidän esimiehensä saattaa ymmärtää olevansa käyttämättä ja siirtää ne uudelleen toiseen projektiin, jossa voi syntyä samanlainen tilanne. Joten on olemassa kaksi hanketta, jotka ovat nyt jumissa testausvaiheessa!
Tällaisessa tilanteessa ongelmia ei ole vaikea nähdä. Mitä hyötyä on kehittää kymmenen tarinaa (tai ohjelmistobittiä), kun niitä ei testata pian?
Nyt, Kanban-menetelmään.
Kanban-menetelmä on erittäin yksinkertainen käsite. Se noudattaa yksinkertaista logiikkaa, jossa käytetään ”vetomenetelmää” pullonkaulojen poistamiseksi ensin ja käynnissä olevien töiden (WIP) rajoittamista parempien työprosessien aikaansaamiseksi.
Yksinkertaisimmassa muodossaan, Kanban, kirjaimellisesti, "visuaalinen taulu" auttaa "vetämällä" kohteita pois tehtäväluettelosta sen sijaan, että työskentelisi aikajanajen kanssa. Kanban-menetelmä auttaa tunnistamaan pullonkaulat siten, että prosessivirta hallitaan paremmin.
Kanban-peruskortilla on luettelo suoritettavista tehtävistä, meneillään olevat tehtävät ja suoritetut tehtävät.
Ohjelmistohallinnassa tehtävät voivat kuitenkin olla hieman monimutkaisempia. Useimmilla ketterillä projekteilla on myös samanlainen hallitus. Kanban-taulussa käyttöönoton vaiheet on merkitty selvästi yhdessä kunkin sarakkeen numeron kanssa. Tämä numero edustaa enimmäismäärää tehtäviä tai juttuja, jotka tietty vaihe voi käsitellä.
Esimerkki Kanban-taululla näyttäisi olevan tällainen toisen viikon alussa. Tämä tarkoittaa, että kehittäjät ja analyytikot eivät työskentele optimaalisen määrän tarinoita viikolla. Olisi ilmeistä, että työ saadaan kasaan testaajan lopussa. Ja organisaatiot voivat varmistaa, että joukkueet työskentelevät yhdessä testauksen suorittamiseksi. Vaihtoehtoisesti he voivat tarkastella muita prosessivirtamalleja, jotta näin ei tapahdu.
Kun hankkeita hoidetaan Kanban-järjestelmän kautta, työtä ei ole vähemmän mahdollista kasata. Tarinat otetaan vastaan suurimman käytettävissä olevan kaistanleveyden mukaan.
Tyypillisessä Kanban-kokoonpanossa työ otetaan vastaan käytettävissä olevan kaistanleveyden mukaan, ja ryhmät vetävät työn sisään niin, että he ovat aina suurimmalla kapasiteetilla. Järjestelmä mahdollistaa myös nopean toiminnan kiireellisissä tehtävissä, jotta ne liikkuvat pöydän läpi minimaalisella vaivalla.
Katso tätä Kanban-lautaa.
On selvää, että kaikki vaiheet toimivat maksimaalisella hyötysuhteella. Ja myös pikateoksessa oleva tehtävä otetaan huomioon.
Kanban ei ole suinkaan ainoa menetelmä, jota käytetään parantamaan tehokkuutta rajoittamalla WIP: tä. On muitakin järjestelmiä, joilla saavutetaan sama tulos - esimerkiksi CONWIP (Constant Works in Progress) ja DBR (Drum-Buffer-Rope) järjestelmät, jotka on tarkoitettu ensisijaisesti valmistusteollisuudelle.
Kanban on kuitenkin järjestelmä, jota on parhaiten muokattu ohjelmistoteollisuuden tarpeisiin.
Kuinka Kanban eroaa ketteristä menetelmistä?
Kanban on sydämessään menetelmä, joka käyttää joitain ketterän projektinhallinnan elementtejä. Monien ketterän kehyksen hankkeiden juuret ovat Lean-lähestymistavat. Ero Kanban-metodologian ja ketterän projektihallinnan välillä ei ole niin mustavalkoinen kuin näiden kahden menetelmän kannattajat uskoisivat. Heillä on enemmän yhteistä kuin eroja.
Ketterä kehys ei ole ehdoton. Kysymys ei ole siitä, ovatko joukkueet ketterät vai eivät. Joukkueilla on usein ketteryyttä vaihtelevassa määrin. Yksi tavoista saada lisää ketteryyttä ohjelmistokehitysprosessissa on käyttää Kanbania.
Kanban- ja Agile-menetelmissä on muutamia eroja. Jotkut Kanban-kehityksen ominaisuuksista, jotka eroavat hieman ketterästä, ovat:
- Aikataulut eivät ole merkittävä tekijä . Tämä on kova käsite kietoa päämme ympäri, koska se vaikuttaa olevan erittäin intuitiivinen. ”Kuinka työskentelet ilman määräaikoja?” Ihmiset kysyvät usein. Mutta jos jokainen joukkueen jäsen on sitoutunut maksimitehokkuuteensa, aika lakkaa olemasta tekijä.
- Tarinat (tehtävät) ovat suurempia kuin tyypillisissä ketterissä järjestelmissä. Tarinoiden pituus ja monimutkaisuus ovat tyypillisesti pidempiä kuin tyypillisessä Scrum-projektissa. Koska painopiste ei ole ajan arvioinnissa, vaan pelkästään prosessin saamisessa eteenpäin, Kanbanilla on varaa työskennellä suurempien tarinoiden parissa.
- Nykyisissä prosesseissa ei ole merkittävää muutosta. Kanbanin ohjelmistokehitysperiaatteet, jotka sen perustaja David Anderson on kertonut blogissaan, sisältävät seuraavat perusperiaatteet:
-
- Aloita siitä, mitä teet nyt
- Sitoudu jatkamaan asteittaista, evoluutiomuutosta
- Kunnioita nykyistä prosessia, rooleja, vastuita ja nimikkeitä
- Jokainen tarina mitataan sykliajalla . Projektia ei arvioida perinteisellä ketterä nopeuden laskennalla (tietyn ajan kuluessa valmistuneiden tarinoiden lukumäärä), vaan jaksoajalla. Tämä tarkoittaa, että Kanban painottaa, kuinka kauan tehtävän suorittaminen kesti. Voit usein nähdä tikkerin monilla Kanban-levyillä, joissa mainitaan kuinka monta päivää joukkue vie tarinan loppuun. Tämä arvio syötetään seuraavaan jaksoon.
Kanban: Hallitus, mutta mikä muuta?
Joten, Kanban on taulu, joka näyttää meille kuinka tarinat järjestetään - että jopa niin iso juttu, monet kysyvät. Itse asiassa on paljon keskustelua siitä, mitä Kanban on ja voi tehdä.
Onko Kanban vain menetelmä työnkulun hallintaan? Vai onko jotain jota voidaan käyttää yhdessä Agile-menetelmien kanssa maksimaalisen tehokkuuden saavuttamiseksi? Vai voiko se olla aivan uusi tapa työnkulun hallintaan?
Jokainen joukkue käyttää Kanbania sopiviksi katsomiaan tilanteisiinsa. Siitä huolimatta, Kanbanilla on potentiaalia toimia elämäntapana ohjelmistokehitykseen, jos sitä käytetään parhaalla mahdollisella tasolla.
Käytetäänkö sitä työnkulun hallintaan vai uuden ohjelmistokehityksen mallina, ei voida kiistää, että se auttaa hallitsemaan WIP-tiedostoja.
Jotta Kanban toimisi parhaiten, on tärkeää ajatella sitä paitsi WIP: ien hallintaa myös projektinhallintakehyksenä. Tietyt perusohjeet auttavat prosessia.
- Optimoi joukkueet siten, että yksikään joukkue ei aloita jotain, jota he eivät voi lopettaa. Tämä auttaa prosessia.
- Älä vastusta muutoksia alkuperäiseen Kanban-järjestelmään verrattuna. Jos projektisi menee hyvin määräaikojen ja aikataulujen kanssa, sisällytä se samaan tapaan kuin haluaisit. Tämä tekee terveellisemmästä ja vankeammasta kehitysympäristöstä.
- Älä vältä tiimityötä. Kanban voi tuntua, mutta ei ole, malli, joka perustuu yksin työskenteleviin henkilöihin. Tiimityön on oltava kiinteä osa Kanban-ohjelmistokehitystä.
- Ajattele laatikon ulkopuolella. Ajattele muutoksia työnkulussa. Monet joukkueet ovat nyt valinneet testiohjatun kehityksen hyväksyntätestiohjatun kehityksen kanssa, jossa hyväksyntätestejä suoritetaan ensin käyttötapauksilla, jotka ohjaavat tarvittavat ominaisuudet ja kehityksen luonteen.
hybridit
Koska yhä useammat yritykset käyttävät tilanteeseensa parhaiten sopivia projektinhallintatyökaluja, ei ole yllättävää, että kaksi parhaista projektinhallintamenetelmistä: Scrum ja Kanban, on integroitu suuriin menestyksiin.
Hybridi, nimeltään Scrumban, on tunkeutumassa moniin hankkeisiin.
Jos organisaatio käyttää jo Scrum-ohjelmaa, mutta on vaikeaa pitää projektia yhdessä joko sprintin kanssa, joka ei toimi hyvin, testatakseen, ettei se ole ilmatiivis, voi olla aika harkita Scrumbania.
Selittääksesi sen yksinkertaisesti, Scrumban otti suurennuslasin sprintteihin. Kyse ei ole vain sprinteistä osana projektia, vaan myös siitä, mitä sprinteissä tapahtuu. Scrumban auttaa tutkimaan kuinka tarina prosessoidaan sprintin sisällä, ja se saattaa tehdä eron.
Scrumban tai mikä tahansa sen muunnos on pieni muutos nykyisiin käytäntöihin verrattuna. Kanbanin käytön kauneus on, että sitä voidaan käyttää käytännössä minkä tahansa projektinhallintamallin kanssa: vesiputous, ketterä tai mikä tahansa niiden välissä.
Kanbanin käytön aloittaminen
Kanban-järjestelmän käyttö on helppoa. Kanban on myös mahdollista toteuttaa minimaalisesti projektin tietyn osan kokeiluversiona.
- Kartta ohjelmistokehitysprosessista. Tee selkeä kartta koko prosessista. Kuinka projekti - alkuperäisestä suunnittelusta kehittämiseen, testaamiseen, ominaisuuksien muutoksiin - toimii todellisuudessa?
- Luetteloi vaiheet, joissa Kanbania käytetään. Suorita vaiheet, jotka ovat täysin hallinnassasi. Tämä käsittää tyypillisesti analyysi-, kehitys-, katsaus- ja testausvaiheet.
- Työ tärkeissä kohdissa, kuten:
- Rajoitukset keskeneräisille töille jokaiselle vaiheelle.
- Prosessit nopeutettuun / estettyyn työhön
- Kirjekuoren takaosa-arviot suhteessa sykliaikaan
- Kanban-paneelin / prosessin / arvioiden tarkistuksen tiheys
- Osta taulu ja pino Post-It-seteleitä.
- Aloittaa
- Tarkista tarvittaessa.
- Toistaa
Joten mene eteenpäin ja aloita Kanban!
Älä pelkää, jos se ei käy niin kuin olet alun perin suunnitellut. Ketterien metodologioiden taustalla oleva idea on sopeutua muutoksiin ihmisissä ja prosesseissa! Kerro meille kokemuksistasi Kanban-menetelmällä.
Suositellut artikkelit
- 6 parasta hyödyllistä projektinhallintatoimistoa (PMO)
- 8 hyödyllistä vaihetta hienostuneiden tarinakarttojen luomiseen projektillesi
- Äärimmäisen ohjelmoinnin 5 tärkeätä arvoa (tehokas)