用户故事地图（9）：开发流程之“研发-评估-交付”阶段
在这一篇文章中，我们将会完成用户故事流程中最后三个阶段：研发、测试和交付。想想距离写完这个读后感应该还剩1〜2篇文章的距离，不免吐了一口气——要想读懂一本书真是不容易，从一本书中读出三本书的知识，更不容易。
从各方收集得来的需求，以“故事”的方式记录在卡片上，并先后经历了“机会”➝“探索”➝“模型设计”➝“故事工作坊”，终于流入开发阶段。在开发阶段，项目会遇到各种问题，它们转化为信息被讨论并反馈，以此来持续的调整方案，并同时更新地图。
在实际开发过程中，我们常将要一个版本要开发的内容按功能模块进行拆分，例如模块A、B在第一阶段交付测试，C在第二阶段交付测试，以此类推。《用户故事地图》一书对功能的拆分方式略有不同。在《用户故事地图（2）》中，我们对这种切分方式已有简单描述，此处再详细介绍下。
研发阶段
功能在正式上线前，会分为三阶段进行开发。它们分别是：
| 阶段 | 内容 | 目标 | 说明 |
|---|---|---|---|
| 第一阶段 | 完成核心流程开发 | 排除技术风险 | 1、通过数据观察功能的性能； 2、使用自动化测试检验稳定性; 3、关注技术挑战和风险，通过消除技术风险，避免风险在后期造成更大成本; |
| 第二阶段 | 开发周边功能 | 关注质量，达到可发布标准 | 1、开发主流程之外的其他可选流程和复杂逻辑； 2、常常加入之前未发现的新特性; 3、原系统无法满足性能上的需求而需要额外投入来解决的问题 |
| 第三阶段 | 打磨产品 | 让产品更抢眼、使用更高效 | 1、可能会加入未预想的东西； 2、使用线上真实数据测试； 3、常常会现在原型阶段无法识别的改进点 |
以上方式并非以独立功能点完成数量进行拆分，而是对所有功能一起进行不同层面的切分。要想达到它，我认为必须达到：功能间耦合度低，自动化测试的参与，还有就是增量开发方式。
在开发过程中，项目会遇到各种问题：来自技术实现、来自外部、来自于设计合理性一致性等。我们心理上是排斥它们的，起码不会认为是好事儿。然而换一个角度想，也许就会不同：
从讨论机会出发，到找到用户，从用户或客户面对的问题，到形成对应的解决方案。所做的每一步、开发的每一个功能都有一个明确的目标，那就是学习（获得更多信息以改进产品）。
——精益创业的核心思路：基于验证的学习
开发过程中出现的问题，恰恰是帮助我们进一步学习的机会。而正视这件事情的关键，在于学习的态度——即遇到的问题可以被总结、沉淀，以解决更多问题。以此来看，“变更”这件事情在某些情况下是正常的，我们必须承认，有一些问题是无法在工作坊中想到的。
在开发过程中，我们依然要保持对用户故事地图的高度使用——实时根据目前项目的开发状态和进度，定时持续的在用户故事地图中标识故事状态（在开发过程中，依然保持对整体的认识）。另一方面，它可以帮助团队在各个阶段都可以看到自己完成了什么，当前的进度和开发重点是什么。做过项目的人都会遇到一个问题，就是为了进度常常会临时去掉一些功能，留待后续开发。然而若没有一个有利的跟踪方式，这部分内容很容易被遗忘，所谓“后续开发”几乎等同于“没有后续”。若将这些功能实时放在地图中，我们就很容易从全局看到这些遗漏功能的影响，并在相应阶段提上开发日程。
由此可见，在项目跟踪上，用户故事地图也发挥着很大的作用。
测试与评测阶段
根据前期的故事切分，我们在开发过程中会陆续获得一些小的开发模块。接下来我们将要对它们进行测试以评估质量，并且判断是否需要调整进度。这个在SCRUM中应该叫“迭代评审会议”或“迭代回顾会议”。我们可以从三个方向来进行测试评估：
- 用户体验质量：
- 交互：从用户角度来看，功能是否简单易用、是否体验到乐趣？
- 视觉：看起来是否让人舒服？
- 一致性：和其他功能对比，在设计上是否具有一致性？
- 功能质量：
- 功能实现的正确吗？
- 是否含有BUG？
- 代码质量：
- 是否符合编码规范？
- 代码是否鲁棒？
通过以上方式获得了可以基本工作的功能模块后，就可以立即找到用户进行测试，从而获得改进建议。我们常讲MVP，但实际上此阶段用于用户测试的模块完全不需要达到上线级别，只要能够帮助用户“成达一个有意义的目标”即可。
受“专家盲点”的影响，开发者并不能完全体会用户的实际使用情况。而用户行为数据和后台反馈又具有局限性，较难对体验的改进有所帮助。因此在功能模块稳定后第一时间邀请用户（邀请其他干系人也是很有必要的）使用是非常有必要的。它并非是向用户讲解，而是用最小的成本来验证它是否能正确的解决用户的问题（相信我，很多项目成员是不会考虑成本这个事儿的）。
交付阶段
功能完成开发后，接下来需要向利益干系人（老板等）和用户交付了。对于利益干系人而言，他们并不会每天使用软件，他们只关心是否可以尽快上线。因此，当向上级汇报时，他们常常听不懂做了什么。为了解决这个问题，我们需要在交付之前经常汇报（用户故事地图可以整体上说明每个阶段完成的内容），交付时要写清做了什么、目的和背景。对于组织内的干系人，项目进度和完成质量要保持持续可见，这样他们才会信任团队。
产品上线后，运用数据和接触用户来了解结果是否达到预期。反馈达到预期、解决了问题，就可以就此结项。若发现了改进的问题，则把它们记录下来，重新回到原点。
—— end ——
所有内容（持续更新中）
