David Anderson - Kanban. Kanban

David J Anderson

Schimbare evolutivă de succes pentru afacerea dvs. de tehnologie

Publicat cu permisiunea Lean Kanban Inc.

Mulțumim Comunității Lean Kanban Rusia reprezentată de Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov și Igor Filipyev pentru ajutorul acordat în pregătirea publicației.

Toate drepturile rezervate.

Nicio parte a acestei cărți nu poate fi reprodusă sub nicio formă fără permisiunea scrisă a deținătorilor drepturilor de autor.

* * *

Dedicat lui Nikola și Natalie

cuvânt înainte

Sunt mereu atent la munca lui David Anderson. L-am cunoscut în octombrie 2003 când mi-a trimis o copie a cărții sale Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. După cum sugerează și titlul, cartea a fost puternic influențată de Teoria constrângerilor (TOC) a lui Eliyahu Goldratt. 1
Theory of Constraints este o metodologie populară de management al producției dezvoltată în anii 1980 de Eliyahu Goldratt, care se bazează pe găsirea și gestionarea constrângerii cheie a sistemului care determină succesul și eficiența întregului sistem în ansamblu. Notă. ed.

Mai târziu, în martie 2005, l-am vizitat pe David la Microsoft, moment în care lucra îndeaproape cu diagramele de flux cumulative. Chiar mai târziu, în aprilie 2007, am avut ocazia să observ cum funcționează sistemul kanban inovator pe care l-a implementat în Corbis.

Vă dau toată această cronologie, astfel încât să vă simțiți ritmul de neoprit în care avansează gândirea managerială a lui David. El nu se ține de o singură idee, încercând să încadreze întreaga lume în ea. Dimpotrivă, încearcă să ia în considerare problema în ansamblu, este deschis către diverse soluții, le încearcă în practică și evaluează principiile muncii. Veți vedea rezultatele acestei abordări în această carte.

Desigur, viteza este bună atâta timp cât este în direcția corectă și sunt sigur că David se mișcă în direcția corectă. Admir în special cele mai recente lucrări cu sisteme kanban. Întotdeauna am crezut că principiile lean pot fi aplicate direct în dezvoltarea de produse, spre deosebire de ideile TOC. Mai mult, în octombrie 2003, i-am scris lui David următoarele: „Una dintre principalele slăbiciuni ale CBT este subestimarea importanței dimensiunii partidului.

Dacă prioritatea ta principală este să găsești și să remediezi constrângerea, atunci asta înseamnă adesea că rezolvi problema greșită.” Încă cred că această afirmație este adevărată.

La întâlnirea noastră din 2005, i-am sugerat din nou lui David să privească dincolo de concentrarea doar pe blocajele din TOC. I-am explicat că hype-ul Toyota Production System (TPS) nu are nimic de-a face cu găsirea și eliminarea blocajelor. Toyota realizează câștiguri de productivitate prin reducerea dimensiunilor și variabilității loturilor, ceea ce reduce cantitatea de stoc necesară. Reducerea unor astfel de stocuri a condus la obținerea de beneficii economice, iar acest lucru a fost posibil prin astfel de sisteme de reducere a lucrărilor în proces precum kanban.

În 2007 am vizitat Corbis. Rezultatul introducerii sistemului kanban arăta impresionant. I-am subliniat lui David că a îmbunătățit foarte mult abordarea kanban folosită la Toyota. De ce am crezut asa? Sistemul de producție Toyota este optimizat pentru a gestiona sarcini repetitive și previzibile cu durată uniformă și costuri uniforme de întârziere. În aceste condiții, este destul de corect să folosiți abordări precum prioritizarea FIFO („primul intrat, primul ieșit”). De asemenea, este destul de corect să blocați primirea lucrărilor dacă se atinge limita sarcinilor incomplete. Totuși, dacă avem de-a face cu activități nerepetitive, imprevizibile, cu durate diferite și costuri de întârziere diferite, aceste abordări nu pot fi considerate optime - și exact așa este în cazul dezvoltării software. Avem nevoie de sisteme mai avansate, iar aceasta este prima carte care le descrie în detaliu practic.

Aș dori să avertizez cititorii despre câteva lucruri. În primul rând, dacă credeți că știți cum funcționează sistemele kanban, atunci probabil vă referiți la cele utilizate în manufacturarea slabă. Ideile din această carte sunt mult mai avansate decât sistemele simple care utilizează limite WIP statice. 2
WIP - lucru în curs, numărul de sarcini în desfășurare. Notă. ed.

Programare FIFO și o singură clasă de servicii. Vă rugăm să acordați atenție acestor diferențe.

În al doilea rând, să nu credeți că această abordare este un sistem de control vizual. Vizualizarea lucrărilor în derulare care se realizează cu panourile kanban este foarte utilă, dar este doar un mic aspect al acestei abordări. Dacă citiți cu atenție această carte, veți găsi o mulțime de lucruri interesante în ea. Cele mai valoroase informații sunt ascunse, de exemplu, în aspecte precum structura proceselor de primire și transmitere a sarcinilor, gestionarea resurselor de neînlocuit și utilizarea claselor de servicii. Nu te lăsa distras de partea vizuală, altfel vei rata cele mai incitante momente.

În al treilea rând, nu reduceți aceste metode doar pentru că par prea ușor de utilizat. Ușurința în utilizare este rezultatul ideilor lui David despre cum să obțineți beneficii maxime cu rezultate minime. El cunoaște bine nevoile practicanților și a acordat o atenție serioasă la ceea ce funcționează cu adevărat. Metodele simple arată o stabilitate ridicată și aproape întotdeauna conduc la cele mai bune rezultate pe termen lung.

Aceasta este o carte fascinantă și necesară și merită un studiu atent. Nivelul de beneficii pe care îl obțineți depinde de cât de serios iei lectura. Nicio altă carte nu vă va prezenta mai bine aceste idei avansate. Sper să vă bucurați de el la fel de mult ca și mine.

