对于故事点的一些理解

在敏捷开发框架中,我们常用故事点来做估算,并用它来表示一个用户故事(User Story)所需要的工作量。有别于人天、功能点,故事点(Story Point)是一组没有单位的组合,是一种相对性的度量方式。它很抽象,也很颠覆,但它让团队实现对于完成一个任务在“难度”方面的估算。而这里指的”难度“包含了”复杂度”(Complexity),”风险”(Risk),”不确定性”(Uncertainty)和”工作量”(Effort-E)。

EPIC和Story你用得来吗?

史诗故事(Epic)和用户故事(User Story)是随着敏捷开发理念而来的两个新概念、新“物种”。它们是站在用户的立场,对产品功能的实现效果所做的描述。 既然是新的“物种”,我们就不应该用传统的理解去看待它。小说和工具书是两类完全不一样的书籍。使用和理解它们的场景是不一样的。

ScrumMaster窘境之”你只是一面镜子”

前些日子写过一篇《一面镜子的使命》。在文章里,我倡议ScrumMaster应该把自己看作平整、干净的“平面镜”。看待问题有景深,面对问题要全面。而不要去做带有主观偏见的“哈哈镜”,也不要去做违心奉承的“魔镜”。 文章反响不错,有很多人同意这个观点 。我很欣慰,也很感谢大家的支持。但我觉得有个角度还没有覆盖到。所以今天再来补充一下,貌似有点自我迭代的意思。