David Anderson - Kanban. Kanban

David J Anderson

Erfolgreicher evolutionärer Wandel für Ihr Technologieunternehmen

Veröffentlichung mit Genehmigung von Lean Kanban Inc.

Wir danken der Lean Kanban Community Russia, vertreten durch Alexey Pimenov, Vyacheslav Tsyrulnik, Anton Manin, Sergey Baranov und Igor Filipyev, für ihre Hilfe bei der Vorbereitung der Veröffentlichung.

Kein Teil dieses Buches darf ohne die schriftliche Genehmigung der Urheberrechtsinhaber in irgendeiner Form reproduziert werden.

* * *

Nikola und Natalie gewidmet

Vorwort

Ich achte immer auf die Arbeit von David Anderson. Ich traf ihn im Oktober 2003, als er mir ein Exemplar seines Buches Agile Management for Software Engineering: Applying Theory of Constraints for Business Results schickte. Wie der Titel schon sagt, wurde das Buch stark von Eliyahu Goldratts Theory of Constraints (TOC) beeinflusst. 1
Theory of Constraints ist eine beliebte Methodik des Produktionsmanagements, die in den 1980er Jahren von Eliyahu Goldratt entwickelt wurde und auf der Ermittlung und Verwaltung der wichtigsten Systembeschränkungen basiert, die den Erfolg und die Effizienz des gesamten Systems als Ganzes bestimmen. Notiz. ed.

Später, im März 2005, besuchte ich David bei Microsoft, zu dieser Zeit arbeitete er intensiv mit kumulativen Flussdiagrammen. Noch später, im April 2007, hatte ich Gelegenheit zu beobachten, wie das bahnbrechende Kanban-System funktioniert, das er in Corbis implementiert hat.

Ich gebe diese gesamte Chronologie wieder, damit Sie ein Gefühl für das unaufhaltsame Tempo bekommen, mit dem Davids Management-Denken voranschreitet. Er hält nicht an einer einzigen Idee fest und versucht, die ganze Welt darin unterzubringen. Im Gegenteil, er versucht, das Problem ganzheitlich zu betrachten, ist offen für verschiedene Lösungen, erprobt sie in der Praxis und bewertet die Arbeitsprinzipien. Die Ergebnisse dieses Ansatzes werden Sie in diesem Buch sehen.

Geschwindigkeit ist natürlich gut, solange sie in die richtige Richtung geht, und ich bin sicher, dass David sich in die richtige Richtung bewegt. Besonders bewundere ich die neuste Arbeit mit Kanban-Systemen. Ich habe immer geglaubt, dass die Prinzipien von Lean direkt auf die Produktentwicklung angewendet werden können, im Gegensatz zu den Ideen von TOC. Außerdem schrieb ich David im Oktober 2003 Folgendes: „Eine der Hauptschwächen von CBT ist die Unterschätzung der Bedeutung der Gruppengröße.

Wenn es Ihre oberste Priorität ist, die Einschränkung zu finden und zu beheben, bedeutet das oft, dass Sie nur das falsche Problem lösen." Ich glaube immer noch, dass diese Aussage stimmt.

Bei unserem Treffen im Jahr 2005 schlug ich David erneut vor, sich nicht nur auf Engpässe im TOC zu konzentrieren. Ich erklärte ihm, dass der Hype um das Toyota Production System (TPS) nichts mit dem Finden und Beheben von Engpässen zu tun hatte. Toyota erzielt Produktivitätssteigerungen durch die Reduzierung von Losgrößen und Variabilität, wodurch die Menge an erforderlichem Lagerbestand reduziert wird. Es war die Reduzierung solcher Bestände, die zur Erzielung wirtschaftlicher Vorteile führte, und dies wurde durch Work-in-Process-Reduktionssysteme wie Kanban ermöglicht.

2007 besuchte ich Corbis. Das Ergebnis der Einführung des Kanban-Systems sah beeindruckend aus. Ich wies David darauf hin, dass er den bei Toyota verwendeten Kanban-Ansatz stark verbessert hatte. Warum habe ich das gedacht? Das Toyota-Produktionssystem ist optimiert, um sich wiederholende und vorhersehbare Aufgaben mit einheitlicher Dauer und einheitlichen Verzögerungskosten zu bewältigen. Unter diesen Bedingungen ist es durchaus richtig, Ansätze wie die FIFO-Priorisierung („first in, first out“) zu verwenden. Es ist auch völlig richtig, den Erhalt von Arbeiten zu sperren, wenn die Grenze der nicht abgeschlossenen Aufgaben erreicht ist. Handelt es sich jedoch um sich nicht wiederholende, unvorhersehbare Tätigkeiten mit unterschiedlicher Dauer und unterschiedlichen Verzögerungskosten, können diese Ansätze nicht als optimal angesehen werden – und genau das ist bei der Softwareentwicklung der Fall. Wir brauchen fortschrittlichere Systeme, und dies ist das erste Buch, das sie im praktischen Detail beschreibt.

Ich möchte die Leser vor einigen Dingen warnen. Erstens, wenn Sie glauben zu wissen, wie Kanban-Systeme funktionieren, dann meinen Sie wahrscheinlich die in der schlanken Fertigung verwendeten. Die Ideen in diesem Buch sind viel fortschrittlicher als die einfachen Systeme, die statische WIP-Limits verwenden. 2
WIP - Work in Progress, die Anzahl der laufenden Aufgaben. Notiz. ed.

FIFO-Planung und einzelne Dienstklasse. Bitte beachten Sie diese Unterschiede.

Zweitens, denken Sie nicht, dass dieser Ansatz ein visuelles Kontrollsystem ist. Die mit Kanban-Tafeln erreichte Visualisierung der laufenden Arbeiten ist sehr nützlich, aber nur ein kleiner Aspekt dieses Ansatzes. Wenn Sie dieses Buch sorgfältig lesen, werden Sie viele interessante Dinge darin finden. Die wertvollsten Informationen verbergen sich beispielsweise in Aspekten wie der Struktur der Prozesse zum Empfangen und Versenden von Aufgaben, zum Verwalten unersetzlicher Ressourcen und zum Verwenden von Serviceklassen. Lassen Sie sich nicht vom visuellen Teil ablenken, sonst verpassen Sie die aufregendsten Momente.

Drittens sollten Sie diese Methoden nicht außer Acht lassen, nur weil sie Ihnen zu einfach erscheinen. Benutzerfreundlichkeit ist das Ergebnis von Davids Ideen, wie man mit minimalen Ergebnissen maximalen Nutzen erzielt. Er kennt die Bedürfnisse der Praktizierenden gut und hat ernsthaft darauf geachtet, was wirklich funktioniert. Einfache Methoden zeigen eine hohe Stabilität und führen fast immer zu den besten Langzeitergebnissen.

