用户故事与敏捷方法①

Posted 2020-08-12 YangLna

 在读这本书之前，自己觉得有点好奇，用户故事指的是什么呢，读完之后，有了体会：用户故事描述了对用户、系统或者软件购买者有价值的功能。它由3方面组成：1>一份书面的故事描述，用来做计划和作为提示；2>有关故事的对话，用于具体化故事细节；3>测试，用于表达和编档故事细节且可用于确定故事何时完整。

    它总共分为了五大部分来介绍：

    第一部分是一些简单的概念或者使用故事的细节方面，比如如何编制用户故事，有哪些细节要求；在故事中找出用户角色模拟使用情节；怎样搜集到用户故事，通过各种途径；如何找到用户代理（替代用户对软件的使用情况），要找对；对已完成的软件如何进行用户故事型的验收测试；写用户故事的一些准则（需要注意的地方，使用户故事更能体现出使用它的好处）。整体就是围绕用户故事的本身，是什么，怎么写，注意点等。

    第二部分是使用用户故事的一个好处：利用迭代计划和发布计划的制定，首先以故事点为单位来估算每个故事所需要花费的时间，再在排列故事优先级的、在选择好迭代长度的情形下，制定一个好的发布计划，在发布中的功能包括有：必须要有的、应该有的、可以有的、这次不会有的。

    第三部分是关于一个好的用户故事的讨论，包括与IEEE830、用例、场景的区别以及使用它的一些具体而细小的好处，在编写用户故事时因一些不好的编写形式等而造成的不良后果，还有就是如何把用户故事和另一种敏捷过程Scrum结合在一起（主要简介了下另一种敏捷过程Scrum）。

    第四部分是利用一个完整的实例对前三个部分进行了一个总结。它的项目是一个南海岸航海用品的网站开发，整个过程大致如下：用户角色（定义客户、定义部分角色雏形、整合与提炼、角色建模、添加虚构人物）->一些用户故事（两种方式：一种不按照角色或者虚拟人物顺序写出故事，另一种是先从一个特定的用户角色或者虚构人物开始写出团队能想到的所有故事，本例采用第二种）->估算故事（依据参加会议的人写估算并阐述理由知道大家估算相近为止）->发布计划（步骤：1.确定迭代长度；2.估算速率；3.给故事安排优先级；4.将故事分配到一轮或者多轮迭代中）。如果想了解使用用户故事的整体架构，则可先参照本例，对于细节再可查阅前三部分。

    第五部分是一个附录，主要包括了极限编程和参考答案。本人理解的极限编程是使用类似于用户故事开发所具有的一些特点的变成方式。极限编程的特征是Kent Beck最初描述的12个实践：短交付周期、计划游戏（发布计划和迭代计划的指定）、重构（指重组或重写代码以改善代码，但不改变其外部行为）、测试（开发人员编写自动化单元测试，客户编写验收测试）、结对编程（好处：思考更广泛、更少的缺陷、解决下相同问题编写代码更少、解决问题更快、理解每一块代码人更多、开发工作满意度增加）、持续一致的节奏（相较于无法持续的节奏进行工作，以一致轻快的步伐前进，能在一段时间内完成更多工作）、团队代码所有权（每个人都拥有所有代码，在这样团队所有权模型下，任何结对的开发人员都可以修改任何代码。事实上，由于重构的实践，结对者要修改其他人写的代码）、编码标准（遵循同一个编码标准很重要）、简单设计（用最简单的设计去交付客户所需的功能）、隐喻（寻找一个适用于整个系统的隐喻来支持对简单设计的追求，这个隐喻提供了一个他们如何思考系统的参照体系）、持续集成（团队可以每月或者每周等集成一次软件，这样就可以避免因不经常整合而导致的更大问题）、现场客户（过去，客户编写好需求文档，把它扔给墙外编写代码的程序员，接着又把系统抛过钱给一些测试人员，这种情况很普遍。但是用XP（即极限编程），这道墙不复存在，客户将和开发团队坐在一起，并成为团队一部分。）

   极限编程的价值：沟通（通过结对编程等类似实践进行沟通）、简单（它关注当下遇到的问题创建解决方案，而不会关注未来预期的问题）、重视反馈，反馈越快越好（客户是团队一部分，甚至与开发人员坐一起，他们通过与团队的频繁交互以及他们编写的验收测试为团队提供反馈）、勇气（如有勇气重构、有勇气在没有整体细致架构情况下前进）。

   整本书内容大致如此。它强调了客户沟通的重要性，几乎整个开发过程都是有客户参与，没有真实客户，可找客户代理（并且要弄清楚该类客户所代表的软件使用人群），着重解决眼下的问题。绝不是闭门造车型的。