在项目的最开始,你需要确定各种需求,只是听取用户的意见还不够。启动太快是一个问题,但等的太久可能会更糟。

36、需求之坑

需求很少存在表面上,它们通常深深地埋在层层假定、误解和政治手段下。

不要搜集需求,挖掘它们

挖掘需求

把政策的文档与需求的文档分开,并用超链接把两者联系起来,使需求成为一般陈述,并把政策信息作为一个例子发给开发者–他们需要在实现中支持的食物类型的例子。最后,政策可以成为应用中的元数据。

找出用户为何要做特定事情的原因,而不只是他们目前做这件事的方式。有一种能深入了解用户需求,却未得到足够利用的技术:成为用户。

与用户一同工作,以像用户一样思考

开采需求的过程也是开始与用户建立和谐的关系、了解他们对你正在构建的系统的期许和希望的时候。

建立需求文档

同用户一起坐下来,从他们那里探问真实的需求,你遇到一些合适的、描述应用需要做什么的情境,将它们写下来,并发布每个人都可以用作讨论基础的文档– 开发者、最终用户以及项目出资人。

用例图

可以用UML活动图捕捉工作流,而且又是腰围手边的事务建模,概念层类图很有用。但真正的用例是具有层次结构和交叉链接的文字描述。

不要做任何表示方法的奴隶,只要是与你的听众交流需求的最好的方法,都可以加以利用。

规定过度

制作需求文档的一大危险是太过具体,好的需求文档会保持抽象。在涉及需求的地方,最简单的,能够准确地反映商业需要的陈述是最好的。

需求不是架构,不是设计,也不是用户界面,需求是需要。

看远些

Y2K问题的出现有两个主要的原因:没有超出当前的商业实践往前看,以及对DRY原则的违反。

抽象比细节活的更长久

再抹一层薄薄的薄荷

许多项目的失败都被归咎于项目范围的增大,也称为特性膨胀、蔓延特性论,或是需求蔓延。

管理需求增长的贵贱是向项目出资人指出每项新特性对项目进度的影响。我们很容易被吸进“只是再增加一个特性”的大漩涡,通过追踪需求,你可以更清楚的看到,“只是再增加一个特性”已经是本月新增的第15个新特性。

维护词汇表

一旦开始讨论需求,用户和领域专家就会使用对他们有特定含义的术语。要创建并维护项目词汇表,这是定义项目中使用的专用术语和词汇的地方。

如果用户和开发者使用不同的名称指称同一事物,或是更糟,用同一名称指称不同事物,这样的项目很难取得成功。

把话说出来

通过将需求制作成超文本文档,可以更好地满足不同听众的需要,我们可以给每个读者他们想要的东西。基于WEB的分发方式还能让你避免典型的两英寸文件夹–名为需求分析,其实永远没有人阅读,墨水刚沾上纸面,就过时了。

37、解开不可能解开的谜题

有些谜题用很明显的解决方法没用,解决方法在另外的地方。解开它的秘诀是确定真正的(而不是想象的)约束,并在其中找出解决方案。

“在盒子外面思考”的俗话鼓励外面找出可能不适用的约束,并忽略它们。如果盒子是各种约束和条件的边界,那么诀窍就在于找到盒子,他可能比你以为的要大得多。

解开谜题的关键在于确定加给你的各种约束,并确定你确实拥有的自由度,因为在其中你将找到你的解决方案。

你必须挑战任何先入为主,并评估他们是否是真实的、必须遵守的约束。问题不在于你是在盒子里思考,还是在盒子外面思考,而是在于找到盒子,确定真正的约束。

不要在盒子外面思考,要找到盒子

在面对棘手的问题时,列出所有在你面前的可能途径,不要排除任何东西,不管它听起来有多无用或愚蠢。对你的各种约束进行分类,并划定优先级。

一定要有更容易的方法

有时你会发现,自己在处理的问题似乎比你以为的要难得多。感觉上好像走错了路,一定有比这更容易的方法。或许现在你已经活在了进度表后面,甚或失去了让系统工作起来的信心。这正是你退回一步,问问自己一些问题:

  • 有更容易的方法吗
  • 你是在设法解决真正的问题,还是被外围的技术问题转移了注意力
  • 这件事情为什么是一个问题
  • 是什么使它如此难以解决
  • 它必须以这种方式完成吗
  • 它真的必须完成吗

