在战场上独自作战不是战士。 有效团队合作的道路

团队是一群人，他们朝着一个共同的目标而努力，将任务和责任分配给特定的结果。 创建团队是为了解决一个人无法完成的任务。 一个高效的团队可以在最短的时间内以最低的成本实现目标。

召集一些人说：“现在您是一个团队，我们正在等待您的结果”，它将无法正常工作。 人们需要组织起来，给他们一个理智的目标，动力和解决问题的能力。



关于Evgeny Fedoreev关于TeamLead Conf的报告的解码。 在报告中，尤金（Eugene）分阶段描述了在Banki.ru上组建有效的开发团队的过程：在团队和部门内雇用，交流，共享知识以及开发开发人员和测试人员。


演讲者简介 ：Evgeny Fedoreev（ hardj ）从事网络开发已有15年，其中6年是团队负责人，现在他在Banki.ru领导新项目的开发。

什么是Banki.ru？

公司的背景是要了解将讨论哪些经验。 Banki.ru是Runet最大的独立金融门户网站，每月访问量超过800万的唯一用户。

IT部门拥有50-70名员工，分为7个开发团队。 所有开发都在内部进行，没有远程开发人员，因此不需要适当的流程和指标。

开发团队的主要任务

在准备报告时，我问了一个问题：

- 开发团队的目的是什么？
- 发展。
- 那是什么意思？ 如果一个人坐下，重构，不带来利益，不解决业务问题-这也是一种发展吗？
-...需要有效开发。

发展效率

效率的概念对管理者而言是一回事，对开发人员而言则是另一回事。

对于经理来说，有效的开发是可以预见的 ：当已知功能的发布日期或完成任务的截止日期以便进行一些业务活动时。

对于开发人员来说，这是一项技术债务的工作 。 这是自从与他们合作以来的痛苦之一。 债务，用于重构，更正和改进的时间很少。

下一个性能标准是错误的最小数量。 可以写道，标准是完全没有错误，但是我们知道这不会发生。 另外，由于不需要测试人员，因此会冒犯他们。

未来的挑战 。 我故意没有写“思想的体系结构”。 深入研究并事先对架构进行思考是邪恶的，因此应该感动未来的发展，但不要狂热。

每个团队都有的其他任何条件 。

开发过程

公司开始发展壮大后，我们开始在Banki.ru建立开发流程。 出现了新的合作伙伴和项目，而6-9个后端开发人员还不够。 我们得出的结论是，我们需要建立开发流程并将其形式化以进行有效的工作。

最初，我们有3个团队，每个团队都有3个后端开发人员和一个负责站点部分的经理。 后端开发人员除工作外，仍在排版和连接jQuery插件，因为那时前端很少有人。



我们让两个前端开发人员和两个测试人员一起生活，没有错误，并认为这种配置就足够了。

在理想的世界中，开发过程应如下所示。

• 项目经理将任务放到后端团队中，然后他们执行它。
• 如果需要修订，他们会将任务发送给前端团队。
• 完善后，前端会将其交给质量检查人员。
• 没有错误？ -生产中。

我们建议世界不是完美的，并且由于任何开发中都存在错误，因此质量检查将返回任务，并添加了另外两个箭头。



更新方案后，我们认为一切都很好，并开始着手进行工作-我们执行了sprint计划，后端团队自己将任务纳入了计划。 他们工作了2个月，才意识到出了点问题。

我们的计划已经改变。 任务像乒乓球中的球一样跳跃：从质量检查到前端，再到开发人员，甚至到达管理人员。



箭需要花费很多时间-交付任务与服务器作战的过程太长。 这不适合我们。 我们希望减少箭头的数量，以便更快地完成任务。

如何减少交货时间？

我想到的第一件事是问一个问题， 为什么我们要退回任务 ？ 为什么后端，前端和质量检查对问题的理解不同？ 为什么意见不同？ 我们得出的结论是，我们在项目经理中发现有罪的一方，他没有完整描述任务，并告诉PM更全面地描述任务，以便每个人都可以理解其含义。

我们有三个后端团队在计划中。 我们让测试人员和前端开发人员参与了计划 ，但是对于3个团队来说，只有2个前端开发人员和2个测试人员。 通常他们没有成功打电话给他们，因为有人必须工作。

