全部与敏捷1有关：流行议程神话

敏捷开发方法已经在IT和非IT中扎根，它们的面貌，刻板印象，迷信和神话已泛滥成灾。 Mail.Ru云解决方案博客的编辑决定与ScrumTrek的敏捷教练Vasily Savunov讨论这个神话。

敏捷是一种敏捷开发哲学，其基础已在《 敏捷软件开发宣言》中进行了描述。 该概念基于四个核心价值：

• 人员和交互比流程和工具更重要；
• 有效的产品比全面的文档更重要；
• 与客户的合作比合同条款上的协议更为重要；
• 准备好进行更改比执行原始计划更为重要。

敏捷方法的原理已经改变了开发过程并赢得了尊重。 现代世界正在加速发展-每天都会出现数十种新服务和数字解决方案。 敏捷使企业在开发新产品时能够足够快地跟上这一步伐，并为用户和客户提供可以尽早解决其问题的解决方案。

伴随着敏捷的流行，它有了正式的解释。 我们将分析使我们无法了解灵活方法的本质并从中获得更多好处的神话和成见。

误解1：敏捷仅是IT

不再。 看看代表敏捷日和敏捷业务会议的发言人发言的公司列表就足够了：Gazpromneft，Rostelecom，Severstal，PTG-Group和12Storeez。 这些以及许多其他与IT行业无关的组织成功地使用了敏捷方法。

误区二：敏捷-不适用于固定预算项目

在固定预算范围内，您可以有很大不同。 问题是承包商与客户之间的关系是什么。 如果使用敏捷，则需要专注于解决客户问题的方法。 换句话说，如果一开始客户和承包商共同进行计划并确定产品的主要优先事项，那么将无法阻止他们确定承包商可以在有限的预算范围内实施哪一部分，最有用的产品。 而且，如果您还规定了定期向客户展示的内容，则很可能会在很短的时间内调整流程，从而调整项目成本。

神话3.敏捷-业务和发展的灵丹妙药：实施，让事情有所改善

在我看来，这是对事物的简化且非常有害的观点。 所有案例和业务都不尽相同，您需要选择正确的方法以在这种情况下有所帮助。

当然，在成功的关键是遵循明确定义的动作算法的情况下，不需要敏捷。 例如，在呼叫中心的工作中，为了获得更好的服务，接线员应使用“脚本”进行对话，即 预定义的通讯方案。 没有实验领域，在这里甚至可能有害。 因此，呼叫中心运营商的活动中不需要敏捷。



如果产品的“加工”或“提炼”成本非常高，甚至可能涉及人类牺牲，那么敏捷将是有害的。 可以说，在建造核电站的过程中，很明显，正如敏捷对我们的指示那样，我们不能以增量方式逐步进行建造。

神话4。Scrum，精益，看板不相交。

方法和工具应分开。 方法论是一种用于构建工作流的算法。 工具是在该算法中使用的“砖”。

不同的方法可能包括相同的工具，但布局不同。 您经常可以看到在实施Scrum时，它们如何使用XP（极限编程）或看板工具。 这是正常现象，因为它们都符合敏捷价值，并允许您灵活地创建产品。

如果我们谈论目前最流行的特定敏捷方法，那么肯定是Scrum和看板。 其他-FDD，XP，RUP等，要么退出舞台，要么很少使用，但其库中的各个工具都参与了Scrum或看板的实现。

神话5. Scrum-如何快速，廉价地生产产品。

至于“快速”，一切都是对的，但对于“便宜”-不。 自己判断：您需要组建一支成熟的团队，并在其中100％强调必要的能力。 这些人将只专注于委托给他们的产品开发，而没有其他任何事情，这意味着他们要么必须聘请此类专家，要么从某个部门“撕扯”他们。 对于业务部门也是如此：如果您想要，如果您不想，则需要分配产品负责人，该负责人仅将50％至80％的时间用于该团队及其产品。

