No estimation?

[Bob Jiang (Gmail)]

Hi all,

  近日Ron Jefferies发表了一篇博文，是有关估算的。

估算是否还需要，欢迎大家一起探讨哈。

http://www.mountaingoatsoftware.com/blog/thoughts-on-estimation

Best Regards
姜信宝

13910939018

Bob Jiang博客 | 《Scrum精髓》 | Agile Coach | 敏捷教练 | CSP | CSM | PMP | Agile1001联合发起人

====================================================

Changing Myself, Changing the World!

====================================================

[张克强]

估算如果与承诺捆绑在一起，并且这种承诺是难以变更的话，那么这种估算是很有可能成为一种敏捷“毒药”的 --- 诱使或者迫使团队超时工作

但是，以往的某些Scrum传播中，故意的强化估算和承诺，使得经理们、老板们很是喜欢Scrum，大大得促进了Scrum的传播。

Scrum两位创始人并不赞成，在ScrumGuide中，没有使用“承诺”这个词，反而说明估算是种预测，预测也意味着可能不准。

有人说，反正都是加班，搞这样的Scrum也是加班，无所谓了！不必纠结估算与承诺了。反正，加班也是完不成的，老板也没啥话说了。

大过年的，还在扯这些，大家权当娱乐啊！

--
您收到此邮件是因为您订阅了Google网上论坛上的“agileshanghai”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agileshangha...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

张克强 | Mike Zhang

blog: 从高效过程到卓越结果

weibo: 张克强-敏捷307 

[Joseph Yao]

大家新年好。趁着串门的间隙，我也来抒发一下我对“估算”的看法吧。和 Ron 的想法类似，我现在觉得“估算”的价值越来越低，有时甚至是对团队是有害的（如克强下面描述的情况）。

为什么说估算的价值越来越低呢？我觉得主要是由很多开发中的不确定性导致的，而这些不确定性是很难通过估算活动来解决甚至发现的。以做一个需求（用户故事）为例，这样的不确定性可能包括：

• 如果团队做实例化需求的实践，并且将那些实例变成自动化测试来驱动开发的话（ATDD），你可能会在写自动化测试时发现很多需要解决的问题，比如如何来模拟一个依赖组件或者如何做端到端的验证。而这些问题通常是很难通过估算活动发现的，只有自动化测试写到那里了才会知道。一旦遇到这样的问题，原来估计的工作量就都是浮云了。
• 如果团队写单元测试和做测试驱动开发（TDD），并且是在遗留代码的基础上做这些事情的话，那么第一件事通常就是给遗留代码加上单元测试（需要隔离依赖）。然而，隔离依赖和写单元测试本身是很难估算工作量的，因为在你接触到遗留代码之前，根本不知道代码是什么样的，也不知道隔离依赖要花多少时间。另外，加上单元测试之后还要对遗留代码做重构，这重构的工作量也是事先无法预见到的。
• 如果团队同时做上面两个实践的话，说实话你很难估计出 ATDD 和 TDD 各需要多少工作量，因为这两件事情通常是并行发生的，是你中有我，我中有你的过程。因此，也很难通过估算知道做这两个实践一共要多少工作量的。
• 如果团队按照上面的方式工作，除了估算，拆分任务的可行性也很低。因为，设计，编码，自动化测试这些工作都是并行发生且不断浮现的。
• 其实，修 bug 和上面做需求的过程很类似。一个不同点是修 bug 需要先定位问题在哪里，而这件事是修 bug 中最难以估算的部分了，你怎么可能在接触这个 bug 之前就知道问题出在哪里呢？
• 当然，你可能会说“我们团队根本就不会做 ATDD 和 TDD，自动化测试也没有，这样做估算也不行吗？”。如果是这样的情况，我猜这样的团队做估算的结果可能还挺不错的。只不过，团队把很多工作（比如测试或者自动化测试）留到了产品发布前，而那些工作本身是难以估算的（关键是不知道会有多少 bug 产生）。

