以你自己的方式敏捷:YouTrack团队的Scrum指南
六年前，YouTrack团队开始在YouTrack（我们的问题跟踪器和敏捷项目管理工具）。在Jetbrains，Dogfooding是产品开发的关键原则之一。因此，在为客户构建符合敏捷框架的主要原则的客户构建工具时，我们知道我们必须先遇到敏捷的第一手。那是我们决定采用scrum的时候。
这是我们对敏捷行为世界的第一次尝试。不幸的是，经过几年（当我们的敏捷板被发布时），我们暂时放弃了Scrum实践。在2016年，我们介绍了我们的Scrum转世，这次追求完全不同的目标：
- 切换到连续交付
- 加快开发进程
- 提高代码质量
- 改善团队内部的产品愿景共享
在我们找到最适合自己的平衡方法之前，我们尝试了各种实践，做出了妥协，甚至不得不打破一些Scrum规则。
非传统的Scrum团队
在一个完美的Scrum世界中，团队相对较小，人员分布也很好。这使得我们的Scrum团队不够完美。我们共有27人，分布在JetBrains在俄罗斯圣彼得堡和德国慕尼黑的两个办公室。
由于公司规模太大，我们不想让Scrum会议分散我们对产品工作的注意力。这就是为什么我们严格限制了Scrum活动的预算，将每两周的冲刺时间减少到6小时。当然，我们非常依赖视频会议，并利用实时团队协作工具，如Slack。
Scrum角色
为了启动Scrum转换，我们必须定义谁将接受每个核心Scrum角色。
产品拥有者
在YouTrack中，产品负责人的角色由团队领导承担，他负责开发并与团队分享产品愿景。团队领导是在他的头脑中有“大蓝图”的人，确保我们的产品目标满足我们的客户的需求，同时团队寻找最佳的技术解决方案来实现这些目标。
Scrum Master
整个过程由Scrum Master驱动，来自Youtrack团队的开发人员负责在规划期间呈现用户故事，将它们分解为单独的任务，并在Sprint期间跟踪其实现。Scrum大师不断监视进度，并确保每个人都遵循我们同意的规则。然而，我们的Scrum Master所做的真正魔法正在保持新功能之间的平衡，我们热衷于我们需要持续维护和抛光的平凡的事情。这就像绳索 - 在欢呼的人群面前走。
产品待办事项列表
在我们的案例中，产品待办事项列表是我们计划在YouTrack中实现的一组功能。团队每年至少会聚在一起召开一次全面的计划会议，讨论我们的主要目标和产品愿景。因此，我们创建了一个主要方向的列表，并定义了它们的优先级。我们还确定了我们需要开发的最小功能集，以便在早期预览时与我们的客户共享，以便我们能够尽快得到反馈，并在动态中调整新功能。
基于此列表，我们在我们的产品积压中创建了一组问题。我们将积压器保存在youtrack的单独项目中，仅对Jetbrains同事可见。我们将用户的故事从Backlog中链接到我们的公共项目中报告的功能请求和错误。我们还根据Backlog中的用户故事的适当状态同步每个公共功能请求的状态。这样，我们将我们的流程保持对客户的透明。我们不断微调我们的积压，重新排序用户故事，因为它们变得或多或少至关重要。这样，我们试图保持我们的产品开发战略，新想法和永无止境，但必要的维护过程之间的平衡。
Sprint Backlog
在新的sprint开始之前，我们的Scrum Master和Product Owner会检查产品待办事项列表中最重要的项目，并为sprint待办事项列表选择用户故事。我们的sprint计划安排并不总是必须包括产品计划安排中的顶级用户故事:Scrum Master会注意平衡新的亮点特性、对现有功能的改进和维护。
#noestimates方法
在遵循Scrum原则一段时间后，我们已经计算出了团队的自然节奏，现在对我们在一个sprint中可以完成的用户故事的数量有了良好的感觉。因此，大约两年前，我们在Scrum过程中引入了# noestimate方法。这种方法背后的主要概念是，我们的sprint目标是从sprint backlog中交付一组用户描述，而不管我们需要处理多少任务来实现这个目标。我们根据完成的用户描述的数量来跟踪sprint的进度。下面是我们sprint Burndown图表的一个例子:
这种方法允许我们花更少的时间估计用户描述和计算燃尽。我们还添加了一个简单的规则，帮助我们从这个方法中受益:没有任务可能需要超过三天的时间来完成。如果是这样，就必须将其分割成更小的工作单元。
Scrum Sprint计划
每两周的冲刺都从一个计划会议开始。我们召集了整个团队，包括QA工程师、用户体验设计师、支持工程师、技术写手和营销经理，讨论我们想要在即将到来的sprint中处理的用户故事。
计划会议通常从60到90分钟。Scrum Master介绍了为Sprint选择的每个用户故事，并开始讨论。我们的规划会议分为两部分：一般和技术。一般部队致力于讨论业务范围，并需要所有团队成员的存在。
接下来，在技术部分，开发人员讨论技术细节，并将用户故事划分为任务。这部分只有开发者和QA工程师才有义务完成。我们坚信，这些定期会议可以帮助整个团队保持一致，专注于对每个人都重要的事情。
Scrum冲刺
当规划会话结束时，Scrum Master将计划的用户故事从Backlog添加到Sprint Board，并为每个故事创建适当的任务。如果可能，每个人都可以自由地从最上面的泳道中开放任务，并开始工作。
- 在面板的顶部，我们添加了一些关键的错误和我们认为在sprint期间需要完成的重要任务。这个泳道帮助我们关注与任何用户故事无关的重要活动。
- 我们有两条泳道专门用于每个sprint的客户支持活动。关键问题被添加到最上面的泳道，而常见的和主要的支持问题去支持泳道在板的底部。如果我们不能在当前的冲刺中解决这些问题，我们就会在下一个冲刺中把它们移到泳道的顶端。
Scrum Sprint演示
其中一个主要的Scrum原则是透明度的想法。所涉及的所有团队成员都应该了解其他人都在努力，进展正在进行，以及团队正在努力实现的事情。Sprint演示和Sprint回顾都是很好的工具。
在每次Sprint结束时举行的Sprint演示，对于我们的团队来说是最令人兴奋的Scrum活动之一，因为每个演讲者都享受在队友支持下的聚光灯下的时刻。在演示过程中，用户故事的作者将在一个大型共享屏幕上演示各种使用场景，并解释新功能是如何工作的。鼓励讨论和反馈。最后，演讲者受到了英雄般的欢迎，并与观众一起向下一位作者发言。
的Sprint回顾在Sprint演示之后举行，通常在周五。这一小时的会议帮助我们获得关于完成Sprint的反馈，并为下一个Sprint收集“小而酷的功能”的想法。
通过收集、排序和讨论来自团队每个成员的反馈，我们继续进行有积极影响的活动，并消除消极行为。
我们还会投票选出推荐的新功能，并定义胜出者。我们讨论这个建议，如果我们发现它有用，我们将它安排到即将到来的sprint中。
底线
总之，采用Scrum帮助我们提高了团队的表现。团队总是在Scrum迭代结束时交付产品的功能部分，每个人都有完成工作的习惯。这种成就感让每个人都充满动力。评估任务所需的工作量更容易，而且整个团队可以在问题出现时立即解决问题。
我们通过Scrum实现了什么:
- 我们已经将关键bug的数量从2015年的792个减少到2017年的123个。
- 更短的发行周期:我们在2017年推出了4个主要版本。
- 团队成员对当前的产品状态有更好的理解，并且更专注于整体的产品开发。
提示和技巧
我们一直在遵循几个原则，在敏捷美食中找到自己的秘密成分：
- 我们制定规则并同意遵守。
- 每个团队成员都拥有自己的工作，并觉得有责任创造出优秀的产品。
- 自我管理是我们过程中必不可少的一部分。
- 流程需要持续优化，因为在此路径上没有端点。
- 工具应该足够自定义以适应您的过程，而不是相反。
对我们来说，Scrum已经成为一个基础，而不是一个我们必须遵循的严格计划。我们发现，对工作流程进行试验，找出如何结合不同的策略来更有效地进步，以及不断地进行新的设置，都是改善我们日常工作生活和以我们自己的方式变得敏捷的关键。
为了更全面地了解我们的Scrum转变，请阅读这篇文章系列相关帖子在YouTrack的博客上。
