编辑导语：产品在经由市场定位、战略规划、产品设计等流程之后，便可以进入正式的开发环节。在这一环节中，产品团队应当注意哪些事项、以避免造成生产活动的浪费或是团队工作的不协调？本文作者对敏捷开发进行了总结分享，一起来看一下。

至此，我们可以进入产品开发（生产）阶段了。

在工业领域，MVP开发一般在实验室或研究中心完成，经过测试验证后，按照产品文档标准要求在特定的工厂进行批量生产。

实物产品在批量生产过程中遵循“精益管理”的思想，精益管理要求企业的各项活动都必须运用“精益思维”，“精益思维”的核心就是以最小资源投入，包括人力、设备、资金、材料、时间和空间，准时地创造出尽可能多的价值，为顾客提供新产品和及时的服务。

精益管理的目标可以概括为：企业在为顾客提供满意的产品与服务的同时，把浪费降到最低程度。

企业生产活动中的浪费现象很多，常见的有：

• 错误——提供有缺陷的产品或不满意的服务；
• 积压——因无需求造成的积压和多余的库存；
• 过度加工——实际上不需要的加工和程序；
• 多余搬运——不必要的物品移动；
• 等候——因生产活动的上游不能按时交货或提供服务而等候；
• 多余的运动——人员在工作中不必要的动作；
• 提供顾客并不需要的服务和产品。

努力消除这些浪费现象是精益管理的最重要的内容。

由于我在实物产品的规模化生产领域缺乏实战经验，在此就不再为大家做太多的讲述。在互联网领域，精益的思想同样适用，并在敏捷开发中体现得淋漓尽致。

本小节，我着重地为大家讲解关于敏捷开发的精髓知识内容，帮助互联网/软件产品经理实现提高顾客满意度、降低成本、提高质量、加快流程速度和改善资本投入，使组织社会性的价值实现最大化。

一、敏捷开发宣言

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行产品开发。在敏捷开发中，产品项目在构建初期被切分成多个子产品，各个子产品的成果都经过测试，具备可视、可集成和可运行使用的特征。

换言之，就是把一个大产品分为多个相互联系，但也可独立运行的小产品模块或功能，并分别完成，在此过程中产品一直处于可使用状态。

在2001年，17位敏捷方法论的拥护者和倡议者聚集在犹他州的雪鸟滑雪场，起草了一份陈述敏捷组织原则的文件。这份文件基本上代表了不同敏捷方法论的共同点，我们称之为“敏捷宣传”，也叫做敏捷软件开发宣言，是指导以人为中心的迭代软件开发方法，具体四个核心价值内容如图5-14所示。

图5-14 敏捷开发宣传

1. 个体和互动高于流程和工具

项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。

虽然，过程和工具都是好东西，但是它们有时也会成为障碍。面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多。

当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录。

2. 工作的软件高于详尽的文档

可用软件的价值是很重要的，因为软件是为业务目标提供支持的，是可用软件（而不是文件）为客户和也会传递了高价值。

一般来说，一个敏捷项目的进展情况是由开发了多少可用软件来跟踪和报告的。但不是说文档一无是处，适量的文档在绝大多数的项目中是有益的和必要的。

敏捷通过寻求“刚好足够”的文档来避免这种情况。其中的原则是任何文件的创建都应与为客户创造的价值直接挂钩，且不论该价值体现在现状还是将来。

3. 客户合作高于合同谈判

这个价值观的核心是越接近你的客户越好。客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误。在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的。

定位你与客户的关系很重要，你是选择对抗你的客户还是选择与你的客户一起为接近方案努力而使每个人都受益？敏捷团队更愿意和客户在同一方向一起使劲而不是把力气花在背离客户的方向。

4. 响应变化高于遵循计划