我们将任务分别分为前端和后端 ，以便将它们并行提交给开发人员，测试速度更快，而不必等待整个链。

我们尝试了所有解决方案。 结果，时间减少了，但我们仍然不高兴。

我们认为下一步该怎么做。 市场上有很多公司和业务，我们开始研究，观察，挖掘并进入功能团队。

功能团队

这是团队让所有人员完成任务的时间：

• 后端开发人员。
• 前端开发人员。
• 质量检查开发人员。

它们之间也有联系，任务可以跳跃并打乒乓球，但是联系要短得多，花费的时间更少。 整个团队都参与了计划，她对结果很感兴趣，并创建了一幅图：做什么以及如何在短时间内将任务交付战斗模式。

那时，我们转而使用敏捷和Scrum：我们邀请了教练和教练，在公司举办了大师班，并开始了经典的Scrum –两周的冲刺，评估，计划和修饰。 现在任务可以更快地进入战斗模式，但是却遇到了很多问题。

功能团队问题

当时，我们有6个问题。

• 总线系数 。
• 漫长的计划 。 为了进行计划，我们预留了半天或更长时间：我们整理了任务，留了下来吃午餐，然后再次整理。 当计划结束时，没有人可以工作，也不想这样做-失去了一天。
• 未公开的sprint 。 这是一个严重的痛苦-冲刺中的大多数任务没有到达“完成”列。
• 团队任务的不同性质 。
• 新团队的出现 。
• 团队之间的经验交流 。

有问题，我们将解决。

总线系数

最初，每个团队都由一个前端开发人员，一个测试人员和三个后端开发人员组成。 我们雇用了其他前端开发人员- 重复了角色 。

介绍了每周一次的指示会议 。 前端开发人员每周都会分别开会，讨论新技术，解决问题的方法，并就通用的实践方法达成共识。 测试人员还聚集，协商并决定了如何进行测试，并讨论了自动测试。

前端开发人员引入了跨命令代码审查 ，这是当一个开发人员在一个团队中解决问题并将其提供给其他团队审查时，并且至少经过两次声明后，任务才进入测试阶段。

自动测试已添加 。 团队中只有一名测试人员，并且无法复制它，因为没有如此数量的任务。 我们在另一个团队的测试人员的帮助下达成了共识：他将照顾相邻团队的任务，并替换休假的员工。 这稍微增加了时间，但是测试了任务。

长期计划

我们分析了计划任务。 在冲刺时，每个人都在工作和编码，在计划几乎是第一次打开任务并弄清楚要做什么时，测试人员澄清了“完成的定义”，以便了解如何测试任务。

这个过程很耗时。 我们决定在计划之前分解任务 ：我们建议开发人员在空闲时间查看任务，提出问题，以便为计划做准备。

我们邀请管理人员对任务进行更详细的描述 ，但不要过多，以免引起大量文档的影响。

我们特意预留了一个额外的修饰时间，而不是空闲时间。 他们聚集在一起，讨论任务并为计划做准备。

未封闭的冲刺

这很痛苦。 也许有人关闭了它们，但当时与我们同在-不。

我们决定将冲刺能力从10个工作日减少到8个工作日 。 我们认为我们会计划8天，而离开测试人员2天。

实际上，事实证明，当开发人员看到较少的任务时，他会慢慢执行它们。 冲刺中的任务减少了20％，但没有给出任何结果。

在冲刺开始时，虽然有时间，但测试人员制作了测试用例。 从理论上讲，在sprint开始时，当开发人员在工作时，测试人员没有任何任务。 我们同意，这时测试人员可以完成所有任务，草拟测试用例，当任务要进行测试时，他将在准备好的测试用例上运行它，并减少测试时间。 在全球范围内，这没有帮助，尽管时间略有减少。

减少冲刺的容量并加载测试仪并没有帮助，我们考虑了如何解决该问题。 那时，有关马克西姆·多罗费耶夫 （ Maxim Dorofeev）的目标和几种实践的书引起了我们的注意。 我们意识到推动“不可推动”将行不通，并开始从瓶颈（从测试）开始计划冲刺 。 在计划时，测试人员进行评估，从他那里计算出冲刺能力，然后为测试者冲刺任务。

