這是一次一個(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)級(jí)別的各個(gè)部門老大。由于每次意見不統(tǒng)一，僵持不下，導(dǎo)致產(chǎn)品一拖再拖。最后老板迫于壓力，在4月1日給出了一個(gè)命令，必須在4月20號(hào)做出來一個(gè)能看的產(chǎn)品。迫于無奈，在4月10日進(jìn)行封閉式開發(fā)。9天的時(shí)間完成了一個(gè)電商類型的小程序以及面向酒店和公司的兩個(gè)后臺(tái)系統(tǒng)。
正是在這樣的情況下，才能夠體會(huì)到敏捷開發(fā)小而快思想的精髓。
第一點(diǎn)，我們遇到的問題
盡管，前期我們有進(jìn)行一個(gè)相對(duì)比較長的研究，但是并沒有梳理形成一個(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ái)系統(tǒng)，也就是他們往往會(huì)忽略后臺(tái)系統(tǒng)的工作量。
公司又面臨了資金緊張裁員、UI團(tuán)隊(duì)需要多方共用，一些系列問題。
總結(jié)一下我們遇到的問題：
產(chǎn)品設(shè)計(jì)幾乎需要從0開始
大量的后臺(tái)系統(tǒng)開發(fā)工作量沒有被正確評(píng)估
研發(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í)間，不允許需求的變更。
XP：更側(cè)重于測(cè)試驅(qū)動(dòng)開發(fā)，一般迭代為1到2個(gè)星期，允許等量工作量的需求替換。
在整個(gè)開發(fā)過程中，因?yàn)榧夹g(shù)團(tuán)隊(duì)、產(chǎn)品團(tuán)隊(duì)的成熟度還不高，無法提供完整的XP模式開發(fā)方式、而項(xiàng)目有偏向于使用XP模式。綜合考慮，我們?cè)赟crum和XP模式下吸取各自的優(yōu)點(diǎn)：
允許中途變更等量的需求，因?yàn)樵谡麄€(gè)過程中，很有可能面臨老板的新需求，必須做到快速響應(yīng)；
嚴(yán)格按照優(yōu)先級(jí)進(jìn)行開發(fā)，因?yàn)闀r(shí)間短，User Story之間很有可能存在依賴關(guān)系，如果沒有按照優(yōu)先級(jí)進(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)理人肉測(cè)試和項(xiàng)目跟進(jìn)；
第三點(diǎn)，我們?cè)趺催x定工具
敏捷開發(fā)是一種快速響應(yīng)需求的開發(fā)方式，不同于傳統(tǒng)的瀑布式開發(fā)，在管理流程上也就不同。產(chǎn)品經(jīng)理通過采集需求，整理出產(chǎn)品需求池（Product Backlog），然后輸出到研發(fā)團(tuán)隊(duì)進(jìn)行工作量評(píng)估、實(shí)現(xiàn)可行性，最后根據(jù)優(yōu)先級(jí)進(jìn)入到迭代需求池（Sprint Backlog）進(jìn)行一輪迭代。
再通過每天的站立會(huì)進(jìn)行對(duì)需求完成情況的審核，控制風(fēng)險(xiǎn)。以下是一個(gè)完整的產(chǎn)品迭代的過程。
通過什么會(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 評(píng)審會(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ì)對(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ì)劃撲克牌
第四點(diǎn)，為什么我們使用TAPD進(jìn)行開發(fā)
通過上面的描述大家應(yīng)該都比較清楚，敏捷開發(fā)的方式。我們?cè)谧鍪虑榈臅r(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ā)前期，我們通過對(duì)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)度。
第五點(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)后臺(tái)
實(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)閉
我們?cè)谡麄€(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)先級(jí)出現(xiàn)錯(cuò)誤
需求會(huì)沒有被重視，導(dǎo)致開發(fā)過程中需求重新開發(fā)
測(cè)試環(huán)節(jié)節(jié)奏比較混亂，沒有從頭到尾測(cè)試聯(lián)調(diào)
產(chǎn)品更新原型，缺少比較好的同步工具，讓所有人一直都是使用最新的文檔
TAPD上的數(shù)據(jù)
由于離開上家公司的時(shí)候沒有整理出來這些資料，導(dǎo)致沒有辦法直接展示TAPD上的數(shù)據(jù)。
大致上，我們通過9天的時(shí)間完成了：
需求點(diǎn)大致上有300+個(gè)，采用前后端分開提需求點(diǎn)
測(cè)試并且修復(fù)400條bug，基本上做到日清
最后，注意事項(xiàng)
并不是所有的項(xiàng)目都適合用敏捷開發(fā)，在項(xiàng)目沒有特別明確的目標(biāo)，團(tuán)隊(duì)技術(shù)水平太弱、需要工期本身比較長無法細(xì)化顆粒度的情況下，使用敏捷開發(fā)會(huì)存在很多問題。比如：
響應(yīng)無法做到及時(shí)
對(duì)工具的使用無法快速適應(yīng)
沒有明確目標(biāo)，缺乏緊迫感
等等一系列問題，都會(huì)讓整個(gè)敏捷開發(fā)變得不敏捷。導(dǎo)致整個(gè)項(xiàng)目的燃盡圖呈現(xiàn)下圖這樣：
而正常的燃盡圖應(yīng)該未關(guān)閉的線段貼合基線：
不過，嘗試使用敏捷開發(fā)小而快的開發(fā)思想在自己的項(xiàng)目管理過程中也是不錯(cuò)的。
