扫码阅读
手机扫码阅读

故事是不是拆得越细越好呢？

160 2024-01-05
故事 敏捷 拆分 用户 转型
之前我写了一篇鼓励大家拆故事的文章，凭啥总逼我拆成小故事啊？阐述了将大故事拆小的种种好处。然而当大家认识到拆故事的必要性之后，很多人似乎又走向了另外一个极端，他们把故事拆得稀碎，恨不得为界面上每个元素都开出一个故事！
那么故事是不是拆得越细越好呢？当然不是！故事颗粒度的大小都是相对的，拆到什么程度是要经团队自身的摸索验证，求得一个平衡的结果。故事拆分过细可能导致如下问题，需要引起高度重视：

01

情景化严重欠缺

如果故事拆得过细，一个简单的情景有可能被拆到多个故事当中，导致研发人员只见树木不见森林，无法体会单个故事存在的完整意义，那么在设计和开发单个故事方面就存在断章取义、与其他故事的关联性和一致性不够等问题。
结果是，表面上看起来工作都完成了，但完成的质量并不高，如果在做集成测试的时候没有能够把完整的场景逻辑仔细测一遍，那么某些关键的逻辑串联可能就会出现严重漏洞。
这不但影响用户的使用体验和数据安全，研发人员还要花费大量的时间寻找和修复Bug，并且还要从头到尾再梳理一下底层逻辑，防止以后出现更多的问题。
这些补救措施虽然能够解决问题，但它们是在问题引入之后很久才进行的，需要更多的时间来回忆、修复和验证，显然这是一种巨大的浪费，也降低了接收更多新故事的能力，降低了响应能力。

02

依赖严重

如果某些故事的各个微小组成部分关联非常紧密，也就是强耦合，那么把它们强行拆开，会导致多个小故事之间严重依赖。它们要么没法并行开发和交付，要么没法单独测试和验收，一定要等到所有相关联的故事完成之后才能够做有意义的测试。那么这种故事拆解的意义在哪里？

03

责任稀释严重

如果故事拆分得太细，做单个故事的人就只对单个故事负责，至于这个故事最终要解决一个什么问题，他就未必非常上心了。特别是如果这些小故事还分给了不同的人做，那么就进一步降低了研发人员的责任感。反正他一个人做好也没用；他一个人做不好也没那么显眼，因为大家都这样！

04

重复工作增加

修改一个故事要至少做以下工作：

  1. 找到源代码文件

  2. 打开源代码文件

  3. 找到需要修改的代码行位置

  4. 修改代码行

  5. Build

  6. 自测

  7. 签入代码库

  8. 测试人员测试

  9. 产品人员验收

显然这不是一个完整的列表，你还可以加入更多的步骤。

如果故事拆分得太细，会导致在相同代码区域来来回回进行修改，上面的步骤一遍又一遍地执行，很多步骤本可以只做一次，但现在要做很多次。

05

任务切换和衔接损失巨大

如果当前故事和之前做的某个故事有某种关联时，就需要我们再去回忆之前的那个故事，需要大量的时间，如果之前那个故事不是自己做的，消耗的时间更长，比如需要找到那个人，还需要从头理解。

06

故事估算膨胀

如果把一个简单的故事拆分成多个细碎的小故事，而且有些小故事在10分钟左右的时间就可以完成，那么大家在做估算的时候就倾向于多估一些，谁愿意让别人看到自己轻而易举就能完成工作呢？

07

拆完已经不是故事了

很多故事拆完之后，已经不能称之为故事了，我们把它们当作任务而不是故事会更加合理！
所以把场景化的故事书写完整，下面挂着一堆拆出来的任务，这样我们既能够享受细粒度拆分带来的好处，又能够享受到用户故事带来的好处。
关于用户故事，可以阅读大多数人写用户故事的时机都是错的，希望能给你一些启发。

总

结

由此我们可以看出，故事过大不好，过小也不好，要在各种利弊之间寻求一个平衡，并且这个平衡的决定要基于足够的信息，做出理智的决策。
也就是说，你要能够知晓可见和不可见的优点和缺点，知晓你可能享受到的好处和要承担的后果，然后综合考虑，得出结论。
注意：没有一种选择只有优点，没有缺点，并且因为每个人/团队所看重的东西可能不同，导致面对同样的境况，做出的选择有可能不同。无论如何，我们不能忘记故事拆分的初衷（见凭啥总逼我拆成小故事啊？）！
最后需要说明的是，故事拆分是个技术活，是有方法的，是需要学习的，不是说要求大家拆，大家自然就会拆了。
同样的故事，好的方法能够最大限度减少依赖，能够最大限度帮助获得故事拆分的好处，能够最大限度减少故事拆分带来的负面影响。典型的方法有：

  • SPIDR用户故事拆分法

  • 汉堡包用户故事拆分法

  • Humanizing Work用户故事拆分模式