那么，如果估算价值低不做的话，我们还可以做些什么呢？在我看来，完全可以做一些其他事情来达到“估算”本来想达到的目的，比如：

• 首先，没有估算不意味着团队无法知道自己可以在一个迭代里面交付多少。最简单的方式就是算一下团队可以完成的工作（比如需求和修 bug，Scrum中叫 product backlog item）的个数。如果每个工作大小差不多，团队是很容易知道自己一个迭代可以做几个的。即使大小不同，团队也可以在迭代开始时按照顺序一个个的领，直到觉得无法承受为止。
• 没有估算不意味着团队一股脑就开始做了。像Planning Poker 这样的估算活动的关键是让团队充分讨论做需求可能遇到的风险，外部依赖和前提假设。这些讨论还是很重要的，Planning时有必要做一下。
• 没有估算不意味着对需求不进行拆分，细化和协作。通过实例化需求这样的方法，可以找到需求的关键点，从而有效的进行需求的分解和澄清。这里就不展开更多了。
• 没有了估算，做需求或者修 bug 时关键就是按照 timebox 的方式来做。比如，按照团队拥有的迭代总时间量可以算出每个故事可以分配到的时间，也就是说每个故事都需要在这个 timebox 里面完成。以给遗留代码加单元测试为例，做的时候想好打算最多花多少时间来隔离依赖并写单元测试。如果隔离依赖花了太多时间，那就少写几个单元测试吧（反正总比没写强，以后有机会再补就是了）。又或者做一个需求的总时间已经到或者超过 timebox 了，那么团队就应该考虑一下是否要做完这个需求，而放弃其他的需求。

说到底，我觉得迭代开发的一个精髓在于通过 timebox 来把复杂（Complex）的事情降解到繁杂（Complicated）的事情。团队要决定的是如何在有限的 timebox 里面产生最大的价值，而不是按部就班的去完成每一个任务（即使那个任务是很重要的）。Scrum 作为一种迭代和增量的开发框架，他的所有活动（如 Sprint Planning）都是 timebox 的，使用 Scrum 的团队把工作都 timebox 化其实是很自然的一件事。

最后，祝大家可以在新的一年里少做一些低价值的事情（如估算），多做交付一些价值，多拿红包。最后的最后，希望大家给出你的看法和反馈。:)

谢谢，

Joseph

-- 
-- 
您收到此信息是由于您订阅了 Google 论坛“Scrum Gathering”论坛。
要在此论坛发帖，请发电子邮件到 scrumga...@googlegroups.com
要退订此论坛，请发邮件至 scrumgatherin...@googlegroups.com
更多选项，请通过 http://groups.google.com/group/scrumgathering?hl=en 访
问该论坛
网站: http://scrumgathering.cn
微博: http://weibo.com/scrumgathering

--- 
You received this message because you are subscribed to the Google Groups "Scrum Gathering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumgatherin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[wangyu]

我的思路是估算要有，但别太认真就得了。


send from small device

[Joseph Yao]

那么”要估算，但别太认真"的理由是？:)

More AHAs at AHA Conference

[Bob Jiang (Gmail)]

其实大家看Ron的意思，就是估算是为了增加对需求的认识，而不能作为承诺。

比如估算的时候使用计划扑克。

而一旦估算当做承诺，那后果很严重。

Best Regards
姜信宝

13910939018

Bob Jiang博客 | 《Scrum精髓》 | Agile Coach | 敏捷教练 | CSP | CSM | PMP | Agile1001联合发起人

====================================================

Changing Myself, Changing the World!

====================================================

[wangyu]

你绕一圈子也会回到这里，为什么不享受在这里的状态呢？就如同小学语文的教材中作者隐含的含义一样，你更明白还是更糊涂了呢？关键是用这种东西在自己写文章的时候加以利用，并用到妙处。

敏捷的若干方式如果都变成“真理”的话，那还是“敏捷”吗？

