我们继续探讨实践中发生的敏捷开发的细微差别。 如何理解敏捷实施是否正确，哪种实践适合于哪个任务和行业，公司中的谁应将工作转移到“敏捷轨道”上？
敏捷教练ScrumTrek的Vasile Savunov继续与
Mail.Ru Cloud Solutions 博客的编辑分享他的经验。
上一次，瓦西里谈到了什么是敏捷，它包含了什么方法论以及围绕它形成了哪些定型观念。 现在让我们谈谈它的实现。
关于敏捷公司
-灵活的方法中是否存在“行业偏好”？正如我们连续第二年进行的
敏捷俄罗斯研究表明，Scrum主要用于软件开发，金融机构中的看板，以及电信行业中。
作为直接分析收集的数据并与许多受访者一起工作的人，我认为这种情况是由于两个原因：
- IT的变化率显着高于财务的变化率。 因此，最好使用Scrum作为一种方法，由于快速的实验，该方法允许根据外部环境和入口条件的变化灵活地控制优先级并更改方向。 金融更为保守。
- 财务错误的成本要比IT开发高得多。 因此，基于数学而不是实验，他们更看重看板，并允许通过微小但不断的更改来改善整个工作流程。
电信看板也适用。 仅仅是因为该行业的发展载体是数字化。 但是，很少有人了解它的外观。 另外，在电信中，工作的“快速”部分（软件开发）与“慢的”部分（硬件基础结构的支持和开发）相邻。 因此，连同在Scrum上进行的实验一起，使用看板来逐步加速当前流程是有意义的。
各个行业采用了敏捷开发实践。 数量不等于100％，因为可以选择一个以上的项目。 图片/ ScrumTrek-那么移动开发者呢？ 敏捷在移动开发方面是否有细节？在我看来，开发移动应用程序的主要困难是确定应用程序需求，因为可能很难确定涉众。 通过使用客户开发来研究客户需求并使用Scrum快速测试产品假设，可以克服这些困难。
客户发展客户开发 ， 客户开发 ，自定义，客户开发（有趣，有人说吗？）-这是一种通过在实际市场中进行不断测试并根据这些实验的结果进行改进来创建产品的方法。 这将习惯引入科学方法，使产品“科学合理”。
CustDev是精益启动方法的要素之一，而精益启动方法又是创建产品的敏捷方法之一。
总的来说，敏捷与移动开发相得益彰：它需要快速反应，不同专家的参与和协调工作，快速提供结果并在必要时进行更改的能力。
除了Scrum，您还可以在这里直接使用专注于移动开发的方法。 例如，Mobile-D基于XP，Crystal和RUP-方法非常古老且行之有效。 Mobile-D和Scrum之间的主要区别是：明确的阶段，并且主要侧重于产品开发的工程方面。 尽管Scrum更加关注产品管理和交付，但Mobile-D专注于制造过程，并包括XP实践，这些实践显着提高了最终产品的质量。 同时，RUP的影响也会影响，因此该过程相当正规。
另一种最现代的移动开发方法是
SLeSS ，结合了Scrum和
Lean Six Sigma 。 首先，他实现了Scrum工作流程的设置，然后将精益六西格玛方法应用于统计质量管理。 在我看来，SLeSS将必要的灵活性与基于统计的明智决策机制结合在一起。
同时，《 Scrum指南》最初并未禁止在Scrum工作流程中包含任何其他可能对产品开发有用的方法和工具。 因此，以上所有内容都可以在“经典” Scrum框架中实现。
-在特定条件下进行修改的方法有多灵活？应该分别考虑Scrum和看板。
Scrum是一个框架，即一个框架，所有元素都需要：事件，角色和工件。 没有任何东西可以扔掉。 但是，对于如何准确实现这些元素没有严格的要求-随心所欲。 Scrum并没有禁止添加新元素：会议，工件，您需要工作并帮助加快流程的角色。
看板是一组工具和指标。 他没有对使用哪种工具以及使用哪种组合进行严格的设置，因为它是为现有系统的长期演进而设计的。 但与此同时，看板的成功取决于工作过程中数据的收集和定期分析。 如果不这样做，随着时间的流逝，一切都会消亡，并且不会有进一步的改进。 但这没关系：正如爱德华·戴明所说，您不必改变；生存是自愿的。
-适应性Scrum做生意的典型错误是什么？实施灵活方法的主要错误在于使用工具时不理解为什么应该专门使用它们。
例如，在大型组织中，当实施Scrum时，他们通常只是简单地将项目经理重命名为产品的所有者，然后将项目团队改名为Scrum团队，并开始要求在两周内给出最终结果。 但这是行不通的，原因很简单：无法满足Scrum
可以工作的条件 。
- 尽管项目经理被称为产品负责人，但他尚未获得必要的授权，因此无权制定产品愿景或更改实施优先级。 和以前一样，他被迫与领导层协调每一步，并被限制在时间安排和工作量要求的框架内。 因此，决策的速度保持不变。 没有加速或适应不断变化的条件。
- 尽管项目团队称为Scrum团队，但仍可以在每个部门中列出其中的人员，并直接向其部门经理报告。 因此，每个团队成员首先要做的是他的直属经理（而不是产品负责人）将要委托他的工作。 结果，产品任务的优先级将始终较低，这意味着Scrum团队“组装”的产品实施速度根本不会提高。
- 与以前一样，团队成员很可能会忙于其他项目。 虽然Scrum直接声明：团队成员必须100％分配给Scrum团队工作时间，并且只能处理其产品负责人领导的产品。 如果人们按项目/产品之间的百分比“划分”，那么他们将在它们之间切换，这将大大减少每个特定项目/产品上的投入和工作效率。
这种无能为力的“实现”具有许多负面影响，但它们首先是尝试重现机制，而不是重现Scrum的本质。 我在CodeFest 2017大会上的报告“
敏捷的停止信号 ”中详细描述了Scrum实施中的主要错误。
-如何评估公司如何有效实施灵活的方法？有一个
Scrum Open测试，但更多地用作理论知识测试。 在实践中发生了什么，他不允许理解。 鉴于Scrum的基础是团队合作，并且其优先级是产品交付的速度和消费者的价值，所以
360度调查是最合适的。 因此，确定团队的成熟度和客户满意度会更加可靠。
我们使用自己的方法，该方法已在
ScrumTrek诊断工具服务中实现 。 她那样工作。 向团队和外部的相关方询问一系列问题，这些问题涉及他们如何评估团队互动的水平，计划工作，交付给客户的结果的价值，与其他团队的互动等等。 对于每个参数，都会计算意见的中位数，并构建一个复杂的饼图-Radar，它既可以显示团队内部的外观，也可以显示外部外观。
雷达ScrumTrek。 我们看一下评级的分散性
雷达ScrumTrek。 我们看中位数该图包含许多有用的信息。
- 个体的原子估计及其平均值本身很有趣，在此无需解释。
- 团队中的成绩分散是一件有趣的事情。 当规模很大时，有理由就我们团队的一个或另一个方面达成共识。 例如，“客户价值”是什么意思？ 那“送货速度”呢？ 较大的差异表明团队在多个问题上尚未形成一个统一的职位。
很小的差异表示共识和良好的团队合作精神。
- 评级是分类的。 您会看到，这种文化一切都很好，但是某些地方的生产力正在下降。 很清楚在哪里“挖”。
- 团队内部和外部评估之间的差异是最重要的指标之一，它显示了客户和团队中其他相关方的期望以及团队如何感知自己之间的差异。 敏捷是关于业务与销售产品的人员之间的紧密互动，因此，这些差异是“检查时间”这两个领域并就如何重组团队达成一致的极好的理由。
收集数据后，必须在整个团队和利益相关者的参与下对图表进行分析。 一切都向他们展示了团队工作从不同角度看待的情况，并将分析结果处理为改善工作的具体步骤。
关于Scrum实施团队
-公司应该从谁那里开始实施敏捷开发方法？Scrum实施始终来自业务目标。 因此，客户应该首先考虑内部或外部加速。 然后，您需要弄清楚产品的概念，以便可以迭代地完成它。 然后才组成一个团队。 为了Scrum而无法使用Scrum。 而且，解决特定问题可能太昂贵了。
谁将成为公司的“敏捷指南”，这是一个没有唯一正确答案的问题。 我看到技术总监成为了变革的“推动者”。 在某些情况下，该计划源自商业活动，甚至看到这种计划是如何“从下方”产生的。 这完全取决于人的精力和动力，取决于他是否能够使用灵活的方法将其发展愿景嵌入产品或部门的业务环境中。
当主动性来自高层管理人员时是理想选择。 在俄罗斯市场，这一方向的进步是显而易见的。
-通过引入灵活的方法，组织或团队中会出现哪些新的角色和职能？ 其中哪些是必需的，哪些是可选的？对于Scrum，这是Scrum主管，产品所有者和开发团队的角色。 所有这些都是必需的。 开发团队也被视为“角色”，因为它不仅将开发人员，而且也将需要该产品的每个人都原则上结合在一起：分析师，设计师等。
Scrum-master和产品的所有者可能有助手来承担部分职责，而结果的责任仍由Scrum-master或产品的所有者承担。
产品的所有者通常是企业的人。 但不一定：假设我们为生产创建某种工程解决方案，那么总工程师可以扮演这个角色。 归根结底，这是最了解我们为谁生产产品的消费者，首先解决什么问题，在创建产品时应如何建立优先级的人。 产品所有者有权根据来自市场和消费者的数据独立确定产品的组成，这一点非常重要。 他应有权对与他互动的有关各方说不。 这是必要的，以便优先事项被商定并迅速做出决定。
Scrum-master是一个人，其任务是创建一个强大，团结，负责和理想的自组织团队。 重要的
不是团队领导者 ，即不是领导者。 不允许Scrum-master提供指导或直接干预产品开发。 他是组织者，主持人，教练和敏捷实践者。 以我的经验，最好的Scrum主管来自项目经理-只要他们经过培训并设法从指令格式过渡到教练格式即可。
教练沟通方式沟通的教练风格是指我们在平等的基础上与人沟通。 我们不认为先验的成年独立人士是要接受监督的病房，而是尝试鼓励他们独立寻求解决问题的办法。 而且只有当他们陷入停顿时，我们才会介入并提供专业知识。 换句话说，在沟通的教练风格中，指示性方法被委派的方法所代替。
一个例子 。 一位下属来到领导者那里说：“我无法从这两种实施方案中选择最好的一种。 您决定！”
如果您使用教练方法，经理将开始提出问题：您为什么选择这两个选项？ 你从什么开始的？ 您在它们之间进行选择的困难是什么？ 还有谁可以帮助您？ 依此类推。 通过提问，主教练可以帮助一个人探索可能的选择。 结果，一个人已经知道自己最好的方法，而领导者只需要就下属来的日期达成协议，并告诉他发生了什么。
委派之后的下一步就是眼光。 在认可方法中，员工或团队达到了成熟和负责的级别，以至于主管从业务角度仅对问题作了顶层说明。 员工或团队独立考虑解决方案，评估期限，确定风险。 经理可能只是认可所有这一切-从他的专业知识的角度添加一些内容并进行一些调整。 然后，他们就需要显示结果的里程碑达成共识。 此外，员工或团队完全负责结果的实施和演示。 在认可方法中，作为业务任务的一部分，主管仅充当员工或团队的策展人和助手。
说到教练的沟通方式。 还有一个
敏捷教练 。 他的任务是建立工作流程，教育人员并为他们提供敏捷中日常活动的工具。 包括冲突解决工具。 其他一切都超出了它的权限。 理想情况下，敏捷教练应该组建团队或部门，以便一切工作都能独立进行，而无需敏捷教练。
过渡期总是伴有不适感。 敏捷教练旨在帮助团队以最小的摩擦度过这一时期，并开发出新的-方便有效的工作方法。
扩展时，可以引入其他角色，例如在
SAFe框架中所述 ，但它们仍基于Scrum-master或产品所有者的职权范围和工作原理：仅出现有关产品的层次结构级别。
安全的SAFe或可
伸缩敏捷框架是在大型软件开发团队中使用敏捷的框架。 在最简单的实现中，该方法涉及两个级别：团队和计划（分别为团队和计划）；随着组织结构和产品变得越来越复杂，投资组合和大型解决方案也会添加到其中。 SAFe的工作基于诸如ART（敏捷发布培训）-“发布培训”之类的实体。 通常，它将多个团队和感兴趣的各方联合成一个结构，该结构可以长时间共同创建对客户有价值的产品或产品的一部分。
-产品所有者和Scrum-master在“理想世界”中的功能有何区别？规模的一方面是产品所有者代表的业务利益，另一方面是Scrum主管负责的团队的活力和有效性。 为了使团队快速取得成果，系统必须处于平衡状态。 如果产品的所有者感到“压力”，团队将在晚上和周末工作，很快，他将面对少数干劲十足，毫无干劲的人，而不是一个协调良好的团队。 如果Scrum-master盖过了自己的毯子，那么发展将既不会动摇，也不会一sw不振，不断发生争执，而且会比必要的时间更长。
例子因此，这不是抽象的，这是团队内部的一个发明的微对话。 看看它的每个角色怎么说：
产品负责人 ：所以！ 我们将需要提供这样的功能！ 您在上一个冲刺中做得很好，所以我认为您可以做到！
Scrum-master ：但是在上一个Sprint中，团队做出了类似的复杂性极限，我不得不在周末去，有些则在晚上工作。 另一个这样的冲刺-人们将开始生病，筋疲力尽，也许结果将开始。 我们不带它去吗？
产品负责人 ：真的那么认真吗？ 如果是这样，让我们与团队讨论如何在不消耗人员的情况下完成冲刺。 此功能有一部分需要完成，看起来并不复杂。
Scrum-master ：让我们与团队讨论。 您知道只有她才能说出它是否“困难”。
产品负责人 ：加油。
-对于那些要担任上述角色之一的人，哪些方法和管理模型值得掌握？在业务能力方面，除了需要按阶段确定优先级并与团队进行更紧密的互动外，一切与普通管理层一样都是“遵循经典”。
产品负责人应学习精益创业，客户开发和其他现代方法来创建产品。
对于
Scrum-master，能力范围更广：简化，冲突管理，团队动力，教练以及敏捷实践。 相反，这些是心理学领域的技能，因此在培训管理人员时会感到缺乏。
-集体拥有代码是否真的减少了公司对“明星”开发人员的依赖？ 他们的动力下降了吗？没有灵活的方法，集体代码所有权是可行的。 足够的代码审查协议和其他正式规则，并且开发人员可以自动执行。
通常，公司本身会激起工程师的“星光”行为：乍一看，与组建一个中农团队，系统地减少因错误造成的风险并提高他们的敬业精神相比，它聘请一名超级专家并全权委托他对结果负全责，这对于公司来说是更具收益的。
这是一个难题：短期或长期的成功。 雇用“明星”似乎对企业有利。 但是，这样的专业人士加入公司后的三年，五年，七年会发生什么？ 他将变得不可或缺。 并带来至少三个负面后果。
首先，这样的人几乎
没有空闲时间 ，而公司基本上不在乎。 她的逻辑是：“我们不会付给您高昂的薪水，以便您可以休息。” 陷入类似情况时，人们很快就会精疲力尽，陷入犬儒主义，并试图从自己的职位中获得最大的利益。
-, . , , , .
: , , , , . , .
-,
«» . , : , «», «» . : , , .
— , - ?- , «»: . .
- . , , .
- «» , , , , . . . , , .
- «». «» , «- ». Scrum-, «», , «» , , . , , «».
, , . , « ». , , « » . , «
. - ».
Mail.Ru Cloud Solutions .