David Anderson - Kanban. Calea alternativă la agilă

Despre cartea
Ghid detaliat pentru Canbana de la o persoană cu o experiență de 30 de ani, a aplicat pentru prima dată această metodă în dezvoltarea software-ului.

David Anderson, care a introdus metoda Canbana în mai multe companii și imbunatatirea in mod constant, spune cum sa introduceti in mod eficient ideile de producție înclinată în evoluțiile tehnologice și operațiunile IT - cu rezistență minimă la schimbările și, în timp ce menține ritmul optim pentru toți angajații.

Kanban dezvăluie rapid problemele care afectează performanța și determină comanda să se concentreze asupra rezoluției lor pentru a menține un flux constant de muncă. Efectuarea de probleme vizuale ale calității și procesului, Canbanul face posibilă evaluarea influenței defectelor, a restricțiilor, a variației și a costurilor economice asupra fluxului de lucru și a numărului de angajați.

O limitare simplă a sarcinilor neterminate prin Canbana conduce la îmbunătățirea calității muncii și a performanței acesteia. Combinația de optimizare a fluxului de lucru și o calitate îmbunătățită ajută la reducerea timpului de execuție și crește predictibilitatea și probabilitatea de a lucra la timp. După ce au stabilit cadre de eliberare regulați și un program constant, Kanbanul ajută la crearea relațiilor de încredere cu clienții și cu alți participanți la valoarea creării de valori - alte departamente, furnizori și parteneri dependenți.

Sa demonstrat că Canbanul îmbunătățește satisfacția utilizatorilor datorită programelor religioase regulate, fiabile și de înaltă calitate. De asemenea, sa demonstrat că îmbunătățește productivitatea, calitatea și reduce timpul de dezvoltare. Există dovezi că Canbanul poate deveni un catalizator pentru apariția unei organizații mai flexibile din cauza schimbărilor culturale evolutive.

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

- Ce este Kanbanul?
- De ce aveți nevoie de compania dvs.?
- Cum să o puneți în aplicare?
- Cum să recunoaștem oportunitățile de îmbunătățire în afaceri - și ce să faceți cu ei?

Pentru cine această carte
Pentru managerii și managerii companiilor IT.

Despre autor
David Anderson este fondatorul Universității Lean Kanban și al Școlii de Management David J Anderson, ajutând managerii și managerii să obțină rezultate mai bune cu ajutorul tehnicilor avansate.

Anderson are 30 de ani de experiență în companiile tehnologice. A introdus metode flexibile de management în companii precum Motorola și Microsoft.

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

David Anderson.

Kanban. Calea alternativă la agilă

David J. Anderson.

Schimbarea evolutivă de succes pentru afacerea dvs. de tehnologie

Publicat cu permisiunea lui Lean Kanban Inc.

Vă mulțumim pentru ajutor în pregătirea publicării Comunității Lean Kanban Community Rusia în Pimenova Alexey, Vyacheslav Rasselnik, Anton Manina, Serghei Baranova și Igor Filipian

Toate drepturile rezervate.

Nici o parte din această carte nu poate fi reprodusă în orice formă fără permisiunea scrisă a deținătorilor de drepturi de autor.

* * *

Dedicat lui Nikola și Natalie

Prefaţă

Întotdeauna am grijă de lucrarea lui David Anderson. L-am întâlnit în octombrie 2003, când mi-a trimis o instanță a cărții sale Agile Management pentru Inginerie Software: Aplicarea teoriei constrângerilor pentru rezultatele afacerii ("Management flexibil de gestionare a software-ului: aplicarea teoriei restricțiilor de sistem pentru rezultatele afacerii"). După cum se poate presupune din nume, teoria restricțiilor (TOC) Ilie Goldratta a avut o mare influență asupra cărții. Mai târziu, în martie 2005, l-am vizitat pe David în Microsoft, în acel moment el a lucrat strâns cu diagrame de flux cumulativ. Chiar mai târziu, în aprilie 2007, am observat cum acționa sistemul de canbură descoperiri în Corbis.

Eu aduc toată această cronologie, astfel încât să vă simțiți, în ce ritm incontrolabil este promovat de gândirea managementului lui David. El nu ține singura idee, încercând să se potrivească întregii lumi sub ea. Dimpotrivă, el încearcă să ia în considerare problema în ansamblu, deschisă pentru diferite soluții pentru diverse opțiuni, le are gust în practică și evaluează principiile muncii. Rezultatele acestei abordări vor vedea în această carte.

Desigur, viteza este bună, dacă este îndreptată în direcția cea bună și sunt sigur că David se mișcă în direcția cea bună. Mai ales admir ultima lucrare cu Kanban-Systems. Întotdeauna am crezut că principiile producției înclinate pot fi aplicate direct la dezvoltarea produsului, spre deosebire de ideile lui Tos. Mai mult, în octombrie 2003, am scris David următoarele: "Una dintre principalele slăbiciuni ale lui Tos este subestimarea importanței părții partidului. Dacă prioritatea principală este de a găsi și de a elimina restricția, atunci înseamnă adesea că tocmai decideți această problemă. " Încă mai consider că această declarație este adevărată.

