thought thought

速度（Velocity）不背这个锅

不管是故事点还是理想人天的估算方法，估算的都是用户故事的相对大小，跟实际完成时间没有直接关系。估算是为了更好的计划，不能把估算当做一种承诺；速度是可变化的，可以用来修正计划的误差。

问题：

• 虽然按照故事点来估算，但是每个点都跟天数对应起来，而且不是理想人天，是实际耗费人天；
• 把这种估算当做一种承诺，要求故事需要在点数对应的天数内完成；
• 用户故事的只是关注开发完成。

到底该如何估算？点数又该如何使用呢？

问题：

• 开发团队的估算不应该受到外部因素的影响；
• 虚估点导致的估算不准确失去了估算原本的价值和意义。

估算的意义是什么？什么时候需要调整点数进行重估？

问题：

• 一切围绕速度，如果比较顺利，满足了速度要求，团队可能就放松了，不一定会做更多的特性开发；如果不顺利，速度赶不上，那就可能面临着加班或者愁着怎么能给故事涨点以增加速度；
• 不再是业务价值驱动，不会正常的从价值的角度去考虑工作的优先级，速度被严重的误用。

速度有什么用？又该如何利用呢？

带着这些误解中引发的疑问，我们一起来探讨一下。

1. 基于故事点的估算

故事点是纯粹对用户故事大小的相对度量，不应该跟任何的天数或者工作量等关联。

用户故事本身的大小属性不会发生变化，基于故事点的估算不会过期，不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如，一个点数为3的用户故事，它的复杂度相对于那个点数为1的基准故事来说不会发生变化，不管谁、也不管用什么技术来开发这个用户故事。

故事点的大小是指团队所有角色工作加一起的统一估算数值，需要多个角色一起合作讨论才能得出这个估算，因此，故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意，不应该按照开发的点数、测试的点数去估算用户故事的大小，需要结合一起给出一个唯一的数值。

2. 基于理想人天的估算

理想人天的估算需要基于这样的假设：

• 所估算的故事是唯一要做的工作
• 所有需要的东西在故事开始前都会准备好
• 故事开发过程中不会被打断。

在不考虑其他因素的情况下，这种理想人天的估算是类似于故事点的估算方法，同样是一种相对大小的估算。

理想时间跟耗用时间是不同的。比如一场NBA比赛的理想时间为12分钟一小节，但是实际比赛耗用时间需要比这个时间长很多，因为中间有暂停、死球等时间。理想人天的估算是基于理想时间的，在软件开发过程中会有多个因素导致实际耗用时间跟理想时间会有很大的不同，比如开会、讨论等。

理想人天的估算方法很容易让人根据一个故事所需完成的任务多少去估算，而不是从这个故事跟其他故事的相对大小角度去考虑；不同人估算的理想人天也会有不同，导致估算可能会不太准确。这在估算的时候是需要特别注意的。

在团队不熟悉故事点估算方法的初期，理想人天的估算方法更容易开始；理想人天的估算对于团队外部人员更容易解释清楚，也更方便预测速度。

哪种方法更好

从前面的介绍可以看到，两种估算方法各有利弊，都是对于用户故事大小的相对度量，不能跟实际完成天数关联起来。通常，更推荐使用故事点的估算方法，根据团队自身情况也可以选择采用理想人天。

前面提到的误解里对于用户故事没有在预定的天数内完成考虑给故事涨点，也就是重估，这种以进度来驱动重估的做法是不对的。没有在估算天数内做完可能有两个方面的原因：1. 估算不准确，低估了；2. 被其他工作所打断，或者团队技术原因导致进度较慢...

发现估算不准确的情况可能需要调整，但不能是因为做不完赶不上进度而调整。当所有用户故事的相对大小是准确的时候，不需要重估；只有当其中一个或多个用户故事的相对大小不准确的时候，需要调整该部分用户故事的点数大小。

我们来举例解释这个问题：

1. 不需要重估的情况