Don Reinertsen,

Partea I
Bazele

Capitolul 1
Rezolvarea dilemei managerului Agile

În 2002, eram manager de dezvoltare la biroul de la distanță al Motorola din Seattle al diviziei de telefoane mobile a Motorola (se numea PCS) și m-am trezit într-o situație dificilă. Departamentul meu făcea parte dintr-un startup pe care Motorola o achiziționase cu un an mai devreme. Am dezvoltat software de rețea pentru transmisia wireless de date, cum ar fi descărcarea fără fir și controlul instrumentelor. Aceste aplicații back-end făceau parte din sisteme integrate care erau strâns cuplate cu codul client al telefonului mobil, precum și cu alte elemente din rețelele de telecomunicații și infrastructura operațională, cum ar fi facturarea. Termenele au fost stabilite de manageri care nu au acordat atenție complexității inginerești a proiectului, riscurilor acestuia sau amplorii acestuia. Codul de bază a evoluat dintr-o pornire, multe caracteristici planificate inițial fiind amânate până mai târziu. Un dezvoltator senior a insistat ca produsele noastre să fie numite „prototipuri”. Aveam cu disperare nevoie să creștem productivitatea și calitatea produsului pentru a ține pasul cu cerințele afacerii.

În activitățile mele zilnice din 2002 și în procesul de lucru la cartea anterioară 1
Anderson, David J. Management agil pentru inginerie software: aplicarea teoriei constrângerilor pentru rezultatele afacerii. Upper Saddle River, NJ: Prentice Hall, 2003.

M-au preocupat în principal două probleme. În primul rând, cum să protejezi echipa de cerințele din ce în ce mai mari ale afacerii și să obții ceea ce se numește acum „ritmul optim” în comunitatea agilă. Și în al doilea rând, cum pot implementa cu succes o abordare agilă în întreaga organizație, depășind rezistența inevitabilă la schimbare?

Găsirea ritmului potrivit

În 2002, comunitatea agilă credea că ritmul optim este doar o „săptămână de lucru de 40 de ore”. 2
Beck, Kent. Programarea extremă explicată: îmbrățișați schimbarea. Boston: Addison Wesley, 2000. Ediția rusă: Beck K. Extreme Programming. Sankt Petersburg: Peter, 2002.

Principiile Manifestului Agile 3
Beck, Kent și colab., „Principiile din spatele manifestului Agile”. http://www.agilemanifesto.org/principles.html. Traducere rusă: http://agilemanifesto.org/iso/ru/principles.html .

Ei au spus că „procesele agile contribuie la dezvoltarea optimă. Sponsorii, dezvoltatorii și utilizatorii trebuie să fie pregătiți să mențină un ritm constant la nesfârșit.” Cu doi ani mai devreme, echipa mea de la Sprint PCS a tot auzit de la mine că „dezvoltarea de software la scară este un maraton, nu un sprint”. Dacă membrii echipei ar trebui să mențină un ritm constant în procesul de lucru la un proiect de un an și jumătate, atunci nu li s-ar putea lăsa să se epuizeze într-o lună sau două. Proiectul a trebuit să fie planificat, bugetat, cronometrat și evaluat pentru a se asigura că membrii echipei au petrecut o perioadă rezonabilă de timp lucrând în fiecare zi și nu sunt prea obosiți. Ca manager, sarcina mea a fost să ating acest obiectiv și satisface toate cerințele de afaceri.

Când eram în prima mea funcție managerială (a fost în 1991, la un start-up care făcea plăci de captură video pentru computere personale și mai mici), CEO-ul 3
Chief Executive Officer - Chief Executive Officer (CEO). Notă. ed.

El a spus că conducerea a avut o „opinie extrem de negativă” despre mine. Întotdeauna am răspuns „nu” atunci când oportunitățile noastre ca dezvoltatori erau deja epuizate și din ce în ce mai multe produse sau funcții erau solicitate de la noi. Până în 2002, devenisem un obicei: am petrecut încă zece ani refuzând să mă supun capriciilor proprietarilor de afaceri.

Echipele de dezvoltare și departamentele IT ale companiilor depind în mare măsură de alte grupuri care negociază, cerșesc, amenință și reelaborează în mod constant chiar și cele mai evidente și obiectiv concepute planuri. Vulnerabilii includ, de asemenea, planuri bazate pe o analiză atentă și pe experiența istorică. Majoritatea echipelor, lipsite de analiză amănunțită și de experiență istorică, nu au putut face față celor care le-au împins să-și asume angajamente obscure și adesea imposibile.

Între timp, angajații s-au împăcat cu volumul de muncă nebunesc, iar sarcinile exorbitante au devenit norma. Nimeni nu pare să se fi gândit la faptul că inginerii de software pot avea și o viață socială sau de familie. Sună dur, dar este adevărat! Cunosc prea multe exemple în care volumul excesiv de muncă a distrus pentru totdeauna relațiile de familie. Este greu să simpatizi cu tocilarul tipic dezvoltator. În statul meu natal, Washington, venitul unui inginer de software este al doilea după cel al unui dentist. Ca pe vremea lui Ford, adică în anii 1920, când oamenii din fabricile lui câștigau de cinci ori mai mult decât media națională, nimănui nu-i trece niciodată prin cap să se gândească la monotonia muncii sau la bunăstarea specialiștilor: ei sunt plătit atât de mult! Este greu de imaginat sindicatele din industrii bazate pe cunoaștere, cum ar fi dezvoltarea de software, pentru că nimeni nu va examina cu seriozitate cauzele bolilor fizice și psihologice cu care se confruntă dezvoltatorii. Angajatorii mai responsabili oferă, de exemplu, măsuri precum masajul sau psihoterapie. Sau își petrec zile de sănătate mintală - și asta în loc să acorde atenție studierii cauzelor principale ale problemei. Un scriitor tehnic la o firmă de software binecunoscută mi-a spus odată: „Nu-i nimic dacă iau antidepresive, pentru că toată lumea o face!” Programatorii sunt de obicei de acord cu toate cerințele, sunt plătiți bine și suferă consecințele. Am vrut să schimb asta, să găsesc o abordare reciproc avantajoasă care să-mi permită să spun da și să-mi protejez în continuare echipa, asigurându-mă că s-a atins ritmul optim. Am vrut să-mi aduc membrii echipei înapoi în comunitate și familie și să îmbunătățesc condițiile care provocau stres și probleme de sănătate pentru dezvoltatorii sub treizeci de ani. Așa că am decis să încep să mă ocup de aceste probleme.