În cadrul întâlnirii noastre din 2005, am oferit din nou David să arate mai departe decât să se concentreze pe locurile înguste în Tos. I-am explicat că succesul zgomotos al sistemului de producție Toyota (PST) nu are nimic de-a face cu căutarea și eliminarea blocajelor. Creșterea performanței Toyota realizează datorită scăderii volumelor lotului și reducerii variabilității, reducând astfel numărul de rezerve de producție necesare. A fost reducerea unor astfel de rezerve care au condus la atingerea avantajelor economice, iar acest lucru a fost posibil datorită unor astfel de sisteme de reducere a producției incomplete, așa cum Kanban.

În 2007, am vizitat Corbis. Rezultatul introducerii sistemului kanban părea impresionant. Am subliniat că David a îmbunătățit în mod semnificativ abordarea Kanbanului utilizată în Toyota. De ce am crezut așa? Sistemul de producție Toyota este optimizat pentru a lucra cu sarcini repetitive și previzibile cu aceeași durată și valoare de întârziere omogenă. În aceste condiții, este destul de corect să se utilizeze astfel de abordări, cum ar fi FIFO-Prioritizare ("prima dată - primul stânga"). De asemenea, blochează corect primirea de muncă dacă se atinge limita sarcinilor neterminate. Cu toate acestea, dacă ne ocupăm de activități neprofitabile, imprevizibile, cu o durată diferită și o valoare diferită de întârziere, aceste abordări nu pot fi considerate optime - și anume lucrurile sunt încheiate cu dezvoltarea software-ului. Avem nevoie de mai multe sisteme avansate, iar aceasta este prima carte care le descrie cu detalii practice.

Aș dori să avertizez cititorii despre unele lucruri. În primul rând, dacă credeți că știți cum funcționează sistemele Kanban, atunci probabil că aveți în vedere cele utilizate în fabricarea Lean. Ideile descrise în această carte sunt mult progresive decât acele sisteme simple care utilizează limitele statice ale WIP, FILO-Planning și o singură clasă de servicii. Vă rugăm să acordați atenție acestor diferențe.

În al doilea rând, nu credeți că această abordare este un sistem de control vizual. Vizualizarea sarcinilor neterminate realizate cu ajutorul cărbunelui Kanban este foarte utilă, dar este doar un mic aspect al acestei abordări. Dacă ați citit 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 astfel de aspecte ca structurile procedurilor și sarcinile de trimitere, gestionarea resurselor indispensabile și utilizarea claselor de servicii. Nu vă distrați de partea vizuală, altfel săriți cele mai interesante momente.

În al treilea rând, nu resetați aceste metode din conturi doar pentru că ele par prea simple de utilizat. Ușor de utilizat este rezultatul ideilor lui David privind modul de obținere a beneficiului maxim cu rezultate minime. El știe nevoile practicanților și a acordat o atenție deosebită ceea ce funcționează cu adevărat. Metodele simple arată o stabilitate ridicată și aproape întotdeauna duce la cele mai bune rezultate pe termen lung.

Aceasta este o carte fascinantă și necesară, merită un studiu aprofundat. Nivelul de beneficiu pe care îl extrageți de la ea depinde de cât de serios reacționați la citire. Nici o altă carte nu vă va prezenta mai bine aceste idei avansate. Sper că o va place ca mine.

Soluție Dilemma Manager Agile

În 2002, am fost un manager de dezvoltare în biroul de la distanță al diviziei de telefoane mobile Motorola din Seattle (a fost numită PCS) și a fost într-o situație dificilă. Departamentul meu a făcut parte dintr-o pornire pe care Motorola a câștigat un an mai devreme. Am dezvoltat un software de rețea pentru transmisia de date wireless, cum ar fi descărcare wireless și managementul instrumentului. Aceste aplicații de servere incluse în sistemele integrate care au fost strâns legate de codul clientului de telefoane mobile, precum și cu alte elemente din rețelele de telecomunicații și o infrastructură de operare, cum ar fi facturarea. Termenele limită au fost numite de către managerii care nu au acordat atenție complexității ingineriei proiectului, riscurilor sau scalei sale. Baza codului sa dezvoltat de la startup, în timp ce dezvoltarea multor capabilități planificate inițial a fost amânată mai târziu. Un dezvoltator senior a insistat ca produsele noastre sunt numite "prototipuri". Am fost cu disperare necesară pentru a îmbunătăți productivitatea și calitatea produselor pentru a satisface cerințele de afaceri.

În activitățile sale zilnice în 2002 și în procesul de lucru la cartea anterioară (1), am fost preocupat de două probleme. În primul rând, cum să protejați echipa de cerințele de afaceri tot mai mare și să realizați faptul că acum în comunitatea agilă este obișnuită numită "ritm optim". Ș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?

În căutarea unui ritm optim

În 2002, comunitatea agilă a perceput tempo-ul optim pur și simplu ca "săptămâna de lucru de 40 de ore" (2). Principiile Agile-Manifest (3) au citit că "procesele agile contribuie la o dezvoltare optimă. Sponsorii, dezvoltatorii și utilizatorii trebuie să fie pregătiți să mențină un ritm permanent pentru timpul infinit. " Cu doi ani înainte de aceasta, echipa mea din Sprint PCS auzită în mod constant de la mine că "dezvoltarea de software la scară largă este un maraton, nu un sprint". Dacă membrii echipei trebuiau să mențină un ritm constant în procesul de lucru la un proiect de două ori, era imposibil să le permită să ardă într-o lună sau altceva. Proiectul a fost necesar pentru planificarea, introducerea în buget, vopsea timpul și expunerea membrilor echipei zilnic a petrecut o perioadă rezonabilă de timp și nu prea obosită. Înainte de mine, ca manager, a fost sarcina de a atinge acest obiectiv și Satisface toate cerințele afacerii.

