David Anderson - Kanban. Kanban

David J Anderson

Úspešná evolučná zmena pre vaše technologické podnikanie


Publikované so súhlasom spoločnosti Lean Kanban Inc.


Ďakujeme Lean Kanban Community Russia zastúpenej Alexejom Pimenovom, Vjačeslavom Tsyrulnikom, Antonom Maninom, Sergejom Baranovom a Igorom Filipjevom za pomoc pri príprave publikácie.


Všetky práva vyhradené.

Žiadna časť tejto knihy nesmie byť reprodukovaná v žiadnej forme bez písomného súhlasu držiteľov autorských práv.


Copyright © 2010 David J. Anderson

© Preklad do ruštiny, vydanie v ruštine, dizajn. LLC "Mann, Ivanov a Ferber", 2017

* * *

Venované Nikole a Natálii

Predslov

Vždy venujem pozornosť práci Davida Andersona. Stretol som sa s ním v októbri 2003, keď mi poslal kópiu svojej knihy Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. Ako už názov napovedá, kniha bola výrazne ovplyvnená Teóriou obmedzení (TOC) Eliyahua Goldratta. 1
Teória obmedzení je populárna metodika riadenia výroby vyvinutá v 80. rokoch Eliyahu Goldrattom, ktorá je založená na hľadaní a riadení kľúčového systémového obmedzenia, ktoré určuje úspešnosť a efektivitu celého systému ako celku. Poznámka. vyd.

Neskôr, v marci 2005, som navštívil Davida v Microsofte, v tom čase už úzko spolupracoval s kumulatívnymi vývojovými diagramami. Ešte neskôr, v apríli 2007, som mal možnosť sledovať, ako funguje prelomový systém kanban, ktorý zaviedol v Corbise.

Celú túto chronológiu uvádzam preto, aby ste mali pocit, akým nezastaviteľným tempom napreduje Davidovo manažérske myslenie. Nedrží sa jedinej myšlienky, snaží sa do nej vtesnať celý svet. Naopak, snaží sa problém vnímať ako celok, je otvorený rôznym riešeniam, skúša ich v praxi a hodnotí princípy práce. Výsledky tohto prístupu uvidíte v tejto knihe.

Samozrejme, rýchlosť je dobrá, pokiaľ ide správnym smerom, a som si istý, že David ide správnym smerom. Obdivujem najmä najnovšiu prácu s kanban systémami. Vždy som veril, že princípy lean sa dajú priamo aplikovať na vývoj produktov, na rozdiel od myšlienok TOC. Navyše, ešte v októbri 2003 som Davidovi napísal toto: „Jednou z hlavných slabín CBT je podceňovanie dôležitosti veľkosti strany.

Ak je vašou najvyššou prioritou nájsť a opraviť obmedzenie, potom to často znamená, že práve riešite nesprávny problém.“ Stále verím, že toto tvrdenie je pravdivé.

Na našom stretnutí v roku 2005 som Davidovi opäť navrhol, aby sa nezameral len na úzke miesta v TOC. Vysvetlil som mu, že hype výrobného systému Toyota (TPS) nemá nič spoločné s hľadaním a odstraňovaním úzkych miest. Toyota dosahuje zvýšenie produktivity znížením veľkosti a variability sérií, čo znižuje množstvo požadovaných zásob. Práve znižovanie takýchto zásob viedlo k dosiahnutiu ekonomických výhod a umožnili to také systémy znižovania rozpracovanosti ako kanban.

V roku 2007 som navštívil Corbis. Výsledok zavedenia systému kanban vyzeral pôsobivo. Upozornil som Davida, že výrazne zlepšil prístup kanban používaný v Toyote. Prečo som si to myslel? Výrobný systém Toyota je optimalizovaný tak, aby zvládol opakujúce sa a predvídateľné úlohy s jednotným trvaním a jednotnými nákladmi na oneskorenie. Za týchto podmienok je celkom správne použiť prístupy, ako je FIFO-prioritizácia („prvý dovnútra, prvý von“). Je tiež celkom správne zablokovať príjem práce, ak sa dosiahne limit nedokončených úloh. Ak však máme do činenia s neopakovateľnými, nepredvídateľnými činnosťami s rôznym trvaním a rôznymi nákladmi na oneskorenie, tieto prístupy nemožno považovať za optimálne – a to je presne prípad vývoja softvéru. Potrebujeme pokročilejšie systémy a toto je prvá kniha, ktorá ich prakticky podrobne popisuje.

Chcel by som čitateľov upozorniť na pár vecí. Po prvé, ak si myslíte, že viete, ako fungujú kanban systémy, potom máte pravdepodobne na mysli tie, ktoré sa používajú v štíhlej výrobe. Myšlienky v tejto knihe sú oveľa pokročilejšie ako jednoduché systémy, ktoré používajú statické limity WIP. 2
WIP - rozpracovaná práca, počet rozpracovaných úloh. Poznámka. vyd.

FIFO plánovanie a jedna trieda služby. Venujte prosím pozornosť týmto rozdielom.

Po druhé, nemyslite si, že tento prístup je systém vizuálnej kontroly. Vizualizácia rozpracovanosti, ktorá sa dosahuje pomocou kanban tabúľ, je veľmi užitočná, ale je to len malý aspekt tohto prístupu. Ak si pozorne prečítate túto knihu, nájdete v nej veľa zaujímavostí. Najcennejšie informácie sú skryté napríklad v takých aspektoch, ako je štruktúra procesov prijímania a odosielania úloh, riadenie nenahraditeľných zdrojov a využívanie tried služieb. Nenechajte sa rozptyľovať vizuálnou časťou, inak prídete o tie najvzrušujúcejšie momenty.

Po tretie, neznevažujte tieto metódy len preto, že sa zdajú príliš jednoduché na použitie. Jednoduché použitie je výsledkom Davidových nápadov, ako získať maximálny úžitok s minimálnymi výsledkami. Dobre pozná potreby praktizujúcich a venoval veľkú pozornosť tomu, čo skutočne funguje. Jednoduché metódy vykazujú vysokú stabilitu a takmer vždy vedú k najlepším dlhodobým výsledkom.

Je to fascinujúca a potrebná kniha a zaslúži si starostlivé štúdium. Úroveň úžitku, ktorý z toho získate, závisí od toho, ako vážne čítanie beriete. Žiadna iná kniha vám tieto pokročilé myšlienky neuvedie lepšie. Dúfam, že si to užijete rovnako ako ja.

Don Reinertsen,

I. časť
Základy

Kapitola 1
Riešenie dilemy agilného manažéra

