編輯導語：作為一名UI/UX設計師，在工作中接觸到“敏捷”一詞時，也會感覺到模式和難以理解。從需求到設計每一步都需要了解清楚，那么敏捷開發(fā)這種模式該如何做呢，我們一起來看看吧。

剛接觸敏捷時我對這種模式是不能理解的，沒有調(diào)研沒有文檔，從需求到設計用的方法和學校里所學的完全不一樣，但經(jīng)過兩年的工作后，我的認知開始發(fā)生變化，下面我將作為一個UI/UX分享一些我對敏捷式開發(fā)的理解。

在互聯(lián)網(wǎng)行業(yè)中，一個項目的完整生命周期都是由一個團隊完成的，團隊成員也許會變化，但任何一個角色都不可或缺。

為了更好地完成共同目標，團隊成員除了在自己負責的領(lǐng)域是專家，還需要了解其他人的工作內(nèi)容及整個團隊的工作模式。工作模式是連接團隊成員的一種運作方式，要求每個人都清晰了解，并認同。

一、敏捷式開發(fā)宣言（Agile Program Development）

起源于20世紀90年代，由開發(fā)程序員提出，是相對于傳統(tǒng)軟件開發(fā)方法（如瀑布流模型）而言的一種新軟件開發(fā)模式。這里認為該模式不僅僅適用于開發(fā)，也適用于團隊除開發(fā)外的其他角色，因此將它視作為團隊工作模式。下圖為敏捷開發(fā)的價值觀。

個體和互動高于流程和工具：人是最重要的因素，敏捷提倡打破部門的概念，人與人之間面對面溝通，交流。敏捷的辦公室常常是很熱鬧的。

工作的軟件高于詳盡的文檔：看文檔是一件讓人頭疼的事，無論是需求或技術(shù)文檔，撰寫和維護都需要耗費大量的人力，文檔的不靈活性讓其地位在敏捷開發(fā)中地位降低，因此這里的文檔要盡可能精簡，能用軟件替代文檔的任務首選軟件。

客戶合作高于合同談判：客戶對產(chǎn)品的需求會隨著他自己的認知和心情變化，能從一開始就確定細節(jié)的項目實在太少，經(jīng)常與客戶溝通，給予反饋才能促成項目的成功。

響應變化高于遵循計劃：和瀑布流中將產(chǎn)品的功能完全規(guī)劃好后集中開發(fā)不同，不斷變化的需求讓敏捷從業(yè)者制定計劃時盡可能的簡化，這里可以結(jié)合MVP（Minimum Viable Product 最小可行性產(chǎn)品）的概念去理解。

每次迭代交付一個可用的最小功能，這個功能時是不完美的、簡陋的，只能滿足用戶最基本的需求，然后通過后期客戶的正反饋慢慢完善功能。這種方式試錯成本低，能快速應對需求變化。

二、工作流程

這里簡單描述自己工作中兩周為一個迭代的工作流程。

一個開發(fā)階段稱為一個Sprint（沖刺），每個Sprint開始前，都會舉行一個Planning Meeting（計劃會）來共同規(guī)劃這個迭代的開發(fā)任務，會議主持人一般為PM（產(chǎn)品經(jīng)理）或PO（Product Owner，產(chǎn)品負責人）。

會上，PO會向團隊成員展示列入這個迭代開發(fā)的需求。

每一個需求都是一個或多個任務（Task），PO根據(jù)優(yōu)先級安排要開發(fā)的任務，描述每個任務要達到的目標，和設計、開發(fā)、測試確認，在Scrum Master（敏捷教練，一般為技術(shù)大牛）的協(xié)作下找到任務處理人并以工時為單位預估任務完成需要的時間。

最后，團隊成員之間聊個五毛話題增進感情，Planning Meeting就算結(jié)束了。在接下來的兩周內(nèi)，每天上午團隊成員要開一個簡短的Standing Meeting（站會），每人說明昨天做了什么，完成度如何，如有拖延是因為什么原因，是否需要其他成員幫助，以及今天計劃要完成的任務。

