神马文学网难得有情郎之--遇上用例驱动的团队 - 花钱的年华 - CSDNBlog
来源：百度文库 编辑：神马文学网 时间：2024/04/28 06:07:02
就像小说里那些早慧的少年，很早就尝试过用例驱动的需求文案，结果与客户，一个愁默默，一个恨绵绵。
最狂热的用例编写者也承认，用例对客户与需求人员都是一种heavy的相互折磨。
客户看用例时总要收摄心神来阅读整个交互的流程，还有那些该死的扩展流异常流，没经过程序员专业抽象训练的客户，对着这些伪代码一般的情景脚本，刚开始的一两个还好，看多了，就是白天也能睡去。客户只是看都如此了，负责写的人当然也不会好过。
但heavy的工作总有heavy的好处，否则早被唾弃于舞台的背面。
在用户的角度，用例比模棱两可的功能点描述要清晰，也更直白于系统的价值。
在开发团队角度，RUP的核心方法论之一---用例驱动的口号，明白人自然明白他的妙用。
设计人员有了新的设计手段：“用时序图分析用例的实现，在描述过程中确定构件或类，分配它们的职责和方法”，通过对用例覆盖率的追踪，将需求与设计之间的信息损耗这个famous problem大大降低。
测试人员和文档人员，更可以直接把系统用例笑纳为《测试用例》和《用户手册》。
来到亿迅大陆后，被这里的用例文明给震住了，每个项目的软件规格说明都是屯门清一色的几百页的前景，用例规约，业务规则，词汇表，补充规约组成.......
昨天又看到了一批新的用例诞生，但实在有好些明显的不足啊，忍不住旧事重提的记下一批经典的错误。不过.....只要能和客户达成需求共识，就是一份好的用例了，也不用花太多时间在学术性的讨论上。
1.客户没有能力阅读用例
如果客户实在没办法撑住困意看完用例的细节，即使草草签了名，得不到用户真正确认的用例，依然无法用来驱动设计和测试。
解决方法：放弃编写用例，改回用户容易看的传统方式。
2.团队没有能力实现用例驱动
如果开发团队在设计与测试时，根本不依照用例细节驱动，那用例对开发团队就只是个摆设，花瓶。
解决方法：对设计、测试人员进行用例驱动的培训，如果事不可为就干脆放弃，怎么省事怎么做。
3.在用例中描述系统内部工作
经典错误，开发人员把用例当作设计文档来写，如“系统将销售信息写入数据库”，实际上应该写的是“系统记录销售”。
解决方法：站在客户的角度，把系统视为黑盒，删除所有内部设计描述。
4.在用例中描述界面
另一个经典错误，不说了，如果在意用户信息包括了姓名和密码，可以在词汇表里记录，而用例写成--显示<用户信息>。
5.在用例中越出系统边界描述整个业务流程
要建立的系统只是整个业务流程里的一部，善良的需求人员为了大家清楚来龙去脉，将系统外的处理步骤也写进了用例的情景。
如：
1.用户去营业厅开户
2.用户拨号接入
实际上去营业厅开户不属于宽带接入认证系统的职责。
解决方法：开户的描述应该放到用例的前置条件中。前置与后置条件是说明系统边界外的业务流程的好地方。
6.过多的用例，让人晕菜
国外的惯例，一个用例一般有半个以上人月的开发量。
解决方法：
1.开户，销户这样的CRUD型用例可以合并成一个管理用例，以四个主场景分别表达。
2."老板问：你每天做什么阿?"，"我每天登陆系统"。这就是用例没有提供足够价值的明显标志。
3.用例中的每一个步骤，其实都可以写成一个独立的用例，分 or 不分？
4.用例的打包组织是一门艺术，功能包、顶级目标用例，Actor，开发团队与版本号等。
7.过多的扩展事件和异常事件流，让人晕菜
即使是受过训练的程序员，2a, 3b1看多了也要晕掉，记住阅读者是人而不是机器。
解决方法：
1.如果逻辑不多，可以一句话讲完，不影响主场景的，不建议新起一个事件流。
2.可以使用活动图来辅助说明。在RSM7.0的模版里，每个用例都会带上一个活动图。
8.过多的关系，继续让人晕菜
“不要花一个月的时间去讨论应该include还是extend”。大家对include, extend and generalize都不熟悉，那就干脆都不要用了。
参考材料：
《编写有效用例--Wriging Effective Use Case》Corkburn 2001，大家现在使用的用例模版都是他创下来的，此书无可替代。
《用例模式与蓝图--Use Cases Patterns and Blueprints》我觉得比另一本名字相近的《Patterns for Effective Use Cases》要实用一些。
最狂热的用例编写者也承认，用例对客户与需求人员都是一种heavy的相互折磨。
客户看用例时总要收摄心神来阅读整个交互的流程，还有那些该死的扩展流异常流，没经过程序员专业抽象训练的客户，对着这些伪代码一般的情景脚本，刚开始的一两个还好，看多了，就是白天也能睡去。客户只是看都如此了，负责写的人当然也不会好过。
但heavy的工作总有heavy的好处，否则早被唾弃于舞台的背面。
在用户的角度，用例比模棱两可的功能点描述要清晰，也更直白于系统的价值。
在开发团队角度，RUP的核心方法论之一---用例驱动的口号，明白人自然明白他的妙用。
设计人员有了新的设计手段：“用时序图分析用例的实现，在描述过程中确定构件或类，分配它们的职责和方法”，通过对用例覆盖率的追踪，将需求与设计之间的信息损耗这个famous problem大大降低。
测试人员和文档人员，更可以直接把系统用例笑纳为《测试用例》和《用户手册》。
来到亿迅大陆后，被这里的用例文明给震住了，每个项目的软件规格说明都是屯门清一色的几百页的前景，用例规约，业务规则，词汇表，补充规约组成.......
昨天又看到了一批新的用例诞生，但实在有好些明显的不足啊，忍不住旧事重提的记下一批经典的错误。不过.....只要能和客户达成需求共识，就是一份好的用例了，也不用花太多时间在学术性的讨论上。
1.客户没有能力阅读用例
如果客户实在没办法撑住困意看完用例的细节，即使草草签了名，得不到用户真正确认的用例，依然无法用来驱动设计和测试。
解决方法：放弃编写用例，改回用户容易看的传统方式。
2.团队没有能力实现用例驱动
如果开发团队在设计与测试时，根本不依照用例细节驱动，那用例对开发团队就只是个摆设，花瓶。
解决方法：对设计、测试人员进行用例驱动的培训，如果事不可为就干脆放弃，怎么省事怎么做。
3.在用例中描述系统内部工作
经典错误，开发人员把用例当作设计文档来写，如“系统将销售信息写入数据库”，实际上应该写的是“系统记录销售”。
解决方法：站在客户的角度，把系统视为黑盒，删除所有内部设计描述。
4.在用例中描述界面
另一个经典错误，不说了，如果在意用户信息包括了姓名和密码，可以在词汇表里记录，而用例写成--显示<用户信息>。
5.在用例中越出系统边界描述整个业务流程
要建立的系统只是整个业务流程里的一部，善良的需求人员为了大家清楚来龙去脉，将系统外的处理步骤也写进了用例的情景。
如：
1.用户去营业厅开户
2.用户拨号接入
实际上去营业厅开户不属于宽带接入认证系统的职责。
解决方法：开户的描述应该放到用例的前置条件中。前置与后置条件是说明系统边界外的业务流程的好地方。
6.过多的用例，让人晕菜
国外的惯例，一个用例一般有半个以上人月的开发量。
解决方法：
1.开户，销户这样的CRUD型用例可以合并成一个管理用例，以四个主场景分别表达。
2."老板问：你每天做什么阿?"，"我每天登陆系统"。这就是用例没有提供足够价值的明显标志。
3.用例中的每一个步骤，其实都可以写成一个独立的用例，分 or 不分？
4.用例的打包组织是一门艺术，功能包、顶级目标用例，Actor，开发团队与版本号等。
7.过多的扩展事件和异常事件流，让人晕菜
即使是受过训练的程序员，2a, 3b1看多了也要晕掉，记住阅读者是人而不是机器。
解决方法：
1.如果逻辑不多，可以一句话讲完，不影响主场景的，不建议新起一个事件流。
2.可以使用活动图来辅助说明。在RSM7.0的模版里，每个用例都会带上一个活动图。
8.过多的关系，继续让人晕菜
“不要花一个月的时间去讨论应该include还是extend”。大家对include, extend and generalize都不熟悉，那就干脆都不要用了。
参考材料：
《编写有效用例--Wriging Effective Use Case》Corkburn 2001，大家现在使用的用例模版都是他创下来的，此书无可替代。
《用例模式与蓝图--Use Cases Patterns and Blueprints》我觉得比另一本名字相近的《Patterns for Effective Use Cases》要实用一些。
难得有情郎之--遇上用例驱动的团队 - 花钱的年华 - CSDNBlog
架构师09年书单 - 花钱的年华 - CSDNBlog
架构师核心技能养成计划 - 花钱的年华 - CSDNBlog
Hadoop-- 海量文件的分布式计算处理方案 - 花钱的年华 - CSDNBlog
《井冈山的情郎》诗歌
《井冈山的情郎》
世间最美的情郎
世间最美的情郎
世间最美的情郎
七的故事之青涩年华
屈默杯酒人生之三十：30岁后的女人难嫁有情郎- 屈默 - 新浪BLOG
屈默杯酒人生之三十：30岁后的女人难嫁有情郎
SD卡驱动开发随笔(1) - Professionaler(自由人）的专栏 - CSDNBlog
30岁后的女人难嫁有情郎
你是世间最美的情郎
世间最美的情郎—仓央嘉措
Nutch 0.8笔记--Google式的搜索引擎实现 - 花钱的年华 - BlogJav...
我最喜欢和关心的开源项目 - 花钱的年华 - BlogJava
用例驱动的需求过程实践
BlogJava - 花钱的年华 - Python+wxWidgets快速开发桌面小程序
架构师书单3rd Edition - 花钱的年华 - JavaEye技术网站
Linux的文件系统结构 - 隼之 - CSDNBlog
Linux的文件系统结构 - 隼之 - CSDNBlog
QuickServer--在吵闹的环境里快速搭建自己的TcpServer(Pragmatic系列) - 花钱的年华 - BlogJava