Promsvyazbank的我们正在积极地从瀑布通道团队迁移到边缘食品团队。 在某个地方花费了数个锥体，在某个地方已经可以改变耙度，但是结果，我们积累了很多与边缘变换有关的经验。 在这篇文章中，我们想分享经验-突然之间，您会发现一些新东西。
过渡到Edge的想法是如何诞生的
通常，公司中会出现一名意识形态专家，他会用Edge病毒感染每个人，谈论团队合作的价值。 他承诺，一切将变得简单而快捷，结果将使想象力惊叹，金钱将倒入我们的口袋，所有员工都将乐意带着咖啡杯和无休止的饼干躺在矮凳上。
为了加强对Edge的看法，我们邀请专家来预测产品的数百天工作，并因此预测产品的“衰变”及其消亡。 然后，也许是公司的灭亡。 一个例子是HTC和Blackberry。 如何不重蹈覆辙？ 顾问提供的食谱已被Google，Amazon，Apple等巨头使用，即灵活敏捷。
转换期间通常会发生什么
现在，您已经学会了所有必要的短语和短语，才能获得PMI Agile认证从业人员的光荣称号：“站立，修饰，演示，团队，董事会，贴纸，一切都经过了他们的认可而遍及整个森林。” 您是您所在领域的专业人士，您知道其工作原理和工作原理，还知道所有新的必要概念，事件和流程。 仍然需要进行敏捷转换。 这是常见错误的列表。
- 有开发部门，他们组成了边缘团队。
- Jira中无休止的更改请求任务队列变成了RFC待办事项，只需轻按一下即可。
- 以前，资源是集中分配给任务的，但现在它们已经将任务分配给了开发人员。
- “这位开发人员将如何处理我们？ 让我们在待办事项中执行此任务，他将能够做到。”
- 您设定了一个目标，以便在一个月的工作中摆脱对任务的评估。 作为响应，开发人员说：“好的，让我们开始执行此sprint，然后完成下一个。”
- 任务是否与安全部门和律师协调？ 让我们介绍一个规范性假期，而忽略这一刻。
- 任务是由老板分配的吗？ 然后我们做一个边缘，一个扁平的结构，但是“我仍然是老板”。
我们到底会得到什么？
结构未更改。 负责人将任务设置为下属。 人们脑力激荡，许多领导者，这些领导者在明确的期限内同时设定了不同的任务。 任务仅以冲刺（而非数月）衡量。
该做什么是不可理解的；该怎么做是不可理解的。 没有文档！ 整个团队始终坐在会议上，古老而又精干的技术人员和程序员都来参加会议。 他们看着团队中的员工，就像他们来到动物园观察背包中长臂猿的行为一样。
Scrum Master谈论就绪的定义和完成的定义。 但是，他们知道这是重要且必要的，为什么开发人员会拒绝？
尽管领导层在最后期限前完成了任务，但是不幸的是，在敌人和僵尸的猛烈攻击下，仍然脆弱站立的年轻人敏捷地死了。
怎么需要？
您不能盲目跟随成功公司的模式。 通过类比，例如通过足球，在这里更容易解释。 想象您是一名教练，您的球队在比赛结束前五分钟正在输球。 著名的培训师Ernesto Valverde使用了一个完美计划的例子。 据他介绍，前锋路易斯·阿尔贝托·苏亚雷斯闯入禁区，他被拆毁，法官任命点球。 莱昂内尔·梅西（Lionel Messi）上篮得分，恰好在离门将最远的上角射门。 无可挑剔的计划。 但是您不是Valverde，并且您的团队中没有Suarez和Messi。 仅此而已。 你输了
此外，我们开始坚持流程，而忘记了为什么要在工作中实施流程。 因此，我建议您制定一个目标并将其挂在显眼的地方。 大家都知道如何设定目标。 目标必须是具体的，可衡量的，可实现的，有意义的和有时限的。 在实践中这一切意味着什么？
实际上，这意味着在整个过程中最重要的是客户。 因此，一定要花时间，弄清楚谁是您的真正客户，谁为您带来钱。 描述他的人。 并非所有公司都对此问题有明显的答案。
对于客户而言，您正在生产产品，因此使用后，客户仍然会满意。 产品必须是：
- 有用，即解决重要的客户问题；
- 高质量，即达到或超过客户期望；
- 按时制作和提供，而不是一年。
该产品又由团队创建。 实际上，产品和团队是密切相关的。 正如在加勒比海盗沉船中被淹死的团队所说：“团队的一部分是船的一部分。” 一个好的产品离不开一个好的团队，反之亦然。 这就是大多数边缘转换尝试都失败的主要原因。 为避免这种情况，我们Promsvyazbank银行开始通过选择产品线和产品所有者来启动每个团队。
关于产品所有者的方式已经有很多说法和文章。 所有这一切都是正确的，主要的困难是找到您需要的人。 这是产品负责人的工作：
- 设定目标；
- 描述上层积压；
- 考虑KPI，通过它可以不断监控实现目标的方法； 包括不要忘记一个快乐的客户；
- 计算积压任务如何影响KPI。
产品的所有者不是知道如何有效转换他人酒店优先事项的人，而是想要的人。 他希望为客户提供最好的产品，并以他每天看到的方式制造产品。
开发团队是负责任的人员，可以独立地独立开发产品。 团队必须具备实现结果所需的所有能力。 外部依赖关系不能被控制；必须通过在团队中包含或培训合适的人员来消除它们。 绝对不需要组建具有冗余角色的团队。 要达成共识，团队应尽可能小。 从团队中消除这个角色；如果没有它，情况会变得更糟吗？
一开始对团队来说最好的问题是：“您是否有足够的能力实现目标？” 形成参与者组成的最有效做法是自我设计，即员工自己确定与谁和谁一起工作。 我们一开始就已经尝试这样做-当我们建议自己进行轮换时，效果很好。
现在已经有了一个团队，它应该努力确保在冲刺结束时增加产品的“良性”，并获得明显的商业利润。
Scrum中团队合作的一个很好寓言是龙舟比赛。 鼓手设定同步集体划船的速度，在船的开始处有舵手设定方向。 在我们公司中，产品的所有者管理着业务领域的愿景，而Scrum Master帮助团队保持正确的步调，以在各个方面同步工作。 鼓是Scrum板，是团队活动的常见聚会场所。
这里的主要错误是试图任命一名Scrum主管，甚至将多个角色合为一个人。 也许在成熟的团队中这会起作用，但这绝对不是您的情况。 即使在成熟的团队中，产品所有者也永远不能同时成为Scrum管理员。 您应该找到一名Scrum主管，而不是从与会人员中任命某人。 这样的人将帮助团队从短跑到短跑变得更有凝聚力和效率。
对于工程实践的开发，您不需要创建一个部门来进行诸如单元测试之类的正确工作，而是创建一个对此感兴趣的开发人员社区。 如果这些倡议是从底层诞生的，那么它们将在各个层面得到支持。
团队合作对所有有关方面都应该透明。 这是团队的职责，也是它的重要优势。 团队自行建立工作流程，所有可能出现的问题也将在成长过程中独立解决。
最后一个技巧：使用简单的工具。 吉拉（Jira）中的任何字段和过程都可以轻松地替换为带有一组磁铁的物理板。
我们来了什么？
我们定期有新产品团队。 他们没有讨论敏捷性，而是提出了新的功能。 多亏了团队中的人，创造了对客户有用和方便并且对银行有利可图的产品。