În căutarea unui management de succes al schimbării

A doua problemă care mi-a trecut în minte este managementul schimbării în organizațiile mari. Am fost manager de dezvoltare la Sprint PCS și apoi la Motorola. În ambele companii, a existat o nevoie puternică de a trece la metode de lucru mai flexibile. Dar, în ambele cazuri, am avut dificultăți în implementarea metodelor agile în mai mult de una sau două echipe.

De ambele ori, nu am avut suficientă autoritate pentru a ordona pur și simplu să se facă modificări în mai multe echipe. Am încercat să implementez modificări la cererea conducerii superioare, dar nu am avut autoritatea necesară. Mi s-a cerut să-i influențez pe colegi să implementeze aceleași schimbări în echipele lor ca și eu în a mea. Dar nu s-au grăbit să adopte metode care păreau să funcționeze cel mai bine în echipa mea. Această rezistență a avut probabil mai multe motive. De cele mai multe ori, am auzit că fiecare echipă are propria situație și că metodele mele vor trebui adaptate nevoilor specifice ale celorlalți. La mijlocul anului 2002, mi-am dat seama că era inutil să prescriu în mod rigid orice proces de dezvoltare de software - pur și simplu nu ar funcționa.

Procesul trebuia adaptat fiecărei situații specifice, așa că a fost necesară conducerea activă a fiecărei echipe. Și de multe ori acest lucru nu a fost suficient. Chiar și cu o conducere adecvată, nu există nicio certitudine că pot avea loc schimbări semnificative fără o structură stabilită și sfaturi privind modul de adaptare a proceselor la diferite situații. Dacă managerul, antrenorul sau inginerul responsabil nu are o idee clară despre ce să facă, atunci orice adaptare este probabil să fie subiectivă. În același timp, există o probabilitate mare de erori - de exemplu, introducerea unui șablon de proces neadecvat.

Am încercat să acopăr această problemă în cartea Agile Management for Software Engineering pe care o scriam la acea vreme. M-am întrebat: „De ce dezvoltarea agilă produce rezultate economice mai bune decât abordările tradiționale?” Am vrut să aplic structura teoriei constrângerilor în acest scop. 4
Goldratt, Eliyahu M. Ce este acest lucru numit Teoria constrângerilor și cum ar trebui implementat? Great Barrington, MA: North River Press, 1999.

În procesul de cercetare și scriere a acestei cărți, mi-am dat seama că fiecare situație este unică. Și cum poate o constrângere sau un blocaj să fie la fel pentru orice echipă și proiect în orice moment? Fiecare echipă este unică: abilități, oportunități, experiență diferite. Fiecare proiect diferă de altele în ceea ce privește bugetul, programul, domeniul de aplicare și riscurile. Organizațiile sunt, de asemenea, diferite: au lanțuri valorice diferite și operează pe piețe diferite (Figura 1.1). Mi s-a părut că acest lucru ar putea oferi un indiciu pentru înțelegerea rezistenței la schimbare. Dacă modificările propuse în metodele și comportamentele de lucru nu oferă, în opinia angajatului, un avantaj evident, atunci acesta nu le va accepta. Dacă aceste schimbări nu afectează ceea ce echipa percepe ca un limitator sau un factor de descurajare, atunci echipa va rezista. Cu alte cuvinte, modificările propuse indiferent de context vor fi respinse de angajații care cunosc perfect contextul muncii.

Orez. 1.1. De ce sunt greșite metodologiile generice de dezvoltare

S-ar părea că ar fi mai bine dacă noul proces ar începe să se dezvolte, eliminând o limitare după alta. Acesta este punctul principal al teoriei constrângerilor lui Goldratt. Dându-mi seama că mai aveam multe de învățat, mi-am dat seama de valoarea materialului și m-am grăbit înainte să lucrez la manuscris. Mi-a fost clar că cartea nu dă sfaturi cu privire la modul de implementare a ideilor pe o scară mai mare și nici nu a ajutat mult în găsirea unor modalități de a gestiona schimbarea.

Abordarea lui Goldratt, subliniată în , urmărește să găsească limitări și apoi modalități de a le elimina, astfel încât acestea să nu mai împiedice performanța. După aceea, apare o nouă constrângere și ciclul se repetă. Este o abordare iterativă care îmbunătățește sistematic performanța prin identificarea și eliminarea obstacolelor.

Mi-am dat seama că poți combina această abordare cu câteva tehnici din domeniul lean manufacturing. Modelând fluxul de lucru al ciclului de viață al dezvoltării software ca flux de valoare și creând un sistem de urmărire și vizualizare pentru a capta schimbările de stare ale muncii emergente „curgând” prin sistem, am reușit să identific constrângerile. Abilitatea de a identifica constrângerile este primul pas către modelul de bază al TOC. Goldratt a dezvoltat deja o aplicație a acestei teorii la problemele fluxului de lucru, care poartă numele stângace de „drum-buffer-rope”. Totuși, mi-am dat seama că o versiune simplificată a acestui sistem poate fi implementată în domeniul dezvoltării software.

