文章

巧妙使用“故事点”进行敏捷估计

/分类： /编辑：

克强在“敏捷中国”讨论组中引发对敏捷的估计的讨论（“Scrum sprint plan中规模估算的做法调查”，“关于story point的单位”）。我想分享一下我自己对敏捷估计方法的理解以及对于“故事点”的认识。

在敏捷开发中，团队通过两种方法对迭代做计划。

Read more →

scrumcn_time

理想时间与消耗时间

/分类： /编辑：

一场美式足球赛是多长时间？你可能会说它有四个15分钟长的小节所以总共是60分钟长。或者你会说大约在三个小时左右。

这两种答案都有自己的正确性。它们之间的区别显示了理想时间与消耗时间之间的差异性。理想时间就是当筛除所有周边活动后做一件事情所需要的时间。而消耗时间则是在时钟（或者是日历）上过去的时间。一场足球赛需要大约三个小时的消耗时间。 Read more →

应该为bug修复的故事安排故事点吗

/分类： /编辑：

在把一个产品从传统方法向敏捷方法的迁移过程中，团队通常带着一大堆bug前行。这通常是缺泛持续的高质量要求的自然结果。导入敏捷后不用多久，很多团队（及他们的产品负责人）会决定激进去清除这些Bug的backlog。 通常的做这件事的方法都是在每个Sprint中计划修复掉X个bug，或者是每个Sprint中计划花Y小时用在修复bug上。有时团队会为这样的活动写一个用户故事如“作为一个用户，我希望至少有15个bug被修复”或者“作为一个用户，我希望你这个Sprint中花大约50个小时去修复bug，使得应用系统逐渐的变得质量更高”。即使团队并没有明确的写一个这样的用户故事，他们也通常会在他们的任务板中加这么一行，以便于bug修复的工作是可见并且可以跟踪的。 Read more →

敏捷估算-区分估算和承诺

/分类： /编辑：

在许多企业中，把估算和承诺等价看待是普遍现象。开发团队（无论是否是敏捷团队）根据可用的资源和期望交付的功能，做了一个估算，估算得出需要花费7个月。团队向他们的管理者提供了这个估算，管理者又将这些估算传递给他们的副总，副总又将这些告诉客户。在一些情况下，估算在这个过程中被削减了，留给团队的是一个“拔高了的目标”。这里的问题不在于团队的7个月的估算是对还是错。问题的关键是估算被转变成了承诺。 “我们估计这将需要7个月”被转变成了“我们承诺在7个月完成”。估算与承诺都很重要，但它们应该被视为不同的活动。 Read more →

为大数值辩护

/分类： /编辑：

很多人为我允许（甚至是鼓励）大家将用户故事估算成20，40和100这样的大数值感到惊讶。我们在我们举行的会议以及课程中出售和赠送的计划扑克牌中也把这些大数值的卡片包含进去了。然而，很多人告诉我，他们一个开始就将这些20，40和100的点数卡片抽出然后再也不用了。
Read more →

在合适的时间点进行估算

/分类： /编辑：

虽然产品Backlog的估算很重要，但是并不是所有的团队都需要做估算。那些做估算的团队更需要了解的是为什么要做估算，而不仅仅是如何去做估算。我们估算产品Backlog主要有两个原因：

首先，估算产品backlog条目帮助PO对产品backlog进行排序。 Read more →