上课！ 我们去找经理们推销这个想法：

- 我们决定从测试人员那里计划。 冲刺将关闭，这将很酷！
- 等一下，自由开发者现在会做什么？ 任务将减少，他们将有空闲时间！
- 您是否希望封闭冲刺，发展是可预测的还是人们的主要目标？
- 不，这仍然是可以预见的发展。 让我们关闭冲刺。

对话后，一个团队开始以新的方式工作。 该方案表明了它的生存能力，我们对此进行了研究，完成了冲刺，开发人员有时间。

事实证明，开发人员在空闲时可以做很多事情。

即： 与那些人一起工作。 债务 。 团队始终拥有共同的技术。 欠部门的债。 这些任务可以用于工作和测试。 通常，那些。 债务是系统重构。 对于这些任务，必须进行回归测试，并且团队测试人员不应该总是这样做。 测试部门确定了执行回归的特殊测试人员，包括测试部门的负责人。 这些任务。 债务已分摊给其他员工进行测试，我们的测试人员没有受到影响。

从待办事项中解析任务并阐明需求 。 当开发人员没有任务时，他查看了待办事项，明确了要求。 在计划时，已充分描述了任务，提出了所有问题并做出了决定。 仍然需要澄清细节，仅此而已-测试人员进行评估，任务已经完成。

帮助其他团队 。 那时，我们仍在练习帮助其他团队，在这些团队中，我遇到了麻烦，某人正在休假或生病，并且该项目着火了。 其他团队可以承担单独的私人任务并提供协助。

另外，总会有休假，培训，参加会议，这也需要花费时间进行准备。 当员工有机会学习一些东西，阅读Habr，在工作时间观看有关工作的视频时，忠诚度会提高。 我们解决了这个问题，每个人都感到很舒服。

团队任务的不同性质

我们的产品团队正在做一些新的事情。 他们有两个星期的计划，冲刺，漫长的项目，并且会在1-2个月或更长时间内发布。

我们有营销团队，他们的反应更加积极：任务已经完成了，任务已经完成了。 假设销售部门出售了平台-您需要快速完成。 这些团队最初还负责Scrum和为期两周的冲刺，但事实证明，在冲刺结束时，任务与开始时完全不同。 团队的不满，持续的奔忙，冲刺并没有结束-这种情况令人不快。

我们决定与PM和业务部门进行对话：

- 伙计们，我们有敏捷，Scrum，冲刺，流程-我们不要丢下新任务，但是我们可以预见地发展。
- 看，我们卖出了降落伞，需要在3天内完成。 我们为此支付了一百万。 什么过程？ 还必须赚钱！

一百万说服了我们。 我们开始进一步思考。

我们决定将冲刺时间减少到一周 -因此我们可以更快地做出响应。 这也没有用，因为当时为这个团队制定计划根本没有用。
然后，我们决定不计划冲刺，而是使用看板而不是Scrum ：任务来了，开始工作，发布了。 奏效了。 该团队的工作效率更高，因为它最初了解没有计划，但是只有要执行的任务。

为了改善团队的流程并获得反馈，我们开始每两周进行一次回顾 ：团队聚集在一起，讨论了进展顺利，失败的地方，利弊，并与之合作。

新团队的出现

在那一刻，我们开始成长，出现了新的团队：我们拥有团队领导，开发人员，团队正在成长，并且人们还不习惯彼此。 在此期间，我们不是在谈论计划-人们是第一次看到我们的代码，这可能很糟糕，例如，我们有点麻烦。 必须为此做些事情。

可以采用相同的看板，以便开发人员尽可能地执行任务，但这是一个产品团队，需要教它。 我们决定-让他们学习计划和评估任务，但将冲刺时间减少到1周 。

我们会在1-2个月内将时间增加到2周，这时团队就会习惯了，进入常规产品工作，将建立流程，开发人员将能够正常评估任务。

团队之间的经验交流

在团队内部，开发人员和测试人员相互交流并交流经验，但是这种经验不会更新，因为团队“会自己做饭”。 新的经验无处可寻。

我们开始思考该怎么做，并介绍了每周的团队会议。 会议的目的是通过团队负责人将经验从一个团队转移到另一个团队。

第一次会议如下：