V roku 2002 som bol manažérom vývoja vo vzdialenej kancelárii Motoroly v Seattli divízie mobilných telefónov Motoroly (nazývalo sa to PCS) a ocitol som sa v ťažkej situácii. Moje oddelenie bolo súčasťou startupu, ktorý Motorola získala rok predtým. Vyvinuli sme sieťový softvér na bezdrôtový prenos dát, ako je bezdrôtové sťahovanie a ovládanie prístrojov. Tieto back-end aplikácie boli súčasťou integrovaných systémov, ktoré boli úzko prepojené s klientskym kódom mobilného telefónu, ako aj s ďalšími prvkami v telekomunikačných sieťach a prevádzkovej infraštruktúre, ako je fakturácia. Termíny stanovovali manažéri, ktorí nevenovali pozornosť inžinierskej zložitosti projektu, jeho rizikám, ani jeho rozsahu. Základný kód sa vyvinul zo spustenia, pričom mnohé pôvodne plánované funkcie boli odložené na neskôr. Jeden starší vývojár trval na tom, aby sa naše produkty nazývali „prototypy“. Zúfalo sme potrebovali zvýšiť produktivitu a kvalitu produktov, aby sme držali krok s požiadavkami podniku.

V mojej každodennej činnosti v roku 2002 a v procese práce na predchádzajúcej knihe 1
Anderson, David J. Agilný manažment pre softvérové ​​inžinierstvo: Aplikácia teórie obmedzení pre obchodné výsledky. Upper Saddle River, NJ: Prentice Hall, 2003.

Zaujímali ma hlavne dve veci. Po prvé, ako ochrániť tím pred neustále sa zvyšujúcimi požiadavkami podnikania a dosiahnuť to, čo sa dnes v agilnej komunite nazýva „optimálne tempo“. A po druhé, ako môžem úspešne implementovať agilný prístup v celej organizácii a prekonať nevyhnutný odpor voči zmenám?

Nájdenie správneho tempa

V roku 2002 si agilná komunita myslela, že optimálne tempo je jednoducho „40-hodinový pracovný týždeň“. 2
Beck, Kent. Extrémne programovanie vysvetlené: Prijmite zmenu. Boston: Addison Wesley, 2000. Ruské vydanie: Beck K. Extreme Programming. Petrohrad: Peter, 2002.

Princípy agilného manifestu 3
Beck, Kent a kol., „Princípy za agilným manifestom“. http://www.agilemanifesto.org/principles.html. Ruský preklad: http://agilemanifesto.org/iso/ru/principles.html .

Povedali, že „agilné procesy prispievajú k optimálnemu rozvoju. Sponzori, vývojári a používatelia musia byť pripravení udržiavať konštantné tempo donekonečna.“ Dva roky predtým odo mňa môj tím v Sprint PCS neustále počúval, že „vývoj softvéru vo veľkom je maratón, nie šprint“. Ak by členovia tímu museli udržiavať konštantné tempo v procese práce na rok a pol projekte, potom nemohli dopustiť, aby za mesiac alebo dva vyhoreli. Projekt bolo potrebné naplánovať, naplánovať, načasovať a vyhodnotiť, aby sa zabezpečilo, že členovia tímu trávili každý deň prácou primerané množstvo času a neboli príliš unavení. Mojou úlohou ako manažéra bolo dosiahnuť tento cieľ a spĺňať všetky obchodné požiadavky.

Keď som bol na svojej prvej manažérskej pozícii (bolo to v roku 1991, v startupe, ktorý vyrábal dosky na snímanie videa pre osobné a menšie počítače), generálny riaditeľ 3
Generálny riaditeľ – generálny riaditeľ (CEO). Poznámka. vyd.

Povedal, že vedenie má o mne „extrémne negatívny názor“. Vždy som odpovedal „nie“, keď už boli naše možnosti ako vývojárov vyčerpané a vyžadovalo sa od nás stále viac produktov alebo funkcií. V roku 2002 som sa stal zvykom: ďalších desať rokov som odmietal vyhovieť rozmarom majiteľov firiem.

Vývojové tímy a IT oddelenia firiem sú silne závislé od iných skupín, ktoré neustále zjednávajú, prosia, vyhrážajú sa a prerábajú aj tie najočividnejšie a objektívne navrhnuté plány. Medzi zraniteľné patria aj plány založené na dôkladnej analýze a historických skúsenostiach. Väčšina tímov, ktorým chýbala dôkladná analýza a historické skúsenosti, si nevedela poradiť s tými, ktorí ich nútili prijať nejasné a často nemožné záväzky.

Zamestnanci sa medzičasom zmierili so šialeným pracovným zaťažením a prehnané pracovné zaťaženie sa stalo štandardom. Nikto zrejme nepomyslel na to, že softvéroví inžinieri môžu mať aj spoločenský či rodinný život. Znie to drsne, ale je to tak! Poznám príliš veľa príkladov, kedy nadmerné pracovné zaťaženie navždy zničilo rodinné vzťahy. Je ťažké sympatizovať s typickým vývojárskym geekom. V mojom domovskom štáte Washington je príjem softvérového inžiniera na druhom mieste za príjmom zubára. Rovnako ako za čias Forda, teda v 20. rokoch 20. storočia, keď ľudia v jeho továrňach zarábali päťkrát viac, ako je celoštátny priemer, nikoho ani nenapadne premýšľať o monotónnosti práce alebo o blahobyte špecialistov: sú to zaplatil toľko! Je ťažké si predstaviť odbory v odboroch založených na vedomostiach, ako je vývoj softvéru, pretože nikto nebude seriózne skúmať príčiny fyzických a psychických problémov, s ktorými sa vývojári stretávajú. Zodpovednejší zamestnávatelia ponúkajú napríklad opatrenia ako masáže či psychoterapia. Alebo trávia dni duševného zdravia – a to namiesto toho, aby venovali pozornosť štúdiu základných príčin problému. Technický spisovateľ v známej softvérovej firme mi raz povedal: "Je v poriadku, ak beriem antidepresíva, pretože to tak robí každý!" Programátori zvyčajne splnia všetky požiadavky, dostanú dobre zaplatené a znášajú následky. Chcel som zmeniť tento stav vecí, nájsť obojstranne výhodný prístup, ktorý by mi umožnil povedať áno a stále chrániť svoj tím a zabezpečiť dosiahnutie optimálneho tempa. Chcel som priviesť členov môjho tímu späť do komunity a rodiny a zlepšiť podmienky, ktoré vyvolávali stres a zdravotné problémy vývojárom pod tridsať rokov. Tak som sa rozhodol začať riešiť tieto problémy.

Pri hľadaní úspešného riadenia zmien