任何一个曾在软件项目工作过的人都知道这些项目的本质就是变化。即使底层的技术也在快速变化，新的途径和可能性在不断地被打开。对变化响应的速度就决定你在市场上的灵活性，循规蹈矩的做事将被市场甩在后面，永远慢市场半拍，慢慢你的市场会被蚕食掉。

当你读到这个宣言，你会发现它具有最高原则性，因为敏捷方法论在最高层面上是一致的，但到具体细节上每种方法都会不同。除了敏捷宣言之外，还有12条准则的支持文件，为敏捷宣言提供了更多的扩充细节。

准则1

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。敏捷团队可以很快将可用软件交付到客户手中，并且是开放式地快速更新，给客户带来优先级最高地价值。

准则2

欢迎对需求提出变更，即使在项目开发后期；要善于利用需求变更，帮助客户获得竞争优势。

传统项目管理中的一个原则是设法去影响和控制会导致变化地因素。敏捷项目管理预期到需求会发生变化，并在实际过程中欢迎拥抱这些变化，即使这些变化发生在项目后期。

迅速应对和适应变化能给客户带来显著地竞争优势，从而应对新的机遇。

准则3

要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

不同的敏捷方法论采用不同的迭代周期，但都是相对较短的，关键是能快速把可用的软件交付到客户手上并能利用软件获得有意义的回报。较短的迭代周期可以使团队持续关注客户的价值。

准则4

在项目过程中，业务人员、产品经理与开发人员必须在一起。敏捷项目管理，让业务人员、产品经理和开发人员彼此靠近，并时常让他们在同一个地方一起工作。

通过这样的方式让业务人员和开发人员之间没有隔阂，是因为业务人员和开发人员的共同目标就是通过可用的软件向客户传递价值。

准则5

要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。

传统项目管理，常对员工进行微观管理，不仅告诉他们要做什么，还告诉他们如何做，无意间形成自上而下的管理方式。

敏捷项目建立了一支强有力的团队并积极避免微观管理，要求一个自律的团队，自发告知开发人员做什么。提供相关资源，给予鼓励，相信团队能够完成任务。

准则6

无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。非正式口头的沟通在敏捷项目管理中远比正式的书面沟通更普遍。其想法是两个人坐在一起为一个解决方案努力会比他们用邮件来来往往或交换文件更有效率。

面对面沟通是敏捷项目管理的精髓。这种沟通是公开的，任何团队成员都可以自由参与对话。

准则7

可用的软件是衡量进度的主要指标。计划和文件可能是有用的，但是当最根本的目标发生变化时，它们就可能失去应有的价值。

传统项目往往极其纠结的是，项目的不断更新使得文件成为一种负担。真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的。

准则8

敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

可持续开发的焦点是在团队身上，他们会努力保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工。

理想的目标是保持一种可持续的速度，使团队成员不会感到过度的压力和筋疲力尽，而是能够保持在一个理想的强度下工作。

准则9

对技术的精益求精及对设计的不断完善将提升敏捷性。设计得越完善，维护起来就越简单，即使遇到变化，稳定和优质的项目会比劣质的项目更加允许团队快速应对变化。

准则10

要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术，被所有的敏捷方法所拥护，尤其是精益方法。关键点对客户价值保持关注和毫无犹豫的削减不增加价值的活动。保持简单不只是一种愿望，它使最基本的原则。

准则11

最佳的架构、需求和设计出自自我组织的团队。

自我组织是敏捷团队的核心元素之一。当一个团队是自我组织型的时候，说明该团队自己去决定工作如何分配及谁去做某个特定的工作，而不是人力资源部门或管理层来决定。不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的。

准则12

团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

敏捷项目中最可预见的事情就是变更。传统项目里当项目或阶段完成时开会总结是最常见的做法，而敏捷试着通过更频繁的回顾来完成这项工作。在一个回顾活动中，团队查看各迭代周期中已完成的工作或发布，并评估下一次如何改进他们的做法。每日站立会议即每天简单碰头15分钟是另一项协调团队努力方向、团队自我评定和自我调整的重要方式。

