Ce este Kanban și cum este
util?

1. Munci­torii din ​“down­stream” înde­părtează exact atâtea piese din stoc câte sunt spec­ifi­cate pe kanban
2. Munci­torii din ​“upstream” furnizează de aseme­nea piese strict con­form cărților
3. Nim­ic nu este pro­dus sau mutat fără un kanban
4. Kan­ban­ul tre­buie să fie întot­deau­na atașat pieselor
5. Piese­le defecte nu sunt uti­lizate în sistem
6. Reduc­erea număru­lui de cărți kan­ban face man­age­men­tul mai sen­si­bil la schim­bări. Dar fără o nece­si­tate extremă, nu este reco­mand­abil să se schimbe numărul sta­bilit de cărți.

1. Flex­i­bil­i­tate în plan­i­fi­care. Echipa se con­cen­trează doar pe munca actu­ală, cu pri­or­ități sta­bilite de manager.
2. Înga­ja­ment ridi­cat al echipei în pro­ce­sul de dez­voltare. Datorită întâl­nir­ilor reg­u­late, trans­parenței pro­ce­su­lui și opor­tu­nităților de auto-orga­ni­zare, anga­jații se adună și arată un interes autentic.
3. Dura­ta ciclurilor mai scurtă. Dacă abil­itățile nece­sare sunt deținute de mai multe per­soane, dura­ta se reduce; dacă doar o sin­gură per­soană le deține, apare un blo­caj. De aceea, anga­jații ar tre­bui să împărtășească cunoșt­ințe opti­mizând ast­fel dura­ta ciclurilor. Aceas­ta per­mite întregii echipe să lucreze la sarcinile blo­cate și să restau­reze flux­ul lin.
4. Mai puține blo­ca­je. Lim­itările WIP per­mit iden­ti­fi­carea rapidă a blo­ca­jelor și a zonelor prob­lem­at­ice care apar din lip­sa de con­cen­trare, forță de muncă sau abilități.
5. Viz­ibil­i­tate. Când toți execu­torii au acces la date, devine mai ușor să iden­ti­fi­ci blo­ca­jele. Echipele Kan­ban, pe lângă cărțile în sine, uti­lizează de obi­cei două rapoarte comune: grafice de con­trol și flux cumulativ.

• grupuri de suport soft­ware sau birouri de ajutor.
• Kan­ban funcționează bine în ges­tionarea start-up-urilor fără un plan clar, dar unde are loc o dez­voltare activă.

1. sis­temul funcționează prost cu echipe de mai mult de 5 persoane
2. nu este des­ti­nat pen­tru plan­i­fi­care pe ter­men lung.

Exem­ple de apli­care în IT

Exact de la Microsoft: Debu­tul Kan­ban în dez­voltarea software-ului

Uti­lizarea prin­cipi­ilor Kan­ban în tehnolo­gia infor­mației a început acum puțin mai mult de 10 ani. David Ander­son, unul din­tre prin­ci­palii pro­mo­tori ai Kan­ban pen­tru dez­volta­torii de soft­ware, a con­sul­tat Microsoft în 2005. Ei erau nemulțu­miți de per­for­manța depar­ta­men­tu­lui lor — XIT Sus­tained Engi­neer­ing, care repara ero­r­ile din apli­cați­ile interne. Până la începutul anu­lui de raportare, acest depar­ta­ment era cel mai rău din divizia sa. Back­log-ul depășea dimen­si­unea accept­abilă de cin­ci ori, iar tim­pul de livrare pen­tru proce­sarea unei cereri era, în gen­er­al, de cin­ci luni.

Noul PM, cu con­sul­tați­ile lui Ander­son, a cres­cut pro­duc­tiv­i­tatea depar­ta­men­tu­lui prob­lem­at­ic cu 155% în nouă luni. Tim­pul de livrare a fost acum de cin­ci săp­tămâni, back­log-ul a revenit la o dimen­si­une nor­mală, iar finalizarea sarcinilor în timp util s‑a sta­bi­lizat la 90%. Toate aces­te rezul­tate au fost obținute cu o inte­grare min­imă a anga­jaților noi; per­son­alul a con­tin­u­at să repare erori în ace­lași mod — doar abor­dările de orga­ni­zare a muncii s‑au schimbat.

Dumitriu a întâmp­inat un depar­ta­ment for­mat din trei dez­volta­tori și trei tes­teri, care avea 80 de cereri îngrămădite în back­log. PM-ul însuși a fost numit tem­po­rar deoarece cer­ințele pos­tu­lui includeau exper­tiză în tehnolo­gia ASP, admin­is­trarea SQL Serv­er și cunoșt­ințe despre MS Project Serv­er. Man­age­men­tul își imag­i­na un ​“techie” care putea să codeze, să pregătească rapoarte și să prog­nozeze încăr­că­tu­ra back­log-ului în această poz­iție. Așa cum se cre­dea pe atun­ci, prob­le­ma depar­ta­men­tu­lui ar fi fost dezvăluită dacă s‑ar fi adunat o can­ti­tate mare de date. Dumitriu nu era un ast­fel de ​“techie”.

