敏捷交付！＝迭代开发

听到很多人说：“我们在做敏捷开发，每次发布都分成多个迭代进行开发。”

可是，细问之下发现，他们在每个迭代结束时，开发的软件无法达到“可上线”的质量要求，甚至软件根本无法运行起来。

 

他们只关注本迭代开发的Story测试是否完成了，有的甚至只关注于开发活动完成了没有。

 

可真正做到敏捷交付的话，至少要做到：

 

1. 已完成了本迭代Story的测试，并且Bug已修复并验证通过；

2. 回归测试已完成，验证之前已完成的功能没有被破坏。

 

想要按这种方式来交付的话，而自动化测试还不完善的话，解决的方式 好象只有一个“增加测试人员的数量”。

因为每次迭代结束之后，都要做回归测试。那么随着开发的深入，已开发的功能不断增加，回归的工作量也会成指数级增长。

而“增加测试人员”只是“引鸠止渴”，HR只能是拼命去招测试人员。

 

所以，要想做敏捷交付，自动化测试是必修课，而不是选修课。

 

看到这里，你可能会认为，自己所在的团队根本无法做到这一点。

 

那么，我的问题是：为什么做不到？是现在做不到，还是一直做不到？想做到这一点，要付出哪些努力？多长时间能达到？

 

你使用敏捷交付方式开发软件，那你先回答这些问题吧！

 

 

如果想做没有痛苦的敏捷开发，你可以开站会，拆分故事、玩扑克、建立backlog，这些都很容易，但收效不会太大。

 

你一定会遇到更困难的问题，甚至要否定你原来坚持的东西。此时，你的痛苦才显现出来。

 

只有医好这些痛苦，你才能享受到敏捷开发的快乐！