敏捷软件开发中的一个钻牛角尖的问题
0
悬赏园豆：10
[已解决问题]
解决于 2008-12-04 09:21
最近一直在读《敏捷软件开发:原则、模式与实践(C#版) 》
现在这本书我将近读了一半了,有个不明白的地方想和大家讨论一下：
在书中讲到第二部分《敏捷设计》时,在第7章《什么是敏捷设计》的7.3节中有一个Copy程序，在对程序进行修改，使之能适应输入设备的变化后，书中提到，这时没有必要对输出设备也进行相应的修改，等以后确定有该需求变化时再修改也不迟，也就是说这时只需满足单一输出设备即可。这一点与敏捷设计原则相吻合，没有问题。
可问题是，到了第26章《薪水支付案例研究-第一次迭代开始》的26.3节中，在对雇员和工会的从属关系分析中，当前明明只有一个工会，并且在那次迭代分析中也没有提到过以后会有多个工会，可作者还是对其进行了修改，让雇员能够从属于多个组织。这不是和上面提到的Copy程序设计原则相矛盾吗？
我知道这有点钻牛角尖了，而且实际开发中也是要具体问题具体分析的，可我还是想搞明白，实际开发中对问题的考虑是简单点好还是全面的好呢？
最佳答案
0
其实并部矛盾吧，COPY没有预见，是因为无法预见，并不知道以后要增加的设备是什么设备。
而工会是可以预见的，按照上面的描述，只是数量的变更。
所以，我觉得并不矛盾。
我们想想以上两种情况的场景，更好理解：
假如你正在做一个打印机相关的程序，主管对你的要求只是满足打印机就好。那你会很很快去考虑如何完成，并尽快完成。根本不会去考虑是要在传真机或其它设备上应用。
而后种情况，比较容易在我们的思维内出现，一个，多个……
其他回答(2)
0
偶没看过这本书，说实话对敏捷也不熟。仅就楼主的叙述做些猜测吧。对于第一个Copy程序，关键在于那句“确定有该需求变化时再修改也不迟”。也就是说，可以判断即便将来需要把程序扩展到支持输出设备对现有代码的改动量也不大。
对于第二个程序，可能考虑到将来如果要把雇员与工会的关系由多对一改为多对多的话对现有代码的改动量比较大。所以还不如一开始就弄个更灵活些的。
总的来说，需求变更的很大一部分是对程序的扩展。最理想的情况是扩展时不需要修改现有代码（或者修改量比较小，而且是可测试、可评估的），也就是Open-Close原则。所以在最初设计时，如果发现可以以很小的代价，获得好得多的扩展性，则可以考虑使用这个扩展性好的方案。算不算过度设计由你自己掂量。
0
实际开发中对问题的考虑是简单点好还是全面的好呢？
不管是做什么开发，实际开发中当然是考虑全面点好，这样可以减少后期遇到的很多问题，如果前期考虑不周，在开发中间如果遇到问题，就要重新考虑项目的相关内容，甚至有可能，影响后面的开发进度。
我认为，在开发的需求分析阶段，尽量做详细，可以减少很多不必要的麻烦，当然，也要避免过度。如果中间加入了新的Features，那么不是我们的需求分析的问题，而是需求中途发生的变化，这样项目一定也要作出相应的时间或其他方面的调整，这样造成的时间或其他投入的增加是正常的。