Cu toate aces­tea, începând să anal­izeze oper­ați­u­nile XIT ală­turi de Ander­son, a iden­ti­fi­cat rapid fac­torii cheie care afec­tau neg­a­tiv viteza departamentului:

• Prog­nozarea impli­cați­ilor (ROM) îndeplinirii unei cereri dura mult timp. Atât dez­volta­torul, cât și testerul tre­buiau să petreacă o zi de muncă întreagă real­izând cal­culele nece­sare, ver­i­ficând codul și com­pletând doc­u­men­tația. În medie, o cerere apărea zil­nic. Con­form cal­culelor PM-ului, 40% din pro­duc­tiv­i­tatea depar­ta­men­tu­lui era direcțion­ată către ROM;
• Pri­or­i­tate era dată cererilor cu o val­oare mai mare. XIT era finanțat pe baza val­orii comen­zii. Pri­or­i­ti­zarea cererilor era dis­cu­tată lunar la întâl­nir­ile man­ager­ilor depar­ta­men­tu­lui cu clienții — man­ageri din alte depar­ta­mente. Cu un back­log în expan­si­une la viteza actu­ală, unde doar 6 – 7 cereri erau proce­sate lunar, pri­or­itățile altor cereri se schim­bau con­stant în funcție de tre­cerea tim­pu­lui. Multe din­tre ele erau amâ­nate pen­tru un ​“mai târz­iu” sem­ni­fica­tiv, nu egal cu luna următoare.
• La eta­pa ROM, jumă­tate din cereri erau fil­trate. Unele erau prea mari și erau recal­ifi­cate ca proiecte care tre­buiau trans­fer­ate în alte depar­ta­mente, altele erau prea scumpe și pur și sim­plu anu­late. Unele cereri nu erau luate în dez­voltare deoarece imple­mentarea lor ar dura prea mult. Ast­fel, 40% din pro­duc­tiv­i­tatea depar­ta­men­tu­lui era chel­tu­ită pe anal­iza cererilor, 50% din­tre aces­tea fiind respinse. Aprox­i­ma­tiv 15 – 20% din resurse­le de lucru erau risipite.
• Lucrările pregăti­toare asupra cererilor ar putea dura luni înainte de începerea imple­men­tării. Cal­culările la eta­pa ROM puteau fi pier­dute sau uitate în acel timp. Mai ales dacă imple­mentarea era real­iza­tă de un alt dez­volta­tor decât cel care a început analiza.

Soluții Kan­ban pen­tru depar­ta­men­tul prob­lem­at­ic al Microsoft

La sfârși­t­ul anu­lui 2005, pro­duc­tiv­i­tatea depar­ta­men­tu­lui a cres­cut cu 155%. Pen­tru a îmbunătăți și mai mult activ­i­tatea XIT, au fost aduși doi anga­jați: un dez­volta­tor și un tester. Numărul cererilor din back­log a scăzut la 10, iar un dez­volta­tor a proce­sat con­stant 11 cereri pe trimestru. În medie, 56 de cereri au fost final­izate pe trimestru com­par­a­tiv cu 11 ante­ri­or. Cos­tul cererilor a scăzut de la 7500 $ la 2900 $.

Apli­ca­tia în Corbis

După ce a obțin­ut suc­ce­sul la Microsoft, Ander­son în 2006 a început să abor­deze o nouă sarcină com­plexă. Acum lucra la Cor­bis — o altă com­panie a lui Bill Gates, care nu pără­sise încă MS. Una din­tre activ­itățile Cor­bis era licențierea de fotografii. La acel moment, era cea de‑a doua cea mai mare bib­liotecă de fotografii stoc din lume cu o bază de date de aprox­i­ma­tiv 3,5 mii de imagini.

Sarci­na lui Ander­son era să accel­ereze lan­sările prin­ci­pale ale com­paniei. Inter­val­ul din­tre lan­sări era de trei luni și putea crește chiar mai mult. Dis­cutarea plan­u­lui de lansare dura man­age­men­tu­lui două săp­tămâni. Era nece­sar să se sta­bilească lansarea unor ver­si­u­ni secun­dare sau actu­al­izări la fiecare două săp­tămâni. În ace­lași timp, resurse­le cheie tre­buiau direcțion­ate către proiec­tul principal.

Un tablou Kan­ban a apărut în biroul Cor­bis, unde Ander­son vor­bea cu echipa zil­nic. Scop­ul PM-ului era să îmbunătățească con­trolul vizual asupra pro­ce­selor, să încu­ra­jeze auto-orga­ni­zarea și o mai mare respon­s­abil­i­tate per­son­ală în rân­dul execu­to­rilor. Sis­temul Kan­ban a fost de aseme­nea des­ti­nat reduc­erii supraveg­herii man­ager­ilor și creș­terii productivității.

Pe lângă cărțile col­orate și grafice, pe tablou a apărut și un ​“coș de gunoi” — în care erau trim­ise sarcinile care erau prea mari.

Foto din prezentarea ofi­cială prezentare 

