精益，敏捷，Scrum的至关不错的总结

时间 2019-12-13

标签敏捷 scrum 至关不错总结繁體版

原文原文链接

词汇表：精益，敏捷，Scrum，Sprint，看板

将Lean和Agile看做几乎相同的事情，它们基本上是处理具备不少不肯定性的项目的好方法，这就是为何成功的初创公司采用这种方法。（有关精益，敏捷和Scrum起源的事实历史，请参阅此处。）框架

Scrum和Kanban是最受欢迎的两个敏捷项目管理框架。它们有很大的不一样 - Scrum彷佛更经常使用，纯粹的看板更少。但实际上每一个人都使用他们本身的Scrum修改版本，这是鼓励的，一般采用看板的元素（咱们也这样作）。ide

Sprint是一个Scrum术语。这是Scrum中的迭代周期。学习

因此： 精益≈敏捷> Scrum>冲刺测试

为何精益和敏捷？

由于在这个不断变化的社交和数字参与世界中，咱们须要更好的方式来开展业务和管理组织。ui

精益和敏捷是现代组织功能失调的两个主要缘由的解毒剂：编码

瀑布项目管理，和
功能层级组织结构。

瀑布与敏捷项目管理

当咱们想到项目管理时，咱们大多数人都会想象一个规范，按部就班的工做方法，并有良好的规划和明确的目标设定。这基本上是瀑布项目管理。spa

瀑布项目管理思想在咱们的文化中根深蒂固。咱们的教育强调良好的准备和一步一步的审慎。进展正在达到检查点的标记。了解咱们正在走上正轨可让咱们感到温馨和自信，同时也有助于咱们的教师和领导者更轻松地监控和管理。这是一个很好的方法。没有瀑布，世界上许多现代奇迹都不会存在。全球各地的企业已成功扩展瀑布。但瀑布有其局限性：它在重复性和相对较低的不肯定性项目中运行良好。.net

现实是，世界充满了不肯定性。人类的行为很难预测。在您正在开发还没有找到市场的产品的项目中，瀑布式项目管理是寻找适合产品市场的很是昂贵的方式。您能够负担得起废弃和重建产品的次数有限，而且在瀑布中进行另外一次产品构建迭代所需的时间会使您在竞争中处于劣势。设计

敏捷成为解决瀑布缺点的解决方案。对于企业来讲，它是一种更快，更具成本效益且风险更低的方法，能够应对其业务的诸多不肯定因素。在这个快速数字化转型的世界中，再也不仅仅是创业公司必须应对扰乱市场。跨行业的各类规模的企业都须要更好的方法来应对变化，敏捷是一种解决方案。3d

传统与敏捷组织结构

委派工做对领导者和管理者来讲是一项平常挑战。团队之间的移交文化为追求更高层次的企业目标创造了障碍。敏捷经过从新定义的团队合做和领导模式从根本上解决了这些组织挑战。

在传统组织中，领导和管理团队负责决策 - 战略和解决问题，预计答案未来自上方。这给领导者“作出正确决策”带来了巨大风险。再一次，在这个快速发展的数字和社交时代，对任何人而言，很难一鼓作气。认识到解决问题是一个发现过程，敏捷鼓励假设创建和实验做为一个总体组织练习。简单地说，更多的眼睛和集体智慧增长了“把事情作对”的机会。

精益与敏捷的精神

精益和敏捷是方法，而不是方法。即便是敏捷的实施框架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，咱们很是了解组织行为和黑客攻击方法，以推进成功的精益和敏捷组织转型。