之前我有介紹微軟如何執行 agile (http://www.wretch.cc/blog/kojenchieh/15331734), 那時候有提到 feature crew, 現在又找到一篇來印證, 讓我更進一步了解他的做法, 也發現大家講的都很一致.
作者提到在微軟裡面, 大家都知道他們公司很大, 要處理的 featues 也很多(作者說大約有 1200 個個別的 features), 那他們怎麼做, 可以讓這樣龐大機器運作. 它們的解法就是 feature crew. 並且這個解法已經在 MS Office 團隊運作多年, 所以看起來並不是只是理論而已.
(1) Working process
當一個 feature crew 被 assign 一個 feature 時, 大概會做以下的事情:
- 從 main source 中create一個branch, 已產生一個獨立的環境來建置這個 feature
- 當 feature crew 在開發時會有2個checkpoints. 第一個是 design review. feature crew 必須說明它們如何規劃來解決問題
- 第二個檢查點是 demo. 展示它們所做出來的結果
- 接來下 feature crew 會把 main source 的東西整合到 branch 的 source.
- 然後他們會進行檢查, 確認他們是否滿足 quality gates 的條件.
- 如果都沒問題, feature crew 才會把branch 的 source 整合回 main source 中
- 從 main source 中create一個branch, 已產生一個獨立的環境來建置這個 feature
- 當 feature crew 在開發時會有2個checkpoints. 第一個是 design review. feature crew 必須說明它們如何規劃來解決問題
- 第二個檢查點是 demo. 展示它們所做出來的結果
- 接來下 feature crew 會把 main source 的東西整合到 branch 的 source.
- 然後他們會進行檢查, 確認他們是否滿足 quality gates 的條件.
- 如果都沒問題, feature crew 才會把branch 的 source 整合回 main source 中
(通常他們會在4-6周做完這件事情)
(2) Quality gate
微軟訂了 16 不同的 quality gates, 來確定是否 feature 已經被做完. 其中有幾項是:
- security plan
- static code analysis
- code coverage
- no performance regressions
- localization testing
- API review
- All bugs fixed
- security plan
- static code analysis
- code coverage
- no performance regressions
- localization testing
- API review
- All bugs fixed
不過作者提到在這麼大的團隊中, 為了讓大家可以全速進行, 這樣的 quality gates 訂好, 是有幫助專案維持一致的品質水準.
參考文獻: How Microsoft/DevDiv uses TFS - Chapter 2 (Feature Crews)
全站熱搜
留言列表
