UI 設計進階 1-3：敏捷開發的技巧

作者：Hindy

原文地址：uicircle.club/a/144

轉載無限歡迎，但請註明「作者」和「原文地址」。感謝您對作者版權的尊重。

前言

本文是 UI 設計進階系列的第 1-3 篇，系列目錄：uicircle.club/a/128。

互聯網產品上線後需要不斷更新迭代，而敏捷開發可謂是保持產品及團隊活力的最好辦法。本文就將為大家介紹為什麼及如何執行敏捷開發。

為什麼產品一定要更新迭代？

關於這個問題也許可以追溯到上世紀 20 年代，通用汽車公司總裁阿爾弗雷德 · 斯隆（Alfred P. Sloan）提出的汽車設計新模式，即「有計劃地廢棄制度」（Planned obsolescence）。他們認為必須有計劃地考慮以後幾年之間不斷更換汽車部分設計，使樣式每 2 年有一次小變化，每 3-4 年有一次大變化。其目的是促使消費者為了追逐新的式樣潮流，而放棄舊款的積極市場促銷方式。

我們可以發現直到今天車廠還在保持這種更新方式。而這一理念也擴散到更多工業產品設計。我們每天用的手機就是其中更新最頻繁的品類之一。

軟體設計也是如此，但又不止如此。尤其相比傳統工業產品，互聯網產品更新周期要短得多。還是拿手機舉例，某手機系列更新可能是以年計，而軟體更新則以周計，完全是不同量級。另外，除了新增功能、修改樣式，修復程序大大小小的 bug 也是軟體更新的重大理由。因此對互聯網產品而言，快速更新迭代是非常重要的一環，也是我們追求「敏捷開發」的重要原因。

什麼是敏捷開發？

如上所說，我們需要通過不斷快速更新產品以保持產品及團隊的活力。那麼「敏捷開發」就是最好的辦法。

敏捷開發是一套軟體開發的價值和原則，倡導演進式開發，提早交付，持續改進，鼓勵對變化做出快速靈活的反應。

敏捷（Agile）這個術語是由敏捷軟體開發宣言（Manifesto for Agile Software Development）推廣的，它定義了上述這些價值觀（見參考資料）。

傳統的軟體開發會羅列一大堆想要的功能，然後進行線性流程開發，在很大程度上像瀑布一樣向下，因此被稱作瀑布流開發流程（Waterfall Process）。而敏捷開發則將項目分解成多個「小目標」，通過分階段不停完成這些目標，一個大項目隨之完成。

Scrum 介紹

Scrum 可能是目前應用最廣的敏捷開發綜合框架。它最突出的的優點有：

• 適用範圍廣，多數產品類型都適用；
• 擁有完整的框架，且易上手；
• 快速迭代，以一個個 Sprint 為周期，快速開發；
• 適應性強，可根據自己團隊、項目的需求靈活應用。

我之前所在的創業團隊基本就是按照 Scrum 框架來進行產品開發的，非常高效。但我要提的是這套框架只是個基礎，具體應用到自己的團隊一定要做選擇性的調整。比如我們團隊因為人少，且同事也都是自我驅動能力非常強的人，因此去除了 Scrum Master。總之，我不認為這世上會有任何一條標準是拿來就能用的，切記靈活應用。

我在這也為大家簡單介紹下 Scrum 的主要內容及操作流程，具體可以查看文末參考閱讀的鏈接來閱讀完整的內容。

Scrum 三個角色

Scrum 首先定義了三個角色：Product Owner、Scrum Master、Development Team。

• Product Owner：產品負責人，確定「大家要做什麼」，互聯網公司一般由產品經理（或類似職能的人）擔任。
• Scrum Master：Scrum 的推動者，並輔助團隊其他人。
• Development Team：開發團隊包含各種專業人員（建議 3 至 9 人為一個團隊），專註開發。

Scrum 開發流程

Step1 維護需求池

這是我自己基於原框架補充的一個步驟。在快速迭代過程中，我們需要有這麼一個完善的「需求池」來管理來自各方的需求，由產品負責人維護。

Step2 建立一個 Sprint

Sprint 類似開發周期，是 Scrum 的核心，在互聯網公司其長度通常為一周或兩周或一個月。Sprint 由產品負責人建立，確定本期開發的主要目標（Vision）、一條條新增的功能或優化等產品待辦事項列表（Product Backlog）。

Step3 計劃會議

Sprint 中要做的工作在 Sprint 計劃會議中來做計劃。這份工作計劃由整個 Scrum 團隊共同完成。一般長度兩周的 Sprint 不要超過 3 個小時。Scrum Master 要確保會議順利舉行，並且每個參會者都理解會議的目的。本會議大家可以理解為我在上一文「通用開發流程」中提到的「計劃開發計劃」。

Sprint 計劃會議回答以下問題：

• 一起最終決定接下來的 Sprint 中要包含什麼內容？
• 如何完成所選的工作？

Step4 每日站會

在 Sprint 開始後，還有一件事情是每日站會。站會一般在早上，控制在 15 分鐘之內。每個成員輪流交代三件事：

• 我昨天做了什麼？
• 今天要做什麼？
• 遇到了什麼問題（可能需要誰的幫助）？

如果有具體的問題要交流，則放在會後一對一交流，注意控制時間。

Step5 評審會議

在 Sprint 結束前（約在開發階段後期），團隊會進行 review，各自交流我們完成的工作。但這是一個非正式會議，演示的目的是為了獲取反饋並促進合作，並根據實際情況，適度調整產品待辦事項列表。

Step6 回顧會議

Sprint 回顧會議是團隊檢視自身並創建下一個 Sprint 的機會。

回顧會議發生在 Sprint 評審會議結束之後，下個 Sprint 計劃會議之前。

Scrum Master 要確保會議舉行，並且每個參會者都明白會議的目的，確保會議是積極的和富有成效的。

Sprint 回顧會議的目的在於：

• 回顧前一個 Sprint 中的情況；
• 找出並加以排序做得好的和潛在需要改進的主要方面；
• Scrum Master 制定改進 Scrum 團隊工作方式的計劃。

協作工具推薦

這裡我只推薦自己真實使用過的好產品，不瞎羅列。

Atlassian：www.atlassian.com

大而全，適合大公司，多人多項目。

Teambition：www.teambition.com

國產卻不失國際范兒，小團隊或小項目建議用這個，基本能滿足一切需求。

Slack：slack.com

留言板式的交流分享工具，簡潔的設計，大小團隊都適用。UIcircle 的會員社區目前就在用這款產品，歡迎加入我們（見下方）。

免費獲取完整 PPT，請關注公眾號 uicircle，回復「agile」即可 (<ゝω·)☆~

本系列合集：uicircle.club/a/128。

如果你想提升設計能力，亦或充實自己的周末，歡迎加入我們的會員社區??

→點這報名

參考閱讀

• Planned obsolescence - wikipedia：en.wikipedia.org/wiki/Planned_obsolescence
• Manifesto for Agile Software Development：agilemanifesto.org
• Scrum Guides：scrumguides.org
• 如何實施 SCRUM ？ - 知乎：zhihu.com/question/19638322

推薦閱讀：