一周下來，要開一個半程回顧會，了解開發(fā)進度，若有延遲，及時做出對應調(diào)整。兩周下來是一個全程Review Meeting（回顧會），回顧這個迭代的完成度，并展示實現(xiàn)的功能，現(xiàn)場Demo。

三、部分概念理解

注：這部分示例圖來自騰訊敏捷類辦公產(chǎn)品Tapd。

1. 需求及任務（Story and Task )

需求由PO建立，是將用戶故事（User Story）簡化后的產(chǎn)物，描述在什么場景下需要完成什么樣的功能，對開發(fā)而言就是一個開發(fā)任務（Task）。

功能比較復雜的需求往往會被拆解成多個需求，拆分到以用戶角度可接受的最小顆粒度功能作為子需求，以父子需求的方式進行關(guān)聯(lián)。開發(fā)的角度上看可以由一個開發(fā)（Story Owner）接下這個任務，再分配給其他開發(fā)人員。

2. 需求池（Backlog）

需求池里記錄著待開發(fā)的需求及優(yōu)先級，優(yōu)先級按照對用戶的價值進行排序，高的會先開發(fā)。PO在表述需求時往往不會有詳細的需求文檔，一般會用簡短的文字描述在需求詳情里，再加上面對面溝通將需求傳遞給設計或是開發(fā)。

3. 故事板（Story Board）

以卡片的形式展示當前迭代的進度，包括任務內(nèi)容，優(yōu)先級，處理人，狀態(tài)等信息。PO可從這里清楚地看到團隊的進度，開發(fā)也可以通過篩選來了解自己各種狀態(tài)的開發(fā)任務。

4. 工時

工時是影響一個迭代完成度的重要因素，涉及到任務處理人對工時的預估，如果實際工時高于預估，勢必會造成任務延期或開發(fā)加班，影響整個迭代的完成度，如果實際工時低于預估，便會造成人力資源的浪費，影響效率。

準確的預估工時需要開發(fā)人員有豐富的經(jīng)驗，掌握業(yè)務邏輯，了解自己的開發(fā)能力，此外工時還包括安全時間，以處理特殊情況。

一般每個開發(fā)一周有略低于40（5×8）個工時的任務量。處理Bug所用時間不算在工時內(nèi)，Bug秉承優(yōu)先解決，誰開發(fā)誰解決的原則。

四、成也靈活，敗也靈活

敏捷的特點，優(yōu)點，缺點都是靈活。

優(yōu)點：

• 應對需求的靈活性讓功能的開發(fā)時間縮短，可盡早得到市場的反饋，提高規(guī)避風險的能力
• 人與人之間的直接溝通能充分利用時間，工作效率提高

缺點：

• 面對面溝通讓信息傳遞的質(zhì)量隨傳遞人數(shù)的增加而降低，從產(chǎn)品到設計到開發(fā)再到測試的信息傳遞會出現(xiàn)偏差，這讓敏捷在大項目大團隊中的實施變得困難
• 較少的文檔在團隊人員過多，人員變動或項目持續(xù)時間較長時無法全面了解到產(chǎn)品的全貌，溝通成本增加

五、總結(jié)

• 敏捷是一種理念，原則，價值觀，不同的團隊在實行這個模式都是不同的。
• 實行敏捷的目的是為了幫助團隊高效地合作溝通，過程中的去文檔，去流程，面對面溝通都只是手段，最后還是以結(jié)果為導向。切記敏捷流于形式，糾結(jié)于步驟！
• 敏捷要求團隊成員有很強的主觀能動性，并能主動推進整個項目前進，當他人停滯不前時，PUSH他們。
• 敏捷團隊的建立需要時間和經(jīng)驗積累，當任務出現(xiàn)問題時主動承擔責任優(yōu)于互相推諉，成員間切忌心存芥蒂，這樣才能保持團隊的凝聚力。

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

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