În ceea ce privește originea, tambur-tampon-coarda este un exemplu de clasă de soluții cunoscute sub numele de sisteme de tragere. După cum vom vedea în , kanban este, de asemenea, un exemplu de acest tip de sistem. Un efect secundar al sistemelor de tragere este că limitează WIP la o sumă predeterminată, prevenind angajații să fie copleșiți. În plus, doar lucrătorii care se confruntă direct cu restricția rămân complet încărcați; toți ceilalți ar trebui să aibă timp liber. Mi-am dat seama că sistemele de tragere ar putea rezolva ambele probleme care mă îngrijorau. Sistemul de tragere îmi va permite să introduc modificări incrementale, care (speram) să reducă semnificativ rezistența la acestea, precum și să ușureze atingerea ritmului optim. Am luat decizia de a trece la sistemul tambur-tampon-coardă cât mai curând posibil. Am vrut să experimentez evoluția incrementală a procesului și să văd dacă oferă ritm optim și rezistență redusă la schimbare.

O astfel de oportunitate a apărut în toamna anului 2004 la Microsoft, care este descrisă în detaliu în această carte în analiza exemplului.

De la tobă-tampon-frânghie la kanban

Soluția tambur-tampon-coarda de la Microsoft a dat roade. Rezistența a fost slabă, performanța s-a triplat, timpul de livrare a fost redus cu 90% și predictibilitatea s-a îmbunătățit cu 98%. În toamna lui 2005, am raportat despre rezultatele obținute la o conferință la Barcelona 5
Anderson, David J. și Dragos Dumitriu, „De la cel mai rău la cel mai bun în 9 luni: Implementarea unei soluții Drum-Buffer-Rope în departamentul IT al Microsoft,” Proceedings of the TOCICO World Conference, Barcelona, noiembrie 2005.

Și în iarna lui 2006 a făcut un alt reportaj. Munca mea a atras atenția lui Donald Reinertsen, care a făcut o vizită specială la biroul meu din Redmond. A vrut să mă asigure că totul era pregătit pentru o tranziție completă la kanban.

Kan-ban - un cuvânt japonez care se traduce literal prin „placă de semnalizare”. În producție, o astfel de placă este folosită pentru a vizualiza ritmul în creștere al producției, ceea ce permite producerea mai multor produse. Angajații din fiecare etapă a procesului nu pot trece la următoarea fază de lucru până când semnalul corespunzător este transmis prin intermediul panoului kanban. Deși știam de existența acestui mecanism, nu eram convins că este util sau chiar viabil în raport cu munca intelectuală, în special dezvoltarea de software. Am înțeles că kanban a oferit ritmul optim, dar nu știam despre buna sa reputație ca metodă de stimulare a îmbunătățirii incrementale a procesului. Nu știam că Taiichi Ohno, unul dintre creatorii sistemului de producție Toyota, a spus: „Cele două principii principale ale sistemului de producție Toyota sunt automatizarea just-in-time și asistată de om, sau autonomie. Un instrument este folosit pentru a gestiona sistemul - acesta este kanban. Cu alte cuvinte, Kanban este vital pentru proces. kaizen(„îmbunătățirea continuă”) utilizată de Toyota. Este mecanismul care face ca sistemul să funcționeze. Acum, cu cinci ani de experiență în spate, accept asta ca pe un adevăr absolut.

Din fericire, Don a făcut un argument convingător pentru trecerea de la drum-buffer-rope la kanban. Suna destul de ezoteric: sistemul kanban oferă o tranziție mai lină de la timpul de nefuncționare la un blocaj decât toba-tampon-coarda. Cu toate acestea, înțelegerea acestei distincții nu este esențială pentru citirea și înțelegerea acestei cărți.

Reexaminând soluția implementată de Microsoft, mi-am dat seama că dacă am percepe-o imediat ca rezultat al unui sistem kanban, atunci rezultatul ar fi același. Mi s-a părut interesant faptul că două abordări diferite duc la același rezultat. Deci, din moment ce a fost același proces, nu m-am simțit obligat să-l văd doar ca pe produsul sistemului tambur-tampon-coarda.

Am început să prefer termenul „kanban” acestei expresii complexe. Este folosit în manufacturarea slabă (la fel ca și sistemul de producție Toyota). Acest corp de cunoștințe a primit mult mai multă distribuție și recunoaștere decât teoria constrângerilor. Kanban, în ciuda originii sale japoneze, este mai puțin metaforic decât toba, tamponul și frânghia combinate. Acest cuvânt este mai ușor de pronunțat, explicat și, după cum sa dovedit mai târziu, de predat și implementat. Aici s-a blocat.

Apariția metodei kanban

În septembrie 2006, am părăsit Microsoft pentru a conduce dezvoltarea de software la Corbis, o companie privată de depozitare a fotografiilor și proprietate intelectuală din centrul orașului Seattle. Inspirat de ceea ce a realizat Microsoft, am decis să implementez un sistem kanban pull în Corbis. Și aici, rezultatele au fost foarte reușite, ducând la dezvoltarea majorității conceptelor prezentate în această carte. Este un set extins de acele concepte — vizualizarea fluxului de lucru, tipurile de elemente ale fluxului de lucru, cadențe, clase de servicii, raportare de management special și analiza activității — care definesc metoda Kanban.

În această carte, descriu Kanban (cu majuscule) ca o metodă de schimbare evolutivă folosind sistemul de tragere kanban (minuscule), vizualizarea și alte instrumente pentru a cataliza introducerea ideilor slabe în dezvoltarea tehnologiei și operațiunile IT. Este un proces evolutiv și pas cu pas. Kanban vă permite să realizați optimizarea proceselor bazată pe context, cu rezistență minimă la schimbare, menținând în același timp ritmul optim pentru toți oamenii implicați.

Cartea lui David Anderson Kanban preia de la prima pagină.

Cu imagini, grafice și concluzii Biografia condensată a lui David dezvăluie metodologia Kanban pentru ciudatul înțelept de management de proiect. Managementul de proiect este interesant atunci când este spus la persoana întâi de către dezvoltatorul direct al metodei.

