游戏开发中最重要的部分
敏捷开发-因为您正在更快地构建工作软件并逐步交付软件-迫使开发团队面临一个共同的基本问题：如何在开发新软件的工作与支持已经在生产中使用的系统的需求之间取得平衡，无论是要替换的旧系统，还是仍在构建的系统，有时两者都有。
对于跟随Scrum的敏捷团队来说，这尤其是一个问题。 一方面，为了使团队能够达到Sprint的目标和承诺并为将来的计划树立速度， 不应在团队工作期间中断团队。 另一方面，在Scrum中进行迭代和增量工作的目的是尽早并频繁地向客户交付工作软件，该客户希望尽快使用该软件，然后他们需要使用该软件的支持和帮助。 –需要从编写软件的人员那里获得帮助和支持。
在某个时候（通常仍在开发系统的早期），这些团队必须停止与假装的客户一起冒泡 ，而开始与具有真实需求的真实客户一起在现实世界中工作 。
支持客户并仍在构建新软件
这意味着团队必须找到一种方法来兼顾设计和开发的支持和维护工作 ，处理快速变化的优先级和中断以及投诉和问题以及事态破裂时的消防压力，同时仍在尝试提供高质量的软件并按时完成任务。
要在两种截然不同的工作与直接相反的目标，激励措施和指标之间取得平衡是不容易的。 正如Don Schueler在“敏捷开发与客户支持之间的脆弱平衡”中解释的那样，开发团队-甚至是与客户紧密合作的敏捷团队-大多是内向型的，内部专注于交付，速度，成本，代码质量和技术问题。 支持团队具有前瞻性，专注于客户关系，客户体验和完整性，并将运营风险降至最低。
开发是指可预测和高效：按时交付并降低开发成本。 支持指的是快速响应和有效：倾听客户，回答问题，进行计划外的工作，找出问题并立即解决问题。 开发工作是关于流程，连续性，可预测性，速度的，如果管理得当，则主要在团队的控制之下。 支持和维护工作是中断驱动的，立即的，不一致的且不可预测的–这是一种完全不同的工作和思考方式。 开发工作要求团队团结在一起，以便他们可以就共同的目标和设计进行协作。 大多数维护和支持工作是分离的和相互联系的，较小的任务可以由独立工作的人员完成。 即使是在高压项目中，开发也要数周或数月才能完成。 支持和维护工作需要在几天或几小时甚至几分钟内完成。
敏捷支持模型：维护受害者
团队尝试处理支持和维护的一种方式是牺牲团队中的某个人：提供一个“维护受害者” ，暂时承担团队其他成员的支持负担，让其他人专注于设计和开发工作。 这包括从Ops或直接从客户接听电话，查看日志，解决问题，修复错误。 这可能意味着下班后留下来帮助进行故障排除或修复生产问题或提出解决方案，并在下班后和周末待命。
团队的其他成员试图假装此受害者不存在。 如果受害人不忙于解决支持问题或修复生产中发现的错误，则他们可能会解决其他错误或其他一些低优先级的开发工作，但是从团队的速度中减去了他们–没有人依赖它们来交付任何重要的事情。
团队通常通过一个或两个Sprint的支持和分类职责来轮换某人。 这样，每个人都在某个时候“分担了痛苦”，并且对支持问题和操作问题有所了解。 被牺牲来支持也有积极的一面。 开发人员有机会了解更多有关该系统的知识，并扩展了他们的一些技术技能，并且摆脱了Sprint后Sprint交付的仓鼠。 他们有机会扮演英雄，介入并修复重要问题并使客户满意。
Kent Beck和Martin Fowler在规划极限编程中通过创建一个小的生产支持团队将该想法扩展到了更大的组织：2-4个开发人员自愿致力于解决错误和处理生产问题。 开发人员将几个Sprint用于生产支持，然后轮流重新进行开发工作。 Beck和Fowler建议进行错开的轮换，确保至少有一个开发人员在第一次旋转中，而在另一轮中则是第二次旋转，以便支持团队中的至少一名成员始终了解正在发生的事情以及正在解决的问题。
牺牲维护受害者或团队可以使团队中的其他大多数人继续发展，同时仍能履行支持承诺。 这种方法假设团队中的每个人都有能力找出并解决系统中的任何问题-每个人都是跨职能的通才 。 这意味着无论是谁，都需要足够的知识和经验，以便他们能够处理大多数问题而又不引入团队的其他成员–您不能通过支持和维护工作来轮换新手，至少没有高级的人支持他们。
而且，您还必须为太大或太紧急的问题做好准备，以使维护受害者无法自行解决。 即使拥有一支敬业的团队，您仍可能需要某种程度的懈怠或缓冲来应对紧急情况和一般性的帮助，以免您持续消耗Sprint。 您可以根据“昨天的天气”，团队在过去几周或几个月内必须完成的支持工作量来提供合理的津贴。 如果您无法完成这项工作，或者整个团队在支持，消防和紧急修复上花费了太多时间，那么您做错了事，必须控制一切，然后才能以任何方式构建更多软件。
看板代替Scrum或在Scrum内部
有些团队发现， 看板的 结构要比Scrum或XP好得多，而不是试图在时间范围内进行维护和支持，而是在支持 ， 维护和操作与新开发工作之间取得平衡。
看板的排队模型和任务板的使用使您可以轻松查看需要完成的工作，正在完成的工作，正在执行的工作，正在发生的事情以及发生任何变化的时间。
通过看板，可以更轻松地跟踪和管理需要不同技能的各种工作，而这些工作并不总是很适合1周或2周的时间范围。
看板并不假装您不会或不会被打扰–相反，它可以帮助您管理打扰并最大程度地减少对团队的影响。 首先，在看板中，您限制了团队一次可以处理多少种不同类型的工作 。 这使团队可以控制即将开展的工作，并专注于完成工作。 看板的队列和任务模型允许紧急情况通过升级/优先通道抢占正在进行的任何工作。 而且优先级可以一直保持变化 ，直到最后一刻–团队成员只要有空进行更多工作，就可以从就绪队列中拉出最高优先级的工作项，无论是设计，开发新功能还是修复错误，或处理支持问题。
看板可以帮助团队将重点更多地放在眼前的战术问题上。 当您的维护和支持工作多于新设计和开发时，或者当您必须对重大问题主张控制权或通过诸如新系统启动之类的许多动人事物来管理某些事情时，这是一个更好的模型。
Devops改变了一切
Devops以及随后的Etsy ， Facebook和Netflix等组织（他们甚至称其为NoOps ）都试图完全打破开发，维护，支持和运营之间的界限。 Devops使开发人员直接而紧密地参与他们所构建系统的支持，维护和操作。 在这些组织中工作的开发人员不仅在编写代码，还属于运行基于在线服务的业务的团队的一部分，这意味着与设计和编写更多软件相比，支持工作同样重要，有时甚至更重要。
在这些组织中，开发人员应对其软件负责 ，以使其投入生产并确保其正常工作。 他们正在呼吁他们使用的软件存在问题。 他们积极参与系统的操作，从而深入了解系统的工作方式和运行方式，以及测试，配置和调试系统以及解决问题的方法。
Devops更改了开发人员的工作方式以及工作方式。 他们从项目工作转移到快速功能开发，修复，调整和强化。 可用性，可靠性，性能和安全性以及其他操作因素变得比交付计划和速度同样重要，甚至更为重要。 开发人员花了更多时间思考如何使系统正常工作，如何简化部署和设置以及人们需要了解的信息，以了解系统内部的状况，可能有用的度量和工具，如何处理不良数据和基础架构。故障，进行更改时可能出什么问题，需要与谁核对以及需要进行哪些测试。
维护与支持–责任与反馈
开发人员是否需要（甚至应该）接听用户的一线支持电话，他们至少需要成为调查和解决问题的第二级和第三级支持的一部分。
这不仅是因为他们通常是唯一能够真正弄清楚并解决许多问题的人。
撇开道德风险论点 ，即对于开发人员不对自己的决定和工作质量所造成的后果承担全部责任是否在道德上是可以接受的，对于开发人员直接参与支持和维护他们使用的软件而言，具有明显的优势。
最重要的是反馈，开发商从支持一个真正的系统获得的质量- 反馈是太宝贵了他们忽视。
关于您在构建系统上做对了什么以及做错了什么的真实反馈。 关于您认为客户需要什么与他们真正需要什么的反馈。 客户真正发现有用的功能（以及他们没有的功能）。 设计薄弱的地方。 您的大部分问题来自哪里 （代码的20％中80％的错误隐藏在哪里），测试和审查中的弱点所在，需要重点关注和需要改进的地方。 有价值的信息，包括正在构建的内容，构建的方式以及如何计划和确定优先级，以及如何变得更好。
当开发人员被卷入消防生产事故并进行根本原因分析审核时，他们可以了解有关为现实世界构建软件所需的大量知识。 认真思考问题是如何发生的以及如何防止它们可以改变您计划，设计，构建，测试和部署软件的方式； 以及人们如何团队合作。
将所有这些工作都转嫁给其他人，通过服务台或离岸维护团队进行过滤，会破坏这些宝贵的反馈循环，对涉及的所有人产生负面影响。
彼得·吉拉德·莫斯（Peter Gillard-Moss） 解释了这种情况 ：
在一家初创公司中，开发人员会很好地解决问题，因为没有其他人可以这样做。 但是在某些时候，事情发生了变化：
“……经理们认为，我们花太多的时间来调查用户的问题，而花了足够的时间来构建企业想要的新功能。 开发人员需要提高生产力，而更高的生产力意味着开发人员应开发更多新功能。 为了使开发人员能够发展，他们需要“处于区域内”。 他们需要耳机和大屏幕来粘接眼睛。 他们并不需要像愚蠢的用户那样打扰小打扰，因为他们弹出一个窗口，说他们的信息在尝试刷新时会重新发送。”
但是通过这样做，开发团队与他们的工作结果以及与客户的联系断开了……
“系统思想家会告诉您这是错误的。 您已经从将用户连接到负责一个隔离度的团队的系统变成了具有三个隔离度的系统。 或换一种方式思考：生产产品的团队，负责改进和修复的人员过去与最终用户只有一个度，而最终用户使用产品并正在反馈产品的缺点和问题，但现在是三个度。 而且并非始终都是三度。 大多数情况下，团队不会听到有关大多数支持问题的信息。 而且在大多数情况下，团队甚至不会与听到大多数支持问题的团队进行太多互动。”
结果：客户无法获得所需的支持。 开发人员没有获得他们需要的信息，以了解如何使系统更好地工作。 一个支持团队陷入了困境，人们只是想防止事情变得更糟，并希望有一天能找到更好的工作。 这是一种自我增强的负面螺旋。
在我们的商店中，始终将支持优先于开发。 我们的高级开发人员会与操作一起为系统提供支持，如果在下班后出现问题，我们将新软件投入使用并随时待命，我们会随时待命。 他们可以从需要帮助的任何团队吸收其他人。 结果，我们几乎没有什么严重的问题，而且这些问题很快得到了解决。 每个人在支持工作中获得的经验可帮助他们设计和编写更好，更安全的代码。 这使得系统更具弹性，更容易支持，成本更低，设置和运行更安全，更改更容易安全。 这也使我们的组织变得更好。 它使开发人员和运营部门更加紧密地联系在一起，也更加接近于对业务重要的事物。
无论您是否称其为“敏捷”，没有什么比团队直接与客户合作，立即响应问题并在实时系统中更改需求的团队更为敏捷。 尽管一些开发人员和管理人员将其视为开销，但要维持工程并尝试将其推销给其他人，以便他们可以专注于“更具战略性”的工作，而其他人则意识到这确实是软件开发的前沿，并且是唯一的运行成功的软件组织的方法，也是使软件和开发人员变得更好的唯一方法。
翻译自: https://www.javacodegeeks.com/2013/10/dont-you-know-that-support-is-the-most-important-part-of-a-developers-job.html
游戏开发中最重要的部分