Dies ist ein faszinierendes und notwendiges Buch und verdient ein sorgfältiges Studium. Der Grad des Nutzens, den Sie daraus ziehen, hängt davon ab, wie ernst Sie das Lesen nehmen. Kein anderes Buch führt Sie besser in diese fortschrittlichen Ideen ein. Ich hoffe, Sie genießen es genauso wie ich.

Don Reinertsen,

Teil I
Grundlagen

Kapitel 1
Das Dilemma des agilen Managers lösen

Im Jahr 2002 war ich Entwicklungsleiter in der Motorola-Niederlassung der Mobiltelefonsparte von Motorola (sie hieß PCS) in Seattle und befand mich in einer schwierigen Situation. Meine Abteilung war Teil eines Startups, das Motorola ein Jahr zuvor übernommen hatte. Wir haben Netzwerksoftware für die drahtlose Datenübertragung entwickelt, wie z. B. den drahtlosen Download und die Gerätesteuerung. Diese Back-End-Anwendungen waren Teil integrierter Systeme, die eng mit dem Client-Code von Mobiltelefonen sowie anderen Elementen in Telekommunikationsnetzen und der betrieblichen Infrastruktur, wie z. B. der Abrechnung, gekoppelt waren. Fristen wurden von Managern gesetzt, die die technische Komplexität des Projekts, seine Risiken oder seinen Umfang nicht beachteten. Der Kerncode entwickelte sich aus einem Startup, wobei viele ursprünglich geplante Funktionen auf später verschoben wurden. Ein leitender Entwickler bestand darauf, dass unsere Produkte „Prototypen“ genannt werden. Wir mussten dringend die Produktivität und Produktqualität steigern, um mit den Anforderungen des Unternehmens Schritt zu halten.

Bei meinen täglichen Aktivitäten im Jahr 2002 und bei der Arbeit am vorherigen Buch 1
Anderson, DavidJ. Agiles Management für Softwareentwicklung: Anwendung der Theorie der Einschränkungen für Geschäftsergebnisse. Oberer Sattelfluss, NJ: Prentice Hall, 2003.

Mir ging es hauptsächlich um zwei Themen. Erstens, wie man das Team vor den ständig steigenden Anforderungen des Geschäfts schützt und das erreicht, was heute in der agilen Community als „optimales Tempo“ bezeichnet wird. Und zweitens, wie kann ich einen agilen Ansatz erfolgreich in der gesamten Organisation implementieren und die unvermeidlichen Widerstände gegen Veränderungen überwinden?

Das richtige Tempo finden

Im Jahr 2002 dachte die agile Community, dass das optimale Tempo einfach eine „40-Stunden-Arbeitswoche“ sei. 2
Beck, Kent. Extreme Programming Explained: Embrace Change. Boston: Addison Wesley, 2000. Russische Ausgabe: Beck K. Extreme Programming. Sankt Petersburg: Peter, 2002.

Prinzipien des Agilen Manifests 3
Beck, Kent et al., „Die Prinzipien hinter dem agilen Manifest“. http://www.agilemanifesto.org/principles.html. Russische Übersetzung: http://agilemanifesto.org/iso/ru/principles.html .

Sie sagten: „Agile Prozesse tragen zu einer optimalen Entwicklung bei. Sponsoren, Entwickler und Nutzer müssen bereit sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.“ Zwei Jahre zuvor hörte mein Team bei Sprint PCS immer wieder von mir, dass „Softwareentwicklung im großen Maßstab ein Marathon ist, kein Sprint“. Wenn die Teammitglieder bei der Arbeit an einem anderthalbjährigen Projekt ein konstantes Tempo beibehalten mussten, durften sie nicht in ein oder zwei Monaten ausbrennen. Das Projekt musste geplant, budgetiert, terminiert und bewertet werden, um sicherzustellen, dass die Teammitglieder jeden Tag eine angemessene Zeit mit der Arbeit verbringen und nicht zu müde sind. Als Führungskraft war es meine Aufgabe, dieses Ziel zu erreichen und alle geschäftlichen Anforderungen erfüllen.

Als ich in meiner ersten Führungsposition war (es war 1991 bei einem Start-up, das Videoaufzeichnungskarten für PCs und kleinere Computer herstellte), war der CEO 3
Vorstandsvorsitzender - Vorstandsvorsitzender (CEO). Notiz. ed.

Er sagte, dass das Management eine „extrem negative Meinung“ über mich habe. Ich habe immer dann mit „nein“ geantwortet, wenn unsere Möglichkeiten als Entwickler bereits ausgeschöpft waren und immer mehr Produkte oder Features von uns verlangt wurden. Bis 2002 war ich zur Gewohnheit geworden: Ich verbrachte weitere zehn Jahre damit, mich zu weigern, den Launen der Geschäftsinhaber nachzugeben.

Entwicklungsteams und IT-Abteilungen von Unternehmen sind stark von anderen Gruppen abhängig, die ständig verhandeln, betteln, drohen und selbst die offensichtlichsten und objektivsten Pläne überarbeiten. Anfällig sind auch Pläne, die auf sorgfältiger Analyse und historischer Erfahrung beruhen. Die meisten Teams, denen es an gründlicher Analyse und historischer Erfahrung mangelte, konnten nicht mit denen fertig werden, die sie dazu drängten, obskure und oft unmögliche Verpflichtungen einzugehen.

Inzwischen haben sich die Mitarbeiter mit dem wahnsinnigen Arbeitspensum arrangiert, exorbitante Arbeitsbelastungen sind zur Normalität geworden. Niemand scheint darüber nachgedacht zu haben, dass Softwareingenieure auch ein soziales oder familiäres Leben führen können. Klingt hart, ist aber so! Ich kenne zu viele Beispiele, wo übermäßige Arbeitsbelastung die Familienbeziehungen für immer zerstört hat. Es ist schwer, mit dem typischen Entwicklerfreak mitzufühlen. In meinem Heimatstaat Washington steht das Einkommen eines Softwareentwicklers nur hinter dem eines Zahnarztes. Wie zu Zeiten von Ford, also in den 1920er-Jahren, als die Menschen in seinen Fabriken das Fünffache des Landesdurchschnitts verdienten, denkt niemand an die Monotonie der Arbeit oder das Wohlergehen der Spezialisten: Sie sind es so viel bezahlt! Gewerkschaften sind in wissensbasierten Branchen wie der Softwareentwicklung kaum vorstellbar, weil niemand ernsthaft die Ursachen für die körperlichen und psychischen Leiden von Entwicklern untersucht. Verantwortungsvollere Arbeitgeber bieten beispielsweise Maßnahmen wie Massage oder Psychotherapie an. Oder sie verbringen Tage der psychischen Gesundheit – und das anstatt sich darauf zu konzentrieren, die Grundursachen des Problems zu untersuchen. Ein Technischer Redakteur einer bekannten Softwarefirma sagte einmal zu mir: „Es ist okay, wenn ich Antidepressiva nehme, weil das jeder tut!“ Programmierer gehen normalerweise auf alle Forderungen ein, werden gut bezahlt und tragen die Konsequenzen. Ich wollte das ändern, um einen für beide Seiten vorteilhaften Ansatz zu finden, der es mir ermöglicht, Ja zu sagen und trotzdem mein Team zu schützen, um sicherzustellen, dass ein optimales Tempo erreicht wird. Ich wollte meine Teammitglieder zurück in die Gemeinschaft und Familie bringen und die Bedingungen verbessern, die Entwicklern unter 30 Stress und gesundheitliche Probleme bereiteten. Also beschloss ich, mich mit diesen Problemen zu befassen.

