本文作者將結(jié)合自身經(jīng)驗(yàn)，與大家一起來聊聊敏捷流程中每個環(huán)節(jié)的主要任務(wù)及內(nèi)容。enjoy~

說到敏捷開發(fā)，相信大家都多少有了解。目前大部分互聯(lián)網(wǎng)公司的開發(fā)模式肯定不是傳統(tǒng)的瀑布式開發(fā)，更多的應(yīng)該是偏向于敏捷開發(fā)。最近一段時間參與的項(xiàng)目，項(xiàng)目組采用的是敏捷開發(fā)迭代制度，雖然可能和嚴(yán)格意義上的敏捷開發(fā)有所區(qū)別，但是適合的才是最好的。在實(shí)踐中，通過項(xiàng)目的反思總結(jié)，制定適合自己團(tuán)隊(duì)的敏捷模式是最好的。

首先簡單來介紹一下敏捷開發(fā)：敏捷開發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)。在敏捷開發(fā)中，軟件項(xiàng)目在構(gòu)建初期被切分成多個子項(xiàng)目，各個子項(xiàng)目的成果都經(jīng)過測試，具備可視、可集成和可運(yùn)行使用的特征。換言之，就是把一個大項(xiàng)目分為多個相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)——來自百度百科。簡單來講，在快速發(fā)展的互聯(lián)網(wǎng)時代，開發(fā)周期不宜太長，采取小步迭代，更能適應(yīng)當(dāng)今這個時代。

網(wǎng)上的敏捷開發(fā)的流程圖是這樣的：

我們項(xiàng)目組的流程，實(shí)際是這樣的：

雖然和許多標(biāo)準(zhǔn)的敏捷流程不完全一樣，但其實(shí)我們的流程保留了核心的幾個環(huán)節(jié)。接下去來聊聊每個環(huán)節(jié)的主要任務(wù)及內(nèi)容。

需求整理階段

時間：此環(huán)節(jié)的時間往往不計(jì)入迭代周期，一方面是需求和設(shè)計(jì)經(jīng)常會發(fā)生變動，而功能設(shè)計(jì)確定后，進(jìn)入開發(fā)階段的變動比較少；另一方面是開發(fā)在進(jìn)入當(dāng)前迭代的時候，此時產(chǎn)品就應(yīng)該進(jìn)入到下一個迭代的設(shè)計(jì)周期了。

參與人員：產(chǎn)品人員、技術(shù)負(fù)責(zé)人、項(xiàng)目經(jīng)理

工作任務(wù)：此環(huán)節(jié)任務(wù)其實(shí)不少，包括了產(chǎn)品人員對迭代的需求進(jìn)行梳理，對需求完成設(shè)計(jì)。產(chǎn)品在完成產(chǎn)品方案后，小范圍召集產(chǎn)品經(jīng)理、技術(shù)負(fù)責(zé)人、進(jìn)行評審。在交互稿、設(shè)計(jì)稿都完成后，進(jìn)行召開迭代會議。

產(chǎn)品關(guān)注：此階段產(chǎn)品的主要工作是在需求池中進(jìn)行篩選，整理出高優(yōu)先級的任務(wù)，作為此次迭代的功能列表。因筆者都是在小公司，所以產(chǎn)品文檔、交互稿都是由產(chǎn)品人員通過原型來展現(xiàn)。

踩過的坑：某次該會議叫了過多的人，導(dǎo)致會議時間過長，會議效果也不好（由于此環(huán)節(jié)主要是對總體功能列表進(jìn)行討論，只需叫上產(chǎn)品小隊(duì)、技術(shù)負(fù)責(zé)人就夠了）；還有就是設(shè)計(jì)的原型在此階段就做的太細(xì)，導(dǎo)致部分需求其實(shí)并不需要（此環(huán)節(jié)設(shè)計(jì)以大的框架及流程為主，細(xì)節(jié)的交互、規(guī)則等可以在之后再根據(jù)需要進(jìn)行完善）；

迭代會議階段

時間：此環(huán)節(jié)為迭代周期正式開始

參與人員：項(xiàng)目組所有人員

