📝 docs(1.0): 更新整个目录

Signed-off-by: Tony Deng <[email protected]>

Author: tonydeng

SUMMARY.md

@@ -1,11 +1,10 @@
 # Summary
 
 * [敏捷的用户故事方法](README.md)
-* [一、起步](starting.md)
-  * [1. 背景](ch1/README.md)
-  * [2. 编写故事](ch2/README.md)
-  * [3. 用户角色建模](ch3/README.md)
-  * [4. 收集故事](ch4/README.md)
-  * [5. 与用户代理合作](ch5/README.md)
-  * [6. 用户故事验收测试](ch6/README.md)
-  * [7. 优秀的用户故事准则](ch7/README.md)
+* [1. 什么是用户故事](ch1/README.md)
+* [2. 编写故事](ch2/README.md)
+* [3. 用户角色建模](ch3/README.md)
+* [4. 收集故事](ch4/README.md)
+* [5. 与用户代理合作](ch5/README.md)
+* [6. 用户故事验收测试](ch6/README.md)
+* [7. 优秀的用户故事准则](ch7/README.md)

ch1/README.md

@@ -1,4 +1,10 @@
-# 1. 背景
+# 1. 什么是用户故事
+
+![起步](../images/starting.jpg)
+
+这一部分会说明**什么是用户故事**，如何使用它们开始，介绍**如何编写**用户故事，如何利用系统的**用户种类**来确定故事，如果在难以接触到用户的情况下**与充当用户角色的人一起工作**，如何**编写测试**来**验证**故事已经完成。
+
+最后，给出一些有助于编写良好故事的**指导原则**。
 
 ## 软件需求是一个沟通的过程
 

ch7/README.md

@@ -88,9 +88,7 @@
 
 比如这样的故事：
 
-> 系统必须支持最大50个并发用户的峰值
->
-> 约束
+> **约束：** 系统必须支持最大50个并发用户的峰值
 
 其他约束的例子如下：
 
@@ -142,6 +140,78 @@
 
 在写故事时，**要充分利用故事的灵活性，以便应用于各个层级**。
 
