2021-09-20日客套企业名录搜索软件新增111953条企业名录资源,注册提取>>>

这是Product Monk产品管理教程的第十五章。全部章节目录参见本文

瀑布模型

传统上,瀑布模型被看作一种SDLC(软件开发生命周期)方法。

瀑布模型,包括一个分步骤、线性前进的软件开发活动。在瀑布模型中,一个阶段的输出变成下一个阶段的输入,两者之间没有重叠的阶段。

软件开发瀑布模型

虽然瀑布模型是一个简单的、文档记录良好、可预测的工作流程。但是,它有很多缺点:

  • 产品中变动范围有限
  • 严重依赖于初始需求收集
  • 直到生命周期中的后期,才有产品原型的工作
  • 高风险和不确定性
  • 对真实客户无法使用功能的修改和测试,范围有限

敏捷方法

随着对更灵活SDLC方法的需求,敏捷成为首选方法。敏捷讨论的是迭代和增量的软件开发,这使它能够适应以后可能需要的变化。

迭代VS增量开发
  • 迭代产品开发——意味着通过连续的、迭代的改进周期来构建产品。你可以从能够完成任务的最粗糙实现开始,然后在每个阶段对其进行细化。不断改进它,在每次迭代中获取更多的价值,直到得到正确的产品为止。
  • 增量产品开发——指的是逐步构建你的产品。在每个周期的产品发布中,不断增加产品价值,实现一个产品增量(可以是一个功能特性或一个小的变化)。

敏捷结合了迭代产品开发和增量产品开发的好处,减少了开发成本和上市时间,还增加了响应式开发的好处。

根据敏捷宣言,我们必须重视:

  • 流程和工具之上的个体和交互
  • 在软件上投入工作,要胜过编写全面的文档
  • 客户合作高于合同谈判
  • 对变化做出反应,而不是按照计划行事

你可以在这里阅读更多敏捷原则的内容。

什么时候使用敏捷方法?

Stacy矩阵帮助你确定,何时使用敏捷方法

关于我们对问题的几种认知状态,是由美国前国防部长唐纳德·拉姆斯菲尔德提出的。他认为:世界上的事物可以分为这样几类:我们知道我们知道的,我们知道我们不知道的;此外,还有我们不知道我们知道的,以及我们不知道我们不知道的。下图描述了这四种信息。

Scrum框架

Scrum是众多敏捷方法中的一种,被众多敏捷实践者所实践。

它被定义为——“Scrum是一种通过降低复杂性,专注于构建满足业务需求产品的管理和控制过程。”

Scrum包含瀑布模型的所有活动,但是并没有将它们作为连续阶段来实现,而是将它们放入多个迭代或冲刺(sprint),从而创建可工作的产品。在每个sprint中,都可以添加和改进在前一个sprint中创建的特性和功能。

Scrum如何工作:

  1. 划分所有的需求(用户故事),并将它们安排到后备需求(Backlog)中
  2. 将工作划分为多个sprint
  3. 从后备需求中提取用户故事,形成当前Sprint的内容,并进行需求分析
  4. 对当前sprint的用户故事进行设计
  5. 实现
  6. 用户故事测试
  7. 以可工作软件产品的形式,发布这些特性
  8. 转移到下一个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和看板方法,都有一些相同的概念,但又有不同的方法。两者的对比参见下表。

下一章开始介绍产品的度量指标到底是什么。