产品开发管理
这是Product Monk产品管理教程的第十五章。全部章节目录参见本文。
瀑布模型
传统上，瀑布模型被看作一种SDLC（软件开发生命周期）方法。
瀑布模型，包括一个分步骤、线性前进的软件开发活动。在瀑布模型中，一个阶段的输出变成下一个阶段的输入，两者之间没有重叠的阶段。
虽然瀑布模型是一个简单的、文档记录良好、可预测的工作流程。但是，它有很多缺点：
- 产品中变动范围有限
- 严重依赖于初始需求收集
- 直到生命周期中的后期，才有产品原型的工作
- 高风险和不确定性
- 对真实客户无法使用功能的修改和测试，范围有限
敏捷方法
随着对更灵活SDLC方法的需求，敏捷成为首选方法。敏捷讨论的是迭代和增量的软件开发，这使它能够适应以后可能需要的变化。
- 迭代产品开发——意味着通过连续的、迭代的改进周期来构建产品。你可以从能够完成任务的最粗糙实现开始，然后在每个阶段对其进行细化。不断改进它，在每次迭代中获取更多的价值，直到得到正确的产品为止。
- 增量产品开发——指的是逐步构建你的产品。在每个周期的产品发布中，不断增加产品价值，实现一个产品增量(可以是一个功能特性或一个小的变化)。
敏捷结合了迭代产品开发和增量产品开发的好处，减少了开发成本和上市时间，还增加了响应式开发的好处。
根据敏捷宣言，我们必须重视：
- 流程和工具之上的个体和交互
- 在软件上投入工作，要胜过编写全面的文档
- 客户合作高于合同谈判
- 对变化做出反应，而不是按照计划行事
你可以在这里阅读更多敏捷原则的内容。
什么时候使用敏捷方法?
Stacy矩阵帮助你确定，何时使用敏捷方法
关于我们对问题的几种认知状态，是由美国前国防部长唐纳德·拉姆斯菲尔德提出的。他认为：世界上的事物可以分为这样几类：我们知道我们知道的，我们知道我们不知道的；此外，还有我们不知道我们知道的，以及我们不知道我们不知道的。下图描述了这四种信息。
Scrum框架
Scrum是众多敏捷方法中的一种，被众多敏捷实践者所实践。
它被定义为——“Scrum是一种通过降低复杂性，专注于构建满足业务需求产品的管理和控制过程。”
Scrum包含瀑布模型的所有活动，但是并没有将它们作为连续阶段来实现，而是将它们放入多个迭代或冲刺（sprint），从而创建可工作的产品。在每个sprint中，都可以添加和改进在前一个sprint中创建的特性和功能。
Scrum如何工作：
- 划分所有的需求（用户故事），并将它们安排到后备需求（Backlog）中
- 将工作划分为多个sprint
- 从后备需求中提取用户故事，形成当前Sprint的内容，并进行需求分析
- 对当前sprint的用户故事进行设计
- 实现
- 用户故事测试
- 以可工作软件产品的形式，发布这些特性
- 转移到下一个sprint，并将上一个版本的反馈包含到未来的sprint中
Scrum团队
一个理想的scrum团队由7个人（+/-2）组成。[杰夫·贝佐斯描述的2个披萨团队]
scrum团队不是一个基于能力的团队，而是一个跨职能的团队，由具备不同技能的不同成员组成(设计、前端开发、后端开发、数据库、测试)。
它拥有集体的知识和技能，这使得团队能够作为一个有凝聚力的单元，来把产品做出来(而不是依赖于外部团队)。
它作为一个团队，从用户角度交付产品功能(而不是从单一的能力或技术角度)。
产品负责人PO（Product Owner）
产品负责人是scrum团队和业务之间的桥梁。PO负责对后备需求的维护、添加(根据反馈)和优先级排序，并确保团队理解产品以及每个功能特性的目的和价值。
Scrum 专家（Scrum Master）
Scrum专家保持开发团队的生产力。Scrum 专家作为开发团队的仆人和领导者，确保他们的问题、关注点和障碍都得到解决。总而言之，scrum专家负责开发过程的顺利运行。
开发团队
开发团队负责产品的交付和质量。团队中没有任何层级，成员拥有不同的技能、专长和经验。
Scrum事件（Events）
冲刺Sprint
开发周期通常持续1到4周(持续时间贯穿整个项目)。团队在sprint期间，执行固定数量的任务，并在sprint结束时开发、测试和部署可工作的应用程序。
此外，在每一个sprint中，产品的可用性和价值都会随着功能的增加而增加，并且根据前一个sprint的反馈进行改进。
Sprint计划
sprint开始时，产品负责人(以及scrum团队)定义了在当前sprint中，团队需要实现的具体目标。然后基于这个目标，PO和团队从产品后备需求中选择用户故事，对其审查并提交到任务中。然后Scrum专家将这些任务添加到sprint的后备列表中。
每日scrum会议(站立会议)
团队会议花15分钟，通报彼此在上次会议之后的任务完成情况。他们会讨论当天的目标以及团队遇到的任何潜在障碍。
Sprint评审
在sprint的最后，团队会演示他们在sprint中开发的应用程序。
因此，这是团队获得产品反馈的机会。
Sprint回顾
Sprint专家指导scrum团队进行回顾。它的主要目的是在学习中，同时改进团队的过程。
度量指标
度量标准对于衡量团队的绩效非常重要。理解团队绩效如何的两个关键指标，是燃尽图（burndown chart）和产品开发速度。这两个指标都是基于故事点数的。
燃尽图提供了一个图形化视图，说明团队燃尽(完成)用户故事的速度有多快。它是后备需求中已经完成的故事数量，与sprint中仍需去做的用户故事总数的比值。
产品开发速度测量在sprint中用户故事完成的平均速率。我们可以通过已完成的故事点数，除以产品后备需求中的总故事点数来计算产品开发速度。
产品开发速度度量，在冲刺中预期完成的工作。它确保团队在sprint中不会过度使用。
看板方法（Kanban Methodology）
看板是一种专注于持续交付的敏捷方法。它使用了“准时制”（JIT）方法（1940年由丰田使用）——团队根据团队的能力将工作（WIP）拉进来，而不是将工作硬推进处理流程中。
看板是在看板Board的帮助下实现的。最基本的看板由3个泳道组成：
要做的（To do）、正在做的（Doing）、已完成的（Done）。但是，开发团队可能会使用更多的列。
看板中使用的关键绩效指标。
周期时间——团队完成一个任务/用户故事所需的时间。
Scrum v/s 看板方法
Scrum和看板方法，都有一些相同的概念，但又有不同的方法。两者的对比参见下表。
下一章开始介绍产品的度量指标到底是什么。