Când am lucrat la prima poziție de conducere (a fost în 1991, în startup, care a făcut taxa de captură video pentru computerele personale și mai mici), CEO a raportat că conducerea a avut o "opinie extrem de negativă". Întotdeauna am răspuns "nu" atunci când capabilitățile noastre au fost deja epuizate și mai multe produse sau funcții ne-au necesitat. Până în 2002, mi-a intrat obiceiul: am petrecut încă zece ani, refuzând să realizăm capriciile proprietarilor de afaceri.

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

Cu imagini, grafice și concluziio biografie comprimată a lui David dezvăluie metodologia canbanului pentru un fan sanatos de management al proiectului. Managementul proiectului este interesant atunci când este descris de dezvoltatorul direct al metodei primei persoane.

Despre autor

Pe blogul oficial David J Anderson este indicat ca n reddadear Lean Kanban Inc. De asemenea, el T.reneriat pe management și consultant de la data de 2000, vorbitor și conferință de lider din 2005. Pentru prima dată într-o poziție senior, sa găsit în 1991, astfel încât experiența sa comparați sincer Kanban și Cascada, Agile, Scrum, Alte metodologii de management de proiect.

El a creat canalul pentru a ridica nivelul muncii intelectuale și creative. Scopul lui David a fost livrarea în timp util, conformitatea lucrării la obiective și o gestionare adecvată a companiilor moderne în general.

Pe exemple reale de la Microsoft, Motorola și Corbis, a spus și a arătat și a arătat principiile, metodele și instrucțiunile pentru introducerea Kanbanului în companie.

Sarcina semantică și esența cărții

Carte . Calea alternativă B.Agile este compilat de un bărbat care, în general, a inventat canalul.Cartea este foarte interesantă și informativă. Este foarte interesant să dezvăluiți linia dintre filosofia Kaizen ( Îmbunătățire permanentă)Metodologie ( a se sprijini) Și canbana (metoda de conservare a resurselor umane și materiale).

Kaizen este filozofia și etica relațiilor dintre atelierul de lucru și administrație.

Producția de piele estesistemul de management al proiectelor creat în Toyota pentru a elimina toate deșeurile și resursele din procesele companiei.

Canba.- Aceasta este o metodă de gestionare a proiectului, care dau drumulrestricționați sarcini de funcționare simultan. Dacă există o limită de oameni, unelte sau timp, Canbanul ajută la distribuirea sarcinilor și proiectelor.

O mare influență când a scris această carte despre Anderson, a fost produsă teoria restricțiilor. În cartea mult despre limitele de ștergere, gâtul îmbuteliat și abilitățilesolicitați sincer sarcina maximă pe unitate de timpîn care calitatea este păstrată la nivel optim.

Teoria restricțiilor Dr. Eliasu Gudratta (Teoria constrângerilor, TOC) este o metodologie de gestionare a afacerii de fabricație. Fizicianul israelian a dezvoltat teoria și metoda practică de gestionare a organizațiilor, algoritmii de lucru din producția, logistica și vânzările de bunuri. O abordare sistematică a identificării restricțiilor în companii ajută la personalizarea tuturor. Potrivit experienței lui Gardenratta, cel mai adesea restricția este politica companiei.

WIP-Limit (Lucrul în Progress) este numărul de sarcini care pot fi deschise în același timp.

Gâtul sticlei (blocaj) - un moment într-un curent de lucru atunci când există o gravă restricționarea resurselor sau a oportunităților. Diagramele arată într-adevăr ca un gât îngust al sticlei: și înainte, iar după o astfel de situație din scheme există o extindere a liniilor.

Stereotipuri despre Kanban.

Când auzim despre Kanban, atunci ne imaginăm adesea o bord cu autocolante - acest stereotipul pe care îl impunem mass-media. Figila, pe perete există o listă de autocolante deschise, efectuate și finalizate . Puteți aplica ziduri virtuale și programe pentru gestionarea proiectelor în care vor fi făcute sarcini, priorități și alte nuanțe.

Metodologia canbanului nu va fi o placă aici și nu autocolante, ci controlul procesului și transferul de sarcini pe perete. Ceea ce regulile care și de ce mișcă autocolante Cât de mult pot fi autocolante în coloana "efectuată", de ce limitați numărul din această coloană - îi spune lui David pe paginile "Kanban. Calea alternativă în agilă. "

Kanban nu este o tablă cu autocolante, Stickers doar indicatorul de încărcare de lucru.

Anderson a dezvoltat Kanban astfel încât să nu începem un nou proiect până la trecerea celor anterioare. Prin urmare, un dezvoltator alege numărul de autocolante - 3-5, de exemplu, și exact atât de multe sarcini pe unitate de timp pot fi deschise. Numai prin completarea oricăror sarcini, el poate lua unul nou.

