l

2015年1月9日 星期五

敏捷架構的8個原則(下)

Jan. 07 20:57~22:45

image

 

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

***

原則7:There is no monopoly on innovation(沒有對於創新的壟斷)

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

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

螢幕截圖 2015-01-07 21.38.37

節錄自《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)的翻版,因為這一點過於複雜,所以這本書特別另外加了一章來解釋,請參考下圖。

螢幕截圖 2015-01-07 22.52.32

節錄自《Agile Software Requirements》

 

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

***

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

1 則留言:

  1. 有的時候我在更新架構的時候經常會發生大翻版的狀況,這個時候會想要階段性Apply上去;事先訂定目標和階段以及每個階段會達成的效益(i.e. 當然還要效益驗證,有時候改錯方向了要修正);接著還要思考階段之間的平行運做的可能性(i.e. 考量人力資源和手邊Task數量),接著就會開始進行

    進行的時候每個階段要一鼓作氣,因為,如果改到一半會出現一堆神奇的Bug...不知道這個是不是符合第8條呢?

    回覆刪除