Auf der Suche nach erfolgreichem Change Management

Das zweite Thema, das mir auf der Seele brennt, ist das Änderungsmanagement in großen Organisationen. Ich war Entwicklungsleiter bei Sprint PCS und dann bei Motorola. In beiden Unternehmen bestand ein starker Bedarf an flexibleren Arbeitsmethoden. Aber in beiden Fällen hatte ich Probleme, agile Methoden in mehr als einem oder zwei Teams umzusetzen.

Beide Male hatte ich nicht genug Autorität, um einfach Änderungen an mehreren Teams anzuordnen. Ich habe versucht, auf Wunsch der Geschäftsleitung Änderungen umzusetzen, hatte aber nicht die nötige Autorität. Ich wurde gebeten, Kollegen dazu zu bewegen, in ihren Teams die gleichen Änderungen umzusetzen wie ich in meinem. Aber sie hatten es nicht eilig, Methoden zu übernehmen, die in meinem Team am besten zu funktionieren schienen. Dieser Widerstand hatte wahrscheinlich mehrere Gründe. Meistens habe ich gehört, dass jedes Team seine eigene Situation hat und meine Methoden auf die spezifischen Bedürfnisse anderer zugeschnitten werden müssen. Mitte 2002 wurde mir klar, dass es sinnlos war, einen Softwareentwicklungsprozess starr vorzuschreiben – es würde einfach nicht funktionieren.

Der Prozess musste an jede spezifische Situation angepasst werden, sodass eine aktive Führung jedes Teams erforderlich war. Und das war oft nicht genug. Selbst bei richtiger Führung gibt es keine Gewissheit, dass ohne eine etablierte Struktur und Beratung, wie Prozesse an unterschiedliche Situationen angepasst werden können, signifikante Veränderungen eintreten können. Wenn der Manager, Coach oder verantwortliche Ingenieur keine klare Vorstellung davon hat, was zu tun ist, dann ist jede Anpassung wahrscheinlich subjektiv. Gleichzeitig besteht eine hohe Wahrscheinlichkeit von Fehlern – zum Beispiel die Einführung eines unpassenden Prozess-Templates.

Ich habe versucht, dieses Thema in dem Buch Agile Management for Software Engineering zu behandeln, an dem ich damals schrieb. Ich fragte mich: „Warum bringt agile Entwicklung bessere wirtschaftliche Ergebnisse als traditionelle Ansätze?“ Dazu wollte ich die Struktur der Constrainttheorie anwenden. 4
Goldratt, Eliyahu M. Was ist dieses Ding namens Theory of Constraints und wie sollte es implementiert werden? Great Barrington, MA: North River Press, 1999.

Beim Recherchieren und Schreiben dieses Buches wurde mir klar, dass jede Situation einzigartig ist. Und wie kann eine Einschränkung oder ein Engpass für jedes Team und Projekt zu jeder Zeit gleich sein? Jedes Team ist einzigartig: unterschiedliche Fähigkeiten, Möglichkeiten, Erfahrungen. Jedes Projekt unterscheidet sich von anderen in Bezug auf Budget, Zeitplan, Umfang und Risiken. Auch Organisationen sind unterschiedlich: Sie haben unterschiedliche Wertschöpfungsketten und agieren auf unterschiedlichen Märkten (Abbildung 1.1). Mir schien, dass dies einen Anhaltspunkt für das Verständnis des Widerstands gegen Veränderungen liefern könnte. Wenn die vorgeschlagenen Änderungen der Arbeitsmethoden und des Verhaltens nach Ansicht des Arbeitnehmers keinen offensichtlichen Vorteil bringen, wird er sie nicht akzeptieren. Wenn diese Änderungen keinen Einfluss darauf haben, was das Team als Begrenzer oder Abschreckung wahrnimmt, wird das Team Widerstand leisten. Mit anderen Worten: Änderungsvorschläge ohne Rücksicht auf den Kontext werden von Mitarbeitern abgelehnt, die den Kontext der Arbeit perfekt kennen.

Reis. 1.1. Warum generische Entwicklungsmethoden falsch sind

Es scheint, dass es besser wäre, wenn sich der neue Prozess zu entwickeln beginnt und eine Einschränkung nach der anderen beseitigt. Dies ist der Kernpunkt von Goldratts Theory of Constraints. Als ich erkannte, dass ich noch viel zu lernen hatte, erkannte ich den Wert des Materials und eilte mit der Arbeit am Manuskript voran. Mir war klar, dass das Buch keine Ratschläge gibt, wie man Ideen in größerem Maßstab umsetzt, und auch keine große Hilfe dabei, Wege zur Bewältigung von Veränderungen zu finden.

Goldratts Ansatz, der in skizziert wird, zielt darauf ab, Einschränkungen zu finden und dann Wege, sie zu beseitigen, sodass sie die Leistung nicht länger behindern. Danach entsteht eine neue Einschränkung, und der Zyklus wiederholt sich. Es handelt sich um einen iterativen Ansatz, der die Leistung systematisch verbessert, indem Hindernisse identifiziert und beseitigt werden.

Mir wurde klar, dass man diesen Ansatz mit einigen Techniken aus dem Bereich Lean Manufacturing kombinieren kann. Durch die Modellierung des Lebenszyklus-Workflows der Softwareentwicklung als Wertstrom und die Erstellung eines Nachverfolgungs- und Visualisierungssystems zur Erfassung von Zustandsänderungen der entstehenden Arbeit, die durch das System „fließt“, konnte ich die Einschränkungen identifizieren. Die Fähigkeit, die Einschränkung zu identifizieren, ist der erste Schritt in Richtung des zugrunde liegenden TOC-Modells. Goldratt hat bereits eine Anwendung dieser Theorie auf Workflow-Probleme entwickelt, die den plumpen Namen „Trommel-Puffer-Seil“ trägt. Ich habe jedoch festgestellt, dass eine vereinfachte Version dieses Systems im Bereich der Softwareentwicklung implementiert werden kann.