Despre autor

Listat pe blogul oficial al lui David J Anderson ca p Președintele Lean Kanban Inc. De asemenea, el t manager de management și consultant din anii 2000, vorbitor și gazdă a conferinței din 2005. Pentru prima dată într-o poziție de conducere, a fost în 1991, așa că experiența sa vă permite să comparați sincer kanban și cascadă, agil, scrum și alte metodologii de management de proiect.

A creat kanban pentru a ridica nivelul muncii intelectuale și creative. Scopul lui David a fost să livreze la timp, să atingă obiectivele și să gestioneze în mod adecvat companiile actuale în general.

Folosind exemple reale din viața Microsoft, Motorola și Corbis, el a povestit și a arătat principiile, metodele și instrucțiunile de implementare a kanban-ului într-o companie.

Încărcarea semantică și esența cărții

Carte . Rută alternativă cătreAgile este scris de persoana care a inventat kanban în primul rând. Cartea este foarte interesantă și informativă. Aici, linia dintre filosofia lui Kaizen este foarte interesant dezvăluită ( imbunatatire continua), metodologie ( A se sprijini) și Kanban (o metodă de conservare a resurselor umane și materiale).

Kaizen este filozofia și etica relației dintre muncitorii din fabrică și conducere.

Lean manufacturing este un sistem de management al proiectelor creat la Toyota pentru a elimina orice pierdere de timp și resurse din procesele companiei.

Kanbaneste o metodă de management de proiect care oferă o cale limitează sarcinile care rulează simultan. Dacă există o limită de oameni, instrumente sau timp, kanban ajută la distribuirea sarcinilor și proiectelor.

Anderson a fost foarte influențat de teoria constrângerilor în scrierea acestei cărți. Cartea este plină de limite WIP, blocaje și capacitatea de adeterminați sincer sarcina maximă pe unitatea de timp, care mentine calitatea la un nivel optim.

Teoria constrângerilor (TOC) a Dr. Eliyahu Goldratt este o metodologie de management al afacerilor de producție. Un fizician israelian a dezvoltat o teorie și o metodă practică de gestionare a organizațiilor, algoritmi pentru operarea producției, logisticii și comercializării mărfurilor. O abordare sistematică a identificării constrângerilor în companii ajută la configurarea totul. Conform experienței lui Goldratt, De cele mai multe ori, politica companiei devine o constrângere.

Limită WIP (lucrări în curs) — numărul de sarcini care pot fi deschise în același timp.

Gâtul de sticlă - un moment în fluxul de lucru când există o problemă serioasă limitarea resurselor sau oportunităților. Pe diagrame, chiar arată ca un gât îngust al unei sticle: atât înainte, cât și după o astfel de situație, liniile se extind pe diagrame.

Stereotipuri despre kanban

Când auzim de kanban, ne imaginăm adesea o tablă cu autocolante - acest stereotip ne este impus de mass-media. În mod figurat, există o listă de sarcini de autocolante deschise, care rulează și finalizate pe perete. . Puteți folosi pereți virtuali și programe pentru a gestiona proiecte, în care vor fi introduse liste de sarcini, priorități și alte nuanțe.

Metodologia kanban de aici nu va fi o tablă și nu autocolante, ci procesul de monitorizare și transfer de sarcini pe perete. După ce reguli, cine și de ce mută autocolantele, câte autocolante pot fi păstrate în coloana „efectuat”, de ce limitați numărul din această coloană - asta spune David pe paginile " Kanban. O cale alternativă către agilitate.

Kanban nu este o placă lipicioasă, autocolantele sunt doar un indicator al volumului de muncă.

Anderson a proiectat kanban-ul astfel încât să nu începem un nou proiect până la finalizarea celor anterioare. Prin urmare, pentru un dezvoltator, numărul de autocolante este selectat - 3-5, de exemplu, și exact atât de multe sarcini pe unitatea de timp pot fi deschise pentru el. Numai după ce a terminat oricare dintre sarcini, el poate prelua una nouă.

Vorbim mult despre orele-om și prețul lor, dar de multe ori nu ne dăm seama că există o oră de muncă productivă și o oră luată din viață. Și există o săptămână de muncă productivă, domeniul căreia trebuie să iei concediu medical. David vorbește despre acest ritm de lucru când fiecare oră este productivă și aceasta este o stare constantă de sănătate a echipei.

Agile, Scrum și Kanban

Anderson este sigur că metodologiile Agile și Scrum sunt formulate și rigide. În opinia sa, managementul de proiect ar trebui să fie individual în fiecare companie. Prin urmare, Agile și Scrum cu algoritmii lor standardizați de acțiune sunt învechite, precum metodologia clasică Waterfall pas cu pas. O interdicție kan - metoda este asa specifice companiei, care îi sperie pe adepții metodologiilor flexibile!

Agile este o metodologie agilă cu care programarea a început istoric în formatul lansării de actualizări la programe la fiecare două luni. Iterațiile de programare de câteva săptămâni pentru a adăuga fiecare caracteristică accelerează procesul de dezvoltare și reduce riscul.

Scrum este o altă metodologie agilă, cu iterații scurte, dar mai mult control asupra procesului de programare. Există sprinturi - perioade de timp cu anumite sarcini de îndeplinit. Sunt strict limitate. Există întârzieri - liste de sarcini în general, care sunt distribuite de proprietarul produsului. Nu aparține echipei de dezvoltare, dar prioritizează sarcinile.

David Anderson

Kanban. O cale alternativă către agilitate

David J Anderson

Schimbare evolutivă de succes pentru afacerea dvs. de tehnologie

Publicat cu permisiunea Lean Kanban Inc.

Mulțumim Comunității Lean Kanban Rusia reprezentată de Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov și Igor Filipyev pentru ajutorul acordat în pregătirea publicației.

Toate drepturile rezervate.

Nicio parte a acestei cărți nu poate fi reprodusă sub nicio formă fără permisiunea scrisă a deținătorilor drepturilor de autor.