Vorbim despre multe despre orele și prețul lor, dar adesea nu-și dau seama că există o oră de muncă productivă și o oră de viață. Și există o săptămână de muncă productivă, pe terenul care trebuie să ia concediu medical. David vorbește despre un astfel de ritm când fiecare oră este productivă și aceasta este o stare constantă sănătoasă a echipei..

Agil, scrum și kanban

Anderson este încrezător că metodologiile flexibile agile și scrum sunt șablate și ospitaliere. În opinia sa, managementul proiectului ar trebui să fie individual în fiecare companie. Prin urmare, agile și smulse cu algoritmii de acțiuni standardizate sunt învechite, precum și o cascadă clasică de metodologie pas cu pas. Și Ban Kan. - metoda este așa adaptabil la caracteristicile companieiCe sperie adepții metodologiilor flexibile!

Agile este o metodologie flexibilă cu care a început istoric programarea în formatul actualizărilor de reînnoire la programe la fiecare două luni. Iterații de programare în câteva săptămâni pentru a adăuga fiecare funcție accelerează procesul de dezvoltare și a reduce riscurile.

Scrum este o altă metodologie flexibilă cu iterații scurte, dar control mare asupra procesului de programare. Există sprint - segmente de timp cu anumite sarcini de execuție. Ele sunt strict limitate. Există backbone - liste de sarcini deloc distribuite de proprietarul produsului. Nu se aplică echipei de dezvoltare, dar determină prioritățile sarcinilor.

David J. Anderson.

Schimbarea evolutivă de succes pentru afacerea dvs. de tehnologie

Publicat cu permisiunea lui Lean Kanban Inc.

Vă mulțumim pentru ajutor în pregătirea publicării Comunității Lean Kanban Community Rusia în Pimenova Alexey, Vyacheslav Rasselnik, Anton Manina, Serghei Baranova și Igor Filipian

Toate drepturile rezervate.

Nici o parte din această carte nu poate fi reprodusă în orice formă fără permisiunea scrisă a deținătorilor de drepturi de autor.

* * *

Dedicat lui Nikola și Natalie

Prefaţă

Întotdeauna am grijă de lucrarea lui David Anderson. L-am întâlnit în octombrie 2003, când mi-a trimis o instanță a cărții sale Agile Management pentru Inginerie Software: Aplicarea teoriei constrângerilor pentru rezultatele afacerii ("Management flexibil de gestionare a software-ului: aplicarea teoriei restricțiilor de sistem pentru rezultatele afacerii"). După cum se poate presupune din nume, teoria restricțiilor (TOC) Elia Ghadratta a fost în carte. 1
Teoria restricțiilor este o metodologie populară de gestionare a producției dezvoltată în anii 1980 de Eliyuu Gradratt, care se bazează pe căutarea și gestionarea unei limitări-cheie a sistemului, care predeterminează succesul și eficacitatea întregului sistem în ansamblu. Aproximativ. ed.

Mai târziu, în martie 2005, l-am vizitat pe David în Microsoft, în acel moment el a lucrat strâns cu diagrame de flux cumulativ. Chiar mai târziu, în aprilie 2007, am observat cum acționa sistemul de canbură descoperiri în Corbis.

Dacă prioritatea principală este de a găsi și de a elimina restricția, atunci înseamnă adesea că tocmai decideți această problemă. " Încă mai consider că această declarație este adevărată.

Aș dori să avertizez cititorii despre unele lucruri. În primul rând, dacă credeți că știți cum funcționează sistemele Kanban, atunci probabil că aveți în vedere cele utilizate în fabricarea Lean. Ideile descrise în această carte sunt mult progresive decât acele sisteme simple în care sunt utilizate limitele de ședere statică. 2
WIP - Lucrul în desfășurare, numărul sarcinilor neterminate. Aproximativ. ed.

FIFO-PLANSING și clasa unică de servicii. Vă rugăm să acordați atenție acestor diferențe.

Don ReinerTsen,

Partea I.
Bazele

Capitolul 1
Soluție Dilemma Manager Agile

În activitățile sale zilnice în 2002 și în procesul de lucru la cartea anterioară 1
Anderson, David J. Gestionarea agilă a ingineriei de software: Aplicarea teoriei constrângerilor pentru rezultatele afacerii. Râul superior Saddle, NJ: Prentice Hall, 2003.

M-am îngrijorat de două probleme. În primul rând, cum să protejați echipa de cerințele de afaceri tot mai mare și să realizați faptul că acum în comunitatea agilă este obișnuită numită "ritm optim". Ș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?

În căutarea unui ritm optim

În 2002, comunitatea agilă a perceput tempo-ul optim pur și simplu ca "săptămâna de lucru de 40 de ore" 2
Beck, Kent. Programarea extremă a explicat: îmbrățișați schimbarea. Boston: Addison Wesley, 2000. Ediția în limba rusă: Beck K. Programare extremă. St. Petersburg: Peter, 2002.

Principii ale Agile-Manifest 3
Beck, Kent și colab., "Principiile din spatele manifestului agil". http://www.agilemanifesto.org/principles.html. Traducere în limba rusă: http://gilemanifesto.org/iso/ru/principles.html.