Trommel-Puffer-Seil ist vom Ursprung her ein Beispiel für eine Klasse von Lösungen, die als Zugsysteme bekannt sind. Wie wir in sehen werden, ist Kanban auch ein Beispiel für ein solches System. Ein Nebeneffekt von Pull-Systemen ist, dass sie WIP auf einen vorher festgelegten Betrag begrenzen und so verhindern, dass Mitarbeiter überfordert werden. Außerdem bleiben nur Arbeitnehmer voll ausgelastet, die direkt der Beschränkung ausgesetzt sind; Alle anderen sollten Freizeit haben. Ich erkannte, dass Pull-Systeme beide Probleme lösen konnten, die mich beunruhigten. Das Pull-System wird es mir ermöglichen, inkrementelle Änderungen einzuführen, die (wie ich hoffte) den Widerstand gegen sie erheblich verringern und es einfacher machen würden, das optimale Tempo zu erreichen. Ich habe mich entschieden, so schnell wie möglich auf das Trommel-Puffer-Seil-System umzusteigen. Ich wollte mit inkrementeller Prozessentwicklung experimentieren und sehen, ob sie ein optimales Tempo und einen geringeren Widerstand gegen Veränderungen bietet.

Eine solche Möglichkeit ergab sich im Herbst 2004 bei Microsoft, die in diesem Buch in der Analyse des Beispiels ausführlich beschrieben wird.

Vom Trommelpufferseil bis zum Kanban

Die Trommel-Puffer-Seil-Lösung bei Microsoft hat sich gelohnt. Der Widerstand war schwach, die Leistung mehr als verdreifacht, die Vorlaufzeit um 90 % verkürzt und die Vorhersagbarkeit um 98 % verbessert. Im Herbst 2005 habe ich auf einer Konferenz in Barcelona über die erzielten Ergebnisse berichtet 5
Anderson, David J. und Dragos Dumitriu, „From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department“, Proceedings of the TOCICO World Conference, Barcelona, November 2005.

Und im Winter 2006 machte er einen weiteren Bericht. Meine Arbeit erregte die Aufmerksamkeit von Donald Reinertsen, der einen besonderen Besuch in meinem Büro in Redmond abstattete. Er wollte mir versichern, dass alles für eine vollständige Umstellung auf Kanban bereit sei.

Kanban - ein japanisches Wort, das wörtlich übersetzt „Signaltafel“ bedeutet. In der Produktion wird ein solches Board verwendet, um das zunehmende Produktionstempo zu visualisieren, wodurch mehr Produkte hergestellt werden können. Mitarbeiter in jeder Phase des Prozesses können nicht zur nächsten Arbeitsphase übergehen, bis das entsprechende Signal durch die Kanban-Tafel gegeben wird. Obwohl ich von der Existenz dieses Mechanismus wusste, war ich nicht davon überzeugt, dass er in Bezug auf intellektuelle Arbeit, insbesondere Softwareentwicklung, nützlich oder sogar praktikabel ist. Ich verstand, dass Kanban das optimale Tempo bot, wusste aber nicht um seinen guten Ruf als Methode, um Anreize für inkrementelle Prozessverbesserungen zu schaffen. Ich wusste nicht, dass Taiichi Ohno, einer der Schöpfer des Toyota-Produktionssystems, sagte: „Die zwei Hauptprinzipien des Toyota-Produktionssystems sind Just-in-time und menschengestützte Automatisierung oder Autonomie. Zur Verwaltung des Systems wird ein Tool verwendet - das ist Kanban. Mit anderen Worten, Kanban ist für den Prozess von entscheidender Bedeutung. Kaizen(„kontinuierliche Verbesserung“), das von Toyota verwendet wird. Es ist der Mechanismus, der das System zum Laufen bringt. Jetzt, mit fünf Jahren Erfahrung hinter mir, akzeptiere ich dies als absolute Wahrheit.

Glücklicherweise hat Don überzeugende Argumente für den Wechsel von Trommel-Puffer-Seil zu Kanban geliefert. Es klang ziemlich esoterisch: Das Kanban-System sorgt für einen fließenderen Übergang vom Stillstand zum Engpass als Trommel-Puffer-Seil. Das Verständnis dieser Unterscheidung ist jedoch nicht unbedingt erforderlich, um dieses Buch zu lesen und zu verstehen.

Als ich die von Microsoft implementierte Lösung erneut untersuchte, stellte ich fest, dass das Ergebnis dasselbe wäre, wenn wir es sofort als Ergebnis eines Kanban-Systems wahrnehmen würden. Interessant fand ich, dass zwei unterschiedliche Ansätze zum gleichen Ergebnis führen. Da es sich also um den gleichen Prozess handelte, fühlte ich mich nicht verpflichtet, es nur als Ergebnis der Implementierung des Trommel-Puffer-Seil-Systems zu sehen.

Ich fing an, den Begriff „Kanban“ diesem komplexen Ausdruck vorzuziehen. Es wird in der schlanken Fertigung verwendet (wie das Toyota-Produktionssystem). Dieses Wissen hat viel mehr Verbreitung und Anerkennung erfahren als die Theorie der Beschränkungen. Kanban ist trotz seines japanischen Ursprungs weniger metaphorisch als Trommel, Puffer und Seil zusammen. Dieses Wort ist einfacher auszusprechen, zu erklären und, wie sich später herausstellte, zu lehren und umzusetzen. Hier ist es hängengeblieben.

Die Entstehung der Kanban-Methode

Im September 2006 verließ ich Microsoft, um die Softwareentwicklung bei Corbis zu leiten, einem privaten Unternehmen für Fotospeicherung und geistiges Eigentum mit Sitz in der Innenstadt von Seattle. Inspiriert von dem, was Microsoft erreicht hatte, entschied ich mich, ein Kanban-Pull-System in Corbis zu implementieren. Auch hier waren die Ergebnisse sehr erfolgreich und führten zur Entwicklung der meisten in diesem Buch vorgestellten Konzepte. Es ist ein erweiterter Satz dieser Konzepte – Workflow-Visualisierung, Workflow-Elementtypen, Kadenzen, Serviceklassen, spezielle Managementberichte und Aktivitätsanalyse –, die die Kanban-Methode definieren.

In diesem Buch beschreibe ich Kanban (großgeschrieben) als eine Methode des evolutionären Wandels unter Verwendung des Kanban-Pull-Systems (Kleinbuchstaben), Visualisierung und anderer Tools, um die Einführung von Lean-Ideen in die Technologieentwicklung und den IT-Betrieb zu katalysieren. Es ist ein evolutionärer und schrittweiser Prozess. Mit Kanban erreichen Sie eine kontextspezifische Prozessoptimierung mit minimalem Änderungswiderstand und erhalten gleichzeitig das optimale Tempo für alle Beteiligten.

Das Buch Kanban von David Anderson übernimmt von der ersten Seite an.

Mit Bildern, Grafiken und Schlussfolgerungen Davids komprimierte Biografie enthüllt die Kanban-Methodik für den versierten Projektmanagement-Freak. Projektmanagement ist interessant, wenn es in der ersten Person vom direkten Entwickler der Methode erzählt wird.

