敏捷架構的8個原則（下）

Jan. 07 20:57~22:45

 

今天介紹《Agile Software Requirements》這本書提到的8個敏捷架構原則的最後兩點。

***

原則7：There is no monopoly on innovation（沒有對於創新的壟斷）

在傳統開發方法中，軟體架構的創新設計一般交由架構師專門負責，開發人員僅是負責系統實作出來的「工人」。敏捷開發以團隊為中心，每個團隊成員都可以為軟體架構的創新做出貢獻，所以架構創新不會被所謂的「架構師」所包辦或壟斷。

用講的總是比較容易，要如何讓團隊培養創新能力呢？書中提到ㄧ種可能的方式，如下圖所示。

節錄自《Agile Software Requirements》

 

假設產品每8周釋出一次，iteration（sprint）為期兩周。前三個iteration是一般正常的開發iteration，最後兩周拆成兩個為期一周的hardening iteration（成形疊代或鍛鍊疊代）與innovation sprint。前者又稱為release iteration，用來為產品釋出前做最後的優化準備，例如消除技術債以及讓系統更加穩定。後者則是團隊成員的自由活動時間，只要該活動與公司的業務有關即可。

眼尖的鄉民可能看出這種做法有點mini-waterfall的味道，敏捷開發極端份子一般是不建議產品在釋出之前還有一個hardening iteration或release iteration，因為這代表每個iteration/sprint的產出物並不是真正的Done（沒有真正做完，還留了一些尾巴）。無論如何，當團隊的敏捷性還為到達理想狀態時，在產品釋出前預留一小段「收尾」的時間也是ㄧ種常見的權宜之計。

至於innovation sprint也是ㄧ種經常被提到的做法，讓團隊有一段連續的時間可以用來充電。另一種做法則是讓團隊成員在每個sprint有些slack（鬆弛時間），可用來做為技術精進之用。

***

原則8：Implement architectural flow（實作架構流）

這一條原則Teddy琢磨了老半天還是沒搞懂，書中提到團隊需要提供可視性（visibility）和透明性（transparency）、限制WIP、管理隊列（queue）長度等，以便建立與控制連續的架構更新流。

以上內容聽起來就是看板方法（Kanban Method）的翻版，因為這一點過於複雜，所以這本書特別另外加了一章來解釋，請參考下圖。

節錄自《Agile Software Requirements》

 

書中提了Architectural Epic Kanban System這個東東用來解釋原則8，稍微瞄了一下頭有點痛，已經超出Teddy腦力所能理解的範圍，改天看懂之後再來介紹。

***

友藏內心獨白：沒想到看板還能這樣子使用啊。