需求之坑
Don’t Gather Requirements—Dig for them.不要搜集需求——挖掘它们
挖掘需求
需求是对需要完成的某件事的陈述
“我能否在你们工作时在这里呆上一周”——注意不要妨碍别人工作
Work with a User to Think Like a User.与用户一同工作,以像用户一样思考
建立需求文档
将挖掘出来的需求建立需求文档;
看待用例的一种方式是强调其目标驱动;
把形式化的模板用作备忘录;
规定过度
制作需求文档时的一大危险是太具体;
需求不是架构,需求不是设计,也不是用户界面,需求是需要;
看远些
Abstractions Live Longer than Details.抽象比细节活得更长久
再摸一层薄薄的薄荷
许多项目的失败都被归咎于项目范围的增大——也称为特性膨胀,蔓延特性论或需求蔓延
维护词汇表
对用户和领域专家的属于进行有条例地记录并随时维护
Use a Project Glossary.使用项目词汇表
把话说出来,放在Web上,大家一起看。
解开不可能解开的谜题
自由度
Don’t Think Outside the Box—Find the Box.不要在盒子外面思考——要找到盒子
对于各种约束和条件边界,应该从更高角度看,忽略一些不适用的约束,并确定你确实拥有自由度。
一定有更容易的方法
对于“不能解决的问题”经常问问自己:
1. 它真的必须完成吗?
2. 它必须以这种方式完成吗?
3. 是什么使它如此难以解决?
4. 这件事为什么是一个问题?
5. 你是在设法解决真的的问题,还是被外围的技术问题转移了注意力?
6. 有更容易的方法吗?
等你准备好了
Listen to Nagging Doubts—Start When You’re Ready.倾听反复出现的疑虑——等你准备好再开始
是良好的判断,还是拖延?
对于无法判断项目是否拖延,可采取一种行之有效的技术构建原型,而对于有困难的地方,可进行“概念验证”(proof of concept)
最可怕的事情:花了几周认真开发,却发现原来只要一个原型。
规范陷阱
注:这里的规范通常就是我们平常说的设计
程序规范就是把需求规约到程序员能够接管的程度;规范也是与用户的约定,一份隐含的合约。
Some Things Are Better Done than Described.对有些事情“做”胜于“描述”
应把需求挖掘、设计以及实现视为同一个过程,而不要信任:需求分析、编写规则、编码是独立的分开进行的。因为这些步骤本身就是无缝的。
太细的规范可能会演变为“分析瘫痪”(analysis paralysis)
圆圈与箭头
盲目采用任何形式方法,其结果往往令人失望
形式方法缺点:
1. 大多数形式方法结合图和文字说明,但用户通常喜欢原型
2. 形式方法鼓励专门化,大家更希望了解整个系统,而不是冰山一角
3. 元数据让我们运行时改变应用特征,而大多数形式方法鼓励你在对象间建立静态关系
Don’t Be a Slave to Formal Methods.不要做形式方法的奴隶
批判地看待方法学而从中提取精华,融合到每项工作中。
Expensive Tools Do Not Produce Better Designs.昂贵地工具不一定能制作出更好地设计。