Über den Autor

Aufgeführt im offiziellen Blog von David J. Anderson als p Vorsitzender von Lean Kanban Inc. Auch er t Management Manager und Berater seit den 2000er Jahren, Referent und Konferenzveranstalter seit 2005. Zum ersten Mal in einer Führungsposition war er 1991, sodass Sie mit seiner Erfahrung Kanban und Wasserfall, Agile, Scrum und andere Projektmanagementmethoden ehrlich vergleichen können.

Er schuf Kanban, um das Niveau der intellektuellen und kreativen Arbeit zu erhöhen. Davids Ziel war es, pünktlich zu liefern, Ziele zu erreichen und die heutigen Unternehmen im Allgemeinen angemessen zu führen.

Anhand realer Beispiele aus dem Leben von Microsoft, Motorola und Corbis erzählte und zeigte er die Prinzipien, Methoden und Anleitungen zur Umsetzung von Kanban in einem Unternehmen.

Semantische Belastung und Essenz des Buches

Buch . Alternativroute zuAgile wurde von der Person geschrieben, die Kanban überhaupt erfunden hat. Das Buch ist sehr interessant und informativ. Hier wird die Grenze zwischen der Philosophie von Kaizen sehr interessant aufgedeckt ( ständige Verbesserung), Methodik ( Mager) und Kanban (eine Methode zur Schonung menschlicher und materieller Ressourcen).

Kaizen ist die Philosophie und Ethik der Beziehung zwischen Fabrikarbeitern und Management.

Lean Manufacturing ist ein Projektmanagementsystem, das bei Toyota entwickelt wurde, um jegliche Verschwendung von Zeit und Ressourcen aus den Prozessen des Unternehmens zu entfernen.

Kanbanist eine Projektmanagement-Methode, die einen Weg vorgibt gleichzeitig laufende Aufgaben begrenzen. Wenn Personen, Werkzeuge oder Zeit begrenzt sind, hilft Kanban bei der Verteilung von Aufgaben und Projekten.

Anderson wurde beim Schreiben dieses Buches stark von der Theorie der Beschränkungen beeinflusst. Das Buch ist voll von WIP-Limits, Engpässen und der Fähigkeit dazuBestimmen Sie ehrlich die maximale Belastung pro Zeiteinheit, wodurch die Qualität auf einem optimalen Niveau gehalten wird.

Die Theory of Constraints (TOC) von Dr. Eliyahu Goldratt ist eine Managementmethode für Fertigungsunternehmen. Ein israelischer Physiker entwickelte eine Theorie und eine praktische Methode für das Management von Organisationen, Algorithmen für den Betrieb von Produktion, Logistik und Vermarktung von Waren. Ein systematischer Ansatz zur Identifizierung von Engpässen in Unternehmen hilft bei der Einrichtung. Nach Goldratts Erfahrung Meistens wird die Unternehmenspolitik zu einem Zwang.

WIP-Limit (work in progress) – die Anzahl der Aufgaben, die gleichzeitig geöffnet sein können.

Engpass - ein Moment im Arbeitsablauf, in dem es ernst wird Begrenzung von Ressourcen oder Möglichkeiten. Auf den Diagrammen sieht es wirklich aus wie ein schmaler Flaschenhals: Sowohl vor als auch nach einer solchen Situation dehnen sich die Linien auf den Diagrammen aus.

Klischees über Kanban

Wenn wir von Kanban hören, stellen wir uns oft eine Tafel mit Aufklebern vor – dieses Klischee wird uns von den Medien aufgezwungen. Bildlich gesprochen hängt an der Wand eine Liste offener, laufender und erledigter Sticker-Aufgaben. . Sie können virtuelle Wände und Programme verwenden, um Projekte zu verwalten, in denen Aufgabenlisten, Prioritäten und andere Nuancen eingegeben werden.

Die Kanban-Methodik wird hier kein Brett und keine Aufkleber sein, aber der Prozess der Überwachung und Übertragung von Aufgaben an der Wand. Nach welchen Regeln, wer und warum die Aufkleber bewegt, wie viele Aufkleber in der Spalte „durchgeführt“ aufbewahrt werden können, warum die Anzahl in dieser Spalte begrenzen - das erzählt David auf den Seiten " Kanban. Ein alternativer Weg zu Agile.

Kanban ist kein Klebebrett, Aufkleber sind nur ein Indikator für die Arbeitsbelastung.

Anderson hat den Kanban so konzipiert, dass wir kein neues Projekt beginnen, bis die vorherigen abgeschlossen sind. Daher wird für einen Entwickler die Anzahl der Aufkleber ausgewählt - beispielsweise 3-5, und es können genau so viele Aufgaben pro Zeiteinheit für ihn geöffnet werden. Erst nachdem er eine der Aufgaben erledigt hat, kann er eine neue übernehmen.

Wir sprechen viel über Arbeitsstunden und deren Preis, erkennen aber oft nicht, dass es eine Stunde produktiver Arbeit und eine Stunde des Lebens gibt. Und es gibt eine Woche produktiver Arbeit, deren Bereich Sie krankschreiben müssen. David spricht über dieses Arbeitstempo, wenn Jede Stunde ist produktiv und das ist ein konstanter gesunder Zustand des Teams.

Agile, Scrum und Kanban

Anderson ist sich sicher, dass Agile- und Scrum-Methoden formelhaft und starr sind. Projektmanagement sollte seiner Meinung nach in jedem Unternehmen individuell sein. Daher sind Agile und Scrum mit ihren standardisierten Aktionsalgorithmen ebenso veraltet wie die klassische Wasserfall-Schritt-für-Schritt-Methodik. Ein Kan-Verbot - die Methode ist so unternehmensspezifisch, was die Anhänger flexibler Methoden erschreckt!

Agile ist eine agile Methodik, mit der das Programmieren in der Vergangenheit damit begann, alle paar Monate Updates für Programme bereitzustellen. Die Programmierung von Iterationen von ein paar Wochen, um jede Funktion hinzuzufügen, beschleunigt den Entwicklungsprozess und reduziert das Risiko.

Scrum ist eine weitere agile Methode mit kurzen Iterationen, aber mehr Kontrolle über den Programmierprozess. Es gibt Sprints – Zeitspannen mit bestimmten Aufgaben, die erledigt werden müssen. Sie sind streng limitiert. Es gibt Backlogs – Listen von Aufgaben im Allgemeinen, die vom Product Owner verteilt werden. Es gehört nicht zum Entwicklungsteam, sondern priorisiert Aufgaben.

David Anderson

Kanban. Ein alternativer Weg zu Agile

David J Anderson

Erfolgreicher evolutionärer Wandel für Ihr Technologieunternehmen

