相对于软件公司中的开发团队，维护团队似乎常常默默无闻，做事相对于保守，远没有开发团队那样常常让人有新鲜感。这是一种很普遍的现象，也就是维护团队的价值常常被有意或无意地降低了。 事实上，维护团队的建设和管理比开发团队所应对的挑战大得多，而运行得当的话，可以同项目团队或开发团队形成互补，发挥驱动力。
至于评价Business Value和System Quality所使用的具体指标设定方式，作者已经给了一些建议。要做到这些，除了了解维护团队的产品特点(软件复杂度,可维护性度量指标MM)，也要了解相应的市场变化(不同干系人的需求)。
软件维护团队的目标和流程
软件维护团队被赋予维护已交付产品的职责，主要工作内容是分析修复新发现的Bug, 以及客户对软件提出一些调整，具体的内容要视维护合约而定。总之或么是修修补补，要么就是锦上添花。因为是已交付的产品，其变更是开发团队开发过程中所花费的成本的2~25倍，这在软件工程领域早有定论(可以参考
这里和
这里)。如果因为变更而引入了新的Bug，则表示要完成至少两次变更，成本则是开发过程修复的4~50倍。为了保证变更的质量，降低风险和不一致性成本，软件维护团队的流程通常较开发团队要严格地多，管理上也要细致许多。
下面是一个软件维护团队流程的示例:
维护团队建设
正因为维护团队的约束大，团队建设的难度也更大。最大难题就是人员稳定性的问题。如何选对人进入维护团队？首先做事细致严谨，既要甘于平淡，又要技术能力达标，这样的人是可遇不可求的，而且常有变化。治水在疏而不在堵。个人觉得有四个要点:
一.尽量选择合适的人进入维护团队。虽然难，但还是要努力去做。一定要清楚什么是首要条件，什么是次要条件。比如技术能力是不是首要条件，取决于团队目标。
二.建立良好的轮岗制度，好进好出，至少可以保证顺畅地在维护团队和开发团队间轮调。出入的条件则灵活设置。
三.建立技术交接流程，降低因为人员流动而引发的风险。
四.结合第二点的轮岗制度，可以吸收新进技术人员和实习生到维护团队，在降低工作负荷的同时，也可以活跃团队气氛。
这些做法可以使得维护团队相对开发团队或项目有其独特的优势，也就能吸引一些人。其关键是要维持一种公平性。亚当斯的公平理论提到一个感受的公平的条件就是他是否认可自己的所得与投入的比例。也就是说如果以项目团队的管理方式来带维护团队，维护团队成员能否感受公平呢？
当然这些做法还只是治标，并不治本。要治本，还要再探讨团队目标的设定。
形成新的驱动力
维护所承受的最大压力来源于它的目标设定。所谓格局决定结局。何以形成更为有利的格局？
首先软件维护团队的技术应当与开发团队是相通的，为什么不能加以利用？维护过程中发现的问题和识别出来的需求，是不是可以导入到开发团队中去？
相对于开发团队/项目团队，如果维护团队时间压力相对小(取决产品类型)，就有机会对问题进行深入的研究，特别是领域相关的知识。深入研究问题以降低副作用本身也是维护团队最需要做的。这一优势正是可以加以发挥的特点，就是交给维护团队深入挖掘问题并寻求解决方案的职责。研究成果再以文档或者技术分享的形式移转到研发团队。
另外一点，就是由维护团队参予开发团队的走查，包括设计、文档以及代码，也会为团队的整体能力提升提供莫大的助力。
可行与否？还是从团队目标开始思考。
维护团队中的决策
如果一个维护项目终止，就可能导致维护团队的解散。早一点预见到维护项目的前景，会让管理者有充分的准备时间。
依据<<Software Engineering>>第9版中关于软件进化的说明，软件维护的决策要从市场价值(Business Value)和系统品质(System Quality)两个维度考察。
而得到结果后，就得到不同的决策。
|
Biz Value
|
System Quality
|
Strategy
|
|
Low
|
Low
|
弃用(Scrap)或替换(Replaced)。成本高，但意义不大。
|
|
High
|
Low
|
替换(Replaced or Reengineer)。维护成本高，但商业价值大。
|
| Low | High | 持续演进(Evolution)。维护成本不高，商业价值也不大。 |
|
High
|
High
|
继续维护。
|
至于评价Business Value和System Quality所使用的具体指标设定方式，作者已经给了一些建议。要做到这些，除了了解维护团队的产品特点(软件复杂度,可维护性度量指标MM)，也要了解相应的市场变化(不同干系人的需求)。