Am citit că "procesele agile contribuie la o dezvoltare optimă. Sponsorii, dezvoltatorii și utilizatorii trebuie să fie pregătiți să mențină un ritm permanent pentru timpul infinit. " Cu doi ani înainte de aceasta, echipa mea din Sprint PCS auzită în mod constant de la mine că "dezvoltarea de software la scară largă este un maraton, nu un sprint". Dacă membrii echipei trebuiau să mențină un ritm constant în procesul de lucru la un proiect de două ori, era imposibil să le permită să ardă într-o lună sau altceva. Proiectul a fost necesar pentru planificarea, introducerea în buget, vopsea timpul și expunerea membrilor echipei zilnic a petrecut o perioadă rezonabilă de timp și nu prea obosită. Înainte de mine, ca manager, a fost sarcina de a atinge acest obiectiv și Satisface toate cerințele afacerii.

Când am lucrat la prima poziție de manager (a fost în 1991, în startupul care a făcut o cartelă de captură video pentru computerele personale și mai mici), CEO 3
Chief Executive Officer - Chief Executive Officer (CEO). Aproximativ. ed.

A raportat că conducerea a avut o "opinie extrem de negativă". Întotdeauna am răspuns "nu" atunci când capabilitățile noastre au fost deja epuizate și mai multe produse sau funcții ne-au necesitat. Până în 2002, mi-a intrat obiceiul: am petrecut încă zece ani, refuzând să realizăm capriciile proprietarilor de afaceri.

Echipele dezvoltatorului și departamentele IT ale companiilor sunt în mare măsură dependente de alte grupuri care sunt tranzacționate constant, sunt amenințate, amenințate și reparate chiar și cele mai evidente și dezvoltate în mod obiectiv. În numărul de planuri vulnerabile și de planuri bazate pe o analiză atentă și o experiență istorică de experiență. Majoritatea echipelor care nu au avut metode aprofundate de analiză și experiență istorică nu au putut face față celor care le-au împins pentru a prelua incomprehensibilitatea și adesea fără obligații fezabile.

Între timp, angajații au terminat cu încărcarea nebună, iar volumele exorbitante de lucru au devenit norma. Se pare că nimeni nu a crezut că programatorii pot avea, de asemenea, o viață publică sau de familie. Sună nepoliticos, dar este adevărat! Știu prea multe exemple atunci când sarcina de producție excesivă a distrus pentru totdeauna relațiile de familie. Este dificil să simpatizăm cu un dezvoltator tipic de geek. În starea mea nativă a Washingtonului, venitul inginerului programatorului este inferior numai câștigurilor dentistului. Ca și în zilele Ford, adică în anii 1920, când oamenii din fabricile sale au câștigat de cinci ori mai mult decât o medie a țării, nimeni nu se gândește la monotonia muncii sau la bunăstarea specialiștilor: plătesc atâta! Este greu de imaginat existența sindicatelor în astfel de industrii intelectuale ca dezvoltarea de software, deoarece nimeni nu va studia serios cauzele bolilor fizice și psihologice pe care dezvoltatorii o experimentează. Angajatorii mai responsabili oferă, de exemplu, măsuri precum masaj sau psihoterapie. Sau să petreacă zile de sănătate mintală - și este în loc să acorde atenție studiului principalelor cauze ale problemei. Scriitor tehnic, un angajat al unei companii bine-cunoscute - dezvoltatorul software-ului, odată mi-a spus: "Nu este nimic teribil pe care îl folosesc antidepresive, pentru că totul se face!" Programatorii sunt de obicei de acord cu toate cerințele, obțin un salariu bun și suferă de consecințe. Am vrut să schimbi o astfel de stare de lucruri, să găsesc o abordare reciproc avantajoasă care să-mi permită să spun "da" și, în același timp, să vă apărați echipa, oferind un tempo optim. Am vrut să returnez membrii echipei mele societății și familiei și să îmbunătățim condițiile care au provocat dezvoltatorii care nu au ajuns și treizeci de ani, stres și probleme de sănătate. Prin urmare, am decis să încep să lupt împotriva acestor probleme.

În căutarea gestionării schimbării de succes

A doua problemă, care a ocupat gândurile mele este de a gestiona schimbările în organizațiile mari. Am fost un manager de dezvoltare în PC-urile Sprint și apoi la Motorola. În ambele companii, a existat o nevoie serioasă de tranziție la metode mai flexibile de lucru. Dar, în ambele cazuri, am avut dificultăți în implementarea metodelor agile în mai multe comenzi.

Ambele momente nu aveam suficiente puteri pentru a pur și simplu să facă schimbări la activitatea unui set de comenzi. Am încercat să introduc schimbări la cererea celei mai înalte conducere, dar nu a posedat putere. Mi sa cerut să-mi influențesc colegii, astfel încât ei să introducă în echipele lor aceleași schimbări ca și mine. Dar nu se grăbeau să intre în slujba metodelor care par să se dovedească bine în echipa mea. Această rezistență a avut probabil mai multe motive. Cel mai adesea am auzit că fiecare echipă are propria situație și metodele mele vor trebui să fie personalizate pentru nevoile specifice ale altora. Până la mijlocul anului 2002, mi-am dat seama că nu a putut să prevadă cu greu niciun proces de dezvoltare pentru inutil - pur și simplu nu ar funcționa.

