《騰訊敏捷框架TAPD》研究

2022-01-11 13:10:14 字數 2710 閱讀 7696

tapd

》研究

tapd

》原文進行閱讀,注意甄別原文和感想。

tapd

採用fdd

模式開發,

fdd即特徵驅動開發。

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

特徵與用例的相似之處是,兩者都可以用短句(動賓短語)來描述;兩者的不同之處在於,用例用

uml的用例圖來表示,而特徵是用四色原型(類圖)來表示。

注意,tapd

只是參考了

fdd,不是完全的

fdd。所有的開發團隊都是由產品經理所歸納出來的產品特性去驅動整個產品的研發。

產品經理這個角色有點

scrum

的product owner

的味道。但產品特性和

backlog

相差甚遠,因為產品特性只是乙個動賓短語,而

backlog

卻是乙個完整的故事(

story

),包括一系列的元素:

1.id

(統一標示)

2.name

(名稱)

3.imp

(重要程度)

4.est

(初始估算)

5.how to demo

(如何做演示)

6.notes

(其它)

tapd

參考了scrum

,專案管理過程同

scrum

的過程比較類似,包括每天的晨會、迭代、

timebox

、每個迭代之後會有

showcase

、回顧總結等。

scrum

中的timebox

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

參考了很多

xp的實踐,因為

xp的完整實踐比較「理想化」,所以只採納了某些部分,比如自動化測試和持續整合。

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

寫在白板上比用

excel

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

晨會上每個人的發言不超過

3分鐘為宜,整個會議

15分鐘為宜。這是按照

5人團隊來制定的。如果團隊人數超過

5人,甚至達到

10人、

20人,那麼建議成立兩個團隊。

scrum

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

在每天的晨會上,團隊成員每人都敘述對昨天的工作做乙個總結,總結由

scrum master

記錄在白板上。

總結的內容包括:

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

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

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

當某人遇到問題的時候,其他成員如果有解決辦法或者建議,那麼可以「舉手」,但不用說出解決的辦法,由

scrum master

安排兩人結對程式設計。

一切任務都有

timebox

。scrum

的時間盒最長可以達到

6個星期(乙個半月),感覺太長了,建議時間盒按照

fdd的建議,不超過兩個星期為宜(半個月)。

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

1.分析過程決定了本次迭代過程的工作目標(系統要達到什麼效果)、工作內容(

fdd的功能點)、發布日期。

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

3.系統後台(業務模型)的設計,無論是採用資料庫模型還是領域模型,都由主力程式設計師

/系統架構師負責。之所以要主力程式設計師全程設計,是因為他要走讀(

review

)其他人的**,在沒有理解設計思路的情況下,是無法

review

的。而且成員的水平和風格參差不齊,每個人都參與設計,最後一定會亂套。

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

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

6.考慮到

tdd太複雜,需要面向介面程式設計的思想,以及轉換原來的編碼思想,並非短時間內能改變,所以不強制使用。

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

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

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

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

騰訊敏捷框架TAPD》研究

tapd 原文進行閱讀,注意甄別原文和感想。tapd 採用fdd 模式開發,fdd即特徵驅動開發。fdd的核心是面向產品的功能點,但這個功能點是從客戶角度出發的,並不是從系統角度出來的。功能點是用乙個短句描述出乙個業務需求,而這個業務需求的粒度是按開發時間來衡量的 一般不超過兩個星期 特徵與用例的相...

騰訊敏捷框架TAPD

tencent agile product development 就是白板story wall,平時工作中很多團隊都會使用,這些團隊會把每天開發的一些產品特性採用story的方式每天都在白板裡面展示出來,整個團隊每天都會圍繞這個白板能夠清晰的看到整個產品或者整個專案的乙個過程,包括整個產品特性的過...

關於騰訊敏捷框架TAPD ZZ

企業,網際網路行業有其鮮明的特點 1 關注使用者行為 3 需求不確定性高 4 快速適應變化 5 快魚吃慢魚 3個部分 1上引入了類似fdd這樣的模式,但是也不完全是fdd,只是參考fdd,所有的開發團隊都是由產品經理所歸納出來的產品特性去驅動整個產品的研發。2 專案管理3和持續整合,通過這樣的實踐就...