这会做两件事情:
从代码被集成(进代码库)到小组意识到存在问题之间的时间间隔会被减到最小。
构建显示器将信息传达给整个小组——不论是集成成功完成——还是需要引起注意——这让小组可以立即作出相应的反应。
像这样频繁的集成意味着软件的构建是不停进行的,任何人在任何时候都可以参与构建过程。构建过程需要被自动化,以便使集成尽可能地容易,这是十分重要的。下面就是3Q公司的构建监视器的向小组传达信息的一个例子。
就如上面图画所显示的,构建服务器能够向小组提供额外的信息。
重要的成功因素
自动化——这需要成为一个自动化的过程。否则你将不得不专门找一个开发人员来维持构建过程——这可不是一个有意思的工作。首先就要营造环境,取得设备和实现自动化。
TCR和配对编程——对于这一层次的集成工作,小组必须按照测试-编码-重整循环来进行,这样他们才有信心保证所有的问题只会发生在集成过程里。如果没有TCR循环,这一部分的过程将会非常困难。
按部就班——就像这个小标题说的,不慌不忙地从简单的地方开始,然后随着时间的推移来逐步改进——尤其是在代码编写标准这一块。
保持高效率——第三步
就如我们在《上篇》里说的,敏捷开发过程是一项工作强度很大的编程方式。除此之外,软件开发本身就压力重重,而小组累垮的可能性非常高。
可持续的步伐意味着开发小组现在和未来的工作都将非常艰苦。加班不是我们希望鼓励的事情,尽管有的时候需要如此。如果小组不得不加班工作,那么我们想要尝试将可持续步伐里的加班时间控制在一到两周而不是一到两个月。再强调一遍,敏捷开发是一项强度很大的工作;配对编程要求很多交互和重视,测试-编码-重整循环也是如此。尽管敏捷开发会引发我们小组的最大潜能,但是我们需要清楚很多时候的大量加班会累垮整个小组的风险。
重要的成功因素
这是管理者必须十分清楚的一个领域。确保小组在整个项目里保持合理的步伐是其主要职责。
文章来源于领测软件测试网 https://www.ltesting.net/