scrum
敏捷为什么要使用Scrum而不是瀑布?
编程 星物种 发表了文章 0 个评论 2426 次浏览 2021-05-06 11:14
Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。
在瀑布中，改变成本和进度以确保达到预期的范围，在Scrum中，可以改变质量和约束以实现获得最大商业价值的主要目标。
瀑布模型适用于有序和可预测的项目，其中所有要求都明确定义并且可以准确估计，并且在大多数行业中，此类项目正在减少。客户需求的变化导致企业适应和改变其交付方式的压力增大。
Scrum方法在当前市场中更为成功，其特点是不可预测性和波动性。Scrum方法基于inspect-adapt循环，而不是Waterfall方法的命令和控制结构。
Scrum项目以迭代方式完成，其中首先完成具有最高业务价值的功能。各个跨职能团队在Sprint中并行工作，以便在每个Sprint结束时提供潜在的可交付解决方案。
因为每次迭代都会产生可交付的解决方案（这是整个产品的一部分），所以团队必须实现可衡量的目标。这可确保团队正在进行，项目将按时完成。传统方法没有提供这种及时的检查，因此导致团队可能会下班并最终完成大量工作。
当客户定期与团队互动时，定期审查完成的工作; 因此，可以确保进度符合客户的要求。然而，在瀑布中没有这样的交互，因为工作是在筒仓中进行的，并且在项目结束之前没有可用的功能。
在复杂的项目中，客户不清楚他们在最终产品中需要什么，并且功能需求不断变化，迭代模型可以更灵活地确保在项目完成之前可以包含这些更改。
但是，当完成具有明确定义的功能的简单项目，并且当团队具有完成此类项目的先前经验（因此，估计将是准确的）时，瀑布方法可以是成功的。
敏捷 Vs 瀑布
下面是一个表格，可以更好地了解Scrum和瀑布的差异。
敏捷还是瀑布？
Standish Group的最新报告涵盖了他们在2013年至2017年期间研究的项目。在这段时间内，敏捷和瀑布的成功，挑战和失败的整体突破如下所示，敏捷项目成功的可能性大约是后者的2倍，失败的可能性降低1/3。
来源：vitalitychicago.com - 比较瀑布和敏捷项目成功率
每个伟大的产品需要一个伟大的ScrumMaster
编程 星物种 发表了文章 1 个评论 1899 次浏览 2021-05-04 10:31
摘要
产品负责人和ScrumMaster是两个相互补充的独立敏捷角色。 为了出色地完成工作，产品所有者需要在他们身边强大的ScrumMaster。
不幸的是，我发现通常缺少可以支持产品所有者的ScrumMaster。 有时角色之间会混淆，或者根本没有ScrumMaster。
这篇文章解释了这两个角色之间的区别，产品所有者应该从他们的ScrumMaster中获得什么，以及ScrumMasters从他们中可以期待什么。
产品负责人与ScrumMaster
产品负责人和ScrumMaster是相互补充的两个不同角色。 如果其中一个位置不正确，则另一个会受到影响。 作为产品负责人 ，您应对产品的成功负责-创造一种对用户和客户的工作都非常出色并满足其业务目标的产品。 因此，您可以与用户和客户以及内部利益相关者，开发团队和ScrumMaster进行交互，如下图所示。
上图中的灰色圆圈描述了由产品所有者，ScrumMaster和跨功能开发团队组成的Scrum团队。
ScrumMaster负责流程的成功 -帮助产品负责人和团队使用正确的流程来创建成功的产品，并促进组织变革和建立敏捷的工作方式。 因此，ScrumMaster与产品所有者和开发团队以及受Scrum影响的高级管理层，人力资源（HR）和业务组合作，如下图所示：
要成功成为产品负责人，需要正确的技能，时间，精力和重点。 扮演ScrumMaster角色也是如此。 将这两个角色（甚至是部分角色）组合在一起不仅非常具有挑战性，而且意味着忽略了某些职责。 如果您是产品所有者，请不要承担ScrumMaster的职责！
产品负责人对ScrumMaster的期望
作为产品所有者，您应该从以下几种方面受益于ScrumMaster的工作。 ScrumMaster应该指导团队，以便团队成员可以构建出色的产品，促进组织变革，以便组织利用Scrum并帮助您完成出色的工作：
下表详细说明了您应该从ScrumMaster获得的支持：
ScrumMaster支持您作为产品所有者，因此您可以专注于自己的工作-确保创建具有正确用户体验（UX）和正确功能的正确产品。 如果您的ScrumMaster不提供或无法提供此支持，请与个人联系，并找出问题所在。 不要介入并接管ScrumMaster的工作。 如果您没有ScrumMaster，请将上面的列表显示给您的高级管理层赞助商或老板，以解释为什么您需要身边有合格的ScrumMaster。
ScrumMaster应该对产品负责人有什么期望
Tango花了两个时间，ScrumMaster对您作为产品所有者的工作抱有期望，这是公平的。 下图说明了其中的一些：
下表更详细地描述了ScrumMaster的期望：
Scrum是一个用于开发和维护复杂产品的框架
编程 星物种 发表了文章 0 个评论 1756 次浏览 2021-05-04 09:30
Scrum是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。
在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。
挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
SCRUM框架包括3个角色、3个工件、5个事件、5个价值
3个角色
- 产品负责人（Product Owner）
- Scrum Master
- 开发团队
3个工件
- 产品Backlog（Product Backlog）
- SprintBacklog
- 产品增量（Increment）
5个事件
- Sprint（Sprint本身是一个事件，包括了如下4个事件）
- Sprint计划会议（Sprint Planning Meeting）
- 每日站会（Daily Scrum Meeting）
- Sprint评审会议（Sprint Review Meeting）
- Sprint回顾会议（Sprint Retrospective Meeting）
5个价值
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
SCRUM理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：
第一：透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
第二：检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三：适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
全文阅读：https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html
敏捷为什么要使用Scrum而不是瀑布?
编程 星物种 发表了文章 0 个评论 2426 次浏览 2021-05-06 11:14
Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。
在瀑布中，改变成本和进度以确保达到预期的范围，在Scrum中，可以改变质量和约束以实现获得最大商业价值的主要目标。
瀑布模型适用于有序和可预测的项目，其中所有要求都明确定义并且可以准确估计，并且在大多数行业中，此类项目正在减少。客户需求的变化导致企业适应和改变其交付方式的压力增大。
Scrum方法在当前市场中更为成功，其特点是不可预测性和波动性。Scrum方法基于inspect-adapt循环，而不是Waterfall方法的命令和控制结构。
Scrum项目以迭代方式完成，其中首先完成具有最高业务价值的功能。各个跨职能团队在Sprint中并行工作，以便在每个Sprint结束时提供潜在的可交付解决方案。
因为每次迭代都会产生可交付的解决方案（这是整个产品的一部分），所以团队必须实现可衡量的目标。这可确保团队正在进行，项目将按时完成。传统方法没有提供这种及时的检查，因此导致团队可能会下班并最终完成大量工作。
当客户定期与团队互动时，定期审查完成的工作; 因此，可以确保进度符合客户的要求。然而，在瀑布中没有这样的交互，因为工作是在筒仓中进行的，并且在项目结束之前没有可用的功能。
在复杂的项目中，客户不清楚他们在最终产品中需要什么，并且功能需求不断变化，迭代模型可以更灵活地确保在项目完成之前可以包含这些更改。
但是，当完成具有明确定义的功能的简单项目，并且当团队具有完成此类项目的先前经验（因此，估计将是准确的）时，瀑布方法可以是成功的。
敏捷 Vs 瀑布
下面是一个表格，可以更好地了解Scrum和瀑布的差异。
敏捷还是瀑布？
Standish Group的最新报告涵盖了他们在2013年至2017年期间研究的项目。在这段时间内，敏捷和瀑布的成功，挑战和失败的整体突破如下所示，敏捷项目成功的可能性大约是后者的2倍，失败的可能性降低1/3。
来源：vitalitychicago.com - 比较瀑布和敏捷项目成功率
每个伟大的产品需要一个伟大的ScrumMaster
编程 星物种 发表了文章 1 个评论 1899 次浏览 2021-05-04 10:31
摘要
产品负责人和ScrumMaster是两个相互补充的独立敏捷角色。 为了出色地完成工作，产品所有者需要在他们身边强大的ScrumMaster。
不幸的是，我发现通常缺少可以支持产品所有者的ScrumMaster。 有时角色之间会混淆，或者根本没有ScrumMaster。
这篇文章解释了这两个角色之间的区别，产品所有者应该从他们的ScrumMaster中获得什么，以及ScrumMasters从他们中可以期待什么。
产品负责人与ScrumMaster
产品负责人和ScrumMaster是相互补充的两个不同角色。 如果其中一个位置不正确，则另一个会受到影响。 作为产品负责人 ，您应对产品的成功负责-创造一种对用户和客户的工作都非常出色并满足其业务目标的产品。 因此，您可以与用户和客户以及内部利益相关者，开发团队和ScrumMaster进行交互，如下图所示。
上图中的灰色圆圈描述了由产品所有者，ScrumMaster和跨功能开发团队组成的Scrum团队。
ScrumMaster负责流程的成功 -帮助产品负责人和团队使用正确的流程来创建成功的产品，并促进组织变革和建立敏捷的工作方式。 因此，ScrumMaster与产品所有者和开发团队以及受Scrum影响的高级管理层，人力资源（HR）和业务组合作，如下图所示：
要成功成为产品负责人，需要正确的技能，时间，精力和重点。 扮演ScrumMaster角色也是如此。 将这两个角色（甚至是部分角色）组合在一起不仅非常具有挑战性，而且意味着忽略了某些职责。 如果您是产品所有者，请不要承担ScrumMaster的职责！
产品负责人对ScrumMaster的期望
作为产品所有者，您应该从以下几种方面受益于ScrumMaster的工作。 ScrumMaster应该指导团队，以便团队成员可以构建出色的产品，促进组织变革，以便组织利用Scrum并帮助您完成出色的工作：
下表详细说明了您应该从ScrumMaster获得的支持：
ScrumMaster支持您作为产品所有者，因此您可以专注于自己的工作-确保创建具有正确用户体验（UX）和正确功能的正确产品。 如果您的ScrumMaster不提供或无法提供此支持，请与个人联系，并找出问题所在。 不要介入并接管ScrumMaster的工作。 如果您没有ScrumMaster，请将上面的列表显示给您的高级管理层赞助商或老板，以解释为什么您需要身边有合格的ScrumMaster。
ScrumMaster应该对产品负责人有什么期望
Tango花了两个时间，ScrumMaster对您作为产品所有者的工作抱有期望，这是公平的。 下图说明了其中的一些：
下表更详细地描述了ScrumMaster的期望：
Scrum是一个用于开发和维护复杂产品的框架
编程 星物种 发表了文章 0 个评论 1756 次浏览 2021-05-04 09:30
Scrum是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。
在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。
挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。
SCRUM框架包括3个角色、3个工件、5个事件、5个价值
3个角色
- 产品负责人（Product Owner）
- Scrum Master
- 开发团队
3个工件
- 产品Backlog（Product Backlog）
- SprintBacklog
- 产品增量（Increment）
5个事件
- Sprint（Sprint本身是一个事件，包括了如下4个事件）
- Sprint计划会议（Sprint Planning Meeting）
- 每日站会（Daily Scrum Meeting）
- Sprint评审会议（Sprint Review Meeting）
- Sprint回顾会议（Sprint Retrospective Meeting）
5个价值
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
SCRUM理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。
Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：
第一：透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
第二：检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三：适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
全文阅读：https://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html