工作任務(wù)：此階段為任務(wù)講解、計(jì)劃。主要為產(chǎn)品經(jīng)理對此次迭代的主要任務(wù)進(jìn)行講解，包括需求來源、產(chǎn)品設(shè)計(jì)，技術(shù)人員對此次迭代的時間進(jìn)行排期。

產(chǎn)品關(guān)注：該會議就是傳說中的評審會議。產(chǎn)品要多做準(zhǔn)備工作，因?yàn)闀泻芏嗳藖響荒?，主要還是以業(yè)務(wù)流程、規(guī)則、交互等具體實(shí)現(xiàn)的東西，因?yàn)榧夹g(shù)要進(jìn)行開發(fā)，很多東西需要問清楚。

踩過的坑：這個環(huán)節(jié)坑就是看被懟的慘不慘? 。主要有兩方面的準(zhǔn)備吧，一個是人，因?yàn)榍捌谟袦?zhǔn)備過小范圍的評審（需求整理會議），你要拉攏其他的人員認(rèn)可你的東西，這樣在會議中，這部分人會幫你回答（至少不會提問你）；另一方面還是文檔（原型），在設(shè)計(jì)的時候要多思考，把各種情況考慮全，這樣在會議中被提問時，就能夠很好的回答他人。

迭代計(jì)劃階段

時間：開發(fā)、測試階段

參與人員：項(xiàng)目組所有人員

工作任務(wù)：此階段為開發(fā)階段，技術(shù)負(fù)責(zé)人對功能列表進(jìn)行拆分、排期，開發(fā)人員開始進(jìn)入編碼階段。測試人員根據(jù)需求書寫測試用例，在開發(fā)完成提成后，進(jìn)行產(chǎn)品測試。

產(chǎn)品關(guān)注：本階段產(chǎn)品主要是和開發(fā)人員保持溝通，一些在開發(fā)過程中會發(fā)現(xiàn)的有疑問的地方，需要產(chǎn)品去決策，該如何做。產(chǎn)品提測后，產(chǎn)品人員也要及時去對開發(fā)好的功能進(jìn)行驗(yàn)證，看是否符合預(yù)期。在這間隙，產(chǎn)品需要開始對下一個迭代的需求進(jìn)行梳理。

每日例會：此會議初衷是對每天的工作進(jìn)行回顧，主要是看當(dāng)天的任務(wù)完成情況，是否有難處等，讓大家對項(xiàng)目的進(jìn)度有一個了解。但是實(shí)際應(yīng)用中，我們的例會效果不是很好。建議通過一些協(xié)作工具，用圖表來展示，這樣更有直觀性。

踩過的坑：迭代過程中最大的坑應(yīng)該是需求變更了。原則上迭代會結(jié)束后，不能在此迭代里新增需求。但是需求變更常常就會有新增，這時候需要去評估。如果是改動大的需求，需要召集小分隊(duì)人員進(jìn)行討論，看是否必要加入此次需求；如果是小的改動，則進(jìn)行相關(guān)文檔的更新，并通知到項(xiàng)目組成員。

發(fā)布演示階段

時間：開發(fā)測試完成后，進(jìn)行產(chǎn)品的發(fā)布更新

參與人員：項(xiàng)目組所有人員

工作任務(wù)：此階段為迭代的尾聲，在測試完成后，根據(jù)需要在不同的環(huán)境進(jìn)行發(fā)布，發(fā)布后，可能需要去演示。

產(chǎn)品關(guān)注：到此階段，就正式完成一個迭代的周期了。產(chǎn)品人員應(yīng)該也梳理好了下一個迭代的需求，在本迭代發(fā)布且通過后，就需要開始新一輪的迭代工作了。

踩過的坑：更新經(jīng)常到更凌晨。發(fā)布前一定要做好測試、發(fā)布前準(zhǔn)備工作，要定好發(fā)布計(jì)劃，不然很容易陷入到發(fā)布-測試-發(fā)現(xiàn)bug-修改bug-測試-發(fā)現(xiàn)新的bug….反正每次更新都不省心，經(jīng)常到凌晨。

本文由 @pauly?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議