敏捷开发的业务目标是更早地交付价值，价值的交付不仅仅是早晚上线两天的问题，而是更早上线能够给自己和客户带来更大的价值。越晚交付，价值越低。更快不是绝对速度的快，而是指时间上的早，即通过迭代交付实现分批和更早的交付。

同时灵活地响应变化。当今世界跨界颠覆的案例数不胜数，一个企业的核心能力不再是已有的能力有多强，而是灵活响应变化，快速学习的能力有多好。

注意：在新产品开发中使用敏捷，一定要考虑整体价值的交付，这种交付是可以交付到用户手中使用的交付，是面向市场的交付。

我曾遇到过一个创业团队花了一年半的时间，迭代了26个版本，依然没有完成用户交付，没有将产品推向市场，这种悲剧尽量避免。采用做最小可行性产品（MVP）方法可以有效地避免这种情况的发生。

二、Scrum敏捷开发

在敏捷实践体系中，迭代交付模式是敏捷开发的核心要素。

敏捷开发方法有很多，Scrum提供了迭代管理和持续改进的框架，如图5-15所示。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

图5-15 Scrum敏捷开发流程

Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。

Scrum的最大特色是灵活和增量交付，要求团队之间有开放的沟通和协作。首先是由产品经理收集和整理需求，然后和开发团队确定开发列表，接着进入开发冲刺状态，后面就是日常开会、后期改善。在实际应用中，我们通常将其分为以下5个步骤。

1. 步骤1：创建用户需求列表

一个产品的需求可能来自客户、团队或者产品经理的想法，这些需求的描述必须符合：作为_______，我希望_______，以完成______。这样的好处是让整个团队更容易理解需求，达成共识，图5-16所示为一个实例。

图5-16 用户需求列表（产品功能需求）

2. 步骤2：召开计划会议和制定开发计划（计划版）

Scrum Master负责组织召开计划会议，产品经理和团队一起根据需求的重要性、开发量来确定开发优先级，做工作量预估，制定迭代开发计划（从需求列表中挑选出高优先级 Story（用户需求）作为本次迭代完成的目标。

这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog（迭代代办事项））。

开发团队一旦接受这些开发任务，就应该准时完成，不得修改交付标准。

3. 步骤3：执行迭代计划（任务板）

首先，你需要确定每次Sprint（开发冲刺）的周期，短的周期可以更频繁地发布产品版本，因此可以从客户那里更迅速地收到反馈，修正错误。

这个周期一般为1~4周。当然，你可以根据团队成熟程度或迭代任务确定一个合适的迭代周期，比如2周，这样可以让开发人员更投入地工作。

所谓Sprint，就是在一定时间内全身心投入开发。这个阶段通常用看板来管理需求，每个卡片就是一个开发任务，工作完成后，可以将卡片移到下一个阶段，用看板管理需求。

如图5-17所示：你也可以使用专门的软件来管理看板，例如国外的Jira、国内的明道。

图5-17 敏捷开发项目管理看板

在冲刺中，每一天都会举行项目状况会议，被称为“每日站会”。会议在固定地点和每天的同一时间举行，对于迟到者团队常常会制定惩罚措施（例如罚款、做俯卧撑、在脖子上挂橡胶鸡玩具）。

不论团队规模大小，会议被限制在15分钟。所有出席者都应站立，每个人都必须发言。

会议的目标是讨论当前的任务的状态，一个推荐的汇报形式是：我昨天已经做了什么？我接下来准备做什么？现在遇到什么阻碍和问题？

注意在会议中团队成员不必要针对每个问题进行探讨，只是作为一个重要信息的反馈通道，具体问题相关成员在会后私下当面沟通解决，这样更加高效，避免浪费问题无关成员的时间。

4. 步骤4：产品测试和演示

因为每次的Sprint目标就是交付一个可以用的产品特性，所以测试工作非常重要。