Druhým problémom, ktorý som mal na mysli, je riadenie zmien vo veľkých organizáciách. Bol som vývojovým manažérom v Sprint PCS a potom v Motorole. V oboch spoločnostiach bola silná potreba prejsť na flexibilnejšie pracovné metódy. Ale v oboch prípadoch som mal problém implementovať agilné metódy na viac ako jeden alebo dva tímy.

V oboch prípadoch som nemal dostatok právomocí na to, aby som jednoducho nariadil vykonanie zmien vo viacerých tímoch. Pokúšal som sa zaviesť zmeny na žiadosť vrcholového manažmentu, ale nemal som potrebné právomoci. Požiadali ma, aby som ovplyvnil kolegov, aby vo svojich tímoch zaviedli rovnaké zmeny ako ja vo svojom. Ale neponáhľali sa osvojiť si metódy, ktoré sa zdalo, že v mojom tíme fungujú najlepšie. Tento odpor mal zrejme viacero dôvodov. Častejšie som počul, že každý tím má svoju vlastnú situáciu a moje metódy bude potrebné prispôsobiť špecifickým potrebám ostatných. V polovici roku 2002 som si uvedomil, že je zbytočné striktne predpisovať akýkoľvek proces vývoja softvéru – jednoducho to nebude fungovať.

Proces bolo potrebné prispôsobiť každej konkrétnej situácii, preto bolo potrebné aktívne vedenie každého tímu. A to často nestačilo. Ani pri správnom vedení nie je istota, že k významným zmenám môže dôjsť bez zavedenej štruktúry a rád, ako prispôsobiť procesy rôznym situáciám. Ak manažér, tréner alebo zodpovedný inžinier nemá jasnú predstavu o tom, čo má robiť, potom je akékoľvek prispôsobenie pravdepodobne subjektívne. Zároveň je tu vysoká pravdepodobnosť chýb – napríklad zavedenie nevhodnej šablóny procesu.

Tento problém som sa snažil pokryť v knihe Agile Management for Software Engineering, ktorú som vtedy písal. Zaujímalo ma: "Prečo agilný vývoj prináša lepšie ekonomické výsledky ako tradičné prístupy?" Na tento účel som chcel použiť štruktúru teórie obmedzení. 4
Goldratt, Eliyahu M. Ako sa táto vec nazýva Teória obmedzení a ako by sa mala implementovať? Great Barrington, MA: North River Press, 1999.

V procese skúmania a písania tejto knihy som si uvedomil, že každá situácia je jedinečná. A ako môže byť obmedzenie alebo prekážka kedykoľvek rovnaké pre akýkoľvek tím a projekt? Každý tím je jedinečný: rôzne schopnosti, príležitosti, skúsenosti. Každý projekt sa od ostatných líši rozpočtom, harmonogramom, rozsahom a rizikami. Organizácie sú tiež odlišné: majú rôzne hodnotové reťazce a pôsobia na rôznych trhoch (obrázok 1.1). Zdalo sa mi, že by to mohlo poskytnúť vodítko k pochopeniu odporu voči zmene. Ak navrhované zmeny v pracovných metódach a správaní neposkytujú podľa názoru zamestnanca zjavnú výhodu, potom ich neprijme. Ak tieto zmeny neovplyvnia to, čo tím vníma ako obmedzovač alebo odstrašujúci prostriedok, potom tím bude odolávať. Inými slovami, zmeny navrhované bez ohľadu na kontext budú odmietnuté zamestnancami, ktorí dokonale poznajú kontext práce.


Ryža. 1.1. Prečo sú generické metodiky vývoja nesprávne


Zdalo by sa, že by bolo lepšie, keby sa nový proces začal rozvíjať a odstraňovať jedno obmedzenie za druhým. Toto je hlavný bod Goldrattovej teórie obmedzení. Uvedomil som si, že sa mám ešte veľa čo učiť, uvedomil som si hodnotu materiálu a ponáhľal som sa v práci na rukopise. Bolo mi jasné, že kniha neradí, ako realizovať nápady vo väčšom meradle, ani veľmi nepomohla pri hľadaní spôsobov, ako zvládnuť zmeny.

Goldrattov prístup, načrtnutý v , má za cieľ nájsť obmedzenia a potom spôsoby, ako ich odstrániť, aby už nebrzdili výkon. Potom vznikne nové obmedzenie a cyklus sa opakuje. Ide o iteratívny prístup, ktorý systematicky zlepšuje výkon identifikáciou a odstraňovaním prekážok.

Uvedomil som si, že tento prístup môžete kombinovať s niektorými technikami z oblasti štíhlej výroby. Modelovaním pracovného toku životného cyklu vývoja softvéru ako hodnotového toku a vytvorením systému sledovania a vizualizácie na zachytenie zmien stavu vznikajúcej práce, ktorá „preteká“ systémom, sa mi podarilo identifikovať obmedzenia. Schopnosť identifikovať obmedzenie je prvým krokom k základnému modelu TOC. Goldratt už vyvinul aplikáciu tejto teórie na problémy pracovného toku, ktorá nesie neohrabaný názov „bubon-buffer-lano“. Uvedomil som si však, že zjednodušená verzia tohto systému sa dá implementovať aj v oblasti vývoja softvéru.

Pokiaľ ide o pôvod, bubon-nárazník-lano je príkladom triedy riešení známych ako ťahové systémy. Ako uvidíme v , kanban je tiež jedným z príkladov tohto druhu systému. Vedľajším efektom ťahových systémov je, že obmedzujú WIP na vopred stanovené množstvo, čím bránia preťaženiu zamestnancov. Okrem toho len pracovníci, ktorí priamo čelia obmedzeniu, zostávajú plne zaťažení; všetci ostatní by mali mať voľný čas. Uvedomil som si, že ťahové systémy môžu vyriešiť oba problémy, ktoré ma znepokojovali. Systém ťahania mi umožní zaviesť postupné zmeny, ktoré (dúfal som) výrazne znížia odpor voči nim, ako aj uľahčia dosiahnutie optimálneho tempa. Rozhodol som sa čo najskôr prejsť na systém bubon-nárazník-lano. Chcel som experimentovať s postupným vývojom procesu a zistiť, či poskytuje optimálne tempo a znižuje odolnosť voči zmenám.

Takáto príležitosť sa objavila na jeseň roku 2004 v spoločnosti Microsoft, ktorá je podrobne popísaná v tejto knihe v analýze príkladu.

Od bubna-nárazníka-lana po kanban

