On Feb 19, 2015, at 10:36 PM, wangyu <niu...@gmail.com> wrote:我的思路是估算要有,但别太认真就得了。
send from small device大家新年好。趁着串门的间隙,我也来抒发一下我对“估算”的看法吧。和 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 化其实是很自然的一件事。最后,祝大家可以在新的一年里少做一些低价值的事情(如估算),多做交付一些价值,多拿红包。最后的最后,希望大家给出你的看法和反馈。:)谢谢,JosephOn Feb 17, 2015, at 9:00 AM, 张克强 <zhangk...@gmail.com> wrote:估算如果与承诺捆绑在一起,并且这种承诺是难以变更的话,那么这种估算是很有可能成为一种敏捷“毒药”的 --- 诱使或者迫使团队超时工作但是,以往的某些Scrum传播中,故意的强化估算和承诺,使得经理们、老板们很是喜欢Scrum,大大得促进了Scrum的传播。Scrum两位创始人并不赞成,在ScrumGuide中,没有使用“承诺”这个词,反而说明估算是种预测,预测也意味着可能不准。有人说,反正都是加班,搞这样的Scrum也是加班,无所谓了!不必纠结估算与承诺了。反正,加班也是完不成的,老板也没啥话说了。大过年的,还在扯这些,大家权当娱乐啊!在 2015年2月15日 下午10:33,Bob Jiang (Gmail) <jia...@gmail.com>写道:Hi all,近日Ron Jefferies发表了一篇博文,是有关估算的。估算是否还需要,欢迎大家一起探讨哈。Best Regards
姜信宝--
您收到此邮件是因为您订阅了Google网上论坛上的“agileshanghai”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到agileshangha...@googlegroups.com。
要查看更多选项,请访问https://groups.google.com/d/optout。----
--
您收到此信息是由于您订阅了 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.--
--
您收到此信息是由于您订阅了 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.
--
--
您收到此信息是由于您订阅了 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.
搞不好是被需求变更、技术方案变更或者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。
那么”要估算,但别太认真"的理由是?:)
More AHAs at AHA Conference
<unknown.png>
On Feb 20, 2015, at 10:55 PM, wangyu <niu...@gmail.com> wrote:你绕一圈子也会回到这里,为什么不享受在这里的状态呢?就如同小学语文的教材中作者隐含的含义一样,你更明白还是更糊涂了呢?关键是用这种东西在自己写文章的时候加以利用,并用到妙处。
敏捷的若干方式如果都变成“真理”的话,那还是“敏捷”吗?
不同团队,不同成熟度,不同背景,不同的成员的关系。不同项目可能都不一样。我带的某些团队,就得仔仔细细的估算。有的团队我直接帮他们就估算了。有的直接分分钟出数。有的就不估算。
我很难总结,道理也不想讲,讲的也不一定对。
别太较真就行,过程和方法仅仅是过程和方法。代码仅仅是代码。潮流仅仅是潮流。
回到场景之下,回到人与人之间的关系之下。no estimation 仅仅是应对部分场景和对部分误用的强调而已。
对了谁帮我退一下这个群,我已经退得就差这个了。还是需要自己设置?我再看看的。
祝大家新年快乐,万事如意。少折腾些理论,多做点产品。我妈总说我和骗子差不多,谨记谨记。