第7章 在项目开始之前 Before The Project
36. 需求之坑
完美，不是在没有什么需要增加、而是在没有什么需要去掉时达到的。
——Antoine de St.Exupery,Wind,Sand,and Stars,1939
提示51: Don't Gather Requirements-Dig for Them
不要搜集需求——挖掘它们
如果需求被陈述为“只有人事部门才能查看员工档案”，开发者最后就可能会编写代码，在每次应用访问这些文件时进行明确的检查。
但是，如果陈述是“只有得到授权的用户可以访问员工档案”，开发者就可能会设计并实现某种访问控制系统。
当政策改变时（它会改变的），只有该系统的元数据需要更新。
找出用户为何要做特定事情的原因、而不只是他们目前做这件事情的方式，这很重要。
有一种能深入了解用户需求、却未得到足够利用的技术：成为用户。
提示52: Work with a User to Think Like a User
与用户一同工作，以像用户一样思考
Cockburn的用例模板:
用例样本:
制作需求文档时的一大危险是太过具体。好的需求文档会保持抽象。
提示53: Abstractions Live Longer than Details
抽象比细节活得更长久
提示54: Use a Project Glossary
使用项目词汇表
如果用户和开发者用不同的名称指称同一事物，或是更糟，用同一名称指称不同事物，这样的项目很难取得成功。
37. 解开不可能解开的谜题
提示55: Don't Think Outside the Box-Find the Box
不要在盒子外面思考——要找到盒子
很多时候，对需求的重新诠释能让整个问题全都消失——就像是戈尔迪斯结。
你所需要的只是真正的约束、令人误解的的约束、还有区分它们的智慧。
38. 等你准备好
了不起的表演者有一个共同的特征：他们知道何时开始，何时等待。
提示56: Listen to Nagging Doubts-Start When You're Ready
倾听反复出现的疑虑——等你准备好再开始
39. 规范陷阱
有一个挑战：写一份简短的描述，告诉别人怎样系鞋带。
这是一件极其困难的事情。而我们大多数人不用有意识地思考就能系上鞋带。
提示57: Some Things Are Better Done than Described
对有些事情“做”胜于“描述”
有时一幅图胜过千言万语，有时却又毫无用处
40. 圆圈与箭头
盲目地采用任何技术，而不把它放进你的开发实践和能力的语境中，这样的处方肯定会让你失望。
提示58: Don't Be a Slave to Formal Methods
不要做形式方法的奴隶
提示59: Expensive Tools Do Not Produce Better Designs
昂贵的工具不一定能制作出更好的设计
网友评论