* * *

Dedicat lui Nikola și Natalie

cuvânt înainte

Sunt mereu atent la munca lui David Anderson. L-am cunoscut în octombrie 2003 când mi-a trimis o copie a cărții sale Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. După cum sugerează și titlul, cartea a fost puternic influențată de Teoria constrângerilor (TOC) a lui Eliyahu Goldratt. Mai târziu, în martie 2005, l-am vizitat pe David la Microsoft, moment în care lucra îndeaproape cu diagramele de flux cumulative. Chiar mai târziu, în aprilie 2007, am avut ocazia să observ cum funcționează sistemul kanban inovator pe care l-a implementat în Corbis.

Aș dori să avertizez cititorii despre câteva lucruri. În primul rând, dacă credeți că știți cum funcționează sistemele kanban, atunci probabil vă referiți la cele utilizate în manufacturarea slabă. Ideile din această carte sunt mult mai avansate decât sistemele simple care utilizează limite WIP statice, programare FIFO și o singură clasă de servicii. Vă rugăm să acordați atenție acestor diferențe.

Rezolvarea dilemei managerului Agile

În activitățile mele de zi cu zi din 2002 și în cartea mea anterioară(1), m-au preocupat în principal două probleme. În primul rând, cum să protejezi echipa de cerințele din ce în ce mai mari ale afacerii și să obții ceea ce se numește acum „ritmul optim” în comunitatea agilă. Și în al doilea rând, cum pot implementa cu succes o abordare agilă în întreaga organizație, depășind rezistența inevitabilă la schimbare?

Găsirea ritmului potrivit

În 2002, comunitatea agilă a considerat ritmul optim ca fiind pur și simplu „o săptămână de lucru de 40 de ore”(2). Principiile Manifestului Agile(3) afirmau că „procesele agile promovează dezvoltarea optimă. Sponsorii, dezvoltatorii și utilizatorii trebuie să fie pregătiți să mențină un ritm constant la nesfârșit.” Cu doi ani mai devreme, echipa mea de la Sprint PCS a tot auzit de la mine că „dezvoltarea de software la scară este un maraton, nu un sprint”. Dacă membrii echipei ar trebui să mențină un ritm constant în procesul de lucru la un proiect de un an și jumătate, atunci nu li s-ar putea lăsa să se epuizeze într-o lună sau două. Proiectul a trebuit să fie planificat, bugetat, cronometrat și evaluat pentru a se asigura că membrii echipei au petrecut o perioadă rezonabilă de timp lucrând în fiecare zi și nu sunt prea obosiți. Ca manager, sarcina mea a fost să ating acest obiectiv și satisface toate cerințele de afaceri.

Când eram în prima mea funcție managerială (era în 1991, la un startup care făcea plăci de captură video pentru computere personale și mai mici), CEO-ul a spus că managementul are o „opinie foarte negativă” despre mine. Întotdeauna am răspuns „nu” atunci când oportunitățile noastre ca dezvoltatori erau deja epuizate și din ce în ce mai multe produse sau funcții erau solicitate de la noi. Până în 2002, devenisem un obicei: am petrecut încă zece ani refuzând să mă supun capriciilor proprietarilor de afaceri.

Despre carte
Un ghid aprofundat despre kanban de la un tânăr de 30 de ani, pionier kanban pentru prima dată în dezvoltarea de software.

David Anderson, care a implementat metoda kanban în mai multe companii și a îmbunătățit-o constant, arată cum să introducă în mod eficient ideile slabe în dezvoltarea tehnologiei și operațiunile IT - cu rezistență minimă la schimbare, menținând în același timp ritmul optim pentru toți angajații implicați.

Kanban identifică rapid problemele care afectează performanța și obligă echipa să se concentreze pe rezolvarea acestora pentru a menține fluxul de lucru. Făcând vizibile problemele legate de calitate și proces, kanban oferă o oportunitate de a evalua impactul defectelor, constrângerilor, variabilității și costurilor economice asupra fluxului de lucru și a randamentului angajaților.

Simpla limitare a lucrărilor neterminate prin kanban are ca rezultat îmbunătățirea calității muncii și a productivității. Combinația dintre fluxul de lucru simplificat și calitatea îmbunătățită ajută la reducerea timpilor de livrare și îmbunătățește predictibilitatea și probabilitatea de a livra munca la timp. Prin stabilirea unor cadențe regulate de lansare și prin respectarea consecventă a programelor, kanban ajută la construirea încrederii cu clienții și alți membri ai fluxului de valoare - alte departamente, furnizori și parteneri dependenți.

S-a dovedit că Kanban crește satisfacția utilizatorilor prin lansări regulate, fiabile și de înaltă calitate de software valoros. De asemenea, sa dovedit că îmbunătățește productivitatea, calitatea și reduce timpul de producție. Există dovezi că kanban poate fi un catalizator pentru apariția unei organizații mai agile prin schimbarea culturală evolutivă.

Această carte răspunde la întrebările:

- Ce este kanban?
De ce are nevoie compania ta?
- Cum se implementează?
- Cum să recunoști oportunitățile de îmbunătățire în afaceri - și ce să faci cu ele?

Pentru cine este această carte?
Pentru managerii și șefii companiilor IT.

Despre autor
David Anderson este fondatorul Universității Lean Kanban și al Școlii de Management David J Anderson, dedicată să ajute liderii și managerii să obțină rezultate mai bune prin cele mai bune practici.

Anderson are 30 de ani de experiență în companii de tehnologie. El a introdus practici de management agil în companii precum Motorola și Microsoft.

David a fost primul care a folosit kanban în dezvoltarea de software în 2005.

Kanban înseamnă „tablou de semnalizare” în japoneză. În producție, o astfel de placă este utilizată pentru a vizualiza ratele în creștere, ceea ce vă permite să produceți mai multe produse la un cost mai mic. Un exemplu izbitor este abordarea Toyota, datorită căreia de mulți ani principiul „just in time” a fost implementat eficient, cu costuri minime.

