限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： muyang-0410
引言
“可工作的软件 高于 详尽的文档”，作为敏捷四大宣言之一，它给与了敏捷对文档的定位，然而到底怎么做，在实践中五花八门，甚至对文档的敏捷避而不谈，引发了众多问题和无尽的battles… 需求，作为交付过程的上游，起着举足轻重的作用，本文将围绕敏捷中需求文档的编写 码些文字抛点砖，希望大家对敏捷中需求如何编写及其意义有清晰的认知，并应用到实践中变得更加真正的“敏捷”。
思考
如果对需求抽象，其必需的元素有两个 – 需求产生的背景/需要(why) 和 如何满足需要/需求(what)
why是需求的核心，是需求的价值所在，而what是需求的具象，是具体实现的样子 – 举一个前辈常用的例子- why 是“我要找个女朋友” what 是“我要会弹吉他”
所以，当我们满足需求的时候，我们是满足what还是在满足why呢？
我们是如何一步步忘记初心的
下图描述了在交付过程和角色切分后业务需要是如何在交付过程中被逐渐剥离的，关于需求，在敏捷团队中的各角色应“左移”，不仅要做质量的”守门人”更要做质量的“合伙人” – 这些是从角色的角度出发的；相应的，从文档角度，也势必要保障不仅what还有why在交付过程中的全程满足 – 怎么做呢？
传统的需求活动如下图，从访谈业务需要到产品设计到实施逐步推进，每个步骤有独立的文档，寄希望于每个文档记录正确且充分，实现从WHY到WHAT的转化：
举个例子（接下来会继续使用此例），业务需要WHY是 “为了提升大促活动流量，需要增加新用户数，因此需要通过老用户领取初始红包并分享给好友助力来增加红包金额，好友助力提供个人信息后获得购物券，从而吸引新用户注册以及促销活动的定向推广。”
产品需求WHAT为“在APP首页增加活动栏位，用户点击进入活动页抢红包，活动规则详情展示，红包通过微信和QQ分享，红包助力页面，邀请记录查询，新用户判断，红包活动管理。”及各模块的详细内容描述（逻辑，原型等）。
这大概是最普遍也是大家最熟悉的做法，它经常导致的问题有：
1 需求失焦
当技术团队拿到产品需求文档的时候，因为并没有包含WHY的信息，团队开始聚焦WHAT展开很多逻辑细节（很多团队也习惯了关注what，对需求仅考虑能不能实现，更少的团队可以考虑基于系统历史行为，需求是否合理，而从业务价值出发考虑交付价值的团队就更少了），比如：邀请助力查询页的”助力时间”字段是否需要精确到秒？新用户在活动页拒绝授权是直接关闭页面还是进入二次确认？等等
第一二种情况都很可能针对无关紧要的逻辑细节WHAT造成了交付业务价值WHY的延迟和成本的浪费，第三种情况呢？可能更糟！原因有：
需求变更 – 随着产品负责人对待明确需求模块的确认，已开发的需求模块细节要发生变化，比如“分享模块”暂时不用支持QQ，“邀请记录查询”模块就不需要渠道信息了，关于渠道打标透传的功能和数据库结构都要发生变化。
牵制上线 – 比如，技术团队和产品负责人在加班加点的努力下终于完成了除了“红包规则”的所有模块，可是用户抢红包的金额没有确认和实现需求文档格式，请问整条业务链路怎么跑通呢？
质量失衡 – 和2类似，研发和测试人员充分利用的工作时间，对已明确的模块反复验证确保了质量，而最后赶工做好的“红包规则”却没有时间测试了，那么上线后带来的风险是巨大的。
更不用说项目管控了 – 基于WHAT拆分的研发任务HOW，就算管控的再好，对业务价值的实现并没有太大帮助。
因此，这种基于WHAT面向实施的模块化需求文档，对交付进度紧张的需求渐进明细的场景（也是大多数的场景）是非常不适用的。
2 变更频繁
有别于瀑布类项目，敏捷项目的需求文档往往没有条件去非常明晰和稳定，但是，相比于涉及众多细节的产品需求，业务需要往往是更加稳定的，也就是说，频繁变更的一般是产品需求而非业务需要。
通俗来说，我想找女朋友的初心并没有改变，只是我发现比起弹弹吉他，去隔壁交大球场很酷地打篮球更能赢得女孩子的青睐。
面向产品需求文档WHAT的实施，必然会受到很多变更的影响（除了文档因素，还有PBI管理水平，产品掌控能力，业务清晰程度，技术复杂度等众多因素，不展开讨论）如果团队能聚焦WHY或者说业务价值展开讨论，那么需求的优先级及其明晰程度必然会比传统产品需求引入更少的变更。
怎么做？
需求的格式
敏捷的需求是以用户故事的形式呈现，格式为作为我想要以便，可以看到这样的需求格式将WHO,WHY和WHAT紧密的结合在了一起，而且这样的需求是线性的，是能实现完整的业务链路并且可以独立交付的(感兴趣的同学可以自行学习下INVEST原则）
还是上述的例子，我们可以这样写，比如“作为老用户，我想要登录APP在首页轻松找到活动区域点击进入活动页，以便抢红包”，“作为新用户，我想要通过微信或QQ消息打开朋友转发我的红包助力邀请，输入手机号注册以便轻松成为会员并获得礼券”，“作为运维人员，我想要在运维平台红包规则模块设置和调整规则，以便控制红包金额平衡收支” 等等。
而当技术团队看到这样的需求的时候，考虑的是“轻松找到”到底是怎样才是轻松？活动栏位更明显还是有一个弹窗更好？我是用户的话抢红包后转发好友怎样才最便捷？活动规则要怎么告诉我我才会愿意转发好友？QQ现在使用率是怎样？ 团队是围绕WHY或者说业务价值渐进明细需求，一方面这样明晰的需求会更加稳定变更更少，一方面团队也深刻的理解我到底要实现和交付怎样的产品，至于“助力查询”里的“助力时间”字段要不要精确到秒相信不会是第一考虑的问题也不会是优先阻碍团队研发的问题，也不会成为这条需求的验收标准Acceptance Criteria.
有人会说，这样的需求文档岂不是内容太单薄了？很多逻辑细节描述都没有，怎么研发呢？
需求的原则
用户故事有个3C原则：
Card-需求文档无需详细记录所有细节但是必需明确WHY,WHAT和WHO；
Conversation-需求渐进明细的过程不是产品负责人闭门造车而是和团队沟通讨论的结果；
Confirmation-最重要的可以决定是否可以满足价值的内容需要明确。
如果按照传统的瀑布式思维，产品文档作为研发设计活动的输入，团队在看到产品文档的时候才开始思考实施，的却需要产品文档的细节描述，而当敏捷团队角色左移覆盖需求(PBI Grooming）就用户故事展开思考和讨论后，那么很多描述文字是无须赘述的，需要文字记录下来的需求文档格式，势必是最重要的需要所有人达成共识的内容，也就是验收标准。
验收标准
验收标准的内容和测试用例非常相像，验收标准的格式为：在，当，那么，可以看到这比用户故事/需求更加的详细，它反映了需求全部范围的最小最重要的集合，比如，对用户故事”作为新用户，我想要通过微信或QQ消息打开朋友转发我的红包助力邀请，输入手机号注册以便轻松成为会员并获得礼券” ，验收标准可以是 “在我收到红包助力邀请的微信信息，当我点击微信消息里的红包助力邀请时，那么打开一个H5页面(见原型图）”，“在我没有输入手机号，当我点击“助力”，那么弹窗提示-请输入手机号助力”，“在我输入了手机号，当我点击”助力“，那么验证码框激活，我会收到一条验证码消息”等等。
总结
既然对流程(瀑布到敏捷）对角色（分工到融合）都进行了转型，那么做为信息的载体-文档，也需相应转型；对于需求文档而言，比起传统的WHY到WHAT的分解活动和文档记录，我们更推荐用户故事的形式将WHY和WHAT融合，以便技术团队更针对需求价值WHY的雕琢，以实现需求价值的聚焦，避免面向工程的需求引起的投入失焦，经常性变动和交付阻碍；通过3C原则对需求进行梳理(grooming)将需求渐进明细，并最终反应最核心的明细到可以成为测试用例的验收标准，以实现需求文档的敏捷。
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： muyang-0410
