听到很多人说:“我们在做敏捷开发,每次发布都分成多个迭代进行开发。”
可是,细问之下发现,他们在每个迭代结束时,开发的软件无法达到“可上线”的质量要求,甚至软件根本无法运行起来。
他们只关注本迭代开发的Story测试是否完成了,有的甚至只关注于开发活动完成了没有。
可真正做到敏捷交付的话,至少要做到:
1. 已完成了本迭代Story的测试,并且Bug已修复并验证通过;
2. 回归测试已完成,验证之前已完成的功能没有被破坏。
想要按这种方式来交付的话,而自动化测试还不完善的话,解决的方式 好象只有一个“增加测试人员的数量”。
因为每次迭代结束之后,都要做回归测试。那么随着开发的深入,已开发的功能不断增加,回归的工作量也会成指数级增长。
而“增加测试人员”只是“引鸠止渴”,HR只能是拼命去招测试人员。
所以,要想做敏捷交付,自动化测试是必修课,而不是选修课。
看到这里,你可能会认为,自己所在的团队根本无法做到这一点。
那么,我的问题是:为什么做不到?是现在做不到,还是一直做不到?想做到这一点,要付出哪些努力?多长时间能达到?
你使用敏捷交付方式开发软件,那你先回答这些问题吧!
如果想做没有痛苦的敏捷开发,你可以开站会,拆分故事、玩扑克、建立backlog,这些都很容易,但收效不会太大。
你一定会遇到更困难的问题,甚至要否定你原来坚持的东西。此时,你的痛苦才显现出来。
只有医好这些痛苦,你才能享受到敏捷开发的快乐!