Member-only story
Kanban實務做法 (下)
理論和應用的交集
大概從今年2月算起，我開始每兩周就寫一篇文章，撰寫我對於敏捷方法的心得以及經驗分享，稍微回顧了一下，除了解說目前在科技產業較為流行的方法外，有部分涉及個人敏捷經驗談，以及少許技術類型文章，後者的深度更是我後續想要分享出來的，因為許多社群容易停留在敏捷管理的各式方法論和工具，但深入的技法卻較少人在談論，不然就是散佈在各式論壇中。
以軟體開發為例，敏捷方法除了一般大家聽過的管理框架外，其實還包含了設計模式、測試理論、軟體架構、物件導向分析與設計、精實開發等實務應用的問題，這些才是在實際場域中撐起敏捷精神的應用作法，目前也是極少數的業界前輩會將這些東西統合起來，會被寫下來的也躺在幾百頁的原文書裡，乏人問津，或者藏在長達數小時的演講橋段中。
這也是我覺得許多好理論無法持續傳承或爛尾的原因之一了，因為懂得管理專案的人不一定有足夠的背景知識將這些實務技巧逐步融入工作中，懂得部分實務的人則是不懂得透過敏捷的框架讓好方法逐步感染團隊，當人員流動容易造成斷層。
實務操練
暨上一篇我提及前3項Kanban的實務做法，今天要續談後面另外3項作法，分別是
- 政策透明 (Make Policies Explicit)
大家可能對於朝令夕改恨之入骨，管理決策的透明度容易影響看板管理的品質，特別是看板方法本身並沒有迭代的概念，如果某些團隊的規範沒有明確地被釐清，其實容易引發不必要的誤會，例如: 沒有明確的會議時間、各階段缺乏完成標準、未限制WIP工作過量等等。
在看板方法中其實沒有明確的規範所謂明確的政策應該要長什麼樣，或者是怎麼作，但基本的原則是所規範的準則必須是所有關係人共同擬定的，這樣子的運作才有可能讓團隊朝向自我組織 (self-organized)邁進，而非傳統主僕式領導的模樣。
在Scrum裡面我們有提過DoD (Definition of Done) 的概念，主要是用以界定待辦項目是否合乎潛在可釋出 (potentially-releasable) 的標準，退一步來想，看板的這項原則其實可以視為DoD的擴大解釋版，也就是說，規則的制定不再僅僅是為了檢視項目本身，而是能夠擴及到大至團隊運作，小至項目釋出標準的粒度。
- 實踐回饋循環 (Implement Feedback Loops)
