騰訊敏捷框架TAPD》研究

這篇文檔是研究心得,有些部分是自己的發揮,請搭配《騰訊敏捷框架TAPD》原文進行閱讀,注意甄別原文和感想。

1         框架結構

1.1         產品

TAPD採用FDD模式開發,FDD即特徵驅動開發。

FDD的核心是面向產品的功能點,但這個功能點是從客戶角度出發的,並不是從系統角度出來的。功能點是用一個短句描述出一個業務需求,而這個業務需求的粒度是按開發時間來衡量的(一般不超過兩個星期)。

特徵與用例的相似之處是,兩者都可以用短句(動賓短語)來描述;兩者的不同之處在於,用例用UML的用例圖來表示,而特徵是用四色原型(類圖)來表示。

注意,TAPD只是參考了FDD,不是完全的FDD。所有的開發團隊都是由產品經理所歸納出來的產品特性去驅動整個產品的研發。

產品經理這個角色有點ScrumProduct Owner的味道。但產品特性和backlog相差甚遠,因爲產品特性只是一個動賓短語,而backlog卻是一個完整的故事(story),包括一系列的元素:

1.        ID(統一標示)

2.        Name(名稱)

3.        Imp(重要程度)

4.        Est(初始估算)

5.        How to demo(如何做演示)

6.        Notes(其它)

 

1.2         項目管理過程

TAPD參考了Scrum,項目管理過程同Scrum的過程比較類似,包括每天的晨會、迭代、timebox、每個迭代之後會有showcase、回顧總結等。

Scrum中的timebox是指迭代要有固定的時長,不能超過六個星期。

1.3         開發實踐

參考了很多XP的實踐,因爲XP的完整實踐比較“理想化”,所以只採納了某些部分,比如自動化測試和持續集成。

2         框架實現

2.1         故事牆

把正在開發的系統功能與在白板上,讓團隊所有成員都知道大家在做什麼。

寫在白板上比用Excel或者其它工具管理好,因爲寫在白板上讓人感覺更緊迫、更正式、更一目瞭然,有一種別人在監督、在注視的感覺——增加適當的壓力並不是壞事。

2.2         每日晨會

晨會上每個人的發言不超過3分鐘爲宜,整個會議15分鐘爲宜。這是按照5人團隊來制定的。如果團隊人數超過5人,甚至達到10人、20人,那麼建議成立兩個團隊。

Scrum的晨會是站立着開的,一方面是爲了不讓會議拖沓,另一方面也是爲了讓大家注意力集中(如果坐下肯定有人會順便打開電腦,然後開始上網)。

在每天的晨會上,團隊成員每人都敘述對昨天的工作做一個總結,總結由Scrum Master記錄在白板上。

總結的內容包括:

1.        工作完成的情況。只需要選擇以下狀態即可:未開始、正在開發、已完成。

2.        工作遇到的難點(如果未按時完成);工作中值得注意的地方(可以是系統框架的體會、業務的特殊性、封裝了哪些公共功能等)。

3.        今天要做什麼(如果昨天的工作已完成)。

 

當某人遇到問題的時候,其他成員如果有解決辦法或者建議,那麼可以“舉手”,但不用說出解決的辦法,由Scrum Master安排兩人結對編程。

2.3         時間盒

一切任務都有timeboxScrum的時間盒最長可以達到6個星期(一個半月),感覺太長了,建議時間盒按照FDD的建議,不超過兩個星期爲宜(半個月)。

2.4         一個完整的迭代過程

包括分析、設計、開發、測試和發佈五個過程。

1.        分析過程決定了本次迭代過程的工作目標(系統要達到什麼效果)、工作內容(FDD的功能點)、發佈日期。

2.        設計過程採用快速原型法。快速原型法對業務複雜度不高,着重客戶體驗的項目有着很好的效果。

3.        系統後臺(業務模型)的設計,無論是採用數據庫模型還是領域模型,都由主力程序員/系統架構師負責。之所以要主力程序員全程設計,是因爲他要走讀(review)其他人的代碼,在沒有理解設計思路的情況下,是無法review的。而且成員的水平和風格參差不齊,每個人都參與設計,最後一定會亂套。

4.        做好測試計劃,除了猴子測試,還要有業務模擬測試。

5.        提倡單元測試,爲以後自動化測試做準備。

6.        考慮到TDD太複雜,需要面向接口編程的思想,以及轉換原來的編碼思想,並非短時間內能改變,所以不強制使用。

7.        使用持續集成。持續集成除了降低代碼合併的成本,還保障了提交上來的代碼至少在語法上是可以通過的,不會導致別人下載了新版本的代碼之後編譯失敗。

 

其中分析、設計、開發、測試、發佈這五個過程可以內部再迭代,而且這五個過程不是分階段開展的,即不是分析完了之後才設計,全部設計完了纔開發,開發結束了才測試,測試通過了才發佈。而是邊分析邊設計——在業務不復雜的情況下,這是可行的——邊設計邊開發,開發完一個功能就測試一個功能,同時開發下一個功能。

考慮到小團隊不會配備專人測試,所以可以直接讓客戶進行測試,即測試與發佈(不是最終發佈)合併,由客戶決定是否測試通過(最終發佈)。

2.5         灰度發佈

發佈並不是一口氣全面鋪開,所有用戶同時使用,面是先挑出有代表性的用戶試用。

2.6         迭代總結

每一次系統發佈的時候都會有一個總結,把做得好的發揚光大,做得不好的注意改進。總結是團隊所有成員都參加,並且需要記錄所有發言,會後發給每個人。

2.7         用戶研究

這是騰訊,或者說是網站建設的獨有特點。

 
 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章