UI 设计进阶 1-3：敏捷开发的技巧

Posted 2021-04-25 UIcircle

点上面蓝色 UIcircle 订阅我们哦~

前言

本文是 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.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