Procesul a fost necesar să se adapteze pentru fiecare situație specifică, astfel încât a fost necesară gestionarea activă a fiecărei echipe. Și acest lucru nu era suficient. Chiar și cu îndrumarea corespunzătoare, nu există încredere totală că pot apărea schimbări semnificative fără prezența unei structuri și sfaturi stabilite cu privire la modul de ajustare a proceselor pentru alte situații. Dacă liderul, antrenorul sau inginerul responsabil nu are nicio idee clară despre ce să facă, orice adaptare este probabil să fie subiectivă. În acest caz, probabilitatea erorilor este excelentă - de exemplu, introducerea unui șablon de proces inadecvat.

Am încercat să subliniez această problemă în cartea Agile Management pentru Inginerie Software, pe care am scris-o la acel moment. M-am întrebat: "De ce dezvoltarea flexibilă oferă cele mai bune rezultate economice decât abordările tradiționale?" Am vrut să aplic structura teoriei de restricție în acest scop. 4
Goldratt, Eliyahu M. Care este acest lucru numit teoria constrângerilor și cum ar trebui să fie implementată? Great Barrington, MA: Presa de Nord River, 1999.

În procesul de cercetare și scriere a cărții menționate, mi-am dat seama că fiecare situație este unică. Și cum poate fi o descurajare sau untnenket același lucru pentru orice echipă și proiect în orice moment? Fiecare echipă este unică: alte abilități, oportunități, experiență. Fiecare proiect este diferit de alte bugete, program, volum și riscuri. Organizații non-prietenoase: au lanțuri de valoare diferite, lucrează pe diferite piețe (figura 1.1). Mi se părea că acest lucru ar putea da o cheie pentru înțelegerea rezistenței la schimbare. Dacă schimbările propuse în metodele de lucru și modelele de comportament nu dau, potrivit angajatului, un avantaj evident, el nu le va accepta. Dacă aceste modificări nu afectează faptul că comanda este percepută ca un limitator sau factor de restrângere, comanda va rezista. Cu alte cuvinte, schimbările propuse fără context vor fi respinse de angajați care cunosc perfect contextul muncii.

Smochin. 1.1. De ce metodologiile de dezvoltare universală sunt incorecte

Se pare că va fi mai bine dacă un nou proces începe să se dezvolte, eliminând o restricție după alta. Aceasta este poziția principală a teoriei restricțiilor lui Gardenat. Înțelegerea că încă mai am multe de învățat, mi-am dat seama valoarea materialului și am grăbit să lucrez la manuscris. Mi-a fost clar că cartea nu a oferit sfaturi cum să introducă idei pe o scară mai largă și, de asemenea, greu a ajutat să găsească modalități de a gestiona schimbările.

Abordarea Gardenatt, prezentată, vizează găsirea de restricții, iar apoi modalitățile de a le elimina astfel încât să nu mai preveni performanța. După aceasta, apare o nouă limitare, iar ciclul se repetă. Aceasta este o abordare iterativă care sugerează îmbunătățirea sistematică a performanței prin identificarea și eliminarea obstacolelor.

Mi-am dat seama că puteți combina această abordare cu unele tehnici din domeniul producției înclinate. Modelarea fluxului de lucru al ciclului de viață al dezvoltării software-ului ca flux de creare a valorii și crearea unui sistem de urmărire și vizualizare pentru fixarea schimbărilor în starea lucrărilor emergente, "curge" prin sistem, aș putea defini limitatoarele. Abilitatea de a identifica restricția este primul pas către modelul care stă la baza Tos. Goldratt a dezvoltat deja aplicarea acestei teorii pentru problema fluxului de lucru, care este clumată numele "Tambur-tampon". Cu toate acestea, mi-am dat seama că versiunea simplificată a acestui sistem poate fi implementată în zona de dezvoltare software.

Din punctul de vedere al originii, "coarda tambur-tampon" este un exemplu al unei clase de soluții cunoscute sub numele de sisteme de tragere. După cum vom vedea B, Kanban este, de asemenea, un exemplu de astfel de sisteme. Efectul secundar al sistemelor de tragere este acela că limitează cantitatea de lucru incomplet la suma stabilită în avans, împiedicând supraîncărcarea angajaților. În plus, numai lucrătorii sunt complet încărcați, direct cu restricții; Oricine altcineva ar trebui să rămână timp liber. Mi-am dat seama că sistemele de tragere sunt capabile să rezolve ambele probleme ma îngrijorate. Sistemul de tragere îmi va permite să introduc schimbări pas cu pas, care (așa cum speram) reduc în mod semnificativ rezistența la acestea și, de asemenea, ar facilita realizarea unui tempo optim. Am decis să trec la sistemul de tampon cu tambur la prima ocazie. Am vrut să experimentez cu evoluția pas cu pas a procesului și să vedem cum asigură ritmul optim și reduce rezistența la schimbare.

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

Din sistemul "Tambur-coardă" la canbana

Aplicarea soluției "Tambru-tampon" în Microsoft și-a dat rezultatele. Rezistența a fost slabă, performanța a crescut de mai mult de trei ori, timpul de avans a scăzut cu 90%, iar previzibilitatea a crescut cu 98%. În toamna anului 2005, am raportat rezultatele obținute la conferința de la Barcelona 5
Anderson, David J. și Dragos Dumitriu ", de la cel mai rău la cel mai bun la 9 monschii: implementarea unei soluții de tambur-tampon în departamentul IT Microsoft," Procesele Conferinței mondiale TOCICO, Barcelona, \u200b\u200bnoiembrie 2005.