Un Sis­tem Kan­ban pen­tru Inginer­ie Dura­bilă pe Sis­teme Soft­ware de David J Anderson

Sis­temul Kan­ban a clar­i­fi­cat când flux­ul încetează să fie lin și unde apar întârzier­ile, cunos­cutele blo­ca­je. Dis­cuți­ile rapi­de cu echipa au aju­tat la iden­ti­fi­carea prob­lemelor curente. De exem­plu, testarea dura 3 zile, ceea ce a avut un impact neg­a­tiv asupra cronolo­giei lan­sării. Trei anga­jați s‑au adunat și au găsit o modal­i­tate de a reduce tim­pul la o zi.

Un blo­caj este o secți­une a schemei sau algo­rit­mu­lui oper­ați­u­nilor com­paniei, unde lim­itele de pro­duc­tiv­i­tate ale resurselor sau ale oame­nilor reduc brusc capac­i­tatea de tre­cere a flux­u­lui de sarci­ni. O lip­să de forță de muncă, o conex­i­une proastă la inter­net sau un direc­tor în vacanță blochează sau încetinește exe­cuția sarcinilor.

Lim­itele pen­tru cărțile Kan­ban au fost sta­bilite empir­ic de două ori. În coloana ​“gata pen­tru dez­voltare”, lim­itele au fost cres­cute. O nouă coloană — ​“gata pen­tru testare” — a apărut de aseme­nea. Multe cereri pen­tru down­stream au fost for­mu­late incorect, cauzând risipiri inutile de timp. Prin urmare, PM-ul a inves­ti­gat oper­ați­u­nile flux­u­lui supe­ri­or și a găsit greșeli.

Pro­ce­du­ra de revizuire a cererilor putea dura 100 de zile, dar lan­sările au început să apară totuși la fiecare două săp­tămâni așa cum era plan­i­fi­cat. Decizi­ile despre conțin­u­tul lan­sării au fost luate cu 5 zile înainte de pub­li­care. Prac­ti­ca de numărare, așa cum s‑a întâm­plat în cazul depar­ta­men­tu­lui XIT de la Microsoft, a fost aban­do­nată în favoarea pro­duc­tiv­ității. Pri­or­itățile sarcinilor erau sta­bilite con­form ​“cos­tu­lui întârzier­ilor” sau pregătirii resurselor.

Sis­temul Kan­ban nu numai că l‑a aju­tat pe Ander­son să atingă obiec­tivul sta­bilit, dar a și îmbunătățit moralul din cadrul echipei. Datorită dis­cuți­ilor colec­tive și viz­ibil­ității pro­ce­selor, anga­jații și-au con­stru­it încredere rec­i­procă. Per­son­alul a adop­tat de aseme­nea Kaizen, adică prac­ti­ca îmbunătățirii continue.

Pro­grame și Apli­cații pen­tru KANBAN

Trel­lo

Sis­tem pop­u­lar Kan­ban pen­tru man­age­men­tul sarcinilor. Se remar­că prin atrac­tiv­i­tatea vizuală și inter­fața pri­etenoasă cu uti­liza­torul. Uti­liza­torii sub­lini­ază flex­i­bil­i­tatea sa superioară.

Kan­ban­tool

Tabloul gra­tu­it pen­tru doi uti­liza­tori. Suport API și inter­fețe tactile.

Lean Kit Kanban

Tabloul gra­tu­it pen­tru cin­ci uti­liza­tori cu bune car­ac­ter­is­ti­ci de colab­o­rare. Suport API și capac­ități de import/​export, sta­tis­ti­ci extinse.

Kan­ban­ize

Ser­vi­ciu com­plet gra­tu­it cu funcțion­al­i­tate decen­tă. Pro­pri­etarii săi garan­tează o creștere de 300% a pro­duc­tiv­ității atun­ci când folos­esc pro­dusul lor.

Work­sec­tion

SaaS ucrainean —  apli­cație pen­tru urmărirea rapidă și ges­tionarea proiectelor. În prezent, în plus față de con­tabi­lizarea finanțelor și termenelor lim­ită, există un graf­ic Gantt. În urmă­toarele luni, dez­volta­torii vor adău­ga un tablou Kan­ban cu opți­u­ni de per­son­alizare, făcând ser­vi­ci­ul și mai potriv­it pen­tru Kanban.

---

Verdict

Kan­ban este o prac­tică care ajută la obținerea suc­ce­su­lui, în timp ce uti­lizarea numai a metode­lor agile nu este oblig­a­to­rie. Schim­bările sem­ni­fica­tive sunt real­izate prin elim­inarea tim­pu­lui irosit, ges­tionarea blo­ca­jelor și reduc­erea variabilității.

Cu toate aces­tea, schim­bările de suc­ces nece­sită timp. Aces­tea apar trep­tat, în timp ce rezis­tența echipei la ino­vații este min­imă. Sis­temul Kan­ban motivează per­son­alul să se îmbunătățească fără mod­i­ficări în metodele de inginerie.

Cărțile pen­tru arti­col sunt oferite de kni​ga​.biz​.ua