BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

折叠有价值吗?

| 作者 Dan Puckett 关注 1 他的粉丝 ,译者 石永超 关注 0 他的粉丝 发布于 2011年3月16日. 估计阅读时间: 3 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT