维护项目的敏捷转型

现在敏捷已经是IT行业的开发的行业标准了，大部分公司在产品开发中都采用的敏捷来解决一些由瀑布模型带来的问题。
敏捷的迭代周期短，每个迭代都有预设目标，而且每个迭代都有相应的产出，能大大地提高项目相关人的满意度。
产品开发的一个典型周期是：
需求澄清->开发->测试->发布->维护。
而当产品成熟后，新的功能和改进将会越来越少，同时维护和客户支持的工作量则会越来越大。维护则包括：技术支持、项目管理、工程维护、版本管理。
对于成熟的组织来说，瀑布模型是所有根据客户的要求进行的维护活动（如：产品改进、Bug修复）的一个比较好的方法。
然而，敏捷也变得越来越广泛。不仅仅是开发的团队，维护的团队也在逐步转向敏捷。
我曾经做过维护团队的代理Scrum Master，在我们团队推行维护项目的敏捷转型。
为什么要放弃老的成熟的模式而采用新的模式呢？
在采用老的工作模式时，我们团队基本上是完全被动的：客户报了什么问题，到我们这，我们根据问题定义的优先级分配工程师来解决。问题找到原因后，工程师提交相关改动，等待SCM出开发包。SCM出包后，提交到I&V测试。I&V测试通过后，SCM出正式的客户包。
其实从客户报问题到拿到改动会等很长的时间。如果问题比较麻烦，基本上客户的抱怨会非常多。
同时对维护团队来说，我们的工作是不平衡的，我们有些时候特别忙，而有些时候又特别闲。这样造成团队资源的分配问题。
所以我们试着尝试敏捷，希望维护团队能借鉴敏捷的一些优秀的方法来解决一些维护团队的问题。
在适配敏捷时，我们比之前多了一些变化：
1. 迭代清单(Sprint backlog)： 这个是敏捷的标配。在软件开发中，sprint backlog是记录着一些列需要实现的user stories。而对于维护团队来说，这可能是一个新的概念。一个维护团队的Sprint Backlog基本上是包含着这个Sprint上的所有bugs/issues。同时还有包含一些基于预测模型的bugs数目。同时在每个Sprint开始前，Scrum Team和Product Owner一起来过这个Backlog。Scrum Team可以开始计划哪些 Bugs、改进 Team可以在Sprint中Commit。之前，来自客户的Bugs和改进基本上是我来分配到合适的工程师来做的。而现在Scrum Team被赋予期望来回顾和检查问题，同时也找出问题对应的场景，避免再次出现问题。同时也保证了Scrum Team在一个Sprint的可靠的维护承诺。
2. 维护的易变性： 总所周知，维护的backlog基本上是经常变动的。这就使得Sprint的计划非常有挑战。一个客户非常紧急的问题会打断之前的计划，同时会占用团队的时间和资源。
3. 敏捷团队的动态性：根据Sprint的计划，我们可以根据维护的工作量动态地调整敏捷团队的人力资源。当然，实际情况不一定和计划完全相符，这样需要动态地调整团队资源。
4. 管理客户的期望：大部分的公司都有客户满意度指标（我们也是）。而指标的重要内容就是响应和解决时间和质量。这样Sprint的backlog就要包含管理客户期望的内容。比如对客户响应的管理，对提供规避方案的方式等等。Sprint的计划和回顾需要重点考虑管理客户的期望。
5. 发布版本的流程： 相比于瀑布模型在周期后才发布客户包。敏捷要求每天都有包发布。而且对于维护工程师提交代码，也可以触发SCM发布新包以便于公司的QA验证。
敏捷转型后，我们观察到许多好处：
1. 清洗缺陷： Sprint的计划步骤要求Scrum Team Commit这个Sprint 计划。维护团队需要根据这个Sprint的Backlog，清洗、回顾、并且考虑对应的用户场景。这个使得Scrum Master和Scrum Team一起过一系列的Bugs。不像之前来了问题就直接分配，Scrum Team一起过在Backlog上的问题，找到问题对应的用户场景，同时一起预分析问题。
2. 及时的迭代： 作为敏捷的一个强制要求。一个Sprint应该是两到三周。而对于维护的团队，这个一个新的概念。也就是要求问题必须在这个迭代解决并且被QA测过。这样带来了对问题时间要求的Mindset。可以有效地提高客户的满意度。
3. QA和开发的紧密合作：在瀑布模型中，开发人员提交代码后，然后将问题提交给测试。 测试再根据计划开始测问题。而敏捷使得流程更像喷泉而不是瀑布。这要求开发和测试紧密在Sprint中合作，开发提供Test Image测试就可以验证，同时反馈给开发。而且开发和测试的角度不同有助于更好理解问题。这个有助于建立更加健康的维护团队。
4. 可视化： 敏捷流程要求管理人员参与到团队活动中。管理人员参与团队的计划、回顾使得团队的产出更加让管理人员所知，也使得维护团队可以得到管理人员的期望和意见。这样使得团队的可视化大大提高，并且和管理人员的关系融洽，在一些活动中得到管理人员的支持，可以大大减少团队管理方面的错误行为而造成客户反应到高层领导。

而且对于Scrum Master（也就是我啦）也有很多好处。
敏捷可以让Scrum Master以更加结构化、严格遵循时间的方式管理团队的产出，同时将管理人员的注意转向支持团队的成功。

总的来说，我们在向敏捷转型时，并没有感受到直接的好处。但是我们的团队在敏捷的转型中，确实在团队的士气、生产力和提高客户的满意度上有着有效的提高。