折叠有价值吗?

  • Dan Puckett
  • 石永超

2011 年 3 月 15 日

话题:敏捷语言 & 开发架构文化 & 方法

Mike Burrows写道:

我突然想到,我们经常把较大的功能展开(分解)成规模较小的功能,但事后我们往往不会再把它们折叠回去。

这种做法:

  1. 常见吗?
  2. 好吗?(我能想到一些好的理由)
  3. 不好吗?(同样的,我能想到一些不好的理由)
  4. 视情况而定?(在哪些情况下好,哪些情况下不好?)

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?

敏捷语言 & 开发架构文化 & 方法