Riešenie drum-buffer-lano v Microsofte sa vyplatilo. Odolnosť bola slabá, výkon sa viac ako strojnásobil, dodacia lehota sa skrátila o 90 % a predvídateľnosť sa zlepšila o 98 %. Na jeseň 2005 som informoval o dosiahnutých výsledkoch na konferencii v Barcelone 5
Anderson, David J. a Dragos Dumitriu, „Od najhoršieho k najlepšiemu za 9 mesiacov: Implementácia riešenia Drum-Buffer-Rope v oddelení IT spoločnosti Microsoft“, Zborník zo svetovej konferencie TOCICO, Barcelona, ​​​​november 2005.

A v zime 2006 urobil ďalšiu správu. Moja práca upútala pozornosť Donalda Reinertsena, ktorý špeciálne navštívil moju kanceláriu v Redmonde. Chcel ma uistiť, že všetko je pripravené na úplný prechod na kanban.

Kan-ban - japonské slovo, ktoré sa doslovne prekladá ako „signálna tabuľa“. Vo výrobe sa takáto doska používa na vizualizáciu zvyšujúceho sa tempa výroby, čo umožňuje vyrábať viac produktov. Zamestnanci v každej fáze procesu nemôžu prejsť do ďalšej fázy práce, kým cez tabuľu kanban nedostane príslušný signál. Hoci som o existencii tohto mechanizmu vedel, nebol som presvedčený, že je užitočný alebo dokonca životaschopný vo vzťahu k intelektuálnej práci, najmä vývoju softvéru. Pochopil som, že kanban poskytuje optimálne tempo, ale nevedel som o jeho dobrej povesti ako metódy stimulácie postupného zlepšovania procesov. Nevedel som, že Taiichi Ohno, jeden z tvorcov výrobného systému Toyota, povedal: „Dva hlavné princípy výrobného systému Toyota sú just-in-time a automatizácia za pomoci človeka alebo autonómia. Na správu systému sa používa nástroj – ide o kanban. Inými slovami, Kanban je pre tento proces životne dôležitý. kaizen(„neustále zlepšovanie“), ktoré používa Toyota. Je to mechanizmus, vďaka ktorému systém funguje. Teraz, keď mám za sebou päť rokov skúseností, to akceptujem ako absolútnu pravdu.

Našťastie Don vytvoril presvedčivý prípad na prechod z bubna-nárazníka-lana na kanban. Znelo to dosť ezotericky: systém kanban poskytuje plynulejší prechod z prestojov do úzkych miest ako bubon-nárazník-lano. Pochopenie tohto rozdielu však nie je nevyhnutné na čítanie a pochopenie tejto knihy.

Pri opätovnom preskúmaní riešenia implementovaného spoločnosťou Microsoft som si uvedomil, že ak by sme ho okamžite vnímali ako výsledok systému kanban, výsledok by bol rovnaký. Zistil som, že je zaujímavé, že dva rôzne prístupy vedú k rovnakému výsledku. Takže, keďže to bol ten istý proces, necítil som povinnosť vidieť to len ako produkt systému bubon-nárazník-lano.

Začal som uprednostňovať výraz „kanban“ pred týmto zložitým slovným spojením. Používa sa v štíhlej výrobe (rovnako ako Toyota Production System). Tento súbor vedomostí získal oveľa väčšiu distribúciu a uznanie ako teória obmedzení. Kanban, napriek svojmu japonskému pôvodu, je menej metaforický ako bubon, nárazník a lano dohromady. Toto slovo sa ľahšie vyslovuje, vysvetľuje a, ako sa neskôr ukázalo, aj učí a realizuje. Tu sa to zaseklo.

Vznik metódy kanban

V septembri 2006 som odišiel z Microsoftu, aby som viedol vývoj softvéru v Corbis, súkromnej spoločnosti na ukladanie fotografií a duševného vlastníctva so sídlom v centre Seattlu. Inšpirovaný tým, čo Microsoft dosiahol, som sa rozhodol implementovať kanban pull systém v Corbise. Aj tu boli výsledky veľmi úspešné, čo viedlo k rozvoju väčšiny konceptov prezentovaných v tejto knihe. Je to rozšírený súbor týchto konceptov – vizualizácia pracovného toku, typy položiek pracovného toku, kadencia, triedy služieb, špeciálne manažérske výkazy a analýza aktivít – ktoré definujú metódu Kanban.

V tejto knihe popisujem Kanban (veľké písmená) ako metódu evolučnej zmeny pomocou systému ťahania kanban (malých písmen), vizualizácie a iných nástrojov na katalyzovanie zavádzania štíhlych myšlienok do vývoja technológií a IT operácií. Je to evolučný a krok za krokom proces. Kanban vám umožňuje dosiahnuť kontextovo špecifickú optimalizáciu procesov s minimálnym odporom voči zmenám pri zachovaní optimálneho tempa pre všetkých zúčastnených ľudí.

Kniha Kanban od Davida Andersona preberá od prvej strany.

S obrázkami, grafmi a závermi Davidov skrátený životopis odhaľuje metodológiu Kanban pre dôvtipného nadšenca projektového manažmentu. Projektový manažment je zaujímavý, keď ho v prvej osobe povie priamy vývojár metódy.

o autorovi

Uvedené na oficiálnom blogu Davida J Andersona ako p Predseda spoločnosti Lean Kanban Inc. Tiež on t manažér manažmentu a konzultant od roku 2000, rečník a hostiteľ konferencie od roku 2005. Prvýkrát vo vedúcej pozícii bol v roku 1991, takže jeho skúsenosti vám umožňujú poctivo porovnávať kanban a vodopádové, agilné, scrumové a iné metodiky projektového manažmentu.

Vytvoril kanban, aby zvýšil úroveň intelektuálnej a tvorivej práce. Davidovým cieľom bolo dodávať včas, plniť ciele a vo všeobecnosti primerane riadiť dnešné spoločnosti.

Na reálnych príkladoch zo života spoločností Microsoft, Motorola a Corbis porozprával a ukázal princípy, metódy a návody na implementáciu kanbanu vo firme.

Sémantická záťaž a podstata knihy

Kniha . Alternatívna cesta doAgile píše človek, ktorý kanban vymyslel ako prvý. Kniha je veľmi zaujímavá a poučná. Tu je veľmi zaujímavo odhalená hranica medzi filozofiou Kaizenu ( neustále zlepšovanie), metodológia ( Lean) a Kanban (metóda šetrenia ľudských a materiálnych zdrojov).

Kaizen je filozofia a etika vzťahu medzi pracovníkmi továrne a manažmentom.
Štíhla výroba je systém projektového manažmentu vytvorený v Toyote na odstránenie všetkého plytvania časom a zdrojmi z procesov spoločnosti.

