哈Ha！ 我叫Maxim Lutzau，在Promsvyazbank担任产品负责人。 在将近一年的时间里，新的My Business Internet Banking的开发一直通过Scrum框架进行，在这方面，我已经设法弥补了这一难题。 在这篇文章中，我想谈谈其中最痛苦的事情，以及最终帮助我们的工具。 这样可以避免此类麻烦。
一些员工从根本上反对变革
我们的银行采用了Scrum框架，以加速开发并减少TTM。 实施开始时，事实证明有些员工还没有为此做好准备。 他们不明白为什么这是必要的，以及会带来什么。
“我们过去工作得很好，为什么我们需要这个？”，“为什么我们做的不一样？”，“谁来教我这个，他怎么知道这会更好？” -类似的问题不断出现。 即使这些员工收到了答案，一段时间之后，一切还是再次发生。
在这种情况下，最合理的解决方案是将人员转移到其他项目。 必须这样做，因为辐射负离子的人可以影响所有人。 在我们的历史上，这恰恰是我们集体的医治-总体紧张局势已经消失，每个人都对新信息的感知有所了解。
对变化的负面反应并不取决于年龄。 我们上面讨论的开发人员已有30多年的历史了。 同时，一个已经超过50岁的人正在我们的团队中完美地工作-他在Scrum上没有任何问题。
与不依赖Scrum的人很难互动。
任何组织都必须与那些不在Scrum上工作的人合作。 在我们的案例中，这些团队来自其他项目和部门。 他们通常有更长的项目实施阶段。 老实说，到目前为止，只有RBS开发人员在Scrum上为我们工作。
我们决定不对这个问题做任何事情-不要与我们的混乱者打交道。 我们只是要求他们做我们需要的事情。 当他们返回解决方案时，我们开始链接他们的任务。 如果企业文化本身还不成熟，则不要使交互复杂化。 当然，在进行了Scrum培训之后，我们希望改变所有事情，但是最好是及时停止。
尽管我们不急于其他单位，但与我们合作，他们开始更快地工作。 我们邀请保安人员参加我们的会议和演示，现在就可以同意完全释放只需要一天的时间。 在此之前，花了一个星期到两个星期。
“我们不会赶上冲刺！”
实施Scrum之后，我们从每月报告期切换为两周冲刺。 首先，由于任务的规模，他们不想压缩截止日期。 但是将sprint的大小调整为需要执行的操作是一个大错误。 相反，您需要在冲刺期间调整计划。 要做到这一点很简单-分解任务即可。 当它们的大小减小时，它们更容易按计划进行排列，以使其具有优先级。 少量的代码可以更快地与安全防护人员进行测试，验证和协商。 通常，如果可能的话，我什至建议将冲刺的持续时间从两周减少到一星期。
当团队中的某人没有时间完成冲刺结束时计划的所有工作时，自然就有希望推迟演示的时间-装备齐全。 但是在这种情况下，您仍然需要遵守时间表。 无论如何，值得一提的是工作的结果：他们做了什么，什么以及为什么没有这样做，为了及时而做了什么。 因此，我们不会逃避问题，而是与问题面对面，然后我们可以一起找到解决方案。
在计划的演示失败之后，这种方法会增加工作动力。 如果开发人员在五分钟内为演示准备好展位之前，现在他们在演示的前一天进行演示，然后抛光剩余的凸起部分，以使一切变得超级好。
“为什么我们需要每天站起来？”
刚开始，同事们对每天站立会议上的日常工作分散注意力表示怀疑。 即使他们在线上举行，只需要10分钟。
在解决此问题时，与团队找到共同语言的人的象征性鼓励会有所帮助。 一次，为了好玩，我说过我会在日历上标出那些站起来站起来并开始加号的人。 结果出乎意料，一次冲刺后效果显着。 不想被轰炸，开发人员自己站起来了。 甚至变成了我们的笑话：现在，他们威胁要在我无法参加任何会议时对我不利。
许多人认为Scrum会议需要很多时间。 在这里计算是否真的是足够的。 我们每周有40个小时，只有40个小时。这不是为了组织工作并保持最新状态。
如果整个团队不想参加独立会议，并且会议本身不是很活跃，则表明工作有问题。 好像会议被延迟了15至20分钟以上。 一个关于他在一个人中的活动和计划的故事不应超过一到两分钟。
另一个规则与时间管理有关。 如果对任务的讨论超过30分钟，我们将停止它。 这意味着我们没有时间来开发任务，它分解得很差，仍然需要时间。 这值得关注。 我们为自己设置了30分钟的限制-每个公司都需要建立自己的障碍。
难以理解的积压
Scrum的成功主要取决于明确的计划。 有必要确定应该评估和描述多少个任务，哪些可以暂时推迟。 不要试图一次覆盖所有内容。 开发人员需要了解他在接下来的两个冲刺中将要做什么。 对于更长的时间，一个大概的想法就足够了-以后的细节就更少了。
微观管理不当
开发人员今天在做什么？ 明天会发生什么？ 经理经常碰到这样的问题。 我们能够向我们的管理层解释，所有兴趣点都可以在我们的Scrum板上找到，也可以通过每天站起来来找到。 在Jira中没有带有表格和监视任务的特殊报告。 我们设法将这种微管理压缩到每周一次与管理层的会议上，在那里我报告团队执行的特定任务。
几乎从未写过的东西
最后-有一个明显的问题，我几乎从未发现过。 无需尝试将Scrum管理员和产品所有者结合在一起。 后者正在建立一个业务部门，进行积压工作，并执行KPI。 他对产品的成功很感兴趣，并试图深入研究一切-因此，他开始约会，讨论一些细节。 通常，它会为自己加载一堆函数，因此没有积压的时间。
这发生在我身上。 我组织会议，站起来，解决了团队成员的问题。 因此，未解决积压，也就是说，没有时间进行主要活动。 现在，我们已经找到了一个开发经理，该开发经理对团队有权限，并且还开始执行Scrum管理员的职能，因为他在该框架上有更多的工作经验。 现在，我可以脱离Scrum并完全专注于产品负责人的任务，而产品负责人又应考虑要求。 没有好的要求，就不会有好的产品。 结果，积压工作开始改善，同事们开始了解我们将如何发展。
乍一看，Scrum看起来很简单，但仍有很多陷阱。 我们已经在这个框架上工作了将近一年，但是直到现在，我们才开始或多或少地清楚地评估我们的能力，开始提高发展速度。