David Anderson oferă un set extins de idei (vizualizarea procesului și a regulilor de lucru, tastarea elementelor de lucru, clase de serviciu, cadențe, metrici și grafice pentru contabilitate și analiză de management) care definesc metoda kanban.

Cartea descrie instrumente care vă permit să introduceți în mod eficient ideile slabe în dezvoltarea tehnologică și operațiunile IT cu rezistență minimă la schimbare, menținând în același timp un ritm optim pentru toți angajații implicați în muncă.

Publicat în limba rusă pentru prima dată.

Deținătorii drepturilor de autor! Fragmentul prezentat al cărții este plasat în acord cu distribuitorul de conținut juridic SRL „LitRes” (nu mai mult de 20% din textul original). Dacă considerați că postarea de materiale încalcă drepturile dumneavoastră sau ale altcuiva, vă rugăm să ne anunțați.

Cel mai proaspăt! Rezervați chitanțe astăzi

Testamentul lui Yvette Blanche
Demange Patricia
Periodice

Suzanne s-a ridicat de pe stâncă și era pe cale să se întoarcă la mașină când a auzit o voce:

- Vino! Vino la mine! Vino la mine! Vino!

Și, ca prima dată, aceste cuvinte distincte au fost urmate de un suspine de neînțeles. Fata a încremenit. Vocea era atât de plângătoare, încât nu se putea mișca.

Și apoi a auzit din nou aceste cuvinte:

„Vino, vino... vino la mine!” Vino!

Deodată Susannei i s-a părut că creierul ei va exploda din această singură frază. Timp de câteva minute a rămas nemișcată, dar apoi și-a adunat puterile și s-a repezit la mașina parcată sub copaci. A introdus rapid cheia de contact și a pornit motorul. Voia să plece de aici cât mai curând posibil. Atâta timp cât nu știi sau auzi nimic. Nu poate fi! Ea este doar Susanna Lambert, Susanna Lambert, Susanna Lambert...
Vârcolac
Grinder Alexandra
Periodice

A urmat-o pe Julia până în mlaștină... Fata îi simți privirea asupra ei și era amorțită de groază. Picioarele au început imediat să se cufunde din ce în ce mai adânc în mlaștina rece. Trebuie să plecăm de aici înainte să fie prea târziu! A încercat să se întoarcă spre potecă: iată-l, pământ solid, la propriu la un metru distanță... Dar acolo o aștepta ceva mult mai periculos decât o mlaștină fetidă: un vârcolac acoperit cu lână cenușie! Silueta lui cocoșată a ieșit brusc din întuneric. Capul masiv se legăna încet în timp cu vântul, iar în adâncurile orbitelor, cărbunii ochilor străluceau în mod amenințător. Julia a făcut o ultimă încercare de a-și face față propriei frici, dar groaza a paralizat-o: nu a putut face niciun pas. Între timp, se apropia o creatură ciudată care arăta ca un lup. Între ei erau doar câțiva pași. Acum puteți vedea deja lâna cenușie de pe labele monstrului, aici ghearele ascuțite sclipeau în lumina lunii...
Hotărât magul. Formare
Nazimov Constantin
Fallouts

Un student, este un student peste tot. Divertisment și încercări de a câștiga. Unul dintre lucrurile obișnuite a dus la o tragedie și am ajuns... în lumea magiei. Succes cu el, mi-a placut. Chiar au ajutat și s-au dovedit a fi... studenți, dar deja la academia de magie și s-au pus pe treabă.

Dar viața transformă oamenii și magicienii așa cum își dorește. Lumea asta nu l-a cunoscut pe marele intrigator, cu capacitatea lui de a face bani din aer. Nimeni nu a construit piramide financiare. Prin urmare, mă pot întoarce la maximum. Dar, problemele serioase și escrocherii au dispărut. Una dintre idei s-a dovedit a fi de așa natură încât prietenii mei și cu mine nu am putut digera rezultatul. A trebuit să ies din calea mea și să duc lucrurile la un cu totul alt nivel. Și este greu să o tragi: aici este aurul pungilor și breasla hoților, a oamenilor de rând și a birocraților. Și, de asemenea, probleme cu artefacte și fete, datorii cu carduri și mașini frumoase. Trebuie să te decizi rapid, să reacționezi instantaneu. Eh, dar vreau să trăiesc frumos și sper că va funcționa, deși nu este un fapt...
doamnă în alb
Grey Lara
Detectivi și Thrillere, Thriller

În fiecare zi, după miezul nopții, ceva se întâmplă în castel...

Katerina a înțeles că viața ei era atârnată de un fir. Ea și-a prins fusta cu o mână pentru ca tivul să nu interfereze cu alergarea ei, cealaltă mână a fost întinsă înainte pentru a nu-și izbi capul de perete. In sfarsit o usa! Fata l-a deschis brusc și a fugit pe coridor. Urmărătorul nu a rămas în urmă: pașii lui se auzeau din ce în ce mai limpede. O putea ajunge din urmă pe Katerina în orice moment!

- Pentru ajutor! Pentru ajutor! tipa fata. - Cineva! Ajutor!

S-a împiedicat de o stâncă și a lovit puternic, căzând la podea. Katerina s-a târât deoparte și s-a ascuns. Din fericire, era întuneric, iar urmăritorul a fugit pe lângă ea fără să o observe. Katerina s-a uitat în jur: stătea întinsă într-o cameră întunecată, fără ferestre, fără lumină, nu se vedea nimic...
Racing Joker. Joc de supraviețuire
Nazimov Constantin
Ficțiune, ficțiune eroică

Jocul nu este așa cum l-am imaginat. Minciuna și trădarea, mita și chiar sclavia merg mână în mână aici. Sunt jucători normali, dintre care mulți, care încearcă să trăiască după reguli și onoare. Și se mai întâmplă ca negrul să fie prezentat ca alb, o minciună pentru adevăr.

