這是一次一個(gè)面向老板出產(chǎn)品的經(jīng)歷崔梗。一個(gè)傳統(tǒng)互聯(lián)網(wǎng)公司想要轉(zhuǎn)型成移動(dòng)互聯(lián)網(wǎng)公司的關(guān)鍵節(jié)點(diǎn)上蒜魄，當(dāng)時(shí)經(jīng)過很長一段時(shí)間的產(chǎn)品調(diào)研和業(yè)務(wù)流程的梳理旅挤，每次會(huì)上都會(huì)有近十個(gè)總監(jiān)級別的各個(gè)部門老大伞鲫。由于每次意見不統(tǒng)一，僵持不下儒搭，導(dǎo)致產(chǎn)品一拖再拖搂鲫。最后老板迫于壓力魂仍，在4月1日給出了一個(gè)命令擦酌，必須在4月20號做出來一個(gè)能看的產(chǎn)品媒吗。迫于無奈闸英，在4月10日進(jìn)行封閉式開發(fā)甫何。9天的時(shí)間完成了一個(gè)電商類型的小程序以及面向酒店和公司的兩個(gè)后臺系統(tǒng)捶牢。

正是在這樣的情況下巍耗，才能夠體會(huì)到敏捷開發(fā)小而快思想的精髓炬太。

第一點(diǎn)，我們遇到的問題

盡管炒考，前期我們有進(jìn)行一個(gè)相對比較長的研究斋枢，但是并沒有梳理形成一個(gè)完整體系瓤帚。在整個(gè)研討會(huì)上，也沒有形成一個(gè)明確的產(chǎn)品目標(biāo)以及產(chǎn)品的形態(tài)轰胁。以至于一直停留在梳理業(yè)務(wù)流程上，沒有一個(gè)比較實(shí)質(zhì)的進(jìn)展霎肯，即產(chǎn)品原型搂捧、產(chǎn)品架構(gòu)幾乎空白懂缕。面向老總出產(chǎn)品最尷尬的是他們不在意后臺系統(tǒng)聋丝，也就是他們往往會(huì)忽略后臺系統(tǒng)的工作量弱睦。

公司又面臨了資金緊張裁員况木、UI團(tuán)隊(duì)需要多方共用火惊，一些系列問題屹耐。

總結(jié)一下我們遇到的問題：

• 產(chǎn)品設(shè)計(jì)幾乎需要從0開始

• 大量的后臺系統(tǒng)開發(fā)工作量沒有被正確評估

• 研發(fā)團(tuán)隊(duì)人數(shù)不過

• UI團(tuán)隊(duì)無法All In

以上的問題张症，當(dāng)我們一起討論分析俗他，如果想要快速滿足老板的需求兆衅，必須進(jìn)行封閉式開發(fā)摩疑，而且整個(gè)團(tuán)隊(duì)需要嚴(yán)格的控制和監(jiān)管畏铆，降低風(fēng)險(xiǎn)楷怒。那么就必須要有一個(gè)更高效的協(xié)作方式來完成目標(biāo)瓦灶。所以贼陶，我們選擇使用敏捷開發(fā)的團(tuán)隊(duì)協(xié)作方式碉怔。

第二點(diǎn)庙楚，什么是敏捷開發(fā)

敏捷開發(fā)(Agile Development)是一種以人為核心馒闷、迭代纳账、循序漸進(jìn)的開發(fā)方法疏虫。通過快速卧秘、高效的反應(yīng)速度，積極官扣、高頻的溝通為客戶提供一條暢通的指揮通道翅敌。開發(fā)方式一般分為Scrum和XP。

Scrum： 團(tuán)隊(duì)最佳人數(shù)控制在5～9人惕蹄，一個(gè)迭代為四周時(shí)間蚯涮，不允許需求的變更治专。

image

XP：更側(cè)重于測試驅(qū)動(dòng)開發(fā)，一般迭代為1到2個(gè)星期遭顶，允許等量工作量的需求替換张峰。

image

在整個(gè)開發(fā)過程中，因?yàn)榧夹g(shù)團(tuán)隊(duì)棒旗、產(chǎn)品團(tuán)隊(duì)的成熟度還不高谤祖，無法提供完整的XP模式開發(fā)方式、而項(xiàng)目有偏向于使用XP模式旁舰。綜合考慮，我們在Scrum和XP模式下吸取各自的優(yōu)點(diǎn)：

• 允許中途變更等量的需求竹捉，因?yàn)樵谡麄€(gè)過程中憨闰，很有可能面臨老板的新需求训裆，必須做到快速響應(yīng)变姨；