+## 7.5. 不要过早涉及用户界面
+
+困扰软件需求方法的问题之一是将需求与解决方案混在一起。也就是说，在说明一个需求时，也要明确说明或者暗示解决方案，通常这种解决方案就体现在用户界面上。但是这种方式会将需求和解决方案混在一起，无法清晰的将需求表达清楚，并且会在项目前期有大量的用户界面设计的工作需要进行设计和澄清。
+
+作为PO，你会希望尽可能把用户界面和故事分隔开。
+
+> **用户故事示例：** 打印对话框允许用户编辑打印机列表。**用户可以从打印机列表中添加或删除打印机，用户可以通过自动搜索或者手动指定DNS打印机名称或者IP地址添加打印机。高级搜索选项还允许用户在限制指定的IP地址和子网范围内搜索。**
+
+如上面的用户故事示例中就会包含了太多用户界面的细节。这个故事的实现者和用户就会被告知了有打印对话框、打印机列表以及至少4种搜索方式。最终，用户界面细节将不可避免地塞进故事。随着软件变得越来越完整，故事从完全的新功能实现转移到功能的修改或者扩展时，这种情况就会导致产生大量的用户故事或需求变更。
+
+## 7.6. 需求不止故事
+
+尽管用户故事是一种非常灵活的格式，可以很好地描述许多系统的许多功能，但它们并不适用于所有的系统。如果需要以非用户故事的形式描述一些需求(如产品设计原型、PRD等)，那就以相应的产出要求来进行对应的需求制品的生产和输出。
+
+> 例如，用户界面通常使用具有大量界面截图的文档进行描述。
+
+同样，除了用户故事之外，你可能需要文档记录并对重要系统之间的接口达成一致，尤其是有外部供应商参与开发时。
+
+**如果发现系统的某个方面可以从不同格式的需求描述中受益，请使用该格式来描述相应的需求。**
+
+## 7.7. 故事中包括用户角色
+
+如果项目团队已经识别了用户角色，那么他们在编写故事时就应该使用这些角色。因此，不要写成“用户可以发布自己的简历”​，应该写成“求职者可以发布自己的简历”​。
+
+这种差异很小，但以这种方式编写故事会让用户存在于开发人员的头脑中。开发人员不会去思考平淡的、不形象的、可替换的用户，他们会想象真实的、具象的用户，从而开发出满足用户需求的软件。
+
+英国公司Connextra[插图]是极限编程的早期采用者之一，他们在2001年使用简短的模板将角色融入故事中。每个故事都是用以下格式编写的：**我作为（角色）想要（功能）以便（商业价值）**
+
+你可能想试试这个模板或者使用你自己的模板。​“role-feature-reason”这样的模板可以帮助区分重要的和无价值的故事。
+
+## 7.8. 为一个用户编写故事
+
+如果只为单个用户编写故事，故事通常最具有可读性。对于许多故事来说，为一个或者多个用户编写不会有什么差异。但是，对于某些故事，差异可能很大。例如，考虑一下“求职者可以从网站上删除简历”这个故事。这可以解释为，一个求职者可以删除自己的简历，也可能删除其他人的简历。
+
+通常情况下，**当你在心中只考虑一个单独用户的故事时，这类问题就会变得清晰起来**。
+
+例如，上面的故事可以写成“求职者可以删除简历”​。当写成这样时，一个求职者可能会删除其他人简历的问题就变得更加明显，所以故事可以进一步改写为“求职者可以删除自己的简历”​。
+
+## 7.9. 用主动语态
+
+主动语态就像直接走向目的地--清晰、有活力，通常因其简单明了而备受青睐。它非常适合大多数类型的交流，让你的句子听起来自信而充满活力。
+
+> 示例：香料[宾语]被小贩[主语]卖掉了[动词]：
+> 公式：宾语[动作的执行者]+动词[动作]+主语[动作的接受者]。
+> 在这里，"香料 "成为重点，而小贩在句子中处于次要地位。
+
+用户故事最好使用主动语态来编写，更易于团队和用户来阅读和理解用户故事，能够形成讨论，并达成对用户故事的一致的认知。
+
+> 例如，不要说“简历可以被求职者发布”​，而应该说“求职者可以发布简历”​。
+
+## 7.10. 客户编写故事
+
+理想情况下，客户会编写故事。
+
+在许多项目中，开发人员可以帮忙编写故事，要么在最初的故事编写工作坊中实际编写，要么向客户建议新的故事。但是，编写故事的责任就在于客户了，而不能很便捷的传递给开发人员。
+
+此外，由于客户有责任确定每次迭代的故事优先顺序，因此客户了解每个故事至关重要。做到这一点的最好方法就是客户亲自把故事写出来，但现实情况下是比较难的意见事情，需要我们的PO非常善于挖掘用户需求，并通过条目化的用户故事来客户来确认故事的优先顺序。
+
+## 7.11. 不要给故事卡编号
+
+> 该准则仅适用于使用卡片来编写故事的实践方式。
+
+我们第一次使用故事卡时，许多人都想要给卡片进行编号。通常的理由是，这将有助于跟踪个别卡片或者为故事添加一定程度的可追溯性。
+
+> 例如，当我们发现卡片13上的故事太大时，我们就撕掉卡片13，并用卡片13.1，13.2和13.3替换它。然而，给故事卡编号给流程增加了无谓的开销，并会导致我们抽象地讨论需要形象化的特性。
+
+我宁愿讨论“故事添加用户组”​，也不想讨论“故事13”​，特别不想讨论“故事13.1”​。如果觉得不得不对故事卡进行编号，可以尝试在卡片上添加一个简短的标题，并在其他的故事文本中使用这个标题的简写。
+
+## 7.12. 不要忘记目的
+
+不要忘记，故事卡的主要目的是提示人们讨论该特性。需要注意保持故事的简短性，不要向故事卡中添加更多细节，用它来取代团队的对话讨论。
+
 ## 扩展阅读
 
 - [Slicing the Cake - User story slicing](http://tracks.roojoom.com/r/1757)