Prin voința minții rețelei îmi sunt puse în fața sarcini și misiuni complexe, pe care nici nu le bănuiam. Cursele pentru eliminare sau supraviețuire sunt înlocuite cu fuga de la vânătorii de recompense. Trebuie să intrăm într-o confruntare cu nedreptate și răutate. Pentru a îmbunătăți viața jucătorilor obișnuiți care, în credibilitatea și naivitatea lor, au urmărit promisiuni și s-au trezit într-o situație fără speranță. Atârnă-te în jocul din lume vecină, unde monștrii se întâlnesc la fiecare pas și nu te consideră decât prada lor. Fără toate acestea, nu poți ajunge la linia de sosire.

Pe tot parcursul jocului, prietenii și dușmanii cot la cot cu mine, unii mă ajută în momentele dificile, alții sunt gata să-mi înfige un cuțit în spate, dar trebuie să mă bazez pe mine și pe noroc. Este stabilit un obiectiv, benzina este turnată în rezervor, o amuletă este în jurul gâtului, iar piciorul apasă pedala de accelerație pe podea. Victoria va veni și îmi voi atinge scopul! Așa sper…
Fantome din ceață
Grinder Alexandra
Periodice

Până acum, Elena nu a acordat importanță faptului că proprietara pensiunii în care stătea era singură tot timpul. Ea a presupus că soția lui era fie ocupată în bucătărie, fie ocupată cu alte afaceri și, prin urmare, nu a apărut în fața oaspeților...

Setează „Săptămâna” - produse noi de top - lideri pentru săptămână!

2. Rector blestemat
Vara Lena
Romane de dragoste , Romane de dragoste , Ficțiune , Ficțiune detectiv ,

Aveam un an să termin. Un an - și am putut obține libertatea și independența la care visasem încă din copilărie. Cu toate acestea, moartea subită și foarte suspectă a mamei mele mi-a dat lumea peste cap. A lăsat în urmă multe întrebări, iar singura șansă de a găsi răspunsuri este să meargă la cea mai de elită universitate a Republicii. Am crezut că snobismul noilor colegi ar fi principala mea problemă, dar m-am înșelat. Răspunsurile pe care le caut s-ar putea să mă coste viața și, din anumite motive, acum sunt mai preocupat de viața rectorului local, care este sub blestem.
Academia Arcturus. mireasa de lup
Tei Sylvia
Ficțiune, ficțiune umoristică

Uneori, trădarea nu este sfârșitul, ci începutul.

Ocazional - aceasta este ușa către o altă lume, în care războiul este în prag. Unde vârcolacii luptă până la moarte pentru că femeile și bărbații lor încarcă arme cu gloanțe de argint. Unde un ucigaș misterios se plimbă, roade gâtul tuturor celor care seamănă atât de mult cu tine. Unde zâmbetele bune sunt o șansă sigură de a cădea într-o capcană, iar un lup mârâit la spate este o șansă de a scăpa.

Pregătește-te, te așteaptă aici academia vârcolacilor, un maniac în fața ușii și un om misterios care, dintr-un motiv oarecare, a decis că poate veni la tine noaptea.

Și totul pentru că trădarea nu este sfârșitul, ci doar începutul.
Academia Arcturus 2. Soția lupului
Tei Sylvia
Fantezie, Cyberpunk

Se spune că viața și încrederea se pierd o singură dată. Cândva am fost norocos, dar este puțin probabil ca norocul să fie destinat să se repete. Maniacul care ucide fetele este găsit, dar păpușarul încă trage de sforile păpușilor lui. Moartea urmează fără încetare și trebuie să fiu cu un pas înainte. De data aceasta, pentru a se salva nu numai pe ea însăși, ci și pe vârcolacul, de care este legată prin legături de nedespărțit. El este mai puternic decât restul, iar aceasta este slăbiciunea lui. Ca să-l țin în viață, va trebui să-l trădez. Sau există o altă cale de ieșire?

Portal pentru student. Autoinstruire

* * *

cuvânt înainte

Partea I Bazele

Capitolul 1 Rezolvarea dilemei managerului Agile

Găsirea ritmului potrivit

În căutarea unui management de succes al schimbării

De la tobă-tampon-frânghie la kanban

Apariția metodei kanban

Despre autor

Folosind exemple reale din viața Microsoft, Motorola și Corbis, el a povestit și a arătat principiile, metodele și instrucțiunile de implementare a kanban-ului într-o companie.

Încărcarea semantică și esența cărții

Kaizen este filozofia și etica relației dintre muncitorii din fabrică și conducere.

Lean manufacturing este un sistem de management al proiectelor creat la Toyota pentru a elimina orice pierdere de timp și resurse din procesele companiei.

Limită WIP (lucrări în curs) — numărul de sarcini care pot fi deschise în același timp.

Gâtul de sticlă - un moment în fluxul de lucru când există o problemă serioasă limitarea resurselor sau oportunităților. Pe diagrame, chiar arată ca un gât îngust al unei sticle: atât înainte, cât și după o astfel de situație, liniile se extind pe diagrame.

Stereotipuri despre kanban

Kanban nu este o placă lipicioasă, autocolantele sunt doar un indicator al volumului de muncă.

Agile, Scrum și Kanban

Agile este o metodologie agilă cu care programarea a început istoric în formatul lansării de actualizări la programe la fiecare două luni. Iterațiile de programare de câteva săptămâni pentru a adăuga fiecare caracteristică accelerează procesul de dezvoltare și reduce riscul.

Această carte răspunde la întrebările:

Cel mai proaspăt! Rezervați chitanțe astăzi

Setează „Săptămâna” - produse noi de top - lideri pentru săptămână!

ARTICOLE SIMILARE

Partea I
Bazele

Capitolul 1
Rezolvarea dilemei managerului Agile