有不少方法可以减少测试周期，比如，你可以减少需求数量，或者让开发参与测试。

当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成。这时，我们要进行演示会议，也称为评审会议。

产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum团队的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）。

5. 步骤5：回顾会议和下一个Sprint计划

每一个冲刺完成后，都会举行一次冲刺回顾会议。

回顾会议也称为总结会议，会议的时间限制在4小时，以轮流发言方式进行，每个人都要发言，哪里做得好、哪里不好都可以提出，总结并讨论改进的地方，放入下一轮Sprint计划。

三、Sprint冲刺会议

冲刺（Sprint）计划是Scrum中的事件。Sprint计划的目的是定义在Sprint中可以交付什么，以及如何实现该工作。

Sprint计划是由整个Scrum团队协作完成的。与体育界不同的是，Scrum鼓励总是全速前进，这样就可以在不断学习和改进的同时交付可用的软件。

在Scrum中，Sprint冲刺是完成所有工作的固定时间段，即一个迭代周期。在采取行动之前，必须设置冲刺时间，需要确定时间间隔将是多长时间，冲刺目标以及开始的位置。

冲刺计划会议通过设置议程和重点来开始冲刺。如果做得正确，它还将为团队创造动力，提供取得成功的环境。不良的冲刺计划可能会因设定不切实际的期望而使团队脱轨。

为了确保冲刺的顺利进行，在冲洗计划中要包含若干会议为冲刺过程提供支持，如图5-18所示。

图5-18冲刺计划包含会议

运行一个伟大的Sprint计划事件需要一些纪律。产品负责人必须做好准备，结合之前Sprint评审的经验教训、涉众的反馈以及他们对产品的愿景，从而为Sprint做好准备。

为了增加透明度，产品待办事项列表应该是最新的和细化的，以提供清晰的信息。

Backlog细分在Scrum中是一个可选的事件，因为有些Backlog不需要它。然而，对于大多数团队来说，最好是在Sprint计划之前让团队一起检查和细化Backlog。

输入Sprint计划的一个很好的起点是产品Backlog，因为它提供了一个“东西”的列表，这些“东西”可能是当前Sprint的一部分。团队还应该查看在增量中完成的现有工作，并查看容量。

输出Sprint计划会议最重要的结果是团队可以描述Sprint的目标，以及他们将如何开始朝着这个目标工作。这在Sprint Backlog中是可见的。

冲刺计划应该限制在每周冲刺不超过两小时。因此，例如，为期两周的Sprint计划会议将不会超过两个小时。这被称为“时间限制”，或者为团队完成一项任务设置最大时间量，在本例中是规划Sprint。

Scrum Master（敏捷教练）负责确保会议的时间安排被理解。如果团队在时间框内完成之前感到高兴，那么事件就结束了。时间框是允许的最大时间，没有最小时间限制。

在制定冲刺计划的过程中，很容易陷入“困境”，专注于哪个任务应该先做，谁应该做，以及需要多长时间。

对于复杂的工作，您在开始时所知道的信息水平可能很低，而且大部分信息都是基于假设的。Scrum是一个经验主义的过程，这意味着你不能预先计划，而是在实践中学习。

Sprint计划需要一定程度的评估。团队需要定义在Sprint中可以做什么，不可以做什么：估算工作量和团队能够承受的容量。

良好的评估需要一个基于信任的环境，在这个环境中，信息可以自由提供，并且在过程中讨论假设。如果评估中使用负面的，对抗性的方式完成工作,那么很有可能估算的工作量将很大，会造成不必要的资源浪费。

我们很容易陷入冲刺计划的细节，忘记冲刺计划的重点是为下一个冲刺建立一个“刚刚好”的计划。这个计划不应该成为团队背后的捣乱者，相反，它应该将团队的注意力集中在有价值的结果上，并为组织提供保护。

Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。

同样，Scrum采用了经验方法——承认需求无法完全理解或定义，因此关注如何使得开发团队快速响应不断出现的需求。

