敏捷开发的三个层次 - CSDN
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...

    Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。

    三个角色

    Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。

    Scrum 团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他 们。

    跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。

    Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了 每个迭代都有潜在可发布的版本。

    Scrum角色之:产品负责人

    产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不同而不同。

    产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

    ● 清晰地表达产品代办事项列表条目

    ● 对产品代办事项列表中的条目进行排序,最好地实现目标和使命

    ● 确保开发团队所执行工作的价值

    ● 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作

    ● 确保开发团队对产品代办事项列表中的条目达到一定程度的理解

    产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。

    产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

    为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负 责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发 团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

    Scrum角色之:开发团队

    开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。

    开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点:

    他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。

    开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

    Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。

    开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

    开发团队不包含如测试或业务分析等负责特定领域的子团队。

    Scrum角色之:Scrum Master

    Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。

    Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。

    Scrum Master 服务于产品负责人

    Scrum Master 以各种方式服务于产品负责人,包括:

    ● 找到有效管理产品代办事项列表的技巧

    ● 清晰地和开发团队沟通愿景、目标和产品代表事项列表条目

    ● 教导开发团队创建清晰简明的产品代表事项列表条目

    ● 在经验主义环境中理解长期的产品规划

    ● 理解并实践敏捷

    ● 按需推动Scrum活动

    Scrum Master 服务于开发团队

    Scrum Master 以各种方式服务于开发团队,包括:

    ● 指导开发团队自组织和跨职能

    ● 教导并领导开发团队创造高价值的产品

    ● 移除开发团队进展过程中的障碍

    ● 按需推动Scrum活动

    ● 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队

    Scrum Master 服务于组织

    Scrum Master 以各种方式服务于组织,包括:

    ● 领导并指导组织采用 Scrum

    ● 在组织范围内计划 Scrum 的实施

    ● 帮助员工及干系人理解并实施 Scrum 和经验性产品开发

    ● 发起能提升Scrum 团队生产力的变革

    ● 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum

    四个会议

    四个会议指的是Sprint计划会议、每日例会、Sprint评审会议和Sprint回顾会议。

    Sprint计划会议(Sprint Planning)

    在Scrum中,Sprint计划会议有两部分:

    1. 决定需要完成哪些工作?

    2. 决定这些工作如何完成?

    第一部分:需要完成哪些工作?

    参会人员:团队、项目负责人(Scrum Master)、产品负责人(Product Owner)

    第一部分的会议,产品负责人向开发团队介绍排好序的产品待办事项,由整个Scrum团队共同理解这些工作。

    Sprint中需要完成的产品待办事项数目完全由开发团队决定。做多少工作只能由开发团队决定,产品负责人或任何其它人都不能给开发团队强加更多的工作量。

    第二部分:如何完成工作?

    参会人员:Team 、Scrum Master

    第二部分的会议,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划,从而有信心可以在Sprint中完成所有工作。

    决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

    Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

    Sprint待办事项列表是一个需要在当前Sprint完成的且梳理过的产品待办事项,并包括了一个团队完成这些工作的计划。

    每日站会(Daily Scrum)

    开发团队是自组织的,通过每日站会来确认他们仍然可以实现Sprint的目标。

    每一个开发团队成员需要提供以下三点信息:

    ● 从昨天的站立会到现在,我完成了什么;

    ● 从现在到明天的站立会,我计划完成什么;

    ● 有什么阻碍了我的进展。

    每日Scrum通常不超过15分钟。

    每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。

    每日Scrum既不是向管理层汇报,也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队内部的沟通会议,来保证他们对现状有一致的了解。

    只有Scrum团队的成员,包括ScrumMaster和产品负责人,可以在会议中发言。其他感兴趣的人可以来旁听。

    Sprint评审会议(Sprint Review)

    Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的,Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时(比如,一个Sprint包含2个星期,则Sprint评审会议时长为2个小时)。

    每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表(Product Backlog)。

    Sprint评审会议向每个人展示了当前产品增量的概况。通常都会在Sprint评审会议中调整产品待办事项列表。

    Sprint回顼会议(Sprint Retrospective)

    在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时长的,Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint包含2个星期,则Sprint回顾会议时长为2个小时)。

    Scrum团队总是在Scrum的框架内,改进他们自己的流程。

    SCRUM的三个物件

    三个物件指的是产品待办事项列表(Product Backlog)、Sprint Backlog和燃尽图

    Product Backlog – 产品待办事项列表

    产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

    产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求。 产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。

    产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。

    产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列,每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。

    排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的 Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何 一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完 成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计 划会议中被选择。

    随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详 尽的列表。因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。业 务需求、市场形势和技术的变化都会引起产品待办事项列表的变化。

    若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。

    通过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断 的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而, 产品负责人可以随时更新产品代办事项列表条目或酌情决定。

    梳理在 Sprint 中是一项兼职活动,在产品负责人和开发团队之间展开。通常,开发 团队有自行优化的领域知识。然而,何时如何完成优化是 Scrum 团队的决定。优化通常占用不超过开发团队 10%的时间。

    开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的 决定。但是,最后的估算是由执行工作的人来决定的。

    SPRINT BACKLOG

    Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包 含在下个增量中,以及交付那些功能所需工作的预计。

    Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。Sprint 代办事项列表使开发团队确定的、达到 Sprint 目标所需的工 作清晰可见。

    Sprint 代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到 理解。开发团队在整个 Sprint 中都会修改 Sprint 代办事项列表,Sprint 代办事项列表也 会在 Sprint 的进程中慢慢显现,比如开发团队按照计划工作并对完成 Sprint 目标所需的 工作有更多的了解。

    当出现新工作时,开发团队需要将其追加到 Sprint 待办事项列表中去。随着任务进 行或者被完成,需要更新每项任务的估算剩余工作量。如果计划中某个部分失去开发的意 义,就可以将其除去。在 Sprint 内只有开发团队可以对 Sprint 待办事项列表进行修改。 Sprint 待办事项列表是高度可见的,是对团队计划在当前 Sprint 内完成工作的实时反 映,并且,该列表只属于开发团队。

    Product Backlog 功能点被放到Sprint的固定周期中,Sprint Backlog 会因为如下原因发生变化:

    ❶随着时间的变化,开发团队对于需求有了更好的理解,有可能发现需要增加一些新的任务到Sprint Backlog中。

    ❷程序缺陷做为新的任务加进来,这个都做为承诺提交任务中未完成的工作。

    Product Owner也许会和Scrum team一起工作,以帮助team更好的理解Sprint的目标,ScrumMaster和team也许会觉得小的调整不会影响sprint的进度,但会给客户带来更多商业价值。

    燃尽图(BURN-DOWN CHART)

    Sprint燃尽图(Sprint Burn-down Chart)

    Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

    在Sprint开始的时候,Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成,但没有完成的任务的工作量是累积工作量,团队会根据进展情况每天更新累积工作量,如果在Sprint结束时,累积工作量降低到0,Sprint就成功结束。

    由于在Sprint的刚开始的时候,增加的任务工作量可能大于完成的任务工作量,所以燃尽图有可能略微呈上升趋势。

    发布燃尽图(Release Burn-down Chart)

    在Scrum项目中,团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期,以Sprint为单位, Y轴代表的是剩余工作量,通常以用户故事点、理想人天或者team-days为单位。

    展开全文
  • 敏捷开发三个流程

    千次阅读 2017-08-07 10:45:42
    Scrum敏捷开发流程主要包扩三个角色、四个会议和三个物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...

    Scrum敏捷开发流程主要包扩三个角色、四个会议和三个物件。

    三个角色

    Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。

    Scrum 团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他 们。

    跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。

    Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了 每个迭代都有潜在可发布的版本。

    Scrum角色之:产品负责人

    产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不同而不同。

    产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

    ● 清晰地表达产品代办事项列表条目

    ● 对产品代办事项列表中的条目进行排序,最好地实现目标和使命

    ● 确保开发团队所执行工作的价值

    ● 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作

    ● 确保开发团队对产品代办事项列表中的条目达到一定程度的理解

    产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。

    产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

    为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负 责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发 团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

    Scrum角色之:开发团队

    开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。

    开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点:

    他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。

    开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

    Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。

    开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

    开发团队不包含如测试或业务分析等负责特定领域的子团队。

    Scrum角色之:Scrum Master

    Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。

    Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。

    Scrum Master 服务于产品负责人

    Scrum Master 以各种方式服务于产品负责人,包括:

    ● 找到有效管理产品代办事项列表的技巧

    ● 清晰地和开发团队沟通愿景、目标和产品代表事项列表条目

    ● 教导开发团队创建清晰简明的产品代表事项列表条目

    ● 在经验主义环境中理解长期的产品规划

    ● 理解并实践敏捷

    ● 按需推动Scrum活动

    Scrum Master 服务于开发团队

    Scrum Master 以各种方式服务于开发团队,包括:

    ● 指导开发团队自组织和跨职能

    ● 教导并领导开发团队创造高价值的产品

    ● 移除开发团队进展过程中的障碍

    ● 按需推动Scrum活动

    ● 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队

    Scrum Master 服务于组织

    Scrum Master 以各种方式服务于组织,包括:

    ● 领导并指导组织采用 Scrum

    ● 在组织范围内计划 Scrum 的实施

    ● 帮助员工及干系人理解并实施 Scrum 和经验性产品开发

    ● 发起能提升Scrum 团队生产力的变革

    ● 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum

    四个会议

    四个会议指的是Sprint计划会议、每日例会、Sprint评审会议和Sprint回顾会议。

    Sprint计划会议(Sprint Planning)

    在Scrum中,Sprint计划会议有两部分:

    1. 决定需要完成哪些工作?

    2. 决定这些工作如何完成?

    第一部分:需要完成哪些工作?

    参会人员:团队、项目负责人(Scrum Master)、产品负责人(Product Owner)

    第一部分的会议,产品负责人向开发团队介绍排好序的产品待办事项,由整个Scrum团队共同理解这些工作。

    Sprint中需要完成的产品待办事项数目完全由开发团队决定。做多少工作只能由开发团队决定,产品负责人或任何其它人都不能给开发团队强加更多的工作量。

    第二部分:如何完成工作?

    参会人员:Team 、Scrum Master

    第二部分的会议,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划,从而有信心可以在Sprint中完成所有工作。

    决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

    Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

    Sprint待办事项列表是一个需要在当前Sprint完成的且梳理过的产品待办事项,并包括了一个团队完成这些工作的计划。

    每日站会(Daily Scrum)

    开发团队是自组织的,通过每日站会来确认他们仍然可以实现Sprint的目标。

    每一个开发团队成员需要提供以下三点信息:

    ● 从昨天的站立会到现在,我完成了什么;

    ●  从现在到明天的站立会,我计划完成什么;

    ● 有什么阻碍了我的进展。

    每日Scrum通常不超过15分钟。

    每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。

    每日Scrum既不是向管理层汇报,也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队内部的沟通会议,来保证他们对现状有一致的了解。

    只有Scrum团队的成员,包括ScrumMaster和产品负责人,可以在会议中发言。其他感兴趣的人可以来旁听。

    Sprint评审会议(Sprint Review)

    Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的,Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时(比如,一个Sprint包含2个星期,则Sprint评审会议时长为2个小时)。

    每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表(Product Backlog)。

    Sprint评审会议向每个人展示了当前产品增量的概况。通常都会在Sprint评审会议中调整产品待办事项列表。

    Sprint回顼会议(Sprint Retrospective)

    在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时长的,Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint包含2个星期,则Sprint回顾会议时长为2个小时)。

    Scrum团队总是在Scrum的框架内,改进他们自己的流程。

    SCRUM的三个物件

    三个物件指的是产品待办事项列表(Product Backlog)、Sprint Backlog和燃尽图

    Product Backlog – 产品待办事项列表

    产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

    产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求。 产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。

    产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。

    产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列,每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。

    排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的 Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何 一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完 成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计 划会议中被选择。

    随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详 尽的列表。因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。业 务需求、市场形势和技术的变化都会引起产品待办事项列表的变化。

    若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。

    通过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断 的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而, 产品负责人可以随时更新产品代办事项列表条目或酌情决定。

    梳理在 Sprint 中是一项兼职活动,在产品负责人和开发团队之间展开。通常,开发 团队有自行优化的领域知识。然而,何时如何完成优化是 Scrum 团队的决定。优化通常占用不超过开发团队 10%的时间。

    开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的 决定。但是,最后的估算是由执行工作的人来决定的。

    SPRINT BACKLOG

    Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包 含在下个增量中,以及交付那些功能所需工作的预计。

    Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。Sprint 代办事项列表使开发团队确定的、达到 Sprint 目标所需的工 作清晰可见。

    Sprint 代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到 理解。开发团队在整个 Sprint 中都会修改 Sprint 代办事项列表,Sprint 代办事项列表也 会在 Sprint 的进程中慢慢显现,比如开发团队按照计划工作并对完成 Sprint 目标所需的 工作有更多的了解。

    当出现新工作时,开发团队需要将其追加到 Sprint 待办事项列表中去。随着任务进 行或者被完成,需要更新每项任务的估算剩余工作量。如果计划中某个部分失去开发的意 义,就可以将其除去。在 Sprint 内只有开发团队可以对 Sprint 待办事项列表进行修改。 Sprint 待办事项列表是高度可见的,是对团队计划在当前 Sprint 内完成工作的实时反 映,并且,该列表只属于开发团队。

    Product Backlog 功能点被放到Sprint的固定周期中,Sprint Backlog 会因为如下原因发生变化:

    ❶随着时间的变化,开发团队对于需求有了更好的理解,有可能发现需要增加一些新的任务到Sprint Backlog中。

    ❷程序缺陷做为新的任务加进来,这个都做为承诺提交任务中未完成的工作。

    Product Owner也许会和Scrum team一起工作,以帮助team更好的理解Sprint的目标,ScrumMaster和team也许会觉得小的调整不会影响sprint的进度,但会给客户带来更多商业价值。

    燃尽图(BURN-DOWN CHART)

    Sprint燃尽图(Sprint Burn-down Chart)

    Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

    在Sprint开始的时候,Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成,但没有完成的任务的工作量是累积工作量,团队会根据进展情况每天更新累积工作量,如果在Sprint结束时,累积工作量降低到0,Sprint就成功结束。

    由于在Sprint的刚开始的时候,增加的任务工作量可能大于完成的任务工作量,所以燃尽图有可能略微呈上升趋势。

    发布燃尽图(Release Burn-down Chart)

    在Scrum项目中,团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期,以Sprint为单位, Y轴代表的是剩余工作量,通常以用户故事点、理想人天或者team-days为单位。

    展开全文
  • 敏捷开发

    千次阅读 2019-04-01 10:18:32
    今天来篇正经的,从软件工程的角度来聊一聊敏捷开发模式,文章分两部分: 第一部分通过举例和对标其他行业聊聊软件开发模型的发展演进。 第二部分聊聊敏捷的核心思想。 敏捷开发是互联网界比较流行的软件开发模式...

    「齐齐兽」公众号授权转载
      原文连接:原文连接

    今天来篇正经的,从软件工程的角度来聊一聊敏捷开发模式,文章分两部分:

    第一部分通过举例和对标其他行业聊聊软件开发模型的发展演进。

    第二部分聊聊敏捷的核心思想。

    敏捷开发是互联网界比较流行的软件开发模式,产品、技术、项目管理、运营、美术和测试等各岗位对其理解后都大有益处,运用得当可以事半功倍。现在信息爆炸、良莠不齐,网上很多讲敏捷的文章,Scrum词意没理解到位。去年看了敏捷革命的原版《Scrum: The Art of Doing Twice the Work in Half the Time》,结合大学所学的软件工程聊一聊这个话题,here we go~

     第一部分

    瀑布模型

    先上定义:瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作软件概念,主要分为需求分析,架构设计,详细设计,实现,单元测试,集成部署,系统测试,运营维护。瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠。

    为什么会有瀑布模型?

    如果一个人接项目,他也许不需要这么麻烦,但规模稍微大一些,就需要多人协作,这时候就需要有标准有规范。最开始的时候,大家用了建筑工程领域的模型来对标软件工程。是盖住宅还是盖工厂,或是商厦或是办公楼或是博物馆,需要有严谨的建筑设计图,水电管道布线甚至装修方案,才开始施工。瀑布模型就是这个思维,所以瀑布模型对软件架构师的要求很高,在瀑布模型下,如果把开发软件作为盖栋建筑的话,coder只需要“搬砖”就可以了(在敏捷开发过程中,对研发团队人员的要求会较高,瀑布重视流程、文档,敏捷强调团队内人员能力,特别是cross-functional,要有跨领域的能力。也有人把瀑布模型折叠起来,变成了V字型,目的是每个阶段都有要去验证的东西,看起来是有迹可循的,前后阶段是对应的。个人觉得瀑布模型最重要的是给大家树立了软件工程的基本观念:

    1.前期做足功课很重要;

    2.编码只是软件工程中的一部分。

    「V字模型」

    瀑布模型有什么问题?

    慢慢大家发现,瀑布模型有很多限制和问题,最主要的是不能拥抱变化盖大楼毕竟跟开发软件不一样,软件的需求往往是不断变化的,瀑布模型往往会导致牵一发而动全身,这就导致绝大多数瀑布模型是延期的,而且出来的东西也不是用户最初想要的。客户想要一把瑞士军刀,最终只出来一把螺丝刀,甚至只是一根小木棍儿。。。人们逐渐想办法克服了这个问题,这就是统一软件开发过程(RUP:Rational Unified Process)

    统一软件开发过程

    RUP是瀑布模型的改进,可以这样理解,这个模型把软件开发过程的类比从建筑行业改到了汽车行业。主要认清了两点:

    1.软件是不断迭代的;

    2.软件应该是面向对象的;

    当然,还有很多其他方面的改进细节,就不展开了。一个车型可以是系列的,舒适版、技术版、豪华版,不同年份还不一样,是不断迭代更新的。要想造一辆车,团队可以分头行动,简化一下比如要做一个四只脚的木凳,甲可以先去做凳子面,乙去做凳子腿,前提是两个人定义好怎样连接(接口),用什么样的螺丝,多大的孔,在什么位置连接,凳子腿多高等等,也可以有个专门的丙(项目经理)去协调这些事情。这样凳子腿可以在这个基础上自由地涂些花纹,加个皮套,做些镂空等等。

    「改进后的瀑布模型」

    这个模型已经具备了高内聚低耦合的思想,但还是有个问题,客户或领导通常想看到一些进展,也许一辆车从设计到出厂需要两年,但每几个月大家可以看到一些实实在在的东西,以上面做凳子为例,我们是可以看到凳子腿和凳子面的,也可以想象它们连接起来的样子。而软件不一样,只要各个模块还没有效的连接起来,那基本上啥都没有,特别是对于大多数没有计算机知识的人,基本上是一个“黑盒”过程。这个模型同样面临着延期超预算的风险,同时做出来的也不一定是客户想要的。

     

    随着互联网的发展,对软件的变化需求越来越高,就产生了大家最熟悉的迭代模型,inception,elaboration,construction,transition,四个阶段形成闭环,不断循环往复,其核心理念是软件是增量开发的每次迭代都能看到些进展。敏捷开发就是在这个生命周期模型下演变而来。

    「迭代模型」

    螺旋模型

    接着就有了螺旋模型,螺旋模型并不是推翻了瀑布和RUP,是一种改进,从某种角度来说螺旋也是遵循瀑布模型的,每一次螺旋迭代都要有清晰的目标,明确的需求,规划实现,交付条件等,这个循环也是迭代模型的迭代周期演变。比如说要做一辆汽车,我们可以先做一个自行车,再逐渐地在自行车上加个铃铛,加上发动机,变成4个轮子,加个篷,车把变成方向盘。。。在各方面持续地螺旋迭代下去,最终会出来一个跟汽车差不多的东西。这个例子有一些原型法的味道,螺旋模型往往是较大较复杂的系统使用,目的是减小风险,每一次投入能看到一些东西的产出,希望把整个过程“白盒化”。

    「螺旋模型」

    总结

    以上是关于软件工程的三个主要生命周期模型,逐渐地又出现了极限编程、原型开发、敏捷开发等模型。严格来讲,瀑布模型、迭代模型是生命周期层面的模型(当然,通常也包含了一系列开发层面的工具集),敏捷开发是基于迭代模型发展起来的一整套软件开发指导原则。个人观点是在实际操作中应重视指导原则,弱化方法论。迭代模型在学术上很早就有人提出,敏捷开发的作者之所以能从不同的视角去看待软件开发,并有独特的思维和管理方法,这跟他的个人经历有很大关系,因为他不是做计算机出身为了理解他的思想,我特意购买了《敏捷革命》的英文原版《Scrum,The Art of Doing Twice the work in Half the Time》来阅读,下面部分分享其核心观点。


    第二部分

    我们可以看看《Scrum》的作者杰夫·萨瑟兰的经历,他之所以能以全新的视角来认识和理解软件工程这件事情,很重要的原因在于他不是做这个行业出身。

     

    作者的经历

    杰夫·萨瑟兰毕业于著名的西点军校,他以战斗机飞行员的身份去参加越南战争,在他的队伍里50%的飞行员会被击落,一些会被营救,一些再也回不来。在这个环境里他构建了自己的行动模型,即OODA(Observe,Orient,Decide,Act)执行任务的每时每刻都在重复着这个循环,犹豫就会死。这个行为模式在他的著作里能感受到已经深入骨髓。

     

    参加完越南战争后,他去斯坦福进修了统计学硕士学位。后来边在空军学院做数学教授,边读了一个生物统计学博士,研究细胞、癌症相关的一些东西,学习了系统论方面的东西。在研究细胞的时候,他会不断考虑一个问题:whether the new state is better than the old one 现在这个状态是不是比上一个好。《敏捷革命》原文中多次提到state这个词,这也是作者非常重要的一种思考方式。

     

    其离开大学的第一份工作是做美国的ATM,这个时候他把自己在战争和研究细胞中的方法应用于IT领域,后通过大量实践(其中有为FBI构建犯罪嫌疑人数据库,著作中的重要案例)逐步总结发展出了敏捷模型理论。另外,Scrum不是作者的首创,作者是根据日本两个教授的理论发展总结而来。在学术界,日本的两个教授质疑瀑布,他们认为最好的团队应该像打橄榄球一样,球在队伍中间穿梭,队伍整体快速向目标移动(这才是Scrum想要表达的意思),日本的大企业最开始用这种指导思想(细算一下正是日本IT大发展的时代)。理论早就有了,但很少有美国人这样去实践,作者为了理解日本人的Scrum思想,练习了多年合气道,并用合气道来类比Scrum,并再次用到了“state”思维方式来解释。

    Scrum&Cross-functional

    说到Scrum,我们来聊聊cross-functional。橄榄球大家可能不熟,我们来聊聊篮球。球队里最吃香的是哪种人,当然是那种什么位置都能打且都打得好的,俗称万金油。勒布朗·詹姆斯号称可以从1号位打到5号位,这种人可以体会到在各个位置的人的“不容易”,从而更有利于团队发展。奥尼尔给人篮下巨无霸的印象,但其实他有灵活的运球技巧和出色的娱乐表演天赋,这些综合到一起才成为球迷心中大鲨鱼的人设。NBA里那些最受人崇拜的顶级后卫,基本都会多种绝学,乔丹科比韦德等人,控球、得分、突破、抢板、分球等各项技能均能登堂入室,有些方面甚至前无古人。有一项技能特别突出基本就可以独步武林,但想成为顶级选手,一定是cross-functional的而作为球队老板,希望在有限的资源下,尽可能多地把这种选手招致麾下,才有可能对拉里·奥布莱恩杯发起冲击。勇士的“死亡五小”更是将这种理念发挥到了极致,场上队员几乎都能快攻、投篮和抢板。

     

    回头来看,软件开发也是,cross-functional是对团队人员素质要求的提高,正所谓不会写代码的产品不是好美术。软件开发也是个跨兵种共同协作的同时不断面临变化的事情,从这个角度来看,跟打篮球和橄榄球是相同的,还记得NBA赛场上暂停时大家是怎么解决问题的么,结合上面说的场景“球在队伍中间穿梭,队伍整体快速向目标移动”,这是Scrum中非常重要的理念。

    敏捷作者的一些核心观点(为保原汁原味,摘抄部分原文)

     

    传统的瀑布模型其实是由一大堆图表构成,作者表达了对图表的一些观点:

     

    • Planning is useful. Blindly following Plans is stupid;计划是有用的,但盲目的按计划走是愚蠢的。这跟作者的从军经历有关,其执行任务的时候都是随机应变,也应了中国的那句老话“计划没有变化快”。

    • Every project involves discovery of problems and bursts of inspiration,scrum embraces uncertainty and creativity.任何一个项目都包含了未发现的问题以及随着项目进行的灵感爆发,图表会限制这些,Scrum“拥抱”这些不确定性和创造性。

    • Stop doing what you’re doing ,review what you’ve done;放下手中的事情,想一想我们在干啥。

     

    作者对“敏捷”的一些观点:

    MVP                    

    Minimum viable products to get immediate feedback from consumers,rather waiting until a project is finished;最小化可行产品Minimum viable products,也简称MVP(搜索这个短语会有大量方法论)。用最小化的可行产品来从用户那里快速获得回馈,而不是一直等项目完成。我们通常说的“小步快跑”;

     

    Inspect and Adapt cycle

    上面说的OODA行动模型的抽象,“观察—适应”,这两个过程不断循环。这里面作者提到了一个常用的方法5W2H,在每一个阶段(state)都问自己:

    • What;我们要做的是什么,有什么意义,现在是什么状态;

    • Why;我们为什么要做这个,可不可不做,有替代方案么;

    • When;什么时候做,deadline是什么;

    • Where;在哪做,哪里要用;

    • Who;谁来做,谁对此负责;

    • How;怎么来做,如何配合;

    • How much;多少、程度,多大开销,做到什么程度;

     

    敏捷革命可以应用在各行各业,作者已经在汽车制造、开洗衣店、学生培训、制造宇宙飞创、婚礼策划等领域展开实践,所以说Scrum模型不只是一套软件开发工具集,是具有普世性的价值观

    Agile Manifesto, It declared the following values:people over process;products that actually work over documenting what that product is suposed to do;collaborating with customers over negotiating with them;and responding to change over following a plan,Scrum is the framework I built to put those values into practice.There is no methodology.这就是敏捷宣言的所有原文,后来被各种媒体放大和解读,其实它非常简洁。敏捷宣言,它强调了以下价值观:

                           重于    过程;

    产品真正好用    重于    文档里的设计;

    跟用户合作        重于    跟他们谈判;

    对变化做回应    重于    按计划去做; 

    我建立Scrum模型就是为了把以上价值观揉进一套工具集以方便更好地实践,敏捷模型没有方法论;(没有方法论,没有方法论,没有方法论,这是作者的原话啊,啪啪啪打脸有木有);

     

    总结

    Scrum原著以案例来表达了他对图表、文档、对计划、对团队、对过程管理的一些观点,而Scrum正是这一系列价值观的合集,这才是Scrum的精髓所在,为了快速实践和方便理解这些价值观,作者提供了一些方法比如每日立会、sprint、backlog等。具体方法不赘述了,网上有很多介绍。这些方法都是为了落实上面的观点:我们处在什么状态,我们有什么,如何做下个状态会比现在的好。。。

     

    相比于拿过来方法直接使用,理解好上面的观点再根据实际情况选择方法是更有效的思路。

     

    友情推荐:此文转载于朋友的公众号「齐齐兽」,每周一篇高质量文章。如果你是程序员或产品经理,微信扫描底下二维码,必有收获!

    展开全文
  • ThoughtWorks的敏捷开发

    千次阅读 2018-07-23 11:19:45
    敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发既不是Scrum,也不是XP。 造成这状态的原因,...

    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发既不是Scrum,也不是XP。

    造成这个状态的原因,一方面是行业特点 —— 软件开发还是一个充满不确定性的手工业,方法套路当然不可避免因人而异;另一方面作为一个提倡端到端软件交付的组织,敏捷开发本身并不能解决我们所有的问题。基于这两点,大家都不是特别愿意去总结ThoughtWorks的敏捷方法,换言之“标准化”就不在我们的基因里。

    标准化的初衷

    那么为什么这个时间点来谈这件事情呢?从我个人角度来说对内对外都到了必须总结的时间点。在上一篇文章《忘记“规模化敏捷”》中,我批判了市场上的所谓规模化敏捷框架,如空中楼阁,概念打包。但这样的现象确实也表明敏捷开发已经进入大规模采用阶段,一定的标准化是必须的。

    ThoughtWorks快20年的敏捷开发实战经验不总结给更广大的社区,于我自己感觉是一种不负责任。对内ThoughtWorks中国已经从我加入时,北京东西宫每天流窜两趟招呼到所有人,变成了全国六地1,200多人的数字化服务公司。每年还是很多人为着敏捷慕名而来加入ThoughtWorks,而我能给新员工分享一点敏捷开发实践的机会可能一年一次都难了。

    留在ThoughtWorks的一个重要原因就是差异永远大于共识,这样的环境里想总结点啥,没实战经验保底肯定是会被鄙视的。作为一个开发加入,在近十年的ThoughtWorks生涯里,我做过敏捷开发里除了测试以外的所有角色,如果把咨询的部分经验算成敏捷教练,和最近在努力的UX方向,应该是给了我足够全面的视角来审视ThoughtWorks的敏捷开发。在中国区持续最长时间的离岸敏捷交付团队近4年的经历,和敏捷咨询8年的经历也应该让我有一定经验支撑来谈这个话题。

    标准化的范围

    即使有上面的经验,也只能聚焦在“开发”,而不是“ThoughtWorks敏捷”。针对市场探索和产品创新的方法仍然存在根本性认知上的不同,数字化时代的不确定性又让此刻去更大范围标准化的想法不切实际。但我认为敏捷开发 —— 即从开发团队启动交付到持续迭代运行 —— 已经为我们应对市场不确定性,构建高响应力组织,提供了基石,让我们能够在数字化时代将整个软件开发逐渐改进为真正的价值和成效驱动,而不仅仅是快速交付了一堆不知道有用没用的特性。

    在下面的总结过程中有两个“技术处理”希望大家理解。

    第一,软件开发手工业的属性造成了不同的团队成熟度显然是不同的,总结的ThoughtWorks敏捷开发实践并非所有团队都能够做到,但我强调的一点是所有团队都共识这些实践是有价值的,可能出于某种外部约束做不了,比如部门墙造成业务人员无法参与。

    第二,尽量不引入ThoughtWorks自己的“黑话”,跟Scrum、Kanban和XP这些经典框架相似的实践,保持命名一致,毕竟标准化的作用之一是对外推广。

    换上咨询顾问的帽子,ThoughtWorks敏捷开发方法应该是现在市面上实践过程中最接近敏捷宣言价值主张的实战了。当然距离理想的价值和成效驱动的精益模式仍然有相当的距离,面临的挑战和困难可能不是敏捷开发能够解决的,但这些问题现在却反过来在压迫正确的敏捷开发方法,造成不少团队越来越多的困惑。当一个有追求的开发团队需要持续去解释TDDPair不会降低效率时,技术卓越的追求就在逐步被消磨了。

    ThoughtWorks敏捷开发核心原则

    铺垫很长,希望尽可能在讨论范围上保持客观,现在让我们一起来看看ThoughtWorks敏捷开发模式。

    为了帮助大家理解,我尝试从软件开发实践和管理体系两个维度去解释。先列举一下核心实践,然后从软件开发的几条管理主线帮助大家串联一下这台看似松散,实则精密的机器。这里要再次提醒大家我们讨论的范围仅仅是开发段,所列实践也不会特别关注团队文化建设。

    在展开具体实践前,首先要明确ThoughtWorks敏捷开发的核心原则:价值驱动、技术卓越。

    这两个四字短语在ThoughtWorks这个开发系统里有着不可撼动的地位。毕业刚加入的热血青年质问项目经理一个Story的价值何在?AngluarReact谁更全面?这样的讨论在内部是被鼓励的。

    这两个核心原则甚至上升到了价值观的层面,于是我们认为好的客户一定能够“耐心”跟团队辩论价值,而让团队“听我的”业务人员基本只能维持在一个商务上的甲方。如果开发团队某晚上努力把Angular换成React,管理者(甚至客户)也被要求在强调风险管理的基础上,肯定团队为技术卓越追求付出的努力。

    这对管理人员来说近乎是残忍的,这也是为什么ThoughtWorks在2010年左右经历了一批外聘PM的离职。虽然现在我们创造出了很大PM的管理空间,但值得警惕的是如果没有那些“恼人”的价值问题,和技术上的一点偏执,ThoughtWorks敏捷开发模式很可能就不存在了。

    ThoughtWorks敏捷开发核心实践

    在核心原则下,ThoughtWorks不同团队实践非常多,想要找到万变不离其中的骨干其实挺困难的。记得当年一家保险公司CIO带队来参观,看完早站会后直言不讳没有看懂一个50人的团队在干啥,只看到不同人群在自由组合。于是我花了一个早晨只为解释一小时过程背后的“隐次序”。


    (图:一个现场团队的早站会)


    (图:这是一个离岸团队的现场)

    既然是核心实践,就从一个最小集开始,如果减掉我就认为不再是ThoughtWorks的敏捷开发模式。当然由于ThoughtWorks开发团队更多做的是互联网软件的开发,这个实践集并不一定适用于类似嵌入式设备和合规系统的软件开发。以下是我认为的集合,欢迎大家一起来研讨!

    1. 基于统一迭代节奏的全功能团队

    刚加入ThoughtWorks的时候认识到开发团队除了开发和测试(当然这里我们认为是QA)外,还有BA —— 业务分析师。10年前这个角色在和任何客户合作的时候都需要解释,当然现在大家都已经在开始谈论UX和DevOps了。全功能团队这个实践本身并非是说要固定哪些角色在开发团队,而是强调为了交付软件所需要的技能都应该在一个团队里。在不远的将来,可能我们会再讨论Data Scientist的融入问题。

    这个实践还要强调“统一迭代节奏”,要求团队各个角色同步协作,而不是每个角色自己迭代。我看见过太多的伪全功能团队,一个迭代开发完的Story由QA下一个迭代测试。


    (图:全功能团队跨职能协作示意,一个典型团队包含了BA、Dev、QA和UX。)

    2. 基于Story的需求及范围实时管理

    Story是开发团队的最小工作单元,由于价值驱动的原则,Story INVEST原则是各个角色广泛认可的。如果哪个角色(包含业务)看不懂一个Story,那么大家会认为Story本身有问题。

    ThoughtWorks敏捷开发不对Story进行更技术的Task拆分,这样做保证了大家都关注Story承载的业务价值,当然这需要技术能力上的“全栈”文化支持,即大家以能够同时做多个技术栈为荣。

    运行成熟的ThoughtWorks开发团队有Tasking这个环节,形式可能是全队在迭代启动会上针对复杂Story进行“实现预演”,也可能是资深开发人员在自己显示器上贴出的彩色纸条,每张纸条承载着一个技术动作。小虫和晶晶是我见过把这种Tasking深入工作骨髓的人,有幸看到他们基于这种Tasking模式的神pair是终生难忘的!


    (图:开发人员贴在显示器前彩色的Tasking小纸条)

    虽然有整体项目的Backlog,但Story一般是迭代澄清,为了保证统一迭代,BA一般只会提前一个迭代梳理下一个迭代(类似Scrum中的Sprint)的需求。非常成熟的ThoughtWorks开发团队在这个过程中能够让客户或业务负责人持续迭代参与Story澄清,并能够持续调整Story优先级

    国内由于固定合同项目较多,很多需求澄清发生更早,但实际上很多人不理解保持一定并发性,正是驾驭软件不确定性的关键。“实时性” 是精益Just In Time能够起作用的核心机制。

    范围管理上由于这样的Story迭代机制,基本也需要实时,常用的工具是燃起图(Burn-Up)和累积流量图(CFD来至于Kanban)。Scrum的燃尽图并不推荐,原因是很容易营造一种遵循计划的假象。对于客户/业务和项目管理者,从燃起图能够看到实时需求范围的变化,按期交付风险也能够实时推测。累计流量图在成熟团队广泛应用,它能够直观告诉开发团队瓶颈在哪里,驱动改进。能够收集累计流量图所需的数据,本身也说明团队具备了一定的成熟度。



    (图:燃起Burn-Up图示意,上图为一个最简单的统计展现,仅包含已完成和总共的Story个数。下图是一个相对长期和复杂产品,针对Story进行了类型划分的管理。注意这里的“完成”,包含了Story的分析、开发和测试,甚至一些团队Story DoD中要求上线。制造过程中的Story都是没有完成。)

    行业里目前很关心这方面的电子化平台,ThoughtWorks由于历史原因,用各种平台都有,目前最多的是Jira、Mingle和Rally。但实际上这些平台主要目的还是为了离岸敏捷交付团队,本地的交付团队很多是物理墙+Excel(或Trello)。Story本身不作为审计和追责记录,真正的交付是线上工作的软件。

    3. 基于持续集成和测试前置的质量内建

    持续集成是敏捷实践中最广泛共识的技术实践(没有之一)。ThoughtWorks对持续集成的重视可以从历史经典的开源CrusieControl窥见一斑。由于大显示器的普及和CI展示看板的美化,现在各个团队基本都采用一个显示器展示CI的实时构建情况,但历史上还是有很多类似警报灯这样的创意出现的。


    (图:为一个典型的团队CI看板展示)


    (图:看板一般所在的团队位置。)

    ThoughtWorks持续集成纪律有两条核心,第一是必须每次提交触发构建;第二是每次提交必须基于上次的成功构建。这两条纪律是底线。如果有人说哪个团队CI红着没有修复,基本就等于说这个团队没有干活儿,因为理论上对着失败的构建提交代码是无效的。

    持续集成对代码管理的要求是主干开发,这是ThoughtWorks开发团队的默认模式。去年和刘冉、覃宇通过《代码管理核心技术及实践》一书阐述了行业内流行的分支开发模式实践和工具,但在ThoughtWorks内部,即使对使用比较广泛的GitFlow模式,也是持负面意见居多。显然主干开发的代码管理成本是最低的,但同时也引入了较高的代码实践能力和协同纪律的要求。

    持续集成已经是软件开发过程中质量内建的经典实践,在这个基础上ThoughtWorks开发团队有共识的是测试前置,落地过程中有两个经典方法,即开发的TDD和提前验收(Desk Check或叫Shoulder Check)。

    TDD不用在这里多讲了,每年总会有一两次争论,第二个“D” —— Drvien —— 驱动,永远是大家争论的焦点,但先写单元测试是ThoughtWorks程序员基本素养。代码走查形式多样,但成熟团队一般都从单元测试开始,如果你跟骨灰级程序员新老头走查,他会第一句问你“给我看看你的测试”。

    提前验收操作起来是比较容易的,即开发人员完成Story后,在最后提交前邀请BA和QA快速在开发机上做展示。这样做的好处是尽量避免Story被移动到后期测试或客户验收的时候,才发现需求实现有问题,返工浪费。由于这个预验收时间很快,所以有些团队说是“站肩膀后面”检查。当然这个不是机械的规定,简单Story也不一定要做提前验收。


    (图:提前验收现场,Story开发人员快速讲解实现,现场客户也有可能参加到Story验收交流中。)

    ThoughtWorks敏捷开发对回归测试考虑不多,质量内建意味着不希望最后靠测试把质量关,相比之下,大家对代码走查和Pair这些开发过程中的质量实践更看重,但这些实践的频繁运用在很多团队都受到了成本的约束,并非普遍。关于分层的自动化测试也是一个质量保障的核心话题,但随着技术的进步,认知在逐步清晰,我个人认为还不能说是非常成熟的基础方法。


    (图:一团队的代码集体走查现场)


    (图:开发人员的pair开发,往往会达到1+1 > 2的效率增长。)

    4. 基于Velocity和Cycle Time的持续改进

    持续改进是每个团队必须做的,回顾会议(Retrospective)是基本形式,回顾的内容很多,从交付质量、实践,到团队氛围。但实质上最基本的改进还是围绕Velocity(即迭代交付的Story点数)和交付时间Cycle Time。这里的Cycle Time还称不上“端到端”,原因是很多团队前期的产品梳理和后期的用户验收还是遵循客户合作节奏,比如2个月一次上线。当然原则上共识的是,每次持续集成构建出来的版本都应该是可发布的。

    Velocity是一个很有争议的话题,这个速率理论上只服务于项目管理,即目前规划和实际情况是否出现偏差,是否需要进行风险管理,调整项目范围等。

    ThoughtWorks敏捷开发模式坚决反对把Velocity作为交付KPI,即不作为迭代内的开发合同。假设合作上不存在信任问题,还是有一个无法回避的预测问题,如果Velocity和计划的偏差很大,那么实际的调整成本较高。当然这是一个行业问题,在“大规模手工打造”这个行业现状没有改观之前,最好还是能够坦诚开发过程中遇到的问题和变数。

    Cycle Time是从需求进入开发团队,到制造出可工作软件的速度。理论上当然是越快越好,Kanban告诉我们流速快的团队效率高、响应力快。如果不注意Cycle Time去“改进”Velocity,很可能造成更多的WIP(Kanban引入的在制品概念)堆积在迭代内,最后大家赶工埋下质量隐患,得不偿失。所以我们可以看到在ThoughtWorks合作的两个百人以上规模的大型团队里,都强调团队集体学习Kanban实践。


    (图:一个团队三个半月的累计流量图,能够有效看到在某一个阶段的WIP和Cycle Time数值,并分析潜在问题。)

    5. 基于客户深度参与的统一团队

    从ThoughtWorks历史的交付项目上来看,能够建立互信持久合作关系(>3年)的客户基本都深度参与了迭代开发过程。中国区历史最长,合作规模最大的三个交付项目都是客户团队和开发团队完全整合的。

    客户参加迭代内站会、展示会和回顾会是ThoughtWorks敏捷开发提出的要求。即使在通讯手段相对落后的七八年前,离岸的客户也是几乎每天和开发团队通过电话进行“站会”。这样做的好处不言而喻,大家都能够体会到这种模式下快速建立的信任关系。当然客户和开发团队都有很多其它工作要做,所以这样的协作模式就要求控制每种会议的时间。一些比较普遍的原则有:

    • 迭代站会不超过15分钟
    • 需求澄清每次不超过1小时
    • 展示会1小时以内
    • 回顾会不超过两小时

    虽然如此,这样的模式对客户时间要求依然很高。在咨询其它IT组织的过程中,相关业务人员(即开发团队客户)往往会有畏难情绪。但其实只要时间盒控制好,建立这样的协作节奏后,总投入时间是下降的。看似集中方式的合作模式,比如每个月1天时间需求梳理,其实根本没有办法杜绝后续实现过程中发现的细节问题。而到了迭代验收时才说出的“这不是我想要的”,更是巨大浪费的源头。

    对比Scrum的经典四会,ThoughtWorks敏捷开发和最后的评审会(Sprint Review Meeting)的差异相对较大。开发团队更希望是针对实现的业务场景进行展示,所以会议的名字也变成了展示会(Showcase)。当然不少团队也会评审迭代的产出,有相关的迭代进展报告。


    (图:一大型离岸合作客户将Showcase扩展到整个公司月度的跨产品展示。)

    不少和国内客户合作的开发团队有相对更重一些的迭代总结材料,会占用PM不少的时间。这点上需要警惕,面向价值的原则意味着整个团队,包含客户,都应该更多去思考迭代实现的业务,而不是关注迭代大家的工作量。后者应该是开发团队自己去持续考量和改进。

    ThoughtWorks敏捷开发管理体系

    做了多年的组织转型咨询,如果约束到软件开发领域,管理体系(暂且认为文化部分属于领导力)基本就是以下四个方面:

    • 需求管理:包含从需求澄清到需求最终实现的整个生命周期。

    • 技术管理:包含开发、测试技术的选择和运用。

    • 质量管理:包含开发过程中的质量管理及软件交付前的质量保障。

    • 迭代管理:包含开发团队迭代运作规则及纪律。

    显然ThoughtWorks敏捷开发需求管理是围绕Story展开,其核心是能够支持小批量、小批次的精益模式,同时还要能够尽量保证每个Story业务价值明确。《用户故事与敏捷方法》这本书可能是ThoughtWorks内部没有任何负面评价的实践级著作了。近十年时间里,大家稍有微辞的地方可能是书中对故事大小评估的描述,但INVEST原则的抽象可为神来之笔。

    Story作为需求的管理方法,所有的技术、质量和迭代管理其实都是围绕这个中心,毕竟最后开发目的是实现价值,而Story承载着业务价值。顺便提一句,Story的质量其实是一个核心问题,ThoughtWorks从来不提倡一句话Story描述,即仅仅表面上遵循了As … I want … So that的经典模式,验收条件对于一个Story来说至关重要。

    值得一提的是围绕Story的可视化系统,每个团队都会有一面类似下图的迭代看板,看板上流动的是迭代内的Story,而Story的生命周期则通过顺序的泳道展现给团队所有人。


    (图:基础的Story迭代看板设计,黄色卡片上会写出Story的基本信息。)


    (图:一个团队的Story看板,每个团队都会有自己的内部流程设计,所以各个团队的看板泳道设计也不尽相同。)

    技术和质量管理的核心仍然是前文提到的质量内建。持续集成和自动化测试实际上都将质量管理融入到了技术工程体系里。在ThoughtWorks敏捷开发体系里,很难将技术管理和质量管理分开,重过程质量是这个管理体系的精髓,由此也在2012年演进为《持续交付》的概念。

    由于是全功能团队,并工作在统一节奏下,所以迭代管理的范围中,除了类似Scrum四会协作仪式机制,其余硬性纪律较少。为了保证(成果和问题)“集体所有”(Collective Ownership),ThoughtWorks敏捷开发实践方面特别注意不会聚焦到个体,比如我们说到的Story估点和Velocity统计都是团队为单位,不会指定或统计到个人。

    迭代过程中的缺陷也不会追述到某个特定开发人员。唯一产生个体比较和竞争的可能是在技术卓越原则下的比拼,比如作为TL,至少你写出的代码应该是让团队其他成员赏心悦目。

    虽然本文不谈文化,但这里还是必须强调这样的管理模式本质上是将“价值驱动、技术卓越”上升到文化价值观层面作为支撑才得以实现的。即便经常拿尚奇口中的“tech@core”开玩笑,但实质上这是ThoughtWorks敏捷开发模式能够工作的重要底座。也是为什么很多其他团队感觉ThoughtWorks这种管理模式不可行的核心症结。

    最后问一句,和你感受和认知的ThoughtWorks敏捷开发差异大吗?-;)


    文/ThoughtWorks 肖然
    更多精彩洞见,请关注微信公众号:思特沃克

    展开全文
  • 敏捷开发的初始理解

    2018-05-24 17:06:49
    一,什么是敏捷开发1,敏捷开发的概念敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。把一大项目分为多相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用...
  • 敏捷开发与传统开发的区别

    千次阅读 2019-07-01 14:36:44
    首先我们来看看敏捷开发:不管产品针对的群体是普通大众还是企业的人事部,一铁的事实告诉我们--21世纪的客户对能够立即发布的高质量应用产品总是求“贤”若渴,青睐有加。可遗憾的是老一套传统的开发模式已经不...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 敏捷开发的起源在90年代末期,传统软件开发的方式因为其繁杂的过程,以及对文档的过于严格的要求,造成了很大程度上的效率下降,也就是人们所说的“重型化危机”。因为这一原因,人们开始反思传统方法的利弊,并对其...
  • 以前,当讲到我们团队采用敏捷开发进行APP迭代的时候,我会把“敏捷”二字打上引号。但是最近总结、反思、参加TAPD分享会、公司组织的敏捷培训以及系统的学习了敏捷的理论知识后,我觉得应该把这引号给去掉。 本文...
  • 敏捷开发知识体系笔记

    万次阅读 2015-11-06 10:08:55
    敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • [摘要] ...以下分享产品项目里的九个敏捷开发实战经验。  敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。  在《Scrum:兼顾计
  • 关于敏捷开发,你应该避免的几误区敏捷开发管理背景敏捷开发管理的理论如何做好敏捷开发管理常见的误区和解析敏捷开发过程管理总结 回顾软件工程发展史,就是管理和技术并行的历史。了解敏捷开发管理,有助于将...
  •  随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。笔者的产品开发团队在两年前开始采用敏捷开发方法,一直实践到现在,并取得不错的成果,包括:产品功能更加符合市场和业务...
  • 敏捷开发实战经验

    千次阅读 2018-05-30 18:22:35
    以下分享产品项目里的九个敏捷开发实战经验。 敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。 在《Scrum:兼顾计划与灵活的敏捷开发...
  • 敏捷开发解读

    2010-03-10 22:45:00
    敏捷开发可以分为三个层次,理念,实践,应用。 软件的价值,在于实现客户的需求,和客户合作可以更好的澄清需求,所以敏捷强调和客户合作,过度的和过早的设计很多情况下偏离了实际需求,所以敏捷更强调代码的交付...
  • 简单的说下敏捷开发的一些知识: 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成...
  • 敏捷开发简述

    2019-04-24 22:32:19
    敏捷开发的起源 在90年代末期,传统软件开发的方式因为其繁杂的过程,以及对文档的过于严格的要求,造成了很大程度上的效率下降,也就是人们所说的“重型化危机”。因为这一原因,人们开始反思传统方法的利弊,并对...
  • 框架简介: 软件开发,程序员就是不断地跟变量、方法、类、接口这些东西打交道,随着开发经验地积累,聪明的程序就会发现然开发出来的每软件都不一样,但是...力软敏捷开发框架就是在此基础上做了充分的优化,使...
  • 敏捷软件开发.pdf

    热门讨论 2020-07-24 21:31:35
     0.3.1三个层次和方法集  0.3.2三个层次与本书  0.3.3守-破-离  0.4那么,明天我做什么  第0A章不可知和不可说:演进  0A.1沟通和共享的体验  0A.2守-破-离  第1章创造和沟通的合作博弈  1.1软件和诗歌  ...
  • 敏捷流派众多,在此做一简单的整理与分享。 一、极限编程 极限编程(ExtremeProgramming,简称XP)是由KentBeck在1996年提出的。极限编程是一轻量级的、灵巧的软件开发方法;同时也是一非常严谨和周密的...
1 2 3 4 5 ... 20
收藏数 27,942
精华内容 11,176
热门标签
关键字:

敏捷开发的三个层次