• 嚴(yán)格按照優(yōu)先級進(jìn)行開發(fā)砍鸠，因?yàn)闀r(shí)間短饭弓，User Story之間很有可能存在依賴關(guān)系阀趴，如果沒有按照優(yōu)先級進(jìn)行開發(fā)很容易導(dǎo)致團(tuán)隊(duì)有些成員很忙，有些成員符合無法達(dá)到飽和；

• 采用產(chǎn)品經(jīng)理驅(qū)動(dòng)項(xiàng)目進(jìn)度瑰钮，而不是使用TDD模式，主要原因是因?yàn)檎麄€(gè)技術(shù)團(tuán)隊(duì)在TDD模式上未實(shí)踐過無法做到自我管理的程度，只能通過產(chǎn)品經(jīng)理人肉測試和項(xiàng)目跟進(jìn)腾么；

第三點(diǎn)阻课，我們怎么選定工具

敏捷開發(fā)是一種快速響應(yīng)需求的開發(fā)方式，不同于傳統(tǒng)的瀑布式開發(fā)，在管理流程上也就不同瞳别。產(chǎn)品經(jīng)理通過采集需求，整理出產(chǎn)品需求池（Product Backlog）历谍，然后輸出到研發(fā)團(tuán)隊(duì)進(jìn)行工作量評估乍构、實(shí)現(xiàn)可行性，最后根據(jù)優(yōu)先級進(jìn)入到迭代需求池（Sprint Backlog）進(jìn)行一輪迭代已旧。

再通過每天的站立會(huì)進(jìn)行對需求完成情況的審核璃诀，控制風(fēng)險(xiǎn)。以下是一個(gè)完整的產(chǎn)品迭代的過程弛作。

image

通過什么會(huì)議進(jìn)行管理有鹿？

通常情況下废麻，一個(gè)敏捷開發(fā)需要以下的會(huì)議來把控研發(fā)的進(jìn)度：

• Sprint 需求規(guī)劃會(huì)議

• 項(xiàng)目立項(xiàng)需求同步會(huì)

• Sprint 功能規(guī)劃會(huì)議

• 估算會(huì)議——根據(jù)項(xiàng)目情況合并到 Sprint功能規(guī)劃會(huì)議

• 每日立會(huì)

• Sprint 評審會(huì)議（Review Meeting）——根據(jù)項(xiàng)目需要舉行

• 項(xiàng)目復(fù)盤會(huì)議

  當(dāng)然，我們根據(jù)當(dāng)時(shí)時(shí)間緊迫社牲，在盡可能表達(dá)清楚需求的情況下熟空，降低溝通的時(shí)間，這也導(dǎo)致了后續(xù)出現(xiàn)了一些問題窍帝。比如整個(gè)團(tuán)隊(duì)對項(xiàng)目的理解不夠深入诽偷，在開發(fā)過程中會(huì)存在一些偏差坤学，導(dǎo)致需求返工的情況出現(xiàn)。

敏捷開發(fā)需要依靠什么工具進(jìn)行管理报慕？

在高強(qiáng)度的開發(fā)中深浮，如果沒有一系列工具進(jìn)行管理，將會(huì)讓整個(gè)項(xiàng)目失去控制眠冈。敏捷開發(fā)的工具主要有：

• Excel 需求池
• 任務(wù)看板
• 燃盡圖
• 計(jì)劃撲克牌

傳統(tǒng)工具

第四點(diǎn)飞苇，為什么我們使用TAPD進(jìn)行開發(fā)

通過上面的描述大家應(yīng)該都比較清楚，敏捷開發(fā)的方式蜗顽。我們在做事情的時(shí)候一般是,先戰(zhàn)略后戰(zhàn)術(shù)布卡，然后是執(zhí)行。在我們確定下來要達(dá)成什么目標(biāo)雇盖，使用什么方式進(jìn)行開發(fā)忿等，進(jìn)一步就是如何執(zhí)行的工具選擇上。

傳統(tǒng)的紙質(zhì)或者一些道具顯然不是很方便崔挖，可能它的學(xué)習(xí)成本相較于線上工具的學(xué)習(xí)成本要低贸街，但是制作成本和后期的數(shù)據(jù)統(tǒng)計(jì)導(dǎo)出就需要更多人力來制作。在開發(fā)前期狸相，我們通過對TAPD的了解薛匪，它的基本功能需求、迭代脓鹃、故事墻逸尖、需求規(guī)模等等映射到傳統(tǒng)敏捷開發(fā)所需的管理工具，并且還提供了工作流自定義功能，管理bug的缺陷冷溶。

在整個(gè)項(xiàng)目進(jìn)行過程中渐白，產(chǎn)品經(jīng)理或者項(xiàng)目經(jīng)理可以實(shí)時(shí)查看缺陷統(tǒng)計(jì)、燃盡圖來把握產(chǎn)品進(jìn)度逞频。

