Skip to content

Commit

Permalink
📝 docs(1.0): 完成第七章的前三节
Browse files Browse the repository at this point in the history
refs #3

Signed-off-by: Tony Deng <[email protected]>
  • Loading branch information
tonydeng committed Jul 11, 2018
1 parent e9a37d0 commit abee33e
Show file tree
Hide file tree
Showing 5 changed files with 79 additions and 1 deletion.
17 changes: 17 additions & 0 deletions ch7/7.1.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# 7.1. 从目标故事开始

在一个大型项目中,尤其是有许多用户角色的项目,"如何确定用户故事"这个事情有时让人**无从下手**

我发现最好的办法是考虑每一个用户角色,**了解用户使用我们软件的目的**

例如,思考一下招聘网站例子中的[求职者](../ch3/3.1.md#什么是用户角色)角色。他的确有一个最高优先级的目标:**找到一份工作**。

但我们可以认为这个目标包括以下目标:

- 搜索他感兴趣的工作(基于他的技能、期望薪资、工作地点等)
- 自动搜索,以便于不用每次都手动搜索
- 让他的简历可见,以便于招聘公司能搜索到他
- 很容易申请他喜欢的任何工作


这些**目标**(实际上是高层次的故事)可以**用来衍生出新的故事**
37 changes: 37 additions & 0 deletions ch7/7.2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# 7.2. 切蛋糕

![切蛋糕](images/slicing-the-cake.jpeg)

当面临一个大的故事的时候,通常有许多方法可以将它分解成较小的故事。许多**开发人员首先想到的是将故事按照技术路线分割**

比如,假设团队觉得故事“求职者可以发布简历”在当前这轮迭代中太大了,就必须分割。开发人员可能想沿着技术边界分割,示例如下:

- 求职者可以填写简历表
- 简历表上的信息被写入数据库

在这个案例中,一个故事会在当前迭代中完成,而另一个故事则(很可能)推迟到下一轮迭代里。这种做法的缺陷是,没有一个故事是单独对用户很有用的。

> 第一个故事说的是求职者可以填写简历表,但数据没有被保持。
>
> 第二个故事说的是从简历表上搜集的数据会写入数据库。如果没有第一个故事提供表格给用户,第二个故事就没有什么价值。

一个更好的办法是换一种方式编写故事,每个故事都提供某种程度的完整(`end-to-end`)的功能。

> Bill Wake(2003a)将其称之为“切蛋糕”(`slicing the cake`)
根据这个切蛋糕原则,我们可以把故事“求职者可以发布简历”像下面这样分。

- 求职者可以提交简历,简历上只包括诸如名字、地址、和教育背景这样的基本信息
- 求职者可以提交简历,简历上包括雇主想看的所有信息

在编写用户故事时,更倾向编写像一块完整蛋糕那样功能完整的故事。

具体有两个原因:

- 首先,在开发中,**及早涉及软件应用架构的每一层能够有效地降低最后时刻才发现层次架构方面问题的风险**
- 其次,尽管不十分完美,**即使只提供部分功能,但只要发布的功能可以跑,就可以放心的把应用程序发布给用户使用**

## 扩展阅读

- [Slicing your development as a multi-layer cake -- Luis Fernando Mizutani](http://www.linkedin.com/pulse/slicing-cake-useful-guidelines-breakdown-development-work-mizutani)
24 changes: 24 additions & 0 deletions ch7/7.3.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# 7.3. 编写封闭的故事

`Soren Laueson(2002)`在他的[《Software Requirements》](https://book.douban.com/subject/2696709/)一书中引入了**任务闭包性**的想法。这个想法统一适用于用户故事。

**一个封闭的故事是指随着一个有意义的目标的实现而结束的故事,能让用户使用后觉得他完成了某个任务**

例如,假设招聘网站项目包含故事“招聘者可以管理他发的招聘广告”,这不是一个闭合的故事。管理他发布的招聘广告是没有办法彻底完成的事情。相反,它是一个持续进行的活动。

这个故事可以更好的创建成一个闭合故事的集合。

- 招聘者可以审核针对他发布的招聘广告发的简历
- 招聘者可以更改招聘广告的过期日期
- 招聘者可以删除不适合的申请
- ......

这种**封闭的每个故事都是原来那个非封闭故事的一部分**。使用完这些封闭故事之后,用户可能会有一种**成就感**

**编写封闭故事其实是在互相冲突的各种需求之间权衡的结果**。因为,故事也要小到能做评估,小到可以方便的安排一轮迭代中。

但故事也要足够大(粗颗粒的、高层次的、抽象的),从而避免过早捕获当下还不需要的细节。

## 扩展阅读

- [Software Requirements: Styles & Techniques -- Soren Lauesen](https://www.pearson.com/us/higher-education/program/Lauesen-Software-Requirements-Styles-Techniques/PGM11471.html)
2 changes: 1 addition & 1 deletion ch7/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,4 @@

到现在,我们有了一个很好的基础,了解了什么是故事,如何利用拖网式捕捞以及编写故事,如何识别关键的用户角色以及验收测试在其中起到的作用。

下面,我们将了解一些额外的编写优秀故事的准则
下面,我们将了解一些额外的**编写优秀故事的准则**
Binary file added ch7/images/slicing-the-cake.jpeg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit abee33e

Please sign in to comment.