相对于软件公司中的开发团队,维护团队似乎常常默默无闻,做事相对于保守,远没有开发团队那样常常让人有新鲜感。这是一种很普遍的现象,也就是维护团队的价值常常被有意或无意地降低了。 事实上,维护团队的建设和管理比开发团队所应对的挑战大得多,而运行得当的话,可以同项目团队或开发团队形成互补,发挥驱动力。
软件维护团队的目标和流程
软件维护团队被赋予维护已交付产品的职责,主要工作内容是分析修复新发现的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 | 继续维护。 |
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!