此外，您需要将它们放在一起，放在一个房间里，为他们提供自己的空间，团队活动的道具等等。 另外，您需要记住，每个sprint至少要花费8个小时来进行通信，因为Scrum涉及一系列持续一两个小时的强制性会议。 无论如何，您都必须进行投资，但是Scrum提供的速度和质量的最终收益是非常大的。


Sprint包括4个强制性会议：计划，实施，发布，带回顾的Sprint审查。 此外，每天举行一次短期会议（站立会议），在此期间，团队成员以单一格式“检查时间”并协调其行动。 您无法在打开的Sprint中添加新任务-这使团队习惯于计划并确保不会出现管理混乱。

神话6.看板是一个在上面张贴任务的董事会。

一点都不！ 董事会只是看板的第一步，也是最简单的步骤。 但是问题不仅仅限于它们 。 看板的核心是基于统计数据的复杂数学工具。 因此，将看板等同于木板意味着不要超越其外观。

简而言之，看板的主要目的是：

• 使当前的工作流程透明，并涵盖所有阶段-从企业负责人的任务发生到其实施以及将产品交付给消费者。
• 通过识别时间损失并消除时间损失来管理您的工作流程。 因此，我们使工作流程可预测。
• 根据指标而不是感觉来制定管理决策。

神话7。Scrum和看板可以植入任何项目和公司中。

我不喜欢“种植”这个词，毕竟，敏捷是关于与人合作。 谈论“向团队中灌输”新的思维哲学会更正确。

同时，Scrum和看板嫁接算法不同。

使用Scrum的成功率取决于公司主导的企业文化。 在一个艰难的层次结构中，每个人都需要一张纸，没有高层管理人员的支持，任何“增长” Scrum的努力都不会成功。 我们将必须基于团队方法构建一个新的并行结构。 一种“储备敏捷”，可以保护最高梯队的经理之一。 在这种情况下，有可能在三到四个月内显示出快速的结果。 但是，未来将面临更加艰巨的任务-在整个组织中传播这种文化。 这将持续多长时间是极其困难的。 但是，以我的经验来看，如果新方法覆盖了公司30％的份额，那么它会开始进一步传播自己，并且不再需要来自上方的保护。

Scrum的实施通常需要进行大的更改，包括组织的结构和与承包商的合同（您需要时间和物质合同），预算（阶段性预算）以及其他所有方面。



看板不需要如此根本的改变。 他提供：“从本质开始，并逐步改进它。” 变化率将大大低于Scrum中的变化率，但是所有变化将基于统计数据并有明确的理由。

神话8. Scrum仅设计用于从头开始的项目。

在不同情况下，没有严格的规定Scrum仅用于从头开始开发。 将现有项目转移到Scrum不仅可能，而且通常很合适。 这完全取决于表演者和客户是否愿意重组他们的工作以加快发展。 如果他们准备好了，那么一切都是可以实现的。

例如，Scrum的一位创建者Jeff Sutherland在他的《 Scrum：一半时间内完成两次工作的艺术》一书中，谈到了他是如何使用Scrum开发自动FBI会计系统的。 当他接手该项目时，开发已经进行了第四年，没有发布任何功能，并且该项目无论在末端还是边缘都看不到。 Jeff能够从根本上加快开发速度并使之对客户透明。 六个月后，该产品的第一个工作版本发布了，并在两年内成功完成了开发。

误解9.引入灵活的方法时，与传统等级制代表的冲突是不可避免的

如果一切都正确完成-将团队与传统层次结构分开，将预算交给产品负责人，并聘请真正熟练的Scrum-master，那么就不会有冲突。 但这并不总是会发生。 通常不可能将这两种结构结合在一起，因此只有一种出路：建立一个新的结构，为快速决策和产品实施而精打细算。

关于谁是这样的Scrum大师，您将在下一个系列中学习。 在瓦西里（Vasily）故事的第二部分中，讲述如何实施灵活的开发方法：困难，好处，陷阱和定时炸弹。

UPD 这是续篇： 都是关于敏捷-2：实施敏捷开发的功能

没有时间解释，该材料是由Mail.Ru云解决方案团队无私地，精心地准备的。