极限编程中的质量控制
3.在“信任”与“控制”之间建立平衡
极限编程的许多核心实践实际都是经过实践千锤百炼的准则,这些准则使得极限编程成为一个比较成熟的软件过程,下表总结了极限编程的核心实践对于CMM关键过程区域的满足度:(√表示部分满足,√√表示在适当的环境下几乎满足,--表示未涉及。)
|
2级 KPA |
满足度 |
3级 KPA |
满足度 |
高级 KPA |
满足度 |
|
需求管理 |
√√ |
组织过程焦点 |
|
软件过程管理 |
-- |
|
软件项目规划 |
√√ |
组织过程定义 |
√ |
软件质量管理 |
-- |
|
软件项目跟踪与监视 |
√√ |
培训方案 |
-- |
|
|
|
软件子合同管理 |
-- |
集成软件管理 |
-- |
故障预防 |
√ |
|
软件质量保证 |
√ |
软件生产工程 |
√√ |
技术变更管理 |
-- |
|
软件配置管理 |
√ |
组件协调 |
√√ |
过程变更管理 |
-- |
|
|
|
同行评审 |
√√ |
|
|
尽管极限编程有如此众多的核心实践支持软件质量的控制?可是这些核心实践能被不折不扣地执行吗?结对编程能象传统的同行评审那样有效吗?软件的测试设计足够发现软件错误吗?软件的测试是否100%覆盖了软件需求或设计?这些问题怎么回答?敏捷软件开发方法强调以人优先,认为软件开发人员是负责任的专业人员,他们有动机将程序写得尽可能的好,测试尽可能充分,希望为客户提供高质量的产品,应该得到充分的“信任”。可是,即便软件开发人员有提供高质量软件产品的动机,可是他们具备相应的经验吗?如果不加控制,敏捷方法的下场会不会象早期的快速软件开发方法(RAD)最终变成声名昭著的“快而脏”(Rapid And Dirty)一样。
为此,在“信任”和“控制”之间建立适当的平衡是必要的。
极限编程中的两个角色在质量控制方面起着非常重要的作用,他们是教练(Coach)和追踪员(Tracker)。教练是极限编程中举足轻重的人物,是项目的幕后指挥,总能发现开发过程中出现的真正的问题,用恰当的方式给与解决。他最主要的任务是随时调整项目组的软件开发方向,以期达到非常好的结果。而追踪员的职责是在不影响开发人员的情况下收集项目的过程数据如计划的执行情况、软件的缺陷数、软件错误的改正日志等等,为教练提供统计数据和项目的定量分析结果。
因此,教练和追踪员的职责实际已经涵盖了CMM第4级中的两个关键过程区域:软件质量管理和软件过程管理。可以认为教练和追踪员两个角色的设置使极限编程可以走向更高的过程成熟度。
在实践中,也有一些团队仍然使用专职的有经验的质量保证工程师负责质量保证任务(对于敏捷软件组织,一个庞大的QAG是不适合的),承担追踪员的职责和教练在质量管理方面的职责。其目的也是实现软件质量管理目标。
4.结论
极限编程的核心实践活动本身提供了适用于敏捷软件开发方式的一整套质量控制方法,设立质量保证角色,或者重视发挥“教练”和“追踪员”两个角色的作用,在对程序员的“信任”和“控制”之间建立平衡,是确保质量控制过程的实施,使极限编程方法既保持敏捷又能成为高度成熟软件过程的关键。