Mike Burrows写道:
我突然想到，我们经常把较大的功能展开（分解）成规模较小的功能，但事后我们往往不会再把它们折叠回去。 这种做法：
- 常见吗？
- 好吗？（我能想到一些好的理由）
- 不好吗？（同样的，我能想到一些不好的理由）
- 视情况而定？（在哪些情况下好，哪些情况下不好？）
Kanbandev 讨论组里的一些人认为，将较小的功能折叠回较大的功能并不能增添多少价值。Kurt Häusler说道：
我不喜欢展开和折叠。我的确喜欢将较大的需求展开成许多小的故事，就在刚开始的时候，甚至是在那些需求进入系统前，并且在整个过程中让它们保持较小的规模。我想有时候这可能是做不到的，但是我想，相比简单地利用较大的最小化市场功能（Minimum Market Features）或者微型项目，坚持那么做会更好，因为降低交易成本是很难的，因为客户无法测试“未完成的”功能，因为人们思考问题的时候总是会把问题“想得太大又复杂”。 对功能进行简单轻薄的垂直切分，贯穿整个价值流，就一定会成功（For The Win）。
Ron Jeffries认为：
极限编程过去常常建议大家把故事分解成任务。我们中有很多人不再推荐大家那么做：我们建议大家将它们切割成更小的故事。 在极限编程中，没有明确的“折叠”概念，因为没必要那么做。
Siddharta Govindaraj认为折叠有一些价值，但是：
如果这种观点只是围绕开发团队，那么这能行。你切分好故事并一个个展开它们，没有必要折叠。但是，在开发团队以外，许多端对端的流确实是操作大功能的。所以，尽管你在开发团队中使用的可能是较小的故事，当较大的功能要移动到下一个阶段时，仍然有必要将它们折叠回去。
Ron Jeffries回复道：
为什么你会有下一个阶段的想法？举例来说，在 Scrum 和 XP 中，每个迭代团队都会生产可交付的软件增量（包括所有必要的文档）。 从 kanban 的观点来看，我们只对需要的东西进行建模。但如果它是一个很大的展开或折叠，那么几乎可以确定，这种建模意味着浪费、缓冲和延期，可以移除掉。
Paul Beckford说道：
这里的关键部分是较小的增量、反馈和迭代。当你这样做时，那么折叠这种想法，在最小的增量中就是没有意义的（比如，一个切分，对我而言可能是一组小的验收条件，只需要半天时间），而在其他任何级别的抽象上也都是没有意义的。
查看英文原文： The Value of Collapse?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论