假设一个团队有4个复杂度相当的用户故事，原本估算均为3，预计能够在一个迭代完成的。在第一个迭代结束后，只完成了其中的两个用户故事，也就是完成了6个点，团队感觉这两个用户故事比预估的要大，想调整为原来点数的两倍，由6变成12；由于四个用户故事的大小相当，剩下的两个用户故事也需要调整为原来的两倍，剩下的工作量也变成了12，同样的可能还需要一个迭代才能完成。这样的重估就没有意义。

因此，如果只是发现用户故事实际耗费时间比原来预测的要多，但是故事的相对大小并没有问题的时候，不需要重估，而是要去回顾和分析耗费时间长的原因，并采取相应的措施去改进。

2. 需要重估的情况

假设团队由A、B、C、D四个用户故事，刚开始给每个故事的估点均为3。在开发故事A的过程中发现A比原来估算的值要大，需要调整为5才合适，另一个类似的故事B也是一样，需要调整为5；但是C和D跟它们不一样，估算值应该是准确的，还可以保持为3。这种情况下对A和B的重估是有价值的，因为相对大小发生了变化。

速度是对团队的进度生产率的度量，可以通过计算团队在一次迭代中完成的用户故事所分配的故事点数的总和来得到。比如，完成5个3个点的用户故事，速度是15；如果完成了2个5个点的用户故事，速度是10。关于“完成”的定义不能只是到“开发完成”，而应该是“交付完成”，开发完成不能说明什么，可能后续测试还不能过关、有很多缺陷需要修复等情况。

速度可以修正计划的误差。估算把对工作量的估算和对工作时长的估算完全隔离开来，将必须完成的所有用户故事的点数总和除以迭代的速度，可以推算出迭代的次数，也就是项目持续时间。我们通过一个例子来看速度如何修正误差：

速度不会是稳定不变的。根据团队对技术和业务领域知识的熟悉程度，速度可能会增加；而随着团队人员调整，有新人加入以后，速度可能会下降。在故事点估算准确的情况下，速度正好是反映团队状态的一个参数。不应该为了保持速度的不变去调整估算的结果，而应该根据速度的变化来观察和分析团队的健康程度。

估算是为了更好的做计划，通过估算推算出的持续时间是一种可能性，而不是对交付时限的一种承诺。估算的是用户故事固有的属性，其大小不应该受到交付时长的干扰。老马在文章《WaterfallProcess》里讲到敏捷开发里的计划应该是适应性的，而预测性的、承诺性的计划不属于真正的敏捷。我们需要认真做好估算，尽量的准确，利用速度并根据团队状态和其他项目因素来适时地调整、修正计划。

适应性计划

客户都会希望更短的时间交付更多的功能，但是不要让客户只把目光关注到进度上，要引导客户更多的关注交付的业务价值。因此，在考虑任务的优先级的时候，需要以价值为导向，而不是进度为导向。比如，重构等技术改进、性能调优、生产环境的支持，这些可能比新的特性开发带来的价值更大、有着更高的优先级。

• 不管是故事点还是理想人天的估算方法，估算的都是用户故事的相对大小，跟实际完成时间没有直接关系。
• 不能因为用户故事没有在预期的时间内完成而进行重估，只有相对大小发生变化的时候需要重估。
• 估算是为了更好的计划，不能把估算当做一种承诺；速度是可变化的，可以用来修正计划的误差。
• 始终要以价值为导向，更多的关注质量而不仅仅是进度，计划应该是可适应性的。

参考文献

1. 《敏捷软件开发实践：估算与计划》，作者：Mike Cohn，译者：金明
2. 《点之殇》，作者：冉冉，https://insights.thoughtworks.cn/story-point/
3. 《WaterfallProcess》，作者：Martin Fowler，https://martinfowler.com/bliki/WaterfallProcess.html

Dreams 梦想 原诗及译文

Dreams ——By Langston Hughes

梦想—— 兰斯顿.休斯

Hold fast to dreams, 紧紧抓住梦想，

For if dreams die, 因为如果梦想逝去，

Life is a broken winged bird 生活就只是一只折翅的鸟，

That cannot fly. 再也不能飞翔。

Hold fast to dreams, 紧紧地抓住梦想，