Kanbanje metóda projektového riadenia, ktorá poskytuje spôsob obmedziť súčasne spustené úlohy. Ak existuje limit na ľudí, nástroje alebo čas, kanban pomáha distribuovať úlohy a projekty.


Anderson bol pri písaní tejto knihy veľmi ovplyvnený teóriou obmedzení. Kniha je plná limitov WIP, úzkych miest a možnostípoctivo určiť maximálne zaťaženie za jednotku času, ktorý udržuje kvalitu na optimálnej úrovni.

Teória obmedzení (TOC) Dr. Eliyahu Goldratta je metodika riadenia výrobného podniku. Izraelský fyzik vyvinul teóriu a praktickú metódu na riadenie organizácií, algoritmy na prevádzku výroby, logistiky a marketingu tovaru. Systematický prístup k identifikácii obmedzení vo firmách pomáha všetko nastaviť. Podľa Goldrattových skúseností Politika spoločnosti sa častejšie stáva obmedzením.

Limit WIP (nedokončená práca) — počet úloh, ktoré môžu byť súčasne otvorené.
Prekážka - moment v pracovnom postupe, keď je vážny obmedzenie zdrojov alebo príležitostí. Na nákresoch to naozaj vyzerá ako úzke hrdlo fľaše: pred aj po takejto situácii sa čiary na nákresoch rozširujú.

Stereotypy o kanbane

Keď počujeme o kanbane, často si predstavíme tabuľu s nálepkami – tento stereotyp nám vnucujú médiá. Obrazne je na stene zoznam otvorených, spustených a dokončených úloh s nálepkami. . Na správu projektov môžete použiť virtuálne steny a programy, kde sa budú zadávať zoznamy úloh, priorít a iných nuancií.

Metodika kanbanu tu nebude tabuľou a nie nálepkami, ale proces sledovania a prenosu úloh na stenu. Podľa akých pravidiel, kto a prečo presúva nálepky, koľko nálepiek je možné ponechať v stĺpci „vykonané“, prečo obmedziť počet v tomto stĺpci - to hovorí David na stránkach " Kanban. Alternatívna cesta k agilnosti.

Kanban nie je lepkavá doska, nálepky sú len indikátorom pracovnej vyťaženosti.

Anderson navrhol kanban tak, aby sme nezačali nový projekt, kým nebudú dokončené predchádzajúce. Preto je počet nálepiek zvolený na vývojára - napríklad 3-5 a presne toľko úloh za jednotku času sa mu môže otvoriť. Až po splnení niektorej z úloh môže prevziať novú.

Veľa hovoríme o človekohodinách a ich cene, no často si neuvedomujeme, že existuje hodina produktívnej práce a hodina života. A je tu týždeň produktívnej práce, v ktorej oblasti musíte ísť na nemocenskú dovolenku. David hovorí o tomto tempe práce, keď každá hodina je produktívna a to je neustály zdravý stav tímu.

Agile, Scrum a Kanban

Anderson si je istý, že agilné a Scrum metodológie sú formulované a nepružné. Projektové riadenie by podľa neho malo byť v každej firme individuálne. Preto sú Agile a Scrum s ich štandardizovanými akčnými algoritmami zastarané, podobne ako klasická postupná metodológia Waterfall. Kán zákaz - metóda je taká špecifické pre spoločnosť, čo straší prívržencov flexibilných metodík!

Agile je agilná metodológia, s ktorou sa programovanie historicky začalo vo formáte zavádzania aktualizácií programov každých pár mesiacov. Programovanie niekoľko týždňových iterácií na pridanie každej funkcie urýchli proces vývoja a zníži riziko.

Scrum je ďalšia agilná metodika s krátkymi iteráciami, ale väčšou kontrolou nad procesom programovania. Existujú sprinty - časové úseky s určitými úlohami, ktoré je potrebné dokončiť. Sú prísne obmedzené. Existujú backlogy - zoznamy úloh vo všeobecnosti, ktoré distribuuje produktový vlastník. Nepatrí do vývojového tímu, ale uprednostňuje úlohy.

David Anderson

Kanban. Alternatívna cesta k agilnosti

David J Anderson

Úspešná evolučná zmena pre vaše technologické podnikanie

Publikované so súhlasom spoločnosti Lean Kanban Inc.

Ďakujeme Lean Kanban Community Russia zastúpenej Alexejom Pimenovom, Vjačeslavom Tsyrulnikom, Antonom Maninom, Sergejom Baranovom a Igorom Filipjevom za pomoc pri príprave publikácie.

Všetky práva vyhradené.

Žiadna časť tejto knihy nesmie byť reprodukovaná v žiadnej forme bez písomného súhlasu držiteľov autorských práv.

Copyright © 2010 David J. Anderson

© Preklad do ruštiny, vydanie v ruštine, dizajn. LLC "Mann, Ivanov a Ferber", 2017

* * *

Venované Nikole a Natálii

Predslov

Vždy venujem pozornosť práci Davida Andersona. Stretol som sa s ním v októbri 2003, keď mi poslal kópiu svojej knihy Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. Ako už názov napovedá, kniha bola výrazne ovplyvnená Teóriou obmedzení (TOC) Eliyahua Goldratta. Neskôr, v marci 2005, som navštívil Davida v Microsofte, v tom čase už úzko spolupracoval s kumulatívnymi vývojovými diagramami. Ešte neskôr, v apríli 2007, som mal možnosť sledovať, ako funguje prelomový systém kanban, ktorý zaviedol v Corbise.

Celú túto chronológiu uvádzam preto, aby ste mali pocit, akým nezastaviteľným tempom napreduje Davidovo manažérske myslenie. Nedrží sa jedinej myšlienky, snaží sa do nej vtesnať celý svet. Naopak, snaží sa problém vnímať ako celok, je otvorený rôznym riešeniam, skúša ich v praxi a hodnotí princípy práce. Výsledky tohto prístupu uvidíte v tejto knihe.

Samozrejme, rýchlosť je dobrá, pokiaľ ide správnym smerom, a som si istý, že David ide správnym smerom. Obdivujem najmä najnovšiu prácu s kanban systémami. Vždy som veril, že princípy lean sa dajú priamo aplikovať na vývoj produktov, na rozdiel od myšlienok TOC. Navyše, ešte v októbri 2003 som Davidovi napísal toto: „Jednou z hlavných slabín CBT je podceňovanie dôležitosti veľkosti strany. Ak je vašou najvyššou prioritou nájsť a opraviť obmedzenie, potom to často znamená, že práve riešite nesprávny problém.“ Stále verím, že toto tvrdenie je pravdivé.