具体可以在融实践库 https://www.rongpm.com/rrpl.html 的“需求->需求拆分”中找到。
关于故事拆分的权衡，你还有没有更多的见解？欢迎在评论区中分享！

最后，别忘了点赞、在看和转发哟！

推荐阅读
凭啥总逼我拆成小故事啊？
大多数人写用户故事的时机都是错的
团队级敏捷真的没你想的那么简单
天哪，你们的迭代竟然是这么玩的！
我也来聊聊传说中的敏捷和小瀑布
快速洞察敏捷研发团队状况之六脉神剑
徐东伟敏捷教练公众号
本公众号由资深企业级敏捷教练和咨询顾问徐东伟主理，聚焦敏捷转型、业务敏捷和敏捷组织。每工作日更新，转载结合原创。希望为中国的敏捷事业尽自己的微薄之力！
敏捷转型包括：敏捷转型的策略/敏捷转型的避坑方法/敏捷转型的成功案例
业务敏捷包括：团队级敏捷运作/数字产品管理/数字化转型/创新创业
敏捷组织包括：敏捷战略/精益投资组合管理/敏捷人力/敏捷财务/敏捷治理/敏捷运营/敏捷组织架构/敏捷企业架构

原文链接： http://mp.weixin.qq.com/s?__biz=MzI4NjkwNzE4MA==&mid=2247484758&idx=1&sn=582db9600eb46f088718b5cecf668341&chksm=ebd48b15dca302036e475bee0e1ca8baa5d83cc71185c05867c639dd4882420c8c6872b41c03#rd
相关推荐
聊聊用户故事的估算和拆解
87
故事 用户 估算
对于敏捷和用户故事实践的最大难点，是如何估算用户故事的大小，如何拆解大的故事？过大的用户故事会带来一系列的沟通复杂度和潜在质量风险。本文重温行业经典的估算和拆解方法，并从敏捷团队的实践角度深入思考
聊聊用户故事与测试启发
113
故事 用户 测试
用户故事的概念于1998年被正式提出，在2001年开始逐步成熟，在Scrum流程中配合使用，效果显著。我们先回顾一下用户故事最核心的知识内容，再看看有哪些测试启发
第五章 需求与用户故事
300
故事 需求 用户 Scrum
投票啦，老王要做线上直播答疑啦～
用户故事的独特价值和 INVEST特点
288
故事 用户 敏捷 需求
这一篇和大家聊聊用户故事的独特价值和INVEST特点。
用户故事的独特价值和 INVEST特点
188
故事 用户 敏捷 需求
这一篇和大家聊聊用户故事的独特价值和INVEST特点。
琴瑟和鸣--SCRUM中“讲”好用户故事
223
故事 需求 用户 讲故事
产品研发团队一开始做敏捷转型，往往先引入SCRUM框架，那么，只有SCRUM就足够了吗？答案是不足够。还需要什么？本文会与您共同探讨。
徐东伟Jack

专注于敏捷转型、业务敏捷和敏捷组织！

57 篇文章
浏览 10.1K
徐东伟Jack的其他文章
因为我看不上，所以我不要学！
谨以此文，献给我自己，鞭策我自己，同时献给所有好学的小伙伴！
如果你不知道怎么改进，就从修Bug开始吧！
有人说，我面对团队的研发现状不知从何下手，没关系，可以尝试从修bug开始！
凭啥总逼我拆成小故事啊？
逼你咋地吧，就逼你了！
原来Scrum的这几个会我都白做了
本文1778字，阅读约需2分钟。对于玩Scrum的小伙伴来说，需求梳理、迭代计划、每日站会、迭代评审和迭代回
跟我读Scrum Guide #5 Scrum为复杂问题而生
Scrum为解决复杂问题而生！
随机阅读
CMMI 2.0维持性评估13问
07-12
践行者访谈实录：你真的了解CMMI吗？
07-12
如何阅读CMMI模型的实践
07-12
CMMI 3.0的276条实践中英文对照
07-12
ChatGPT如何帮助做好质量管理工作？
08-21
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线
去下载