Veröffentlichung mit Genehmigung von Lean Kanban Inc.

Kein Teil dieses Buches darf ohne die schriftliche Genehmigung der Urheberrechtsinhaber in irgendeiner Form reproduziert werden.

* * *

Nikola und Natalie gewidmet

Vorwort

Ich achte immer auf die Arbeit von David Anderson. Ich traf ihn im Oktober 2003, als er mir ein Exemplar seines Buches Agile Management for Software Engineering: Applying Theory of Constraints for Business Results schickte. Wie der Titel schon sagt, wurde das Buch stark von Eliyahu Goldratts Theory of Constraints (TOC) beeinflusst. Später, im März 2005, besuchte ich David bei Microsoft, zu dieser Zeit arbeitete er intensiv mit kumulativen Flussdiagrammen. Noch später, im April 2007, hatte ich Gelegenheit zu beobachten, wie das bahnbrechende Kanban-System funktioniert, das er in Corbis implementiert hat.

Ich möchte die Leser vor einigen Dingen warnen. Erstens, wenn Sie glauben zu wissen, wie Kanban-Systeme funktionieren, dann meinen Sie wahrscheinlich die in der schlanken Fertigung verwendeten. Die Ideen in diesem Buch sind viel fortschrittlicher als die einfachen Systeme, die statische WIP-Limits, FIFO-Scheduling und eine einzelne Serviceklasse verwenden. Bitte beachten Sie diese Unterschiede.

Das Dilemma des agilen Managers lösen

In meiner täglichen Arbeit im Jahr 2002 und während meines vorherigen Buches (1) beschäftigte ich mich hauptsächlich mit zwei Themen. Erstens, wie man das Team vor den ständig steigenden Anforderungen des Geschäfts schützt und das erreicht, was heute in der agilen Community als „optimales Tempo“ bezeichnet wird. Und zweitens, wie kann ich einen agilen Ansatz erfolgreich in der gesamten Organisation implementieren und die unvermeidlichen Widerstände gegen Veränderungen überwinden?

Das richtige Tempo finden

Im Jahr 2002 betrachtete die agile Community das optimale Tempo einfach als „eine 40-Stunden-Arbeitswoche“(2). In den Prinzipien des Agilen Manifests(3) heißt es: „Agile Prozesse fördern eine optimale Entwicklung. Sponsoren, Entwickler und Nutzer müssen bereit sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.“ Zwei Jahre zuvor hörte mein Team bei Sprint PCS immer wieder von mir, dass „Softwareentwicklung im großen Maßstab ein Marathon ist, kein Sprint“. Wenn die Teammitglieder bei der Arbeit an einem anderthalbjährigen Projekt ein konstantes Tempo beibehalten mussten, durften sie nicht in ein oder zwei Monaten ausbrennen. Das Projekt musste geplant, budgetiert, terminiert und bewertet werden, um sicherzustellen, dass die Teammitglieder jeden Tag eine angemessene Zeit mit der Arbeit verbringen und nicht zu müde sind. Als Führungskraft war es meine Aufgabe, dieses Ziel zu erreichen und alle geschäftlichen Anforderungen erfüllen.

Als ich in meiner ersten Führungsposition war (es war 1991 bei einem Startup, das Videoaufzeichnungskarten für Personal- und kleinere Computer herstellte), sagte der CEO, dass das Management eine „sehr negative Meinung“ von mir habe. Ich habe immer dann mit „nein“ geantwortet, wenn unsere Möglichkeiten als Entwickler bereits ausgeschöpft waren und immer mehr Produkte oder Features von uns verlangt wurden. Bis 2002 war ich zur Gewohnheit geworden: Ich verbrachte weitere zehn Jahre damit, mich zu weigern, den Launen der Geschäftsinhaber nachzugeben.

Über das Buch
Ein ausführlicher Kanban-Leitfaden von einem 30-jährigen ersten Kanban-Pionier in der Softwareentwicklung.

David Anderson, der die Kanban-Methode in mehreren Unternehmen implementiert und ständig verbessert hat, zeigt, wie man Lean-Ideen effektiv in die Technologieentwicklung und den IT-Betrieb einführt – mit minimalem Widerstand gegen Veränderungen, während das optimale Tempo für alle an der Arbeit beteiligten Mitarbeiter beibehalten wird .

Kanban identifiziert schnell Probleme, die sich auf die Leistung auswirken, und zwingt das Team, sich auf ihre Lösung zu konzentrieren, um den Arbeitsfluss aufrechtzuerhalten. Indem Qualitäts- und Prozessprobleme sichtbar gemacht werden, bietet Kanban die Möglichkeit, die Auswirkungen von Mängeln, Einschränkungen, Schwankungen und wirtschaftlichen Kosten auf den Arbeitsablauf und den Mitarbeiterdurchsatz zu bewerten.

Die einfache Begrenzung unfertiger Jobs durch Kanban führt zu einer verbesserten Arbeitsqualität und Produktivität. Die Kombination aus optimiertem Arbeitsablauf und verbesserter Qualität trägt zur Verkürzung der Vorlaufzeiten bei und verbessert die Vorhersagbarkeit und die Wahrscheinlichkeit, dass Arbeiten pünktlich geliefert werden. Durch die Einrichtung regelmäßiger Release-Kadenzen und die konsequente Einhaltung von Zeitplänen hilft Kanban dabei, Vertrauen bei Kunden und anderen Mitgliedern des Wertstroms aufzubauen – anderen Abteilungen, Anbietern und abhängigen Partnern.

Kanban steigert nachweislich die Benutzerzufriedenheit durch regelmäßige, zuverlässige und qualitativ hochwertige Releases wertvoller Software. Es hat sich auch gezeigt, dass es die Produktivität und Qualität verbessert und die Produktionszeit verkürzt. Es gibt Hinweise darauf, dass Kanban ein Katalysator für die Entstehung einer agileren Organisation durch evolutionären Kulturwandel sein kann.

Dieses Buch beantwortet die Fragen:

- Was ist Kanban?
Warum braucht Ihr Unternehmen das?
- Wie wird es umgesetzt?
- Wie erkennt man Verbesserungspotenziale im Unternehmen – und was kann man damit machen?

Für wen ist dieses Buch?
Für Manager und Leiter von IT-Unternehmen.

Über den Autor
David Anderson ist der Gründer der Lean Kanban University und der David J Anderson School of Management, die es sich zur Aufgabe gemacht haben, Führungskräften und Managern dabei zu helfen, durch Best Practices bessere Ergebnisse zu erzielen.

Anderson verfügt über 30 Jahre Erfahrung in Technologieunternehmen. Er hat agile Managementpraktiken in Unternehmen wie Motorola und Microsoft eingeführt.

David war der Erste, der Kanban 2005 in der Softwareentwicklung einsetzte.