Na našom stretnutí v roku 2005 som Davidovi opäť navrhol, aby sa nezameral len na úzke miesta v TOC. Vysvetlil som mu, že hype výrobného systému Toyota (TPS) nemá nič spoločné s hľadaním a odstraňovaním úzkych miest. Toyota dosahuje zvýšenie produktivity znížením veľkosti a variability sérií, čo znižuje množstvo požadovaných zásob. Práve znižovanie takýchto zásob viedlo k dosiahnutiu ekonomických výhod a umožnili to také systémy znižovania rozpracovanosti ako kanban.

V roku 2007 som navštívil Corbis. Výsledok zavedenia systému kanban vyzeral pôsobivo. Upozornil som Davida, že výrazne zlepšil prístup kanban používaný v Toyote. Prečo som si to myslel? Výrobný systém Toyota je optimalizovaný tak, aby zvládol opakujúce sa a predvídateľné úlohy s jednotným trvaním a jednotnými nákladmi na oneskorenie. Za týchto podmienok je celkom správne použiť prístupy, ako je FIFO-prioritizácia („prvý dovnútra, prvý von“). Je tiež celkom správne zablokovať príjem práce, ak sa dosiahne limit nedokončených úloh. Ak však máme do činenia s neopakovateľnými, nepredvídateľnými činnosťami s rôznym trvaním a rôznymi nákladmi na oneskorenie, tieto prístupy nemožno považovať za optimálne – a to je presne prípad vývoja softvéru. Potrebujeme pokročilejšie systémy a toto je prvá kniha, ktorá ich prakticky podrobne popisuje.

Chcel by som čitateľov upozorniť na pár vecí. Po prvé, ak si myslíte, že viete, ako fungujú kanban systémy, potom máte pravdepodobne na mysli tie, ktoré sa používajú v štíhlej výrobe. Myšlienky v tejto knihe sú oveľa pokročilejšie ako jednoduché systémy, ktoré používajú statické limity WIP, plánovanie FIFO a jednu triedu služieb. Venujte prosím pozornosť týmto rozdielom.

Po druhé, nemyslite si, že tento prístup je systém vizuálnej kontroly. Vizualizácia rozpracovanosti, ktorá sa dosahuje pomocou kanban tabúľ, je veľmi užitočná, ale je to len malý aspekt tohto prístupu. Ak si pozorne prečítate túto knihu, nájdete v nej veľa zaujímavostí. Najcennejšie informácie sú skryté napríklad v takých aspektoch, ako je štruktúra procesov prijímania a odosielania úloh, riadenie nenahraditeľných zdrojov a využívanie tried služieb. Nenechajte sa rozptyľovať vizuálnou časťou, inak prídete o tie najvzrušujúcejšie momenty.

Po tretie, neznevažujte tieto metódy len preto, že sa zdajú príliš jednoduché na použitie. Jednoduché použitie je výsledkom Davidových nápadov, ako získať maximálny úžitok s minimálnymi výsledkami. Dobre pozná potreby praktizujúcich a venoval veľkú pozornosť tomu, čo skutočne funguje. Jednoduché metódy vykazujú vysokú stabilitu a takmer vždy vedú k najlepším dlhodobým výsledkom.

Je to fascinujúca a potrebná kniha a zaslúži si starostlivé štúdium. Úroveň úžitku, ktorý z toho získate, závisí od toho, ako vážne čítanie beriete. Žiadna iná kniha vám tieto pokročilé myšlienky neuvedie lepšie. Dúfam, že si to užijete rovnako ako ja.

Riešenie dilemy agilného manažéra

V roku 2002 som bol manažérom vývoja vo vzdialenej kancelárii Motoroly v Seattli divízie mobilných telefónov Motoroly (nazývalo sa to PCS) a ocitol som sa v ťažkej situácii. Moje oddelenie bolo súčasťou startupu, ktorý Motorola získala rok predtým. Vyvinuli sme sieťový softvér na bezdrôtový prenos dát, ako je bezdrôtové sťahovanie a ovládanie prístrojov. Tieto back-end aplikácie boli súčasťou integrovaných systémov, ktoré boli úzko prepojené s klientskym kódom mobilného telefónu, ako aj s ďalšími prvkami v telekomunikačných sieťach a prevádzkovej infraštruktúre, ako je fakturácia. Termíny stanovovali manažéri, ktorí nevenovali pozornosť inžinierskej zložitosti projektu, jeho rizikám, ani jeho rozsahu. Základný kód sa vyvinul zo spustenia, pričom mnohé pôvodne plánované funkcie boli odložené na neskôr. Jeden starší vývojár trval na tom, aby sa naše produkty nazývali „prototypy“. Zúfalo sme potrebovali zvýšiť produktivitu a kvalitu produktov, aby sme držali krok s požiadavkami podniku.

V mojich každodenných činnostiach v roku 2002 a v mojej predchádzajúcej knihe(1) som sa zaoberal hlavne dvoma problémami. Po prvé, ako ochrániť tím pred neustále sa zvyšujúcimi požiadavkami podnikania a dosiahnuť to, čo sa dnes v agilnej komunite nazýva „optimálne tempo“. A po druhé, ako môžem úspešne implementovať agilný prístup v celej organizácii a prekonať nevyhnutný odpor voči zmenám?

Nájdenie správneho tempa

V roku 2002 agilná komunita považovala optimálne tempo za jednoducho „40-hodinový pracovný týždeň“ (2). Princípy agilného manifestu(3) uviedli, že „agilné procesy podporujú optimálny rozvoj. Sponzori, vývojári a používatelia musia byť pripravení udržiavať konštantné tempo donekonečna.“ Dva roky predtým odo mňa môj tím v Sprint PCS neustále počúval, že „vývoj softvéru vo veľkom je maratón, nie šprint“. Ak by členovia tímu museli udržiavať konštantné tempo v procese práce na rok a pol projekte, potom nemohli dopustiť, aby za mesiac alebo dva vyhoreli. Projekt bolo potrebné naplánovať, naplánovať, načasovať a vyhodnotiť, aby sa zabezpečilo, že členovia tímu trávili každý deň prácou primerané množstvo času a neboli príliš unavení. Mojou úlohou ako manažéra bolo dosiahnuť tento cieľ a spĺňať všetky obchodné požiadavky.

Keď som bol na svojej prvej manažérskej pozícii (bolo to v roku 1991, v startupe, ktorý vyrábal dosky na zachytávanie videa pre osobné a menšie počítače), generálny riaditeľ povedal, že vedenie má na mňa „veľmi negatívny názor“. Vždy som odpovedal „nie“, keď už boli naše možnosti ako vývojárov vyčerpané a vyžadovalo sa od nás stále viac produktov alebo funkcií. V roku 2002 som sa stal zvykom: ďalších desať rokov som odmietal vyhovieť rozmarom majiteľov firiem.

