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

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

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

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

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

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

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

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

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

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

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

二、工作流程

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

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

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

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

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

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

三、部分概念理解

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

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

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

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

2. 需求池（Backlog）

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

3. 故事板（Story Board）

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

4. 工時

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

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

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

四、成也靈活，敗也靈活

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

優(yōu)點：

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

缺點：

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

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

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