Kanban bedeutet auf Japanisch „Signaltafel“. In der Fertigung wird ein solches Board verwendet, um steigende Raten zu visualisieren, wodurch Sie mehr Produkte zu geringeren Kosten produzieren können. Ein markantes Beispiel ist der Ansatz von Toyota, dank dem das Prinzip „Just in Time“ seit vielen Jahren mit minimalen Kosten effektiv umgesetzt wird.

David Anderson stellt einen erweiterten Satz von Ideen zur Verfügung (Visualisierung des Prozesses und der Arbeitsregeln, Eingabe von Arbeitselementen, Dienstklassen, Kadenzen, Metriken und Diagramme für Management Accounting und Analyse), die die Kanban-Methode definieren.

Das Buch beschreibt Tools, mit denen Sie Lean-Ideen effektiv in die technologische Entwicklung und den IT-Betrieb einführen können, mit minimalem Widerstand gegen Veränderungen, während Sie gleichzeitig ein optimales Tempo für alle an der Arbeit beteiligten Mitarbeiter beibehalten.

Erstmals in russischer Sprache erschienen.

Rechteinhaber! Das präsentierte Fragment des Buches wird im Einvernehmen mit dem Distributor von Legal Content LLC "LitRes" platziert (nicht mehr als 20% des Originaltextes). Wenn Sie der Meinung sind, dass das Posten von Material Ihre Rechte oder die einer anderen Person verletzt, teilen Sie uns dies bitte mit.

Das Frischeste! Buchen Sie noch heute Quittungen

Testament von Yvette Blanche
Demange Patricia
Zeitschriften

Suzanne stand vom Felsen auf und wollte gerade zum Auto zurückgehen, als sie eine Stimme hörte:

- Kommen! Komm zu mir! Komm zu mir! Kommen!

Und wie beim ersten Mal folgte diesen deutlichen Worten ein unverständliches Schluchzen. Das Mädchen erstarrte. Die Stimme war so klagend, dass sie sich nicht bewegen konnte.

Und dann hörte sie wieder diese Worte:

„Komm, komm … komm zu mir!“ Kommen!

Plötzlich schien es Susanna, als würde ihr Gehirn bei diesem einen Satz explodieren. Einige Minuten lang stand sie regungslos da, nahm dann aber ihre Kräfte zusammen und eilte zu dem Auto, das unter den Bäumen geparkt war. Sie steckte schnell den Zündschlüssel ein und startete den Motor. Sie wollte so schnell wie möglich hier raus. Solange du nichts weißt oder hörst. Es kann nicht sein! Sie ist nur Susanna Lambert, Susanna Lambert, Susanna Lambert...
Werwolf
Mühle Alexandra
Zeitschriften

Er folgte Julia bis in den Sumpf ... Das Mädchen spürte seinen Blick auf sich und war vor Entsetzen wie betäubt. Sofort begannen die Beine immer tiefer in den kalten Sumpf einzusinken. Wir müssen hier raus, bevor es zu spät ist! Sie versuchte, sich dem Weg zuzuwenden: Hier ist fester Boden, buchstäblich einen Meter entfernt ... Aber dort wartete etwas viel Gefährlicheres als ein stinkender Sumpf auf sie: ein mit grauer Wolle bedeckter Werwolf! Seine gebeugte Gestalt tauchte plötzlich aus der Dunkelheit auf. Der massive Kopf wiegte sich langsam im Takt des Windes, und in den Tiefen der Augenhöhlen leuchteten die Kohlen der Augen unheilvoll rot. Julia unternahm einen letzten Versuch, mit ihrer eigenen Angst fertig zu werden, aber das Entsetzen lähmte sie: Sie konnte keinen Schritt machen. Unterdessen näherte sich eine unheimliche Kreatur, die wie ein Wolf aussah. Zwischen ihnen lagen nur wenige Schritte. Jetzt sieht man schon die graue Wolle auf den Tatzen des Monsters, hier blitzten scharfe Krallen im Mondlicht auf ...
Magier entschieden. Formation
Nazimov Konstantin
Ausfälle

Ein Student, er ist überall ein Student. Unterhaltung und Versuche zu verdienen. Eines der üblichen Dinge führte zu einer Tragödie, und ich landete ... in der Welt der Magie. Viel Glück damit, hat mir gut gefallen. Sie halfen sogar und entpuppten sich als ... Schüler, aber schon an der Zauberakademie und machten sich an die Arbeit.

Aber das Leben dreht Menschen und Zauberer, wie es will. Diese Welt kannte den großen Intriganten nicht, mit seiner Fähigkeit, aus dem Nichts Geld zu machen. Niemand hat Finanzpyramiden gebaut. Daher kann ich mich voll und ganz umdrehen. Aber ernsthafte Probleme und Betrügereien sind verschwunden. Eine der Ideen stellte sich als so heraus, dass meine Freunde und ich das Ergebnis nicht verdauen konnten. Ich musste aus dem Weg gehen und die Dinge auf eine ganz andere Ebene bringen. Und es ist schwierig, es zu ziehen: Hier ist das Gold der Geldsäcke und die Gilde der Diebe, der einfachen Leute und der Bürokraten. Und auch Probleme mit Artefakten und Mädchen, Kartenschulden und schönen Autos. Sie müssen schnell entscheiden, sofort reagieren. Eh, aber ich möchte schön leben und ich hoffe, dass es klappt, obwohl es keine Tatsache ist ...
Dame in Weiß
Graue Lara
Detektive und Thriller, Thriller

Jeden Tag nach Mitternacht passiert etwas im Schloss...

Katerina verstand, dass ihr Leben an einem seidenen Faden hing. Sie griff mit einer Hand nach ihrem Rock, damit der Saum sie beim Laufen nicht störte, die andere Hand streckte sie nach vorne, um nicht mit dem Kopf gegen die Wand zu prallen. Endlich eine Tür! Das Mädchen öffnete sie abrupt und rannte aus dem Korridor. Der Verfolger blieb nicht zurück: Seine Schritte waren immer deutlicher zu hören. Er könnte Katerina jeden Moment einholen!

- Für Hilfe! Für Hilfe! schrie das Mädchen. - Jemand! Hilfe!

Sie stolperte über einen Stein, schlug hart auf und fiel zu Boden. Katerina kroch zur Seite und versteckte sich. Zum Glück war es dunkel und der Verfolger rannte vorbei, ohne sie zu bemerken. Katerina sah sich um: Sie lag in einem dunklen Raum ohne Fenster, ohne Licht, nichts war zu sehen...
Rennjoker. Überlebens Spiel
Nazimov Konstantin
Belletristik, Heldenliteratur

Das Spiel ist nicht so, wie ich es mir vorgestellt habe. Lüge und Verrat, Bestechung und sogar Sklaverei gehen hier Hand in Hand. Es gibt normale Spieler, von denen es viele gibt, die versuchen, nach den Regeln und der Ehre zu leben. Und es kommt auch vor, dass Schwarz als Weiß dargestellt wird, eine Lüge für die Wahrheit.