O knihe
Podrobný sprievodca kanbanom od 30-ročného prvého priekopníka kanbanu vo vývoji softvéru.

David Anderson, ktorý zaviedol metódu kanban vo viacerých spoločnostiach a neustále ju zdokonaľoval, ukazuje, ako efektívne zaviesť štíhle nápady do vývoja technológií a prevádzky IT – s minimálnym odporom voči zmenám, pri zachovaní optimálneho tempa pre všetkých zamestnancov zapojených do práce. .

Kanban rýchlo identifikuje problémy, ktoré ovplyvňujú výkon, a núti tím sústrediť sa na ich vyriešenie, aby práca pokračovala. Zviditeľnením problémov s kvalitou a procesmi poskytuje kanban príležitosť vyhodnotiť vplyv defektov, obmedzení, variability a ekonomických nákladov na pracovný tok a priepustnosť zamestnancov.

Jednoduché obmedzenie nedokončených úloh prostredníctvom kanbanu vedie k zlepšeniu kvality práce a produktivity. Kombinácia zjednodušeného pracovného toku a zlepšenej kvality pomáha skrátiť dodacie lehoty a zlepšuje predvídateľnosť a pravdepodobnosť dodania práce načas. Zavedením pravidelných kadencií vydávania a dôsledným dodržiavaním plánov pomáha kanban budovať dôveru u zákazníkov a ostatných členov hodnotového toku – iných oddelení, predajcov a závislých partnerov.

Ukázalo sa, že Kanban zvyšuje spokojnosť používateľov prostredníctvom pravidelných, spoľahlivých a vysokokvalitných verzií hodnotného softvéru. Ukázalo sa tiež, že zlepšuje produktivitu, kvalitu a skracuje čas výroby. Existujú dôkazy, že kanban môže byť katalyzátorom pre vznik agilnejšej organizácie prostredníctvom evolučnej kultúrnej zmeny.

Táto kniha odpovedá na otázky:

- Čo je kanban?
Prečo to vaša spoločnosť potrebuje?
- Ako to implementovať?
- Ako rozpoznať príležitosti na zlepšenie v podnikaní - a čo s nimi robiť?

Pre koho je táto kniha určená?
Pre manažérov a šéfov IT spoločností.

o autorovi
David Anderson je zakladateľom Lean Kanban University a David J Anderson School of Management, ktoré sa venujú pomoci lídrom a manažérom dosahovať lepšie výsledky prostredníctvom osvedčených postupov.

Anderson má 30 rokov skúseností v technologických spoločnostiach. Spoločnostiam ako Motorola a Microsoft zaviedol agilné manažérske postupy.

David ako prvý použil kanban pri vývoji softvéru v roku 2005.

Kanban znamená v japončine „signálna tabuľa“. Vo výrobe sa takáto doska používa na vizualizáciu rastúcich sadzieb, čo vám umožňuje vyrábať viac produktov pri nižších nákladoch. Pozoruhodným príkladom je prístup Toyoty, vďaka ktorému sa už dlhé roky efektívne realizuje princíp „just in time“ s minimálnymi nákladmi.

David Anderson poskytuje rozšírenú sadu nápadov (vizualizácia procesu a pravidiel práce, typizácia pracovných položiek, triedy služieb, kadencie, metriky a grafy pre manažérske účtovníctvo a analýzy), ktoré definujú metódu kanban.

Kniha popisuje nástroje, ktoré umožňujú efektívne zavádzať štíhle nápady do technologického rozvoja a prevádzky IT s minimálnym odporom voči zmenám, pri zachovaní optimálneho tempa pre všetkých zamestnancov zapojených do práce.

Prvýkrát publikované v ruštine.

Držitelia autorských práv! Prezentovaný fragment knihy je umiestnený po dohode s distribútorom legálneho obsahu LLC "LitRes" (nie viac ako 20% pôvodného textu). Ak sa domnievate, že uverejnenie materiálu porušuje vaše práva alebo práva niekoho iného, ​​dajte nám vedieť.