Și în iarna anului 2006, a existat un alt raport. Treaba mea a atras atenția lui Donald Reinertssen, care a venit în mod special la biroul meu în Redmond. El a vrut să mă convingă că totul este pregătit pentru o tranziție completă la Kanban.

CAN-BAN -cuvântul japonez care este tradus literal ca o "bord de semnal". În producție, acest consiliu este folosit pentru a vizualiza o rată crescândă de producție, ceea ce vă permite să oferiți mai multe produse. Angajații din fiecare etapă a procesului nu pot merge la următoarea fază de funcționare, până când semnalul corespunzător va fi dat prin intermediul tabloului Canban. Deși știam despre existența acestui mecanism, nu am fost convins că este utilă sau chiar viabilă în ceea ce privește munca intelectuală, în special dezvoltarea software-ului. Am înțeles că Canbanul oferă un ritm optim, dar nu știa despre o bună reputație ca o metodă de stimulare a unei îmbunătățiri pas cu pas a proceselor. Nu știam că Taititi, unul dintre creatorii sistemului de producție Toyota, a declarat: "Două principii de bază ale sistemului de producție Toyota sunt" exacte-în-timp "și automatizări cu participarea umană sau autonomia. Pentru a controla sistemul, instrumentul este utilizat - acesta este canalul. Cu alte cuvinte, Kanbanul este extrem de important pentru acest proces. kaizsen. ("Îmbunătățire continuă") utilizată în Toyota. Acesta este un mecanism care determină funcționarea sistemului. Acum, având cinci ani de experiență, accept-o ca un adevăr absolut.

Din fericire, Don a condus un argument convingător în favoarea tranziției de la sistemul de tambur-tampon la Kanban. Suna destul de esoteric: sistemul canban oferă o tranziție mai ușoară de la întrerupere într-un loc îngust decât "coarda tamburului". Cu toate acestea, o înțelegere a acestei caracteristici distincte nu este atât de necesară pentru a citi și înțelege această carte.

După reiterarea deciziei implementate în Microsoft, mi-am dat seama că, dacă l-am perceput imediat ca urmare a sistemului canban, rezultatul ar fi același. Mi se părea interesant că două abordări diferite conduc la același rezultat. Deci, din moment ce același proces a fost obținut, nu m-am simțit obligat să o percepe exclusiv ca urmare a introducerii sistemului de tampon tambur.

Am început să prefer această expresie complexă "Kanban". Se utilizează în fabricarea Lean (la fel ca sistemul de producție Toyota). Această totalitate a cunoștințelor a câștigat mult mai multă distribuție și recunoaștere decât teoria restricțiilor. Kanban, în ciuda originii sale japoneze, mai puțin metaforice decât tamburul, tamponul și frânghia, luată împreună. Acest cuvânt este mai ușor de pronunțat, explica și, după cum sa dovedit a fi ulterior predarea și implementarea. Aici este fixat.

Apariția metodei Kanbang

În septembrie 2006, am părăsit Microsoft și am condus departamentul de dezvoltare software din Corbis - situat în centrul orașului Seattle al unei companii de stocare de fotografii private și protejând proprietatea intelectuală. Inspirat de realizat în Microsoft, am decis să introduc sistemul excavator al Canbanului din Corbis. Și aici rezultatele au avut succes, au condus la dezvoltarea celor mai multe concepte prezentate în această carte. Acest set avansat de concepte este imagistica fluxului de lucru, tipurile de flux de operațiuni, cadență, clase de servicii, raportarea specială a manualului și analiza operațiunilor - care definesc metoda Kanban.

În această carte, descriu Kanbanul (cu o scrisoare de capital) ca o metodă de modificare evolutivă utilizând sistemul excavator al Canbanului (cu o literă mică), vizualizarea și alte instrumente pentru catalizarea introducerii ideilor de producție desalterate în evoluțiile tehnologice și operațiuni. Acesta este un proces evolutiv și pas cu pas. Kanban vă permite să realizați optimizarea procesului asociat contextului, cu o rezistență minimă la schimbare și, în același timp, mențin ritmul optim pentru toți angajații implicați.

Nume: Kanban. Calea alternativă la agilă
Autori): David Anderson.
Editura: Mann, Ivanov și Ferber, - 2017

Descriere:

Ghid detaliat pentru Canbana de la o persoană cu o experiență de 30 de ani, a aplicat pentru prima dată această metodă în dezvoltarea software-ului.

Kanban dezvăluie rapid problemele care afectează performanța și determină comanda să se concentreze asupra rezoluției lor pentru a menține un flux constant de muncă.

Efectuarea de probleme vizuale ale calității și procesului, Canbanul face posibilă evaluarea influenței defectelor, a restricțiilor, a variației și a costurilor economice asupra fluxului de lucru și a numărului de angajați.

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

Ce este Kanbanul?
De ce are nevoie de compania dvs.?
Cum să-l implementați?
Cum să recunoaștem oportunitățile de îmbunătățire a afacerilor - și ce să faceți cu ei?

Aceasta este o carte pentru managerii și managerii companiilor IT.

Citate:

Transparenţă

