《构建之法》学习(6)

  1. 典型用户模板
  • 名字
  • 年龄
  • 收入
  • 代表的用户在市场上的比例和重要性
  • 使用这个软件的典型场景

构建典型场景尤其重要。甚至可以实地测试一下。

  • 使用本软件/服务的环境
  • 生活/工作情况
  • 知识层次和能力
  • 用户的冬季、目的和困难
  • 用户的偏好

2. 用例的基本元素

  • 标题:描述这个用例要达到的目标
  • 角色(Actor):和软件系统交互的角色,例如用户,其他实体,甚至时间(在描述一些和时间相关的场景时有用)
  • 主要成功场景(Main Success Scenario):一系列步骤描述角色是怎样和系统交互,从而达到目标的
  • 步骤(Step):描述每一步的交互(例如一套正常的ATM取款流程)
  • 扩展场景(Extension):描述一些扩展的交互,例如一些意外情况(例如取款时账户余额不足)

3. Use Case的原则

  • 通过讲简单的故事来传递信息

讲故事是最有效的人与人交流信息的途径,通过讲故事(Use Case),团队成员能对需求有统一的了解。当我们用自然语言讲故事的时候,我们不自觉地会把复杂的系统当作一个黑盒子,把重点放在用户的愿望、行动上面,这种做法非常有利于我们找到用户的需求和软件的功能点。当然,故事要包含具体的行动(Actionable),并且是可以验证的(Testable),所以讲故事也要有技巧。

  • 保持对全系统的理解

虽然每一个用例都是一个简单的故事,但是不要忘了它是整个系统的一部分。

  • 关注用户的价值

别迷失在长长的功能列表中,牢记软件的价值在于给用户提供价值。

  • 逐步构建整个系统,一次完成一个用例

Ivar认为这是Use Case2.0方法论中最重要的一个观点。一个用例的完成可能要触及整个系统的各个层面(例如,“用户在ATM上完成跨银行的取款”这一用例需要银行系统各个子系统协同修改,才能完成),不同模块间复杂的依赖关系对团队是一个大的考验。

  • 增量开发,逐步构建整个系统
  • 适应团队不断变化的需求

4. 如何写功能说明书?

写给用户看的。

  • 定义好相关的概念
  • 规范好一些假设(Assumptions)
  • 避免一些误解,界定一些边界条件
  • 描述主流的用户/软件交互步骤
  • 一些好的功能还会有副作用
  • 服务质量的说明

5. 设计文档应该体现下列原则

写给开发者看的。

  • 抽象(Abstraction)
  • 内聚/耦合/模块化(Cohesion, Coupling,Modularization)
  • 信息隐藏和封装(Information Hiding, Encap-sulation)
  • 界面和实现的分离(Separation of Interface and Implementation)
  • 如何处理错误情况(Error Handling)
  • 程序模块对于运行环境、相关模块、输入输出参数有什么假设?这些假设和相关的人员验证过么?
  • 应对变化的灵活性(Adapt to Change)
  • 对大量数据的处理能力(Scalability)

6. 功能驱动的设计(FDD)由以下几个步骤构成:

  • 构造总体模型(Develop an Overall Model)

进入条件:团队已经选好了问题领域专家、主程序员、架构师。

任务1:决定建模小组成员,一般团队成员可以轮流参与

任务2:问题领域专家概要介绍问题领域知识。大家学习已有的参考资料(已有的建模文件、数据模型、功能需求、用户文档等)

任务3:以不超过3人的小团队构建子问题领域的模型,并在适当的时候补充总体模型

任务4:记录模型的信息并保存为文档

验证:和团队内部或外部的利益相关者验证模型以及它们对用户和业务活动的影响

出口条件:总体模型已经建好;各个实体(类)的关系也已经表达清楚,各个实体的属性和函数有初步定义;数据流、事件流程等说明文档已经完备

  • 构造功能列表(Build a Feature List)

进入条件:团队已经选好了问题领域专家、主程序员、架构师

主要任务:构造功能列表

怎么表达一个“功能”?FDD认为,团队成员应该能在第一步工作的基础上,把问题领域描述的活动逐步细化,把大的问题领域分解为小的主题领域(Subject Area),然后描述在主题领域中出现的业务活动(Business Activities),最后细化和提炼出来的功能描述应该符合下列的三元组格式:

<action><result><object>

例如:计算此次销售的总额;验证用户的密码符合最低要求。

注:用英语表达功能时,大多数情况下 of 是很自然的表达方式,例如 Cal-culate the total of a sale,verify the password ofa user. 但是,同样的意思在中文里面会表达为<动作><实体>的<结果>,例如:计算此次销售的总额,验证用户的密码。同时,要注意团队成员估计一个功能所需的时间,如果时间超过两周,则需要再次细化。

验证和出口条件:此时团队应该得到:一系列主题领域、一系列业务活动、一系列功能,这些功能可以满足上面提到的每一个业务活动

  • 制定开发计划(Plan by Feature)

在这一步,开发团队要根据下列因素制定开发计划:

各种实体和功能之间的依赖关系

实体和功能的复杂程度

高风险和高难度的功能要适当提前,这样能让大家早日看到结果

各位成员的忙闲程度

考虑对外承诺的演示/Alpha/Beta发布

验证和出口条件:经过这一步,团队就应该得到:

在每个里程碑中能实现的大致业务活动计划(精确到年/月)

主题领域完成时间(取决于最后一个功能的实现时间)

功能实现的先后次序

功能的相互依赖关系,和功能的所有者的对应关系

各个功能的复杂程度

  • 功能设计阶段(Design by Feature)

在这个阶段,团队成员在主程序员的带领下,分析一组相关的实体及其功能,通过时序图(Se-quence Diagram)和其他工具,展示各个实体和函数如何动态地结合起来实现一个功能。通过这样的活动,团队成员就开始实现具体的实体和函数(使用面向对象语言的类/函数,或其他程序设计元素)。主程序员根据时序图和其他信息,更新实体模型。这一步产生的结果是:

“这次里程碑要发布的功能”文档,及其相关文档

各个业务活动对应的时序图,更新的实体模型,类/方法/属性

各位成员知道自己的功能实现计划,精确到天

  • 实现具体功能(Build by Feature)

具体的团队成员要实现类/函数,进行相关的单元测试,并在代码复审之后,把代码集成到产品构建当中。这一步产生的结果是:一个完整的、验证过的功能。不同的方法论有各种适用范围,我认为,FDD适用于团队成员对于需求没有切身体会的情景,例如要实现不熟悉的行业(银行、证券、物流等)的业务系统。不过,我并未亲历过FDD的项目,仅从纸面上看,FDD 对单元测试之外的测试(如集成测试、压力测试、对用户界面和用户体验的测试)的讲述不足。如果软件团队在这些方面没有足够的投入,最终的系统会存在许多问题。

注意,我对这部分FDD不是很了解,故对书中的内容有大量的摘录。

7. 开发人员的标准工作流程:

开发流程

注意:发现Bug后一定要复审Spec。这难道不需要分情况看bug大小吗?小bug也需要如此?

8. 构建宽严表

构建宽严表