For when dreams go, 如果梦想消失，

Life is a barren field, 生活就是一片荒芜的土地，

Frozen only with snow. 被冰雪封冻。

人教新目标八（下）Unit 1知识点——think (thought, thought)

31.think (thought, thought) 想，认为

考点一：I/We think + 宾语从句. 这个句型中宾语从句的否定要前移到主句上，叫做否定前移。

I think he is from Japan.

I don’t think he is from Japan.

考点二：I/We （don’t） think + 宾语从句. 这个句型的反意疑问句，变化根据从句来变，肯定、否定要根据主句来判断。

I think he is from Japan, isn’t he?

I don’t think he is from Japan, is he?

考点三：think about, think of, think over

（1）think about和think of这两个短语表示“考虑”、“对……有某种看法”时，可以互换。例如：

Don't think of（about）me any more．不要再考虑我。  

They're thinking about（of）buying a new car．他们正在考虑买一辆新车。

What do you think of（about）the film？你认为那部影片怎么样？  

（2）think of表示下列意义时，一般不和think about换用：  

①想要；打算。例如：  

Helen，are you thinking of marrying Tom？海伦，你打算和汤姆结婚吗？  

②想出；想到。例如：  

Who thought of the idea？谁想出的这个主意？  

③关心；想着。例如：  

Lei Feng was always thinking of others．雷锋总是为别人着想。  

④想起；记得。例如：   I can't think of his name．我想不起他的名字。  

（3）think about表示“回想过去的事情”、“考虑某计划是否切实可行”时，一般不和think of换用。例如：  

I often thought about what you said．我常常想到你说过的话。  

I'll think about your suggestion，and give you an answer tomorrow．我要考虑一下你的建议，明天给你答复。  

（4）think over意为“仔细考虑”，后可接名词或代词作宾语。当后接代词时，应把代词放在over之前。例如：  

Think over，and you'll find a way．仔细考虑一下，你就会有办法的。  

We need several days to think this matter over．我们需要几天的时间把这件事情仔细考虑一下。

Let me think it over．让我好好想一想。

用户评论

她的风骚姿势我学不来

这听起来像个深奥的思考体验。

    有18位网友表示赞同！

颓废人士

两个“thought”，会不会有层层递进的感觉？

    有14位网友表示赞同！

断秋风

期待看到这个标题背后的意涵是什么！

    有16位网友表示赞同！

别在我面前犯贱

是不是某种哲学问题的探讨?

    有9位网友表示赞同！

你tm的滚

很有创意的标题，引发了我的好奇心。

    有6位网友表示赞同！

浮世繁华

🤔 思考之于思考，有什么特别之处吗？

    有10位网友表示赞同！

旧事酒浓

感觉像是在描述一种不断深入的思辨过程。

    有20位网友表示赞同！

泡泡龙

"thought thought" 会让人联想到无限的循环感吧。

    有20位网友表示赞同！

容纳我ii

这种重复的表达方式很有冲击力啊！

    有6位网友表示赞同！

凝残月

标题本身就是一道思考练习了，很有意思。

    有18位网友表示赞同！

黑夜漫长

这个标题让我不由自主地开始自己思考...

    有15位网友表示赞同！

何年何念

想知道作者想通过“thought thought”表达什么?

    有12位网友表示赞同！

孤自凉丶

也许这是一个关于内心的深度探究？

    有20位网友表示赞同！

空谷幽兰

挺抽象的标题，但也能让人联想到很多不同的场景。

    有11位网友表示赞同！

蔚蓝的天空〃没有我的翅膀

"thought thought" 简直是思绪的放大镜！

    有17位网友表示赞同！

回忆未来

这个标题很有深度，值得细细品味。

    有9位网友表示赞同！

等量代换

也许是一个关于人类思考能力的探讨？

    有20位网友表示赞同！

哥帅但不是蟋蟀

タイトルから、作者の考え方がすごく興味深いと感じます。

    有13位网友表示赞同！

此刻不是了i

这篇文章可能会让我对思考这件事有更深的理解。

    有9位网友表示赞同！