Dezvoltarea capacității organizației de a urmări transparent progresul și de a pregăti rapoartele de proiect folosind Kanban-System este vitală pentru a crește productivitatea. Kanban oferă transparență atât lucrării în sine, cât și fluxului de lucru.

Întâlniri

Ședințele zilnice staft - o parte integrantă a căii către cultura îmbunătățirii constante. Deoarece colectează echipa în fiecare zi în întregime, toate părțile interesate au posibilitatea de a oferi și de a discuta oportunități de îmbunătățire. După întâlnire, convorbirile informale apar adesea despre optimizarea proceselor.

Sub control

Modificări semnificative sunt posibile prin gestionarea locurilor înguste, excluderea pierderii de timp și o scădere a variabilității, care afectează negativ așteptările și satisfacția clienților.

Informativ de informare

Cardul utilizat pentru a afișa un anumit element de lucru ar trebui să conțină toate informațiile necesare pentru a facilita soluțiile de gestionare a proiectului fără interferențe sau instrucțiunile managerului.

Încredere

Kanban crește serios capitalul social în interiorul echipei. Creșterea încrederii și excluderea factorului de frică încurajează inovațiile comune și rezolvarea problemelor. Ca urmare, cultura Kaizen dezvoltă rapid - îmbunătățirea continuă.

Discuții

Multe aspecte ale Canbana contribuie la faptul că o întâlnire săptămânală privind prioritizarea devine plăcută: aceasta este experiența activităților comune, a muncii și a fluxului de lucru sunt transparente, despre progresul poate fi raportat săptămânal, toată lumea simte implicarea în bună și valoroasă.

Despre autor:

David Anderson. (David Anderson) - Fondator al instituțiilor de învățământ Lean Kanban University și David J Anderson Școala de Management, ajutând managerii și managerii să obțină rezultate mai bune cu ajutorul tehnicilor avansate. Anderson are 30 de ani de experiență în companiile tehnologice. A introdus metode flexibile de management în companii precum Motorola și Microsoft. David a fost primul care a folosit Kanban în dezvoltarea de software în 2005.

Prefaţă Partea I. Bazele
Capitolul 1. Soluție Dilemma Manager Agile
Capitolul 2.. Ce este Kanban-metoda Partea a II-a. Avantajele Canbana
Capitolul 3.. Rețeta succesului
Capitolul 4.. De la cel mai rău pentru mai bine pentru cinci trimestre
Capitolul 5.. Cultura îmbunătățirii constante Partea a III-a. Introducerea canbana
Capitolul 6.. Vizualizarea lanțului valoric
Capitolul 7.. Coordonarea în Kanban-Systems
Capitolul 8.. Formarea cadenței de livrare
Capitolul 9.. Formarea cadenței de reaprovizionare
Capitolul 10.. Setarea limitelor WIP
Capitolul 11.. Formarea acordurilor la nivel de serviciu
Capitolul 12.. Indicatori și rapoarte de gestionare
Capitolul 13.. Scalarea canalei
Capitolul 14.. Prezentare generală de operare.
Capitolul 15.. Începutul tranziției spre Kanban Partea IV. Perfecţiune
Capitolul 16.. Trei tipuri de oportunități de îmbunătățire
Capitolul 17.. Neck-uri îmbuteliate și accesibilitate limitată
Capitolul 18.. Modelul economic al producției înclinate
Capitolul 19.. Surse de variabilitate
Capitolul 20.. Gestionarea problemelor și regulilor de escaladare

David Anderson - Kanban. Calea alternativă la agilă

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

Despre autor

Pe exemple reale de la Microsoft, Motorola și Corbis, a spus și a arătat și a arătat principiile, metodele și instrucțiunile pentru introducerea Kanbanului în companie.

Sarcina semantică și esența cărții

Kaizen este filozofia și etica relațiilor dintre atelierul de lucru și administrație.

Producția de piele estesistemul de management al proiectelor creat în Toyota pentru a elimina toate deșeurile și resursele din procesele companiei.

WIP-Limit (Lucrul în Progress) este numărul de sarcini care pot fi deschise în același timp.

Gâtul sticlei (blocaj) - un moment într-un curent de lucru atunci când există o gravă restricționarea resurselor sau a oportunităților. Diagramele arată într-adevăr ca un gât îngust al sticlei: și înainte, iar după o astfel de situație din scheme există o extindere a liniilor.

Stereotipuri despre Kanban.

Kanban nu este o tablă cu autocolante, Stickers doar indicatorul de încărcare de lucru.

Agil, scrum și kanban

Agile este o metodologie flexibilă cu care a început istoric programarea în formatul actualizărilor de reînnoire la programe la fiecare două luni. Iterații de programare în câteva săptămâni pentru a adăuga fiecare funcție accelerează procesul de dezvoltare și a reduce riscurile.

* * *

Prefaţă

Partea I. Bazele

Capitolul 1 Soluție Dilemma Manager Agile

În căutarea unui ritm optim

În căutarea gestionării schimbării de succes

Din sistemul "Tambur-coardă" la canbana

Apariția metodei Kanbang

Descriere:

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

Citate:

Transparenţă

Întâlniri

Sub control

Informativ de informare

Încredere

Discuții

Despre autor:

Partea I.
Bazele

Capitolul 1
Soluție Dilemma Manager Agile