精益，敏捷，Scrum的相当不错的总结
sing 2019-06-30
词汇表：精益，敏捷，Scrum，Sprint，看板
将Lean和Agile看作几乎相同的事情，它们基本上是处理具有很多不确定性的项目的好方法，这就是为什么成功的初创公司采用这种方法。 （有关精益，敏捷和Scrum起源的事实历史，请参阅 此处 。）
Scrum和Kanban是最受欢迎的两个敏捷项目管理框架。 它们有很大的不同 - Scrum似乎更常用，纯粹的看板更少。 但实际上每个人都使用他们自己的Scrum修改版本，这是鼓励的，通常采用看板的元素（我们也这样做）。
Sprint是一个Scrum术语。 这是Scrum中的迭代周期。
所以： 精益≈敏捷> Scrum>冲刺
为什么精益和敏捷？
因为在这个不断变化的社交和数字参与世界中，我们需要更好的方式来开展业务和管理组织。
精益和敏捷是现代组织功能失调的两个主要原因的解毒剂：
- 瀑布项目管理 ，和
- 功能层级组织结构 。
瀑布与敏捷项目管理
当我们想到项目管理时，我们大多数人都会想象一个规范，循序渐进的工作方法，并有良好的规划和明确的目标设定。 这基本上是瀑布项目管理。
瀑布项目管理思想在我们的文化中根深蒂固。 我们的教育强调良好的准备和一步一步的审慎。 进展正在达到检查点的标记。 了解我们正在走上正轨可以让我们感到舒适和自信，同时也有助于我们的教师和领导者更轻松地监控和管理。 这是一个很好的方法。 没有瀑布，世界上许多现代奇迹都不会存在。 全球各地的企业已成功扩展瀑布。 但瀑布有其局限性：它在重复性和相对较低的不确定性项目中运行良好。
现实是，世界充满了不确定性。 人类的行为很难预测。 在您正在开发尚未找到市场的产品的项目中，瀑布式项目管理是寻找适合产品市场的非常昂贵的方式。 您可以负担得起废弃和重建产品的次数有限，并且在瀑布中进行另一次产品构建迭代所需的时间会使您在竞争中处于劣势。
敏捷成为解决瀑布缺点的解决方案。 对于企业来说，它是一种更快，更具成本效益且风险更低的方法，可以应对其业务的诸多不确定因素。 在这个快速数字化转型的世界中，不再仅仅是创业公司必须应对扰乱市场。 跨行业的各种规模的企业都需要更好的方法来应对变化，敏捷是一种解决方案。
传统与敏捷组织结构
委派工作对领导者和管理者来说是一项日常挑战。 团队之间的移交文化为追求更高层次的企业目标创造了障碍。 敏捷通过重新定义的团队合作和领导模式从根本上解决了这些组织挑战。
在传统组织中，领导和管理团队负责决策 - 战略和解决问题，预计答案将来自上方。 这给领导者“做出正确决策”带来了巨大风险。 再一次，在这个快速发展的数字和社交时代，对任何人而言，很难一气呵成。 认识到解决问题是一个发现过程，敏捷鼓励假设建立和实验作为一个整体组织练习。 简单地说，更多的眼睛和集体智慧增加了“把事情做对”的机会。
精益与敏捷的精神
精益和敏捷是方法，而不是方法。 即使是敏捷的实施框架Scrum，也拒绝称之为方法论。 这是因为没有一种严格的方法可以解决所有不确定性问题。 相反，你遵循某些共同的原则，或者可以概括为精益和敏捷的精神，并且大量适应：
- 坚持不懈地追求产品市场契合度 （=为客户提供真正的价值）作为整体组织的努力。
- 列表项目
- 建立，衡量，学习 ：接受不确定性 - 这就是为什么我们假设，测试和验证我们是否越来越接近客户真正想要的东西。
在它被钉住之前，以小增量进行并继续迭代。 - 了解客户，而不仅仅是销售和营销或领导团队，这是每个人的工作。 认为客户不是别人的工作 - 这也是你的工作。
因此，您被允许并被鼓励与客户一起进行构建测量 - 学习实验（即使您不是直接面向客户），领导团队将作为仆人领导者，促进系统化的协作工作框架。 - 在Lean＆Agile中，没有人会受到指责。 如果出现故障，我们不会责怪某人，而是检查产生故障并修复故障的系统。
实施Scrum
视觉层次结构
首先，您的企业愿景需要以“连接”的方式与组织中的每个人共享：您的员工所做的一切，一直到个人工作的任务级别，需要连接到愿景。
这比人们想象的要难。 领导能够分辨和销售愿景，但这并不一定能让每个人都参与其中。 视觉分享练习实际上是与您的员工一起进行的视觉形成练习。
输入Scrum：Epic，Story，Task是Scrum术语，可帮助人们思考产品或项目中需要构建或完成的所有关键事项，以实现共享愿景。 根据设计，Scrum通过沿着视觉层次结构进行“Backlog”创建练习，将每个人放在同一页面上。
运行Sprint
Scrum是一个由时间限制的项目管理框架，由Sprint组成，根据团队工作的特点，您可以设置一个固定的工作周期，通常在一到四周之间。 （据您所知，另一个流行的敏捷项目管理框架看板是一种“容量受限”的方法。）
我们的想法是以小增量和快速迭代的方式完成工作，特别强调审查工作以帮助团队实现目标。 假设构建和重复实验是Scrum不可或缺的一部分，因为大多数项目都面临不确定性，而发现是关键（营销是一个很好的例子 - 产品市场适合自己是一个发现过程）。
1.积压 (backlog)
想想可能包含在产品中或需要在项目中完成的所有事情。 踏上用户旅程的道路：用户故事是将客户需求和需求置于背景中的一种很好的方式。
用户故事：作为[用户]，我想[什么]，所以[值]。
2. Sprint计划 (Sprint Planning)
优先考虑和估计Backlog，决定在即将到来的Sprint中做什么。
- 为了估计完成每项工作需要多长时间， 规划扑克 很有用。
- 该 看板 （或Scrum的董事会）是Scrum的一个关键项目。 这是信息持久显示，可视化和与团队共享的地方。
鼓励定制以适应团队的工作流程。 - 完成的定义 是Scrum中另一个必须遵守的规则。 Done的定义不仅仅是Sprint团队成员在发布前验证工作的质量保证概念。
它也是Sprint中发生的许多假设和实验的测量和学习标准。 - Scrum中有两个辅导员角色。 第一个是 产品所有者 ，“什么”的人，第二个是 Scrum Master ，“如何”的人。 关键在于促进 - Scrum团队的生产力以“ 速度 ” 来衡量 ，或者他们能够以多快的速度完成任务，并且最有效的是促使团队成员单独和共同决定做什么和做什么，而不是而不是像传统的等级组织那样指导他们。
3.每日站立 (Daily Standup)
一个典型的Scrum团队应该在3到9人之间 ，包括产品负责人和Scrum Master。 任何更大的，团队的速度下降，所以最好分成不同的Scrum团队。
速度的关键在于团队成员之间在进步和障碍方面的丰富沟通。 固定格式每日站立被证明是用于这一目的非常有效： 每天都 在 同一时间 ，为 不到15分钟 ，球队在看板前聚集，并且每个团队成员通过回答以下分享他们的进步三个问题：
- ✓昨天做了什么工作？
- ✓今天计划做些什么？
- ✓任何阻碍的方式？
或者，团队也可以按照看板上的完成和待办事项的顺序进行。 如果多个团队成员参与每个看板委员会项目的工作，这可以是更好的格式。
在 每日站立不是状态更新会 为经理，找出谁是落后于计划或给工作指令。 状态更新仅提供快照 - 重要的是签入流程。 站起来是团队了解已完成的工作和剩下的工作，以便人们加快团队合作。 如果有人被困，其他团队成员会帮忙。 如有必要，Scrum Master会重新调整工作流程，以便于移除障碍物。
4. Sprint评论和回顾 (Sprint Review and Retrospective)
在每个Sprint结束时，Scrum团队会召开两次会议。
第一个是“什么”会议：Sprint Review将讨论由产品负责人推动的最后一个Sprint所做的工作。 这次会议通常伴随着新版本和其他成就的演示，欢迎来自组织其他成员的成员加入。
第二个是“如何”会议：Sprint回顾展。 这是Scrum团队成员反映和讨论在上一个Sprint期间出现的障碍，即使事情进展顺利，还有改进的想法。 Scrum所有者通过确保重点仍然是修复流程而不是人们责备来促进此会议。
在两次会议结束时，团队更新Backlog并计划下一个Sprint。
Scrum的常见陷阱
‣无灵魂的Scrum：冲刺为迷你瀑布
通常，用户故事成为迷你规范文档。 然后，执行编码或任何活动，然后进行UAT（用户验收测试）或其他签核过程。 乍一看，这听起来并不错，许多团队陷入了这个陷阱。
问题是，这只是以迷你瀑布风格运行的迷你项目。 分析，设计，编码和测试以顺序方式完成，可能跨越多个Sprint，最有可能作为功能之间的移交过程（例如BA（业务分析师）>开发人员> QA（质量保证））。
精益与敏捷是关于不确定性的发现。 在Scrum中，构建 - 度量 - 学习周期被设计为在Sprint中发生，并且从事假设，MVP（最小可行产品）构建和测试的团队成员需要彼此尽可能地工作; 即跨职能团队合作。 工作不必是顺序的 - 如果某些东西不起作用或缺少标记，那么完全可以进行设计更改和修改，或者做出有意识的决定以采用不同的方法; 即调整和微型旋转。 迷你瀑布击败了迭代的目的，只实现了Scrum的小增量优势。
‣领土Scrum
敏捷现在在软件开发团队中很常见。 问题是，在许多组织中，只是运行Scrum的开发团队，有效地在组织内创建了一个岛。
结果是开发团队与组织其他部门（即销售团队）之间的交流文化：“我们按照您的规范将产品整合在一起，现在就去销售它”。
传播组织范围敏捷的关键是让人们将敏捷视为一种更广泛的沟通，合作和共同创造概念，而不仅仅是一个项目管理框架。 问一个问题，如果我们内部无法很好地连接，我们如何与客户建立联系？ 这应该会促使持续的客户价值创造和产品市场适应各个团队的思维。
在组织范围的敏捷的实际实施方面，销售和营销的Scrum可以与开发团队的Scrum并行运行。 最终，最好的目标是转向跨职能的Scrum团队，其中开发，销售和营销职能都在每个Scrum团队中，并与产品或客户项目保持一致。
‣Scrum Master in Command
在每日站立期间，如果人们向Scrum Master提供状态更新，并且Scrum Master告诉人们该做什么，那么你就是在击败Scrum的目的。
Scrum是一种系统性的努力，可以使组织脱离管理者 - 工作者模式。 在解决问题的企业中，指挥领导模式失败 - 它依靠领导者得到所有答案，使领导者自己成为障碍。
在敏捷组织中，你试图从人们身上带出所有“合作” - 合作，协作，协调，共同创造，沟通，联系等等。 Scrum Master的作用是保持“co”流向侧面，而不是像指挥一样垂直。
我们还必须了解“工人”在经理 - 工人模式中的被动安慰：接受工作指示是令人欣慰的，因为您不必考虑原因和方法，并且您不受决策责任的影响。 Scrum以多种方式解决了转变为自主工作模式的痛苦; 小型构建模块方法使工作更容易管理，每日站立是为了让团队成员在遇到困难时互相帮助，并且不责备人的文化鼓励个人承担实验风险。
‣冲刺直到你掉落
如果一个领导者设计“冲刺”作为一种系统的手段，使人们在永久的高度戒备中尽可能地努力工作，那只是危机的习惯性管理，或者更糟糕的是，剥削劳动力。
一个不那么邪恶的领导者可能将“冲刺”定位为类似于赛道或游泳中的间歇训练。 他可能会说，通过持续不断的紧张工作，团队将能够突破其表现的界限。 但这会给团队成员带来精神疲惫的风险。 在如此高压力的环境中吸引和留住人才是很难的。
在一次Sprint之后，下一个Sprint立即开始。 如果团队开始尝试从最后一个恢复新的Sprint，显然他们已经过度踱步。 Sprint必须以可持续的速度运行，不需要Sprint之间的休息或恢复时间。
实际上，Scrum Sprints可能不应该被称为sprint。 它应该更像是慢跑或其他东西。 是的，你确实希望你的团队的“速度”增加（在Scrum中我们使用“ Burn Down Charts ”来衡量这一点），但这并不是你追求的终极速度。 你追求的是平均速度的提高，即在相同的时间内覆盖更多的距离。 正如任何长跑运动员都会证明的那样，找到合适的节奏和节奏是迈向远方的关键。
采用精益和敏捷并非易事。 精益和敏捷背后的意识形态是理性的，对大多数人来说都是有意义的，但是将其付诸行动需要思维方式的转变和许多破碎的习惯。 虽然如果做得好，精益和敏捷将带来令人难以置信的生产力，积极性和突破组织。 在Lifecycle，我们非常了解组织行为和黑客攻击方法，以推动成功的精益和敏捷组织转型。
