騰訊TAPD合作夠格：敏捷開發

(1)客戶介紹

最近兩年在創業的道路上，認識一位新朋友——TAPD。我稱呼ta為“T先生”。“T先生 ”就是專程出現為我們解決創業過程中敏捷開發難題的。與“T先生 ”結緣，相處甚久后，尤其認識到“T先生 ”帶來的便利。下面我就結合“夠格”這個項目的實戰過程簡單介紹“T先生 ”為我們這個創業團隊帶來什么。

 

(2)項目背景

 

夠格是一個做“直播+電商”領域的創業項目，產品分布在Android/iOS/網頁端/PC端等多系統多平臺。整個項目采用敏捷開發、版本迭代的過程在跑。產品至今上線一年時間，版本迭代將近20次。基本保持每1-2周一次迭代的過程。整個研發團隊近20人，包括產品/項目經理共3人、設計2人、測試2人，其余為開發團隊。

 

說起創業公司，在創業初期面臨的一個比較大的痛點，莫過于如何實現高效低成本的項目管理模式——小步快跑、快速迭代？如何將研發團隊有效組織起來，在可控、可視化的范圍類進行產品版本迭代更新？

 

和很多創業公司一樣，整個團隊初期在項目管理上使用過任務看板、每日站會、計劃紙牌等線下手段進行項目管理，這也是比較常見的項目管理手段，因為這種方式會更加便捷，沒有“套路”，能讓人一目了然、快速看到現在在發生什么、未來將要發生什么。

 

但是這里會存在以下幾個難題：

1、人工線下操作、記錄粘貼耗費時間和精力；

2、修改刪除麻煩，不方便隨時更新；

3、歷史記錄看不到，無法回顧歷史數據；

4、子任務拆分不方便，拆分后無法修改；

5、對人員管理不便，隨著團隊擴張，操作越來越困難。

 

 

耗費時間和精力

最初大家還是愿意接受線下手工的方式寫字操作各自任務記錄，后面每人每日都要花費大量時間手寫任務列表，進行卡片粘貼。到最后整個團隊都覺得這樣寫起來很麻煩，逐漸放棄了手動寫的過程，轉而進入TAPD進行系統自動管理。

 

更新刪除麻煩

團隊每個人每天都需要對今天完成的任務進行更新，多數時候當大家拿起筆去更新時重寫內容時就開始愁苦。寫了一天代碼要下班了還得重新寫字更新今日任務，尤其碰到需要刪除重新的需求任務更是崩潰。

 

歷史記錄找不到

每天只能看到當天完成了什么，昨天完成了什么。當整張墻貼的密密麻麻時，想找一個人任務時，眼睛都要瞅半天。此時大家真想有個“搜索”功能。尤其在每期迭代結束后，統計每個人任務進度時，簡直要崩潰。此時多希望有個工具能幫我做這件事。

 

子任務拆分不方便

產品需求永遠都會拆分子任務，研發在開發時也需要拆分更細的子任務。此時自己用人工的方法來做就顯得特別麻煩，尤其拆好的子任務要做拆分修改時，更是麻煩。

 

人員管理麻煩

我們當初整個看板名字是固定的，隨著后續有新同事進來，舊同事離開，整個看板都需要更新。這時就需要把看板上的所有任務全部清除后再重新布局。

 

在認識“T先生”后，整個研發團隊的迭代節奏明顯加快許多，原先將近兩周才完成的迭代、現在相同任務量縮短到一周。每日晨會、站會時間也由半小時縮短到15分鐘。研發團隊每日下班的時由原先花費將近10分鐘更新今日任務的時間，縮短至1-2分鐘搞定下班回家。

 

(3)解決方案

說到“T先生”究竟為什么方便了團隊在敏捷開發過程中的使用，這里需要先說我們團隊的產品研發節奏。整個產品研發的迭代順序大致是“需求收集 - 需求分析 - 功能策劃 - 原型設計 - 需求評審排期 - 開發階段  - 測試階段 - 上線階段”，這里實現一個完整的迭代。在TAPD上，我們使用其提供的豐富功能實現項目管理效率的提升和節奏的把控。

 

 

需求收集階段

我們會在TAPD上建立一個“需求池 ”，產品會將收集來的各方面需求收錄到池子里。利用TAPD提供的需求分類功能，會對池子里的需求進行分類管理，比如APP端需求、運營需求、網頁端需求等等。定期對需求池中的需求進行合并刪減。

 

 

需求分析階段

對建立的“需求池”，產品對定期進行評估，利用TAPD提供的優先級和重要性功能 一一對其進行標記。對標記重要和高優先級的需求，會利用TAPD提供的迭代管理功能，創建新迭代，并關聯該迭代。

 

 

功能策劃階段

確定要做的需求，需要從產品功能層面對其進行任務拆分，利用TAPD提供的快速創建子任務功能， 拆分出多個子功能模塊，逐一進行策劃，并快速關聯該功能負責人。對應該負責人即可實時跟進任務進度，進行策劃。此外還可以利用TAPD的關聯父需求功能，快速對新任務進行父需求關聯，分類排版一目了然。

 

 

原型設計階段

“T先生”提供實時更新設計好的原型和交互說明，只需要復制粘貼就可以修改需求任務說明。其中最大的便捷便是只需更新一個任務，就能實時更新所有“復制”該需求的任務。設計師也可以實時同步TAPD提供附件功能，將設計稿關聯上去，方便同步設計稿文件。

 

 

需求評審排期

需求評審會上，只需要打開“T先生”就可以跟研發同學一起過需求評審，遇到對某個需求的疑問可以實時在上面備注修改。需求過完，即可以接著排出每個需求對應的開發人員、測試人員、開發周期、測試周期。整個需求評審會結束后，“T先生”就能為我們展現這期迭代的全景picture，包括對應需求、子任務、對應負責人、開發人員、測試人員、開發周期、上線時間。

 

 

開發階段

開發人員只需按照每個子任務的排期時間，每日晨會對著TAPD看板就可以一目了然知道當前進度是否延期或提前，能提前避免遇到的項目風險問題。每日只需要在上下班時修改對應任務的進度狀態，就可以實時同步給所有人。完成開發即可提測給測試人員。

 

 

測試階段

測試人員根據TAPD的需求內容可提前編寫測試用例，更新到每個任務下。開發人員即可實時同步看到該功能測試范圍和要求。在提測后，測試人員能及時將測出的bug同步到TAPD提供的bug庫里，關聯給對應的開發人員。對bug進行統一管理，不遺漏。

 

 

上線階段

當所有任務測試 完成后，即可上線。上線前產品、運營都可以在看板中列出上線checklist，對應指定負責人員。一項項檢查管理，確保上線工作準備充分。

 

 

以上只是從夠格的實戰項目中介紹了“T先生”在項目迭代過程中帶來的便處。

(4)價值體現

除此之外，TAPD提供的版本記錄和歷史操作能在幫助更好地進行操作記錄和刪除操作管理。項目報表和故事墻能剛好的對項目整體進行數據分析和節奏把控的管理。Wiki能幫助進行團隊知識、規則、流程的沉淀。自定義字段、狀態流轉能更方便開發和測試人員進行任務管理。項目團隊邀請、人員一鍵搜索可輕松實現團隊成員增刪修改。

 

現在我們不僅在產品研發團隊使用“T先生”進行研發項目的管理。我們同時將運營部門、商務部門也按照迭代的模式在“T先生”上進行統一管理，讓各部門之間信息互相同步，實時了解公司整體發展進度。