当你设法回答这些问题时,会有让自己吃惊的发现。很多时候,对需求的重新诠释能让整个问题全都消失。

你所需要的知识真正的约束、令人误解的约束,还有区分他们的智慧。

38、等你准备好

倾听反复出现的疑虑--等你准备好再开始

作为开发者,你再整个职业生涯中都在做同样的事情,你一直在实验个各种东西,看哪些可行,哪些不可行。你一直在积累经验与智慧,当你面对一件任务时,如果你反复感觉到疑虑,或是体验到某种勉强,要注意它。你可能无法准确地指出问题所在,但给他时间,你的疑虑很可能会捷径成某种更坚实的东西,某种你可以处理的东西。

是良好的判断,还是拖延

什么时候是在拖延,而不是在负责地等待所有工作准备就绪?

这种情形下,一种行之有效的技术是开始构建原型。选择一个你觉得会有困难的地方,开始进行某种概念验证。在典型情况下,可能会发生两种情况:

一种是开始后不久发现自己是在浪费时间,这种厌烦可能很好地证明你最初的勉强只是希望推迟启动,放弃原型,回到真正的开发中。

另一种是随着原型取得进展,你可能会在某个时刻得到启示,突然意识到有些基本的前提错了,还将清除地看到怎么纠正错误。愉快的放弃原型,投入正常的项目中。

当你决定把构建原型当做调查你的不适的一种方法时,一定要记住你为何这样做。

从“政治策略”的角度说,去构建原型也许比简单的宣布“我觉得不该启动”、并开始玩单人纸牌游戏更能让人接受。

39、规范陷阱

编写程序规范就是把需求规约到程序员能够接管的程度的过程。这是一个交流活动,旨在解释并澄清系统的需求,比如消除主要的歧义。规范还是留给未来进行代码维护和增强的几批程序员的记录。规范也是与用户的约定。

编写规范是一项重要的职责,但是过分强调规范是一个错误:

  • 规范无法捕捉系统或其需求的每一处细节和细微差别
  • 语言自身的表达能力存在着问题
  • 紧身衣效应,没有给编码者留下任何解释余地的设计剥夺了他们发挥技巧和艺术才能的权利。

对有些事情,做胜于描述

注重实效的程序员,应该倾向于把需求搜集、设计、以及实现视为同一个过程(交互高质量的系统)的不同方面。他们不是孤立进行的,要采用无缝的方法:规范和实现不过是设法捕捉和编撰需求的不同方面。

我们不是在反对生成规范,相反,有时处于合约的原因、因为你的工作环境、因为你正在开发的产品的性质,需要极其详细的规范。只是要知道,随着规范的越来越详细,你得到的回报会递减,甚至是付回报。

40、圆圈与箭头

从结构程序设计开始,经过主程序员团队、CASE工具、瀑布开发、螺旋模型、Jackson、ER图、Boch云、OMT…知道UML,计算技术从来都不确实意图使横须更像工程的方法。每种方法都聚集了自己的追随者。并且都享受到了一段时间的流行,然后被下一个方法取代。这些方法中,或许只有结构化程序设计拥有长久的生命。

不要做形式上的奴隶

形式方法的严重缺点:

  • 大多数形式方法结合图和某些说明文字来捕捉需求
  • 形式方法似乎鼓励专门化
  • 我们喜欢编写有适应能力的动态系统,使用元数据让我们在运行时改变应用的特征。

是否应该使用形式方法

绝对应该,但始终要记住,形式开发方法只是工具箱里的又一种工具。批判的看待方法学,从各种方法学中提取精化,融合成每个月都在变得更好的一套工作习惯,不要变成方法学的奴隶。

昂贵的工具不一定能制作出更好的设计

更多有关《程序员修炼之道》的读书笔记,请关注 :
http://tabalt.net/blog/the-pragmatic-programmer-reading-notes/

本文链接:http://tabalt.net/blog/tpp-before-the-project/,转载请注明。