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

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

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

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

一、敏捷式開發宣言（Agile Program Development）

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

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

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

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

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

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

二、工作流程

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

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

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

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

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

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

三、部分概念理解

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

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

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

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

2. 需求池（Backlog）

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

3. 故事板（Story Board）

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

4. 工時

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

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

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

四、成也靈活，敗也靈活

敏捷的特點，優點，缺點都是靈活。

優點：

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

缺點：

面對面溝通讓信息傳遞的質量隨傳遞人數的增加而降低，從產品到設計到開發再到測試的信息傳遞會出現偏差，這讓敏捷在大項目大團隊中的實施變得困難較少的文檔在團隊人員過多，人員變動或項目持續時間較長時無法全面了解到產品的全貌，溝通成本增加五、總結敏捷是一種理念，原則，價值觀，不同的團隊在實行這個模式都是不同的。實行敏捷的目的是為了幫助團隊高效地合作溝通，過程中的去文檔，去流程，面對面溝通都只是手段，最后還是以結果為導向。切記敏捷流于形式，糾結于步驟！敏捷要求團隊成員有很強的主觀能動性，并能主動推進整個項目前進，當他人停滯不前時，PUSH他們。敏捷團隊的建立需要時間和經驗積累，當任務出現問題時主動承擔責任優于互相推諉，成員間切忌心存芥蒂，這樣才能保持團隊的凝聚力。

本文由 @B端交互設計師 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于CC0協議