不同团队，不同成熟度，不同背景，不同的成员的关系。不同项目可能都不一样。我带的某些团队，就得仔仔细细的估算。有的团队我直接帮他们就估算了。有的直接分分钟出数。有的就不估算。

我很难总结，道理也不想讲，讲的也不一定对。

别太较真就行，过程和方法仅仅是过程和方法。代码仅仅是代码。潮流仅仅是潮流。

回到场景之下，回到人与人之间的关系之下。no estimation 仅仅是应对部分场景和对部分误用的强调而已。

对了谁帮我退一下这个群，我已经退得就差这个了。还是需要自己设置？我再看看的。

祝大家新年快乐，万事如意。少折腾些理论，多做点产品。我妈总说我和骗子差不多，谨记谨记。

send from small device

在 2015年2月20日，上午10:48，Joseph Yao <joseph.ya...@gmail.com> 写道：

那么”要估算，但别太认真"的理由是？:)

More AHAs at AHA Conference

<unknown.png>

[wangyu]

对于一些无组织无纪律的团队，就得逼他们做出承诺。完不成任务直接吊起来打。

send from small device

[皮宇]

搞不好是被需求变更、技术方案变更或者XXXX原因delay闹的把。

不过那还是说明之前估算不认真，没有充分考虑过上述风险。

--
--
敏捷中国 http://www.agilechina.net 邮件列表
如果想发起讨论，请发送邮件到 agile...@googlegroups.com
如欲退订请发送邮件到 agilechina-...@googlegroups.com
更多选项，请访问 http://groups.google.com/group/agilechina
---
您收到此邮件是因为您订阅了Google网上论坛上的“敏捷中国”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agilechina+...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Eric Liao]

估算是为了啥？先想清楚

然后才是要不要做，做多少，如何做

发自我的iPhone

------------------ Original ------------------

From: 皮宇 <ds3...@gmail.com>

Date: 周六,2月 21,2015 10:39 上午

To: agilechina <agile...@googlegroups.com>

Cc: agiles...@googlegroups.com <agiles...@googlegroups.com>, scrumgathering <scrumga...@googlegroups.com>

Subject: Re: [agilechina] Re: No estimation?

[Joseph Yao]

下面有些回复已经和“估算”无关，纯属有感而发。

On Feb 20, 2015, at 10:55 PM, wangyu <niu...@gmail.com> wrote:

你绕一圈子也会回到这里，为什么不享受在这里的状态呢？就如同小学语文的教材中作者隐含的含义一样，你更明白还是更糊涂了呢？关键是用这种东西在自己写文章的时候加以利用，并用到妙处。

说的好抽象啊，恕我的理解力不够了，看完我显然是更糊涂了。我之前的回复和问题，只是想把对“估算”的一些“具体化”的理解说出来，大家交流讨论一下，自己也好有个获得反馈和学习的机会。

我以前其实挺反感用文字的方式来讨论和交流的（如邮件组，微博和微信），后来我渐渐发现根本不是“文字讨论”的问题，原因是很多人讨论时都会给出抽象或者笼统的描述，所以其实大家说的根本就不是一回事。比如，之前别人转发给我有关“代码评审”和“TDD”的讨论，在我看来参与讨论的人对“代码评审”和“TDD”的理解貌似都不一致，大家讨（Hu）论（Ma）的倒是乐此不彼。这种基于抽象概念没有具体例子的讨论一点意义都没有，而热衷于这种讨论的人我管他们叫“喷子”。

但我也发现“文字”讨论可以通过具体的例子来达到更好的交流效果，至少在 agileshanghai 之前很多有关代码的讨论里面是这样的，我也从那些交流中收获不少。“实例化需求”这个方法可能很多人都知道，我觉得“实例化讨论”一样有帮助，至少比空对空互喷来的强多了。

敏捷的若干方式如果都变成“真理”的话，那还是“敏捷”吗？

