Planig

Plan si d'Kanban Produktentwicklung

Mir müesched über Pläne reded. E vo de grösste Missverständnis über Agile isch, dass me kei Pläne mache cha. Es isch nöd wahr. Du chasch nume kei detaillierti langfrischtigi Pläne mache, wo streng gfolgt wärde muesed.

Einer Art, das z'behandled, isch, nöd Gantt-Charts oder Excel-Lischt mit Ufgabä, Deadlines und Zuewiesig z'mache. Wenn du's tuesch – du bisch enttüscht. E vo de Nachteil mit em Fierig vo eme Agile Kanban-Projekt isch, dass du nöd genau sage chasch, wann Sache fertig und veröffentligt wärded.

Wenn du's tuesch, nimmt's wahrschinlich länger Zit, will du's ahalte muesssch, Entwickler dediziere muesssch und Business-Besitzer warted, wo die gläubisch und die dure foadere. Kanban isch anders, will's vo Zuestand zu Zuestand in eme Tempo bewegt, wo em Verarbeitigstempo vo de andere im System entspricht.

Wenn du drängisch, bisch du a de verschidnige Statione gschtäut und schaffe somit Verschwendung. Es nimmt nume länger, bis's veröffentligt wärded.

Es cha bestimmti Merkmol gäh, wo du nöd jede Tag veröffentliche möchtisch. Du chasch si no witerhin veröffentliche, indem du Feature-Flagg oder ähnliche Funktionalität verwendsch. Es isch im Grunde e chliini Administrationssystem oder e Code-Feature, wo du Merkmol für e selektierti Gruppe oder spezifisch Kundschaft aktiviere chasch, wenn's nötig isch.

Das isch, wie du Produktbesitzer und Kanban-Evangelischt glücklich macht. Es cha wunderlich klinge, dass du ungenutzte Merkmol in de Hauptcode-Branch sitzed und somit veröffentlicht hesch, aber solang si guet verwaltet und aktiv bearbeitet wärded, will se vom Produktbesitzer promuviert und kommuniziert wärded, isch's in Ordnung. Ansonsten isch's no meh Verschwendung.

Lueg meh in "D'CTO-Spielbuch" (The CTO Playbook), verfügbar uf Amazon/Kindle.