- 您好，我叫尤金（Eugene），我们现在要发布新闻。
- 太酷了！

下次会议：

- 您好，我叫Eugene，我们继续关注新闻。
好的

没有什么特别的事情发生。

第三次会议：您好...而且都一样。

我们意识到我们需要更改格式。 阅读有关会议的书籍和
介绍了固定的议程。

现在，我们有一个Wiki页面，其中包含Timlid会议的日期，其中概述了本周要讨论的问题和任务。

这个决定的优点

• Timlids正在为会议做准备，因为他们知道议程并了解将要讨论的内容。
• Wiki页面可供所有开发人员使用。 每个员工都可以学习讨论主题，参与流程并提出问题。 会议结束后，我们在评论中修正了该决定，这些评论也可用。
• 如果在1-2个月后仍未解决问题，那么您可以在会议存档中查看如何确定问题的讨论以及如何使团队或团队领导失败。

我们喜欢会议的形式，并开始定期举行会议。

我们引入了一个跨命令的代码审查 。 这是前端开发人员和后来的后端人员已经实践的一种经验交流。 不必将所有代码都提供给跨命令代码审阅，仅重要的事情就足够了，例如共享库或通用代码段。 对于代码审查，我们只选择了感兴趣的团队，没有强制性的批准。
在某些情况下，与银行打交道的相邻团队要求完善功能-添加字段，然后由我们来处理贷款。您可以问另一个团队，但是他们有自己的计划，目前尚不清楚他们何时会满足要求，但您迫不及待。 在这种情况下，我们可以帮助附近的团队，但是在代码审查中，我们可以提供另一个。

碰巧的是，开发人员被要求转移到另一个方向或改变技术。 例如，我们有一位员工已经使用信用卡一年了，要求更改区域，而另一位员工想要将技术从UI更改为Symfony。 根据协议，我们将安排团队之间开发人员的过渡 。

一些公司在星期五举行会议：人们聚集在一起交流经验，讨论问题和交谈。 我们还决定组织星期五的聚会 -我们在Wiki上创建了一个页面，每个想发言的人都在该页面上撰写他的报告的主题。

一切都很棒。 在聚会上，团队讨论了他们在做什么，有什么新消息。 例如，对于其中一个团队，我们有一个误会，没人知道她在做什么。 在星期五的会议上，团队讨论了他们的工作，展示了分析数据，每个人都了解了他们工作的含义。 前端开发人员讨论了组装的进行方式，并讨论了常规技术主题，例如，如何在PHPStorm中使用Debugger，如何进行部署。

然后，发展主题结束，我们转向心理主题，故事开始消失。 如何进一步激发开发人员说些什么？

然后我们想起了KPI ！ 让我们教每个开发人员在星期五的聚会上讲六个月的演讲，并将其包括在他的KPI 2报告中。 我们认为这个想法很酷，每个人都会挺身而出。

事实证明，引入KPI后，开发人员停止制作报告。 强制演出导致负面演出。 程序员决定牺牲100％的KPI实施率，只是为了不提交强制性报告。

结论

当我们以效率解决问题时，公司正在开发，并且出现了新项目，我们不得不适应。 这是我们从中了解到的。

• 适应更改，而不是专注于已接受的更改，请查看更改并选择与团队合作的最佳实践。 如果开发人员无法使用Scrum，请使用看板，这样每个人都会感到高兴和高兴。
• 不断监控和更改流程 。 作为团队负责人，您必须控制团队中的流程。 导演不再适应它，开发人员也不适应它。 , , . , .

— .

. , , , : , PM, .

— , .

, :
— . — , PM.
PM .
— , ? — PM , .

, , .

. .

, . Jira Slack, , , . Scrum-, .

, .

.

. , . , . , - , — , — - . , . :

— ?
— !
— !
— , iMessage!

, - : , .

, : , , , 2 , .

« » .

— , , .

. , «», — , , . , , , . , , .
在环境和团队之间进行过滤。必须分配所有信息，以免影响开发人员。

TeamLead Conf计划的收集工作最热，该项目将于2月25日至26日在莫斯科举行。我将在这里告诉您有关结果的信息，一切都将与时间表挂钩，并且定期的主题收藏将出现在邮件列表中。