我不觉得我之前说的那些有哪一条是“真理”，至少我不是来这里说什么“真理”的，我是来分享，交流和学习的。看到的人有反馈最好，愿意去试试看也行，一笑置之也无所谓。

不同团队，不同成熟度，不同背景，不同的成员的关系。不同项目可能都不一样。我带的某些团队，就得仔仔细细的估算。有的团队我直接帮他们就估算了。有的直接分分钟出数。有的就不估算。

我对你这里说的不同团队都挺感兴趣的，愿意分享一些例子吗（具体为什么和怎么做的）？如果不愿分享的话，算是我少了一个学习的机会了。

其实，你说的这些团队我大体也都遇到过。仔仔细细估的团队后来也不估算了，因为他们很熟悉那些工作了，跟着感觉走就可以了。我帮他们估的团队，我现在觉得我错了，他们可以做的更好。直接估分钟和小时的团队见的多一些，大多数到后来都是和经理玩数字游戏（一个同样的任务以前要8小时，现在熟悉了其实只要4小时就可以了，但凭什么不说8小时呢？）。最后，我们自己团队开发时就不做估算的。

我很难总结，道理也不想讲，讲的也不一定对。

我倒是挺喜欢分享自己的看法和经验的（通过具体的例子），总结和回顾本身就是学习的一部分。结合实例的道理，我相信是有帮助的。我从不介意“说的是对还是错”，本来就没有绝对的对错。现在认为“对的”，方法和技术发展了，都可能变成“错的”。重要的是分享，交流，反馈和学习，对与错都是浮云。扯远一点，据说 Ron Jefferies 以前一直很推崇估算，但是这几年不是照样站出来反驳自己以前的说法吗？

别太较真就行，过程和方法仅仅是过程和方法。代码仅仅是代码。潮流仅仅是潮流。

这句还是挺抽象的，我理解不了。看来我永远成不了那种用一句抽象笼统的话让人“大彻大悟”的大师啊。（这种人机场书店里面有不少的）

回到场景之下，回到人与人之间的关系之下。no estimation 仅仅是应对部分场景和对部分误用的强调而已。

no estimation 本来应该就是对“部分”场景才适用的。我抛出自己看法和问题的目的之一，就是想看看大家觉得哪些场景中 estimation 还是适用的。

对了谁帮我退一下这个群，我已经退得就差这个了。还是需要自己设置？我再看看的。

这邮件里面有三个群，不知道你想退哪一个？如果是 agileshanghai 的话，我倒是可以帮忙。不过，我觉得不管是哪个群都可以自己退了，应该在 groups.google.com 上面可以做的。

祝大家新年快乐，万事如意。少折腾些理论，多做点产品。我妈总说我和骗子差不多，谨记谨记。

也祝你新年快乐，万事如意。我觉得自己做产品和总结反思“理论”并分享出来都是需要的，这样得到学习会更多。如果一直说一些抽象，笼统，模棱两可，”It depends”之类的话，不能真正“帮助”团队成长，那么得不到团队信任甚至被当成“骗子”都是有可能的。我一直努力学习，至少不能让自己成为这样的“骗子”。

最后吐槽一下，尼玛写的累死了，真的不如白天写代码来得爽（不过也证明晚上回这邮件是明智的）。虽然想尽量用例子说话，但估计还是写了一些抽象的东西，请大家见谅，睡觉去了。

[wangyu]

团队确实需要具体的指导和原则的指引，我以为这里可以说一些不同的东西才说这些呢。

我始终认为分享无可厚非，我也很喜欢分享。但我越来越感觉我们不缺少理论，真的不缺少。缺少的是真正用理论而获得的胜利。

那就看看谁的产品能出来呗，我喜欢跟别人比一比。用乔老师的话目标是“日活百万”。骗子们。

一个组织有两种方法获得持续的生命力，第一是弱化自己的边界，第二是引入疯子。我希望我是疯子

再见各位

send from small device