敏捷已经从一个宣言演变成为一项业界标准。多数的软件厂商都在应用敏捷来解决瀑布式中导致的诸多问题。简而言之，使用固定时间长度的sprint来达成预先设定好的目标以及敏捷所主张的整个实施风格能够解决软件项目中痛处。因此，很多软件开发商都使用敏捷，并且通过做项目计划让他们的客户也参与到敏捷当中来。
敏捷这套方法从收集需求开始，就影响着项目的计划和执行。本文将会介绍这些影响和由此带来的新的挑战，尤其是对那些在自身领域处于领先的，拥有超过10年以上的产品（说明是成熟的产品）的软件开发厂商所带来的影响。
一个典型的项目一般从收集需求开始（来自客户，市场或者竞争对手），到开发，测试，发布和售后支持。作为一个成熟的产品，新的特性和功能是对产品的增量加强。然后，于此同时，也对各个团队解决客户可能遇到的问题提出了更高的要求。从客服团队，到管理层，工程师和发布管理都要为现有客户对新版本的部署，部署后的支持和升级负责。
在这种成熟的公司中，瀑布式是曾经是很常见的做法。BUG的修复周期，通常是靠客户的需求来驱动的，也就是说当客户遇到问题是才进行。
然后，随着敏捷成为了规范，不光是开发团队，就连售后支持团队也应用上了敏捷的实践。于是，我有了机会在分别是企业级应用和网络管理巨头的两家公司里，以product owner的身份参与了售后支持的运作。
新的“规范”给售后团队带来了一些新的变化。和其他售后团队一样，他们曾经是按照客户提出问题的先后顺序，优先级和严重性来安排工作的。虽然，问题的严重性依然是修复BUG过程中的主要驱动力，但是由于敏捷流程的引入，给团队带来了更多的考虑因素。
下面是一些我留意到的团队在使用敏捷的过程中所带来的改变和遇到的挑战：
Sprint backlog . 创建和管理一个sprint待办列表对售后和维护团队来说是全新的事物。基本上，它要求团队将所有的BUG或者问题的浏览一遍，这些所有的BUG和问题组成了产品待办列表，然后和product owner一起为这些BUG或者问题估算故事点数，最后团队可以根据这些BUG（也就是用户故事）来制定当前sprint以及以后的sprint的目标。曾经需要由经理或者lead来分配任务的团队，现在需要自己评审，估算，制定故事点数来管理BUG，然后再自己承诺在一个sprint中要解决的问题。
对售后支持团队的影响 支持和维护团队不再围绕着“愿望列表”工作，而是用于一个燃尽的问题待办列表。因为客户经常会在sprint过程中提出问题扰乱sprint和团队的机会以及资源，这样就使sprint计划和坚持执行计划本身边成了一项挑战。
Scrum团队的动力 将开发团队、测试团队、客服团队和product owner放到同一个团队中也是一项挑战，因为通常遇到的情况是QA和product owner的人数不能和团队个数很好地搭配。
管理客户期望 很多客户服务都签订了SLA（服务登记协议），协议中指定了回复和解决问题的TAT（反映时间）。第一次的回复需要第一级售后和工程支持团队(engineering support team)的参与以及分析。随着sprint待办列表成为了工程支持团队的工作清单，第一级的售后团队不得不改变他们的工作方式来满足客户的SLA。
发布和构建流程 PMO（项目管理办公室）也需要参与其中来保证团队能够提交代码和在sprint中进行验证代码的正确性。这里与瀑布式不同的是，瀑布式只在开发周期结束的时候才进行第一次构建，而敏捷则将每日构建视为必须要遵守的规则。
依我所见，能够应用以上这些改变的团队，都对这些改变带来的益处赞赏有加。其中主要的益处有：
梳理问题 Sprint计划要求团队承诺在sprint中要完成的任务。这样就要求售后开发团队对待办列表进行梳理，评审，然后给每个用户故事指定故事点数，最后制定sprint中要完成的任务。这就意味着ScrumMaster要和团队一起，评审所有的BUG和对应的修复。这样的方法让团队能够在一起以有效的方式评审BUG，然后根据它们的复杂度给定故事点数。
有时限的sprint 在敏捷流程中，主张一个sprint应该有固定的时间限制，而且不应长于3到4周。对于支持和维护团队来说，由于每一个BUG的修复都需要在同一个sprint中由QA团队成员验证，否则团队在燃尽图中显示的速率将会降低，而这一切将是一个全新的理念。时间限制给团队带来紧迫感和设定目标的需要，否则将很难在售后的环节中实施敏捷。
QA和开发团队协作 在经典的瀑布式中，开发团队完成编码以后将移交给QA团队进行测试。敏捷将这一过程看作成整条瀑布的一小部分，敏捷要求QA在同一个sprint中完成对代码实现的验证以保证团队健康地持续运作。
可见性 敏捷实践主张管理融入到团队活动当中。管理层参与团队的计划会议和sprint回顾会议让售后团队的工作更具透明性，也让管理层更清楚团队的情况，而不是等到问题发展到需要管理层干预的时候他们才知道问题的发生。在我的经验中，敏捷让ScumMaster能够结构性地展示团队的成绩，然后让管理层更专注于团队的成功。
总而言之，敏捷可能不能直接应用于客户支持流程，但是事实上这样一个强大的方法论能够让管理者改善团队的效率以及流程，来提高客户的满意度和员工的忠诚度。
作者:Shweta Darbha
来源:http://www.scrumalliance.com/articles/401-can-support-and-maintenance-become-agile