Durch den Willen des Netzwerkgeistes werden mir komplexe Aufgaben und Missionen gestellt, von denen ich nicht einmal ahnte. Ausscheidungs- oder Überlebensrennen werden durch die Flucht vor den Kopfgeldjägern ersetzt. Wir müssen in einen Showdown mit Ungerechtigkeit und Gemeinheit geraten. Das Leben gewöhnlicher Spieler zu verbessern, die in ihrer Leichtgläubigkeit und Naivität Versprechungen nachjagten und sich in einer aussichtslosen Situation befanden. Tauchen Sie in das benachbarte Weltenspiel ein, in dem sich Monster auf Schritt und Tritt treffen, und betrachten Sie Sie als ihre Beute. Ohne all dies können Sie die Ziellinie nicht erreichen.

Während des Spiels stehen Freunde und Feinde Seite an Seite mit mir, einige helfen in schwierigen Zeiten, andere sind bereit, mir ein Messer in den Rücken zu treiben, aber ich muss mich auf mich selbst und viel Glück verlassen. Ein Ziel ist gesetzt, Benzin wird in den Tank gegossen, ein Amulett hängt um den Hals und der Fuß drückt das Gaspedal auf den Boden. Der Sieg wird kommen und ich werde mein Ziel erreichen! Ich hoffe…
Geister aus dem Nebel
Mühle Alexandra
Zeitschriften

Bisher legte Elena keinen Wert darauf, dass der Besitzer des Gästehauses, in dem sie wohnte, die ganze Zeit allein war. Sie ging davon aus, dass seine Frau entweder in der Küche oder mit anderen Geschäften beschäftigt war und daher nicht vor den Gästen erschien ...

Set "Week" - Top-Neuheiten - Leader der Woche!

2. Verfluchter Rektor
Sommer Lena
Liebesromane , Liebesromane , Belletristik , Kriminalromane ,

Ich hatte ein Jahr zu beenden. Ein Jahr – und ich konnte die Freiheit und Unabhängigkeit bekommen, von der ich seit meiner Kindheit geträumt hatte. Doch der plötzliche und sehr verdächtige Tod meiner Mutter stellte meine Welt auf den Kopf. Sie hat viele Fragen hinterlassen, und die einzige Chance, Antworten zu finden, ist, an die elitärste Universität der Republik zu gehen. Ich dachte, dass der Snobismus neuer Klassenkameraden mein Hauptproblem sein würde, aber ich lag falsch. Die Antworten, nach denen ich suche, können mich mein Leben kosten, und aus irgendeinem Grund mache ich mir jetzt mehr Sorgen um das Leben des örtlichen Rektors, der unter einem Fluch steht.
Arcturus-Akademie. Wolf Braut
Linde Sylvia
Belletristik, humoristische Belletristik

Manchmal ist Verrat nicht das Ende, sondern der Anfang.

Gelegentlich ist dies die Tür zu einer anderen Welt, in der der Krieg an der Schwelle steht. Wo Werwölfe bis zum Tod für ihre Frauen kämpfen und Männer Gewehre mit Silberkugeln laden. Wo ein mysteriöser Mörder umherstreift und an den Kehlen von allen nagt, die dir so ähnlich sehen. Wo ein gutmütiges Lächeln eine sichere Chance ist, in eine Falle zu tappen, und ein Wolfsknurren hinter deinem Rücken eine Chance ist, zu entkommen.

Machen Sie sich bereit, die Akademie der Werwölfe wartet hier auf Sie, ein Wahnsinniger vor der Tür und ein mysteriöser Mann, der aus irgendeinem Grund beschlossen hat, nachts zu Ihnen zu kommen.

Und das alles, weil Verrat nicht das Ende ist, sondern nur der Anfang.
Arcturus Academy 2. Die Frau des Wolfs
Linde Sylvia
Fantasie, Cyberpunk

Sie sagen, dass Leben und Vertrauen nur einmal verloren gehen. Einmal hatte ich Glück, aber es ist unwahrscheinlich, dass sich das Glück wiederholt. Der Wahnsinnige, der die Mädchen tötet, wird gefunden, aber der Puppenspieler zieht immer noch die Fäden seiner Puppen. Der Tod folgt unerbittlich, und ich muss einen Schritt voraus sein. Dieses Mal, um nicht nur sich selbst zu retten, sondern auch den Werwolf, mit dem sie durch unzerbrechliche Bande verbunden ist. Er ist stärker als die anderen, und das ist seine Schwäche. Um ihn am Leben zu erhalten, muss ich ihn verraten. Oder gibt es einen anderen Ausweg?

Portal für den Studenten. Selbsttraining

* * *

Vorwort

Teil I Grundlagen

Kapitel 1 Das Dilemma des agilen Managers lösen

Das richtige Tempo finden

Auf der Suche nach erfolgreichem Change Management

Vom Trommelpufferseil bis zum Kanban

Die Entstehung der Kanban-Methode

Über den Autor

Anhand realer Beispiele aus dem Leben von Microsoft, Motorola und Corbis erzählte und zeigte er die Prinzipien, Methoden und Anleitungen zur Umsetzung von Kanban in einem Unternehmen.

Semantische Belastung und Essenz des Buches

Kaizen ist die Philosophie und Ethik der Beziehung zwischen Fabrikarbeitern und Management.

Lean Manufacturing ist ein Projektmanagementsystem, das bei Toyota entwickelt wurde, um jegliche Verschwendung von Zeit und Ressourcen aus den Prozessen des Unternehmens zu entfernen.

WIP-Limit (work in progress) – die Anzahl der Aufgaben, die gleichzeitig geöffnet sein können.

Engpass - ein Moment im Arbeitsablauf, in dem es ernst wird Begrenzung von Ressourcen oder Möglichkeiten. Auf den Diagrammen sieht es wirklich aus wie ein schmaler Flaschenhals: Sowohl vor als auch nach einer solchen Situation dehnen sich die Linien auf den Diagrammen aus.

Klischees über Kanban

Kanban ist kein Klebebrett, Aufkleber sind nur ein Indikator für die Arbeitsbelastung.

Agile, Scrum und Kanban

Agile ist eine agile Methodik, mit der das Programmieren in der Vergangenheit damit begann, alle paar Monate Updates für Programme bereitzustellen. Die Programmierung von Iterationen von ein paar Wochen, um jede Funktion hinzuzufügen, beschleunigt den Entwicklungsprozess und reduziert das Risiko.

Dieses Buch beantwortet die Fragen:

Das Frischeste! Buchen Sie noch heute Quittungen

Set "Week" - Top-Neuheiten - Leader der Woche!

ZUM THEMA PASSENDE ARTIKEL

Teil I
Grundlagen

Kapitel 1
Das Dilemma des agilen Managers lösen