Najčerstvejšie! Objednajte si účtenky ešte dnes

  • Testament Yvette Blanche
    Demange Patricia
    Periodiká

    Suzanne vstala zo skaly a chystala sa ísť späť k autu, keď začula hlas:

    - Poď! Poď ku mne! Poď ku mne! Poď!

    A ako prvýkrát, po týchto výrazných slovách nasledoval nezrozumiteľný vzlyk. Dievča zamrzlo. Hlas bol taký žalostný, že sa nemohla pohnúť.

    A potom znova počula tieto slová:

    "Poď, poď...poď ku mne!" Poď!

    Zrazu sa Susanne zdalo, že jej mozog z tejto jednej vety exploduje. Niekoľko minút stála nehybne, no potom pozbierala sily a ponáhľala sa k autu zaparkovanému pod stromami. Rýchlo vložila kľúč do zapaľovania a naštartovala motor. Chcela sa odtiaľto čo najrýchlejšie dostať. Pokiaľ nič nevieš a nepočuješ. To nemôže byť! Ona je len Susanna Lambert, Susanna Lambert, Susanna Lambert...

  • Vlkolak
    Brúska Alexandra
    Periodiká

    Nasledoval Júliu až do samého močiara... Dievča na sebe pocítilo jeho pohľad a od hrôzy bolo strnulé. Nohy sa okamžite začali prepadať hlbšie a hlbšie do studenej bažiny. Musíme odtiaľto vypadnúť, kým nebude neskoro! Pokúsila sa otočiť smerom k ceste: tu je, pevná zem, doslova meter od nej... Ale tam na ňu čakalo niečo oveľa nebezpečnejšie ako páchnuce močiare: vlkolak pokrytý sivou vlnou! Z tmy sa zrazu vynorila jeho zhrbená postava. Mohutná hlava sa pomaly kývala v čase vetra a v hĺbke očných jamiek sa uhlíky očí zlovestne leskli na červeno. Julia sa ešte naposledy pokúsila vyrovnať sa s vlastným strachom, no hrôza ju paralyzovala: nedokázala urobiť ani krok. Medzitým sa blížil strašidelný tvor, ktorý vyzeral ako vlk. Bolo medzi nimi len pár krokov. Teraz už môžete vidieť šedú vlnu na labkách monštra, tu sa v mesačnom svetle blýskajú ostré pazúry ...

  • Mág rozhodol. Tvorenie
    Nazimov Konštantín
    Výpadky

    Študent, je študentom všade. Zábava a pokusy zarobiť. Jedna z bežných vecí viedla k tragédii a ja som skončil... vo svete mágie. Veľa šťastia, páčilo sa mi to. Dokonca pomohli a ukázalo sa, že sú ... študent, ale už na magickej akadémii a pustili sa do práce.

    Ale život obracia ľudí a kúzelníkov, ako chce. Tento svet nepoznal veľkého intrigána s jeho schopnosťou zarábať peniaze z ničoho. Nikto nestaval finančné pyramídy. Preto sa môžem naplno obracať. Vážne problémy a podvody však pominuli. Jeden z nápadov dopadol tak, že sme s kamarátmi nevedeli stráviť výsledok. Musel som ísť z cesty a posunúť veci na úplne inú úroveň. A je ťažké ho vytiahnuť: tu je zlato mešcov a cech zlodejov, obyčajných ľudí a byrokratov. A tiež problémy s artefaktmi a dievčatami, dlhy na kartách a krásne autá. Musíte sa rozhodnúť rýchlo, okamžite reagovať. Ej, ale chcem žiť krásne a dúfam, že to vyjde, aj keď to nie je pravda ...


  • dáma v bielom
    Šedá Lara
    Detektívi a trilery, Thriller

    Každý deň po polnoci sa na hrade niečo deje...

    Kateřina pochopila, že jej život visí na vlásku. Jednou rukou si chytila ​​sukňu, aby jej lem neprekážal pri behu, druhú ruku natiahla dopredu, aby si nenarazila hlavu o stenu. Konečne dvere! Dievča ho náhle otvorilo a vybehlo z chodby. Prenasledovateľ nezaostával: jeho kroky bolo počuť čoraz zreteľnejšie. Katerinu mohol každú chvíľu dobehnúť!

    - Pre pomoc! Pre pomoc! zakričalo dievča. – Niekto! Pomoc!

    Zakopla o kameň, tvrdo narazila a spadla na podlahu. Kateřina sa odplazila nabok a schovala sa. Našťastie bola tma a prenasledovateľ okolo nej prebehol bez toho, aby si ju všimol. Katerina sa obzrela: ležala v tmavej miestnosti bez okien, bez svetla, nebolo nič vidieť...

  • Závodný žolík. Hra na prežitie
    Nazimov Konštantín
    Beletria, hrdinská fikcia

    Hra nie je taká, ako som si ju predstavoval. Klamstvá a zrada, úplatky a dokonca otroctvo tu idú ruka v ruke. Sú tu normálni hráči, ktorých je veľa, ktorí sa snažia žiť podľa pravidiel a cti. A tiež sa stáva, že čierna je prezentovaná ako biela, lož za pravdu.

    Z vôle mysle siete sú predo mnou postavené zložité úlohy a misie, o ktorých som ani netušil. Preteky o elimináciu alebo prežitie sú nahradené útekom pred lovcami odmien. Musíme sa dostať do súboja s nespravodlivosťou a podlosťou. Zlepšiť život obyčajným hráčom, ktorí sa vo svojej dôverčivosti a naivite hnali za sľubmi a ocitli sa v bezvýchodiskovej situácii. Ponorte sa do susednej svetovej hry, kde sa príšery stretávajú na každom kroku a nepovažujte vás za nič iné ako za svoju korisť. Bez toho všetkého sa nemôžete dostať do cieľa.

    Počas celej hry sú so mnou bok po boku priatelia aj nepriatelia, niektorí pomáhajú v ťažkých chvíľach, iní sú pripravení vraziť mi nôž do chrbta, no musím sa spoliehať sám na seba a veľa šťastia. Je stanovený cieľ, do nádrže sa naleje benzín, okolo krku je amulet a noha stlačí plynový pedál na podlahu. Príde víťazstvo a dosiahnem svoj cieľ! Dúfam…


  • Duchovia z hmly
    Brúska Alexandra
    Periodiká

    Elena doteraz neprikladala dôležitosť tomu, že majiteľ penziónu, v ktorom bývala, bol celý čas sám. Predpokladala, že jeho manželka bola zaneprázdnená v kuchyni alebo zaneprázdnená nejakým iným podnikaním, a preto sa neobjavila pred hosťami ...

Set "Týždeň" - top nové produkty - lídri na týždeň!

  • 2. Prekliaty rektor
    Letná Lena
    Romantické romány , ľúbostné romány , Fiction , detektívky ,

    Mal som rok do konca. Jeden rok - a mohol som získať slobodu a nezávislosť, o ktorej som sníval od detstva. Náhla a veľmi podozrivá smrť mojej mamy mi však obrátila svet hore nohami. Zanechala po sebe veľa otázok a jedinou šancou, ako nájsť odpovede, je ísť na najelitnejšiu univerzitu v republike. Myslel som si, že môj hlavný problém bude snobizmus nových spolužiakov, no mýlil som sa. Odpovede, ktoré hľadám, ma môžu stáť život a z nejakého dôvodu sa teraz viac obávam o život miestneho richtára, ktorý je pod kliatbou.

  • Akadémia Arcturus. vlčia nevesta
    Limetka Sylvia
    Beletria, humorná fikcia

    Niekedy zrada nie je koniec, ale začiatok.

    Občas - toto sú dvere do iného sveta, kde je vojna na prahu. Kde vlkolaci bojujú na život a na smrť za svoje ženy a muži nabíjajú zbrane striebornými guľkami. Tam, kde sa potuluje tajomný zabijak, ktorý obhrýza hrdlo každého, kto sa na vás tak veľmi podobá. Kde sú dobromyseľné úsmevy istou šancou dostať sa do pasce a vlčie zavrčanie za vašim chrbtom je šancou uniknúť.

    Pripravte sa, čaká tu na vás vlkolačia akadémia, za dverami maniak a záhadný muž, ktorý sa z nejakého dôvodu rozhodol, že k vám môže v noci prísť.

    A to všetko preto, že zrada nie je koniec, ale iba začiatok.

  • Arcturus Academy 2. Vlkova žena
    Limetka Sylvia
    Fantasy, Cyberpunk

    Hovorí sa, že život a dôvera sa stratia len raz. Raz som mal šťastie, ale je nepravdepodobné, že by sa šťastie malo opakovať. Maniak, ktorý zabíja dievčatá, sa nájde, no bábkar stále ťahá za nitky svojich bábok. Smrť nasleduje neúprosne a ja musím byť o krok vpred. Tentoraz zachrániť nielen seba, ale aj vlkolaka, s ktorým ju spájajú nerozbitné putá. Je silnejší ako ostatní a toto je jeho slabosť. Aby som ho udržal nažive, budem ho musieť zradiť. Alebo je iné východisko?