晚上。 另一项R＆D采访即将结束，我们的采访员被调适为来自未来同事的意外问题。 但并不奇怪：威尔弗雷多·帕累托（Wilfredo Pareto）得出的比率在这里也适用。 在80％的情况下，我们听到了四个问题-大约占总数的20％。 您的流程如何安排？ 我该怎么办？ 一年后如何成为高级/团队负责人？ 搬到欧洲呢？
在本文中，我们将回答第一个问题，并讨论Veeam的开发过程-从团队到团队，这个答案变化最少。
这样的过程。 这是每天或至少有时是成功的可重复动作序列。 您学会了如何煮罗宋汤，每次都变得同样美味-一个过程。 停车不是敲门-掌握了过程。 这个过程使大脑不必每次都去思考例程，而是将其转变为机械功。 大脑释放了创造力。
开发过程是一系列将用户的需求变成有形产品的动作序列。 这些需求由分析师和产品经理制定，由开发人员实施，由测试人员进行严格评估，并由技术作家进行描述。
Veeam的我们正在生产大量用于备份和数据中心复制的产品-这样就不会丢失任何东西。 没有特定客户的经典盒装产品。 乍一看，事情很简单，但有细微差别，因此我们要在第二个十年中做到这一点。
演员们
每个版本都是几组的结果：
- 产品经理或分析师 。 他们优先处理工作，并与客户和合作伙伴与外界进行沟通。 合作可以包括技术。 例如，分销商可以说出他缺少什么来增加销售，而管理程序的制造商可以说出未来的计划。 对于这个团队来说，“口语表达能力”，以暴风雨的意见流捕捉趋势并确定优先顺序的能力非常重要。 然后捍卫所选的职位，说不，解释为什么以这种方式做某件事，而不是其他方式。 在新闻稿，会议或私人场合中都没关系。 这些人教育了销售领域。
- 技术支援 为客户服务热线。 团队最重要的指标是对问题的响应时间及其解决时间（SLA）。 一个月内约有数千个电话。 该团队是多层的，既包括与客户的交互组，又包括呼叫分析，变通方法的开发等组。 基于支持人员收到的信息，列出了改进和紧迫性的列表-是在私有修订中实施，下次更新还是推迟至主要版本。
- 研发人员 。 将请求具体化为代码的人。
- 测试人员或质量检查人员 。 第一台测试仪，一个油箱测试范围和一个振动架同时运行。 他们不仅检查已经实施的内容，而且还在构思阶段联系到工作。 在接近作战环境的基础架构中重复执行管理员的任务，可以更轻松地了解所创建界面的方便程度或所选算法的生产率。 当技术支持得出产品存在缺陷的结论时，QA会重现有问题的方案并监视修复程序。
- 技术作家团队。 他们创建最终用户文档以及特定文档，例如“它的工作方式”和“部署指南”。 他们从开发人员，测试人员和分析师那里获取工作所需的材料。
一些团队更喜欢开放空间，但更常见的是-橱柜团队通过需求会计系统链接在一起。 我们在Microsoft Team Foundation System的基础上实施了该软件，因为我们一直将其用作源版本存储系统。 该系统存储需求（要求），缺陷（错误）和支持电话（问题），需要质量检查人员和开发人员的参与。 每个问题涉及数百名参与者，他们从事数千项任务，要求和缺陷。 该系统有助于保留所有这些，更重要的是，可以平均分配负载，从而优先考虑开发人员。
年轮：开发周期
我们产品的开发是周期性的，每个周期都以下一个版本的发布-发布结束。 以下是版本中反映的内容：
- 持久的市场趋势 。 例如，虚拟化和云基础架构的出现。 改变IT工作模式需要花费数年的时间-此时，用户从怀疑和否认（“这到底是什么”）转变为大众认可（“是的，每个人都在做”）。 一次对数据中心进行虚拟化产生了Veeam，因为在虚拟化条件下，用于备份计算机的旧产品无效。
- 支持新平台 。 以前，Veeam仅用于基于VMWare平台的虚拟数据中心。 随着客户数量和规模的增长，需要支持新平台。 除了VMWare，还出现了其他虚拟机管理程序（Hyper-V），物理服务器，云平台（AWS，Azure）等。
- 市场的战术变化 。 发行了操作系统和管理程序的下一版本。 使用我们产品的早期版本可以获得经验。 例如，这就是我们获得项目级支持的方式-从流行的应用程序服务器（例如Microsoft Exchange，Microsoft SQL Server，Oracle数据库等）中进行选择性恢复。
- 缺陷 。 尽管我们竭尽全力，但生活是不可或缺的，它带来了惊喜。 当然，我们会尽量减少它们。
每个季度，我们大约每年一次（主要）发布更新（更新）。 它们的优点在于，它们可以最小化创建与支持新平台和更改范例有关的体积功能的开销。 根据预算的具体情况，客户的IT部门在年底最活跃，因此我们此时也推出大量版本。
季度更新主要有两个目标：支持受保护服务器的新版本和故障排除。 在更新中，我们收集了自主版本发布以来客户发现的所有缺陷更正。 此外，借助更新，我们可以快速响应受支持平台的变化。 根据SLA的条款，Veeam必须在
不超过三个月的时间内添加对新版本的管理程序的支持。
如果该产品不适用于特定客户怎么办？ 在这种情况下，我们将发布私人修复程序-换句话说，是拐杖。 此类修复程序每周发布一次，并不总是与产品缺陷相关联。 例如，客户端安全设置可能与产品不兼容。 通过发布私有修补程序，我们分析问题的频率并决定是否在下一个季度更新中包括该修补程序。
从黎明到黄昏：发布纪事
每个发布周期都从计划开始-在整个产品级别和单个需求级别。 在第一种情况下，解决了业务优先级和团队之间需求分配的问题。 首先，讨论最紧急的要求或史诗。 以一种好的方式，应将不超过发行总工作量的60％分配给史诗，以便有时间缓冲。 产品计划是在部门负责人（产品，测试人员，开发人员）级别上进行的。
开发人员和测试人员分为团队。 一个团队中的最佳人数是五个。 团队既有职能又有通用性。 在后一种情况下，团队是自给自足的，其中包含在多个领域具有专业知识的开发人员。 功能命令的重点更加狭窄-它们在用户界面，系统组件等上工作。 来自不同职能团队的人员组成虚拟团队，开始实施需求。 至少PM组，开发和测试团队的代表聚集在这里。 团队负责人被分配为职能团队之一的团队负责人。
工作从需求开始。 虚拟团队每周开会。 与会者讨论了过去一周的成功，并计划了下一周的工作。
负责主持的团队负责人主持会议并记录结果。 他还解决了虚拟团队无法解决的问题。 例如，如果您需要移动日期或推迟部分任务。
在功能开发或测试团队内部，控制点之间的距离更近。 通常，每周计划分为不超过两到三天的任务。 有些团队扎根于日常波动的Scrum实践中；在某个地方，团队负责人与团队之间的点对点交互正在更有效地工作。
典型的会议室，讨论项目的当前状态所有开发都分为每周或每两周迭代。 在第一次迭代中，您需要创建一个最低限度的工作功能，该功能随后会逐渐发展壮大-例如，高级用户界面，客户端API等。 最重要的是，骨骼的存在已经使测试人员能够获得功能。
发布周期包括alpha和beta版本。 在他们的帮助下，我们向外界展示了新功能并提前收集了反馈。 如有必要，将更改有关体系结构或功能的决策。 场景不是立即而是成批地带入alpha和beta的状态。 通常，发布周期中大约有两个beta。
在测试阶段之后，团队进入回归测试模式。 在这个阶段，该产品作为一个整体已经可以使用了，用户界面和脚本已经变硬并以较小的强度更改。 一队技术作家在发挥作用。 同时，技术支持团队正在接受培训。
回归测试以两周为周期进行。 周期时间由查看所有产品方案所需的时间确定。 产品越大，场景越多，周期也就越多。 在最后一个循环之前声明一个代码块。 这意味着仅在对大量代码进行审查之后，才可以对产品进行重大更改。 为了避免意外地将新的缺陷引入产品中，需要这种严格的方法。
发布时间越近，开发人员就有更多的空闲时间，而其他人则更少。 产品经理需要准备新闻稿，协调营销服务工作。 测试人员应检查修复程序并执行最终回归测试。 技术作家正在添加用户文档。 在这个有利时机，开发人员正在为下一版本的要求开展研究活动。
这是一个激动人心的时刻，称为RTM-准备上市。 这意味着该产品已经准备好分发给消费者。 两周之内，他将受到记者，服务提供商的折磨。 它将在演示中显示。 两周后，该产品将向所有人开放。 此时，内部变化也在发生：正在准备开发的新分支，正在存储代码。 而且，当然，用于下一版本的构建基础结构也会增加。 公开发布（GA）之后，现在是技术支持的热门时机。 其余的已经在下一版本上工作了。
关于优先级
最后是一些硬件。 如您所知，在“快速，高质量，廉价”的三位一体中，您最多可以选择两个选项。 质量，时间和功能一直在相互争斗。 在我们的盒装产品中，质量第一。 嗯，但是在什么地方质量无关紧要？ 当然不是 整个问题是质量定义。
对我们来说，质量是：
- 保持动物园配置的可靠性和性能 。 从Borodino战役开始，一个客户拥有一个由两台服务器组成的适度数据中心，而另一位客户则在附近与亚马逊建立连接的机库中拥有高端基础设施。 产品在两种情况下均应正常工作。
- 易于使用 。 使用者应尽量避免紧张，并且一定要在没有任何说明的情况下应对。 但是，类似的简单性远非总是隐藏在外部简单性的后面-尝试与刺猬无缝交配。
- 传承 企业的投资是长期的，没有充分的理由就不会将CFO花费在IT上。 因此，您需要保持与先前版本和相关产品的兼容性。 通常在重建数据中心期间，将80年代时代的电子邮件服务器围墙围起来。 他们都嗡嗡作响，不认为会死。
在保持质量的优先级方面，您始终需要为开发人员和测试人员结合一些东西。 功能行为的微小变化会导致对大部分产品的强制集成测试。 尝试在产品中添加亚洲语言环境支持并了解其含义。 因此，优先级问题是PM，测试人员和开发人员共同讨论的问题。
第二个几乎不可破坏的优先事项是时间。 对于更新，发布日期由SLA（对于大型发布）由SLA设置-由业务日历设置。 据统计，在每个发布周期中，将近50％的时间用于开发，将50％的时间用于产品开发（错误修复阶段）。
可以更改的是下一版本的功能。 需求的优先列表或积压在这里有帮助。 从理论上讲，一切都很简单：从待办事项列表中选择下一个优先级功能，然后查看剩余时间。 时间即将结束时，请停止并释放该产品的下一个版本。 魔鬼隐藏在细微差别中：
- 要求不确定 。 例如，可以进一步完善“支持在OS Linux上备份物理机”的要求。 应该支持哪些核心？ 什么分布？ 什么文件系统？ 一个或相同的高级需求可以在一个月或一年内实现。 问题是完整的。
- 团队有专长 。 并非任何团队都能满足所有要求。 C＃开发人员不会编写驱动程序；系统组件的开发人员将无法始终应对Web开发。
- 需求相互依赖 。 这在用户方案级别上并不总是可见的，但是内部却存在这种关系。 从外界的角度来看，可能需要具有不同优先级的要求来支持NTFS和ExtFS文件系统的备份，但是在内部，您首先需要编写一个通用引擎。
- 需求分为延迟的和不可延迟的 。 如果市场正在等待下一版本的某些功能，并且已经宣布，则将其推迟将不起作用。
- 部分要求涉及研究 。 没有研究结果，就不可能计划任务的复杂性（也许根本不可能），并且很难预测这些结果。
这就是敏捷开发发挥作用的地方。 对我们而言，敏捷开发意味着需要定期进行重新开发。 已知新情况-更改了计划。 向待办事项中添加了新的优先级要求-更改了计划。 我们没有时间处理未延迟的需求-我们削减了部分任务或更改了需求。 在技术控制理论中，这称为反馈系统。 记住自动驾驶仪的工作原理。
上述条件下的任何计划都取决于专家的判断。 对团队负责人的专家评估是使整个后续流程清晰且结构化的要素。 专家评估的另一个名称是“列宁主义的斜视方法”，Stratoplan的Alexander Orlov喜欢重复。 这是您根据以前的经验和直觉做出决定的时候。 尽管可能会受到批评，但这还是可行的。 它的工作方式与上述所有过程类似。 如果您仍然有疑问，我们邀请您发表评论。
接下来是什么？
当前的处理技术像家用拖鞋一样舒适舒适。 唯一的问题是，在Veeam中，一些看不见的锥子总是会驱动您：更快，更多，更多，更多。
最近，在芬兰和捷克共和国建立了试点办公室，今年，我们正在为布拉格研发中心的盛大开业做准备，该中心可容纳数百人。
我们布拉格办事处的大厅一个发展办公室最近在以色列成立；加拿大和德国的团队正在增长。 与HP，NetApp，Nutanix，EMC的联合开发项目数量正在增加。
制造厂变成了地理上分散的输送机，同时，新的工艺得以实现。 但是，这是另一篇文章的主题。
保持联系。