TAPD功能概覽

第五點(diǎn)纯衍，敏捷開發(fā)實(shí)踐過程及結(jié)果

成員組成：

一個(gè)產(chǎn)品經(jīng)理、一個(gè)交互設(shè)計(jì)師苗胀、一個(gè)后勤襟诸、3個(gè)后端工程師、3個(gè)前端工程師基协、機(jī)動(dòng)UI設(shè)計(jì)團(tuán)隊(duì)

成果：

完成一個(gè)小程序歌亲、兩個(gè)系統(tǒng)后臺

實(shí)踐過程

整個(gè)TAPD工作流設(shè)計(jì)：

產(chǎn)品規(guī)劃 => 交互設(shè)計(jì) => UI設(shè)計(jì) => 實(shí)現(xiàn)中 => 產(chǎn)品體驗(yàn) => 缺陷

缺陷的處理流程：

新 => 已接受 => 處理中 => 待驗(yàn)收 => 已驗(yàn)收 => 已關(guān)閉

我們在整個(gè)過程中，嚴(yán)格遵循以下幾個(gè)原則：

• 產(chǎn)品設(shè)計(jì)需要拆分高內(nèi)聚低耦合的模塊澜驮，設(shè)計(jì)并且及時(shí)輸出最小可用單元陷揪，保證項(xiàng)目不會(huì)產(chǎn)生類似瀑布流開發(fā)的模式

• 每日完成手頭上的需求才算完成當(dāng)天的工作，確保每個(gè)人的需求能夠完成保證進(jìn)度

• 每日晚上十點(diǎn)進(jìn)行審核杂穷，事實(shí)上悍缠，為了讓大家能夠繼續(xù)加班到凌晨的小技巧，也確保缺陷不過日耐量。

• 每個(gè)模塊需要完整的走過工作流飞蚓，也就包括缺陷，出現(xiàn)問題及時(shí)調(diào)整廊蜒。

實(shí)踐遇到的問題

• 剛開始團(tuán)隊(duì)磨合工具趴拧，沒有及時(shí)變更工作狀態(tài)

• 預(yù)留給產(chǎn)品設(shè)計(jì)的時(shí)間太少，導(dǎo)致產(chǎn)品設(shè)計(jì)并沒有太全面山叮，邊界條件未充分考慮

• 需求排優(yōu)先級出現(xiàn)錯(cuò)誤

• 需求會(huì)沒有被重視著榴，導(dǎo)致開發(fā)過程中需求重新開發(fā)

• 測試環(huán)節(jié)節(jié)奏比較混亂，沒有從頭到尾測試聯(lián)調(diào)

• 產(chǎn)品更新原型屁倔，缺少比較好的同步工具兄渺，讓所有人一直都是使用最新的文檔

TAPD上的數(shù)據(jù)

由于離開上家公司的時(shí)候沒有整理出來這些資料，導(dǎo)致沒有辦法直接展示TAPD上的數(shù)據(jù)汰现。

大致上，我們通過9天的時(shí)間完成了：

• 需求點(diǎn)大致上有300+個(gè)叔壤，采用前后端分開提需求點(diǎn)

• 測試并且修復(fù)400條bug瞎饲，基本上做到日清

最后，注意事項(xiàng)

并不是所有的項(xiàng)目都適合用敏捷開發(fā)炼绘，在項(xiàng)目沒有特別明確的目標(biāo)嗅战，團(tuán)隊(duì)技術(shù)水平太弱、需要工期本身比較長無法細(xì)化顆粒度的情況下，使用敏捷開發(fā)會(huì)存在很多問題驮捍。比如：

• 響應(yīng)無法做到及時(shí)

• 對工具的使用無法快速適應(yīng)

• 沒有明確目標(biāo)疟呐，缺乏緊迫感

等等一系列問題，都會(huì)讓整個(gè)敏捷開發(fā)變得不敏捷东且。導(dǎo)致整個(gè)項(xiàng)目的燃盡圖呈現(xiàn)下圖這樣：

而正常的燃盡圖應(yīng)該未關(guān)閉的線段貼合基線：

不過启具，嘗試使用敏捷開發(fā)小而快的開發(fā)思想在自己的項(xiàng)目管理過程中也是不錯(cuò)的。

參考資料

1. 敏捷開發(fā)之Scrum掃盲篇

2. 敏捷開發(fā)（agile）中story

3. 讀書筆記Scrum 總結(jié)

4. 瀑布式開發(fā)珊泳、迭代開發(fā)鲁冯、敏捷開發(fā)、XP與SCRUM的區(qū)別