欢迎收听PM网事，今天我们来聊用例和用户故事的下半部分。
上半部分我们聊到了Mike Cohn指出的User story的8个优点中的前4个优点，今天我们继续剩下的内容。
我们开始第5个优点：鼓励延迟细节。
这确实是User story的一个优点，User story会更快速地进入开发状态，而不会在建模上花费时间和精力。
第6：支持随机应变的开发。
Mike Cohn认为，写下一个系统的所有需求，然后从上往下想出解决方案，从来就是一个美丽的陷阱，他引用了其他人的看法来证明他的观点，主要有5点：
第1点：用户及客户通常都不会准确地知道自己的实际需求。
第2点：即便软件开发者知道所有的需求，很多需求细节只能随着他们的开发进展变得清晰。
第3点：就算假设所有的细节可以在前面弄清楚，人们也没有能力理解这么多的细节。
第4点：就算我们真的能理解所有的细节，产品和项目也会经常变更。
最后一点：人非圣贤，孰能无过。
看完了这一段，我想我马上就理解了Mike Cohn的痛点，也就是敏捷之所以强调随机应变开发的重要原因，那就是问题的根本其实是项目层面的问题，而不是软件开发的问题，在项目层面的问题得不到解决的情况下，软件行业只好用自己的方法来解决这一问题，那就是随机应变的开发，换句话讲，敏捷是被逼出来的。但是，我必须要说，软件开发是最不应该随机应变的。
从上面提到的问题来看，在软件工程层面解决问题的方法有两个，一个是用一套严谨的软件工程方法管理需求，让项目的利益相关方弄清楚需求，从而在源头堵住不靠谱的需求，减少不必要的变更，实现真正的精益，这属于软件工程层面的治本，另一个方法就是退而求其次，不得不拥抱变化，用灵活轻量级的方式来实现随机应变的开发，实现表面的精益，这属于治标。从目前来看，敏捷采用了第2种方法，那用第1种方法是否可能呢？我认为完全有可能，但前提是和项目管理相结合。那在软件工程层面第1种方式是什么呢？那就是我们可以借鉴RUP的做法，用经过剪裁的RUP方法，也就是一个适度轻量化的方法来实现，这样的话，就可能从根本上解决我们的痛点。换句话讲，Use case和UML其实可以起到更加积极有效的作用。
所以，站在
652
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
