大家好，我叫Alexei Fedorov，我是花旗银行财务团队的负责人。 在本文中，我想分享我们团队中敏捷开发过程的工作方式。
CityMobil是俄罗斯第二大的出租车集合商。 一年来，我们增长了约10倍，并且不会放缓。 如此快速的增长带来了一些局限性：我们需要非常短的上市时间（TTM），从构思到真正的客户使用它的时间应尽可能短。 由于我们将TTM最小化，因此我们不收集发布，而是分别滚动每个任务/功能。 而且，这种方法还有一个重要的优点-如果产品中出现问题，则立即清楚为什么会出现这些问题。 这使您可以回滚任务，而不是整个版本。
为什么不Scrum
几年来，敏捷方法及其Scrum变体（以下称为Scrum）在IT行业中很流行。 Scrum试图以某种方式在每个公司中实施。 每个人都有自己的实施经验，但是通常来说，它很少是积极的。 幻灭和回退到以前的过程通常更多。
我认为，scrum的主要问题是：
- 固定的冲刺。
很少能按时关闭冲刺，以便完成所有操作。 通常，仍然存在一些未固定或未验证的琐事。 改进转移到另一个冲刺，并且为了按时完成，团队需要执行更少的任务。 平衡任务的冲刺，使每个人都有工作很困难。 RnD任务通常不适合固定框架。 最重要的是，企业本身很少要求固定冲刺。 - 各种集会。
Scrum有很多活动：每天的集会，计划和每个冲刺的回顾。 这些会议通常是为展示而举行的，而且累人而不是有益。
总的来说，混乱让我想起了某种货运狂热，它正被引入，希望它会变得更好。 我们的方法是使用有助于实现结果的技术和流程，并摒弃任何干扰因素。
团队
团队及其结构是流程形成过程中的关键角色。 我们的团队包括开发人员和团队负责人。 可选的PM，QA，分析师，设计师。 必须将团队视为单个战斗单位。 这是一个灰色框，在入口处有要求，在输出处（产品）。 内部组织完全受团队支配，在其内部，它可以执行适合它的任何流程。
和我们一样
我们的团队选择了与看板非常相似的流程。 我们有许多任务来源：由错误支持服务发现，产品的新功能，技术债务，相邻团队的功能等。 任务来自何处都没有关系，应该在任务跟踪器中对其进行框定，最好由作者本人来确定。 任何传入的任务都会经历几种强制性状态：“新建”，“正在工作”，“进行中”，“已测试”，“准备部署”。
任务在板上从左到右移动，很少返回。 优先级从上到下，从右到左。 例如，在生产中推出任务比测试更重要，而测试比新开发更重要。 “工作”列实质上构成了团队的待办事项列表-提前两周按优先级排列的线性任务列表。 一旦开发人员了解了他当前的任务，他便从顶部开始进行下一列。
对于特定的开发人员来说，任务不是预先固定的，这种方法可以平衡任务的执行，增加所有开发人员对代码的常识，增加总线系数。 我们尝试处理团队内部狭窄的专业化问题。 每个团队成员必须能够执行积压的任何任务。 如果开发人员自己完成任务，那么他将完全控制其在板上的运动，直到它出现在产品中。 他还检查任务在实际条件下的行为。
在我们每天举行的会议中，在这次会议中，我们不仅讨论计划，问题和已完成的任务，而且还讨论解决问题的方法，提案和总体上使团队成员担心的所有问题。 会议很少需要4个人参加超过30分钟的会议。 每个月，我们都会对一个scram样本进行回顾：什么是好/坏，我们该怎么做，一项提高下个月效率的计划。 我们没有专门的计划，如果我们开始制定大型任务，则可以安排计划。
我们尝试记录每个任务的时间，至少占工作时间的75％。 这样，我们可以实现两个目标：
- 我们寻求并消除时间杀手：既费时又没有带来预期收益的任务。
- 我们根据已经完成的任务来评估任务，从而提高评估的准确性。
我们还有每周的班次：一名开发人员从第二条支持热线回答问题，在日志/监视中搜索新问题，解决紧急任务，并做一些不符合计划的待办事项的事情。 这使其他开发人员可以将更多的精力集中在他们的任务上，而不会被使者分散注意力等。
总结
所描述的过程略有变化，我在多个团队和公司中应用了该过程。 他确立了自己对所有人最灵活和透明的态度。
我们不为所欲为，每进行一次新的回顾，我们都会使我们的工作流程更好，更高效。 每次我们审查使用的做法。 我们没有“神圣的牛”-以前行之有效的方法可能会停止工作，而且许多理论上的好主意并未在实践中以最佳方式展现出来。 我们放下它们，不会后悔。
持续改进的过程是我们团队的基础。