> For the complete documentation index, see [llms.txt](https://prof.aheil.de/devops/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prof.aheil.de/devops/lectures/04_kanban.md). # 04\_kanban ## DevOps - Kanban | Parameter | Kursinformationen | | ------------------------ | ------------------------------------------------------------------------------------------------------- | | **Veranstaltung:** | `262062 DevOps` | | **Semester** | `SEB4` | | **Hochschule:** | `Hochschule Heilbronn` | | **Inhalte:** | `Kanban` | | Startseite | | | **Link auf den GitHub:** | [https://github.com/aheil/devops/blob/main/lectures/04\_kanban.md](/devops/lectures/04_kanban.md) | | **Autoren** | @author | ### Ziele und Kompetenzen * Grundlegende Konzepte hinter Kanban **kennen lernen** * Unterschiede (Vor- und Nachteile) gegenüber anderen agilen Ansätzen **verstehen** * **Verstehen** wann Kanban vorzugsweise eingesetzt werden kann ### Kanban Ursprung * Jap. *kan* 看 (sichtbar) und *ban* 板 (Karte o.d Brett) * Konzepte entstammen dem Toyota Production System (TSP) * Konkret: Just-in-Time Scheduling System * Nur »machen« was benötigt wird * Nur »machen« wenn es benötigt wird * Nur »machen« wieviel benötigt wird Kanban System wurde sowohl für die Produktion als die Software Entwicklung adaptiert. {{1}} *** **Toyota Kanban** > The kanban, a tool that describes **which and how many parts are used where and when, made just-in-time production possible**. The new kanban management system was adopted at all plants in 1963. By producing parts in accordance with the instructions on the kanban, **parts are delivered among the different plants only in the volumes needed, and inventories within each process can be eliminated**. As kanban came into widespread use, problems such as standardization of work and transport management were resolved one after another and production lines operated smoothly. *** {{2}} *** **Drei Prinzipien** * Visualize * Limit Work in Progress * Manage Flow *** ### Das Kanban Board **Visualisierung** * Information Fridge * Muss immer wieder geöffnet werden, um nachzuschauen ob „etwas Neues drin ist“ * Klassische Ticket-Systeme, digitale Boards etc. * Information Radiator * Große sichtbare Displays * Für das eigene Team und alle Interessierten * Aktualisierungen möglichst einfach halten * So groß wie möglich!!! * »Use it or lose it!« {{1}} *** **Beispielboard** ![](https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2Fgit-blob-40dd22fc78a4a8807cbe0ba47e36dda660f676fb%2Fdevops.04.board.jpg?alt=media) Bildquelle: Rakuten Inc., , CC BY-SA 3.0 () *** {{2}} *** **Kanban Board - Tipps** * Große Boards verwenden (s. Information Radiator) * Digitale und physische Boards haben beide Vor- und Nachteile * Bei ungeübten Teams möglichst physische Boards nutzen * Regelmäßige Stand-Ups (Daily Stand-Up) * Den Workflow anpassen, das Board reflektiert den aktuellen Workflow im Team * Der Workflow kommt nicht vom Management, sondern vom Team * Nicht zu viele Gedanken machen, Änderungen willkommen heißen *** {{3}} *** **Kanban Board - Beispielaufbau** ![](https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2Fgit-blob-afe8f8bbe565f7efefa5f18a74d209e305274079%2Fdevops.04.board_aufbau.png?alt=media) *** {{4}} *** **Enter- & Exit-Kriterien** ![](https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2Fgit-blob-8ce9bbde2a678b61d01ef2841a7d0bba7fd0838d%2Fdevops.04.enter_exit_criteria.png?alt=media) *** {{5}} *** **Priorisierung** * Anders als in Scrum: * Priorisierung kann fortwährend erfolgen * Täglich, u.U. auch wöchentlich oder zwei-wöchentlich * Reihenfolge der Tickets am Board spiegelt die Priorität wieder * Es wird immer das am höchsten priorisierte Ticket gezogen * No-Go: Ticket ziehen, das einem am meisten Spaß macht *** ### Work in Progress * Abk.: WiP * Beinhaltet alle begonnen aber noch nicht abgeschlossenen Aufgaben * Auch alle Aufgaben, an denen gerade nicht gearbeitet wird * Auch alle Aufgaben, für die gerade auf Zuarbeit geartet wird * WiP-Limit * Anzahl an gerade in Bearbeitung befindlicher Aufgaben limitieren * Anzahl der Tickets * Typischerweise pro Spalte (in Bearbeitung, Test, Abnahme etc.) {{1}} *** **Little's Law** * Ursprung: John D.C. Little * In den 1950ern einfach angenommen * Erst Ende der 1960er bewiesen * Bedeutung: Je mehr gleichzeitig bearbeitet wird, desto länger dauert die Fertigstellung aller »Work Items« ![center](https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2Fgit-blob-3e8edfd7d8fc92506121fc60e7d4fd507483e1ef%2Fdevops.04.littleslaw.png?alt=media) *** {{2}} *** **Auswirkung von Parallelität** ![](https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2Fgit-blob-1f8585a1bae8481269052646db7173a438dd0d16%2Fdevops.04.parallelitaet.png?alt=media) *** {{3}} *** **WiP-Limit** ![](https://1352029815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FobQn6v8Z1iiTuGdkOJUH%2Fuploads%2Fgit-blob-b8f430031e9993fdfc72fff58e2008f3b1daffba%2Fdevops.04.sequentiel.png?alt=media) *** {{4}} *** **WiP-Limit Wisdoms** * Es gibt keine »goldene Regel« * Beobachten und anpassen * Guter Ansatz: »Stop starting, start finishing « * Beispiel 1: Um Pairing zu forcieren kann ein WiP-Limit von $Teamgröße -1$ gewählt werden * Beispiel 2: Existieren z.B. externe Abhängigkeiten (=Wartezeiten) kann ein WiP-Limit von $Teamgröße \cdot 2$ gewählt werden um Wartezeiten (engl. idle time) zu vermeiden * Beispiel 3: … *** {{5}} *** **Praxis Tipps** * Durchsatz erhöhen * Verschwendung (jap. *muda* 無駄) z.B. durch Wartezeiten oder Blocker vermeiden * Probleme schnell lösen * Kanban ermöglicht häufig Priorisierung (signifikanter Unterschied zu Scrum) * Geeignet für kleine und bekannte Arbeitseinheiten (z.B. im Ops-Umfeld) * Schlechter für Entwicklung, da Aufgaben geschätzt werden müssen * WiP-Limits einhalten *** ## Referenzen