说说迭代中的需求变更(更正)

    我们现在做的项目是典型的小型项目，整个组也就4、5个人，一个迭代周期基本在两周左右。尽管没有明确有“迭代”这么说法，却是以业务人员的策划案做分期 实现。这个分期，按我的理解其实就是迭代。最近发现的一个问题是，在迭代开始后，业务人员却没有办法保证需求在这个迭代周期完成前的稳定性，甚至在各个模 块集成之前，大家就提出N多意见，并且这些意见很多时候都是前后矛盾的。特别是在客户端的开发上，显然，客户端UI和操作习惯方面是最多变的地方。可怜我 们公司唯一的MM程序员快陷入变更频繁的泥潭了，改过去改回来是家常便饭。其实也是她过于老实，要我来说，你们要改，可以，但是我要向业务人员确认，他是 我唯一的变更来源，你们有什么需求向他反应，他来收集和甄别。在《敏捷软件开发》中说到，迭代开始后，客户就同意不再更改当次迭代中的素材的定义和优先级 别，可惜这一点貌似很难做到了，业务人员经常屈从于管理层或者其他小组意见的压力。在我看来，在当次迭代完成前的所有建议或者说需求，都可以收集起来，由 业务人员负责收集、甄别和决定，放入下一个迭代版本的开发，因为我们的迭代周期一般也在两周左右，这个周期足够辨别这些需求的合理性和响应需求的及时性， 而不是像现在这样大家七嘴八舌地提意见，技术人员疲于奔命，乃至于发脾气（入夏真是脾气坏的季节）；系统各部分迟迟无法进行集成测试，造成新的修改意见没 有做完，预定的迭代版本的更无法按时完成的局面。