四、Bocklog用户故事

Sprint目标在高层次上描述了Sprint的目标，但是也可以在编写Backlog用户故事条目时体现。

为了切身了解客户的需求，有些产品设计的市场和研发团队尝试运用基于客户情形，透过观察客户、叙说故事、编写剧本、再现客户情境和体验，从而沟通传达客户需求的剧本导引设计法，利用人类内心思考、言词表达的编故事、说故事的基本能力，将设计者及产品开发有关人员带入产品使用时的情境，透过这种情境故事，让设计者将与产品设计有关之信息自我内化吸收，转换对团队沟通。

用户故事是从客户的角度描述工作的一种很好的方式，如图5-19所示。用户描述将缺陷、问题和改进重新集中于客户所寻求的结果，而不是所观察到的问题。通过向用户故事中添加清晰的、可度量的结果，你可以此评估什么时候能完成。

图5-19 用户故事示例

项目里不同的参与者有不同的需求，产品经理想跟踪进度，开发人员想实现，产品经理想功能，产品老大有更高的视角，而用户想要一个可用的系统，在这些充满冲突的视角中，想要做出一个人人都支持、皆大欢喜的决定，并且持续保持平衡是很困难的事情。

整个项目组就像一个四驱车，一个角色的强势就相当于一个轮子转得过快，这对产品都是损失，导致车子的方向偏移。

我们通过大家一起建立产品全景图的方式，让项目组所有人包括用户站在高空俯视产品，这种同一空间多点对多点的共识就自然地完成了。

我们通过这种一目了然、格式一致的故事地图，让项目组所有人都获得足够的信息，让项目有一个明朗的开发流程，如图5-20所示。

用户故事地图作为一种有效的需求工具，可以做到多角色、多视角。

以合作沟通的方式来全面理解用户需求，涉及的主题包括怎么以故事地图的方式来讲用户需求，如何分解和优化需求。如果通过团队协同工作的方式来积极吸取经验教训，从中洞察用户的需求，开发真正有价值的、小而美的产品和服务。

图5-20用户故事地图示例

用户故事地图是一个吸引用户参与设计他们所需产品的便捷手段。我们原型设计阶段的所有内容来源于用户故事地图，因为故事地图是用户全程参与的，所以在我们整个设计过程中都有用户的身影。

与参与性设计对立的是经验性设计。

在进行新产品设计时，经验性设计高度依赖前期的用户调研，包括用户访谈和用户观察，但是用户不会成为产品设计的真正参与者，后面的阶段基本是靠设计师经验，几乎没有用户身影。

但参与性设计“用户故事地图”通过简洁明了、场景还原的方式让用户参与其中，每个用户故事都做到站在用户的角度，使大家快速知道用户想要什么，为什么要这个。

用户故事易读、易懂，我们边聊故事的同时进行页面框架绘制，因此能激发用户的积极性，成为产品设计的参与者。

同时，随着用户渐渐掌握如何口头表达故事来描绘他们的需求，项目组成员与用户间的关系变得更加亲密主动，这种良性的循环使所有人员都获益良多。

思考：以往我们共识用户/产品需求的方式有两种，一种是文档，翻开一看，那些格式化的语言就变成了世界上最好的催眠曲。读尚且如此，写的人会怎么样？写文档的产品经理脑子里一定会回响一个问题：“这东西写了有人认真看么？”

有文档看还是好的，还有些产品经理会直接拉上团队成员聊，撰写用户故事地图，就算交接需求了，这两种方式你认为哪种更加敏捷有效？这里的共识是点对点的，或者单点对多点的，信息传递也会带来信息内容的损耗，甚至错误的信息。

作者：长乘，公众号：MVP-PM，历任两家世界500强企业产品专家！内容摘自：人民邮电出版社《独具匠心：做最小可行性产品（MVP）方法与实践》

本文由 @长乘 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议