文章

产品负责人的职责

很难给出产品责任人的一个完整职责列表。这跟公司文化、个人和团队的能力、竞争对手等等上下文环境相关。这种上下文环境极大地影响着产品责任人在不同的公司如何开展起工作。因此我不会试图提供一份产品责任人的职责检查列表(“比如必须参加sprint计划会议”),而是认为更有价值的是,思考产品责任人给团队提供的两样东西:愿景和边界。
Read more

产品负责人不是代理

很多时候,产品经理们选择不去做产品负责人(PO, Product Owner)。他们谋划着由一个业务分析员或者产品分析员去“代理”产品负责人。当然,也是因为大部分关于产品负责人的书籍和培训都把他或者她当成是scrum团队的一个附属物:他们要做的只不过是写写用户故事和玩玩计划扑克,要按照INVEST原则而已。所有的这些关于产品负责人的定义都是从开发者的角度来的。
Scrum并没有定义如何使用产品backlog,或者是产品负责人应该做什么。而且,我也确实 认识有人没有用Scrum却在很好的写着用户故事来优化他们的产品管理工作。他们成为了很好的业务分析员,或者需求工程师。
将产品负责人的职责授权出去会进一步增加开发团队与客户之间的距离。我对Scrum Master的期望是他们能缩短这个距离。Scrum Master可以去教会业务如何行使PO的角色来做到敏捷。Scrum Master能帮助PO去理解如何抓住机会,去优化价值,如何与团队合作。在我看来,PO无论如何也不会因为要去做需求开发而变成业务分析员。
Read more

对非功能性需求的估算

几个星期前,我曾经答应某人在博客上发表关于估算非功能性需求的独特挑战的文章。

首先,我们应该知道所谓非功能性需求是指对整个系统状态的一种需求,而不是系统的某个特定功能。非功能性需求通常包括性能,准确性,可维护性,互通性以及便携性等等。

(在这里顺带说一句,如果你对如何用用户故事的形式表达非功能性需求的话可以看这里:http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories。)

估算非功能性需求的挑战是它包含两项成本。第一个是初始维护成本。第二个是持续维护成本。

让我们来看看下面这个例子来说明这两个成本。假设一个团队正在开发一个新产品,而且对该产品有性能方面的需求。在第一个Sprint中,团队可能会考虑到性能的问题,但是由于还没有足够的代码,他们并没有办法去做性能测试。在几个Sprint以后,比如说Sprint 5,团队觉得已经有足够的代码,并且决定从这个Sprint开始做性能测试。

还记得我们提到过的初始维护成本吗?在这个例子中,就是指团队在Sprint 5开始做的性能测试的工作。虽然,性能测试比不会比大多数的其他用户故事多花很多时间。于是,团队在估算的时候给性能测试预留了几个用户故事点数或者理想人日。

接下来,我继续看这个例子。假设团队真的在Sprint 5中进行了性能测试,并且根据测试的结果进行了调优。在第六个Sprint的时候,团队还需要继续增加新功能,这就是刚刚提到的第二个成本—持续维护成本。一旦团队在项目开始中开始关注非功能性的需求(就像例子中的团队在Sprint 5中做的那样),他们就必须在项目中接下来的日子里一直维护下去。我把这项成本看作是一种税。性能测试(或者说持续维护非功能性需求)给团队带来了额外的负担(也就是税)。而且这种负担或者说税必须一直的持续下去。

有些时候,团队和Product Owner会确定每个Sprint都需要承担这种税。在这个例子中,就意味着每次他们要添加一个功能,他们都必须要给新功能甚至是整个系统做性能测试。有时候,团队和PO可能会同意每隔几个Sprint才承担一次。毕竟,有时候团队会说新加入的功能并不会给系统的性能带来什么影响,而且我们并不会在这个Sprint后发布。我们可以把每个月的进行性能测试想象成销售税或在VAT。把每隔几个月进行一次测试的想象成季度税,例如在美国的独立承包商所付的税。

我们到底应该如何估算非功能性需求呢?答案很简单,把上面提到的两项成本分开估算。像估算其他用户故事或者待办事列表项目一样估算初始维护成本。团队和Product Owner需要一起估计什么时候开始进行测试,因为在第五个Sprint开始做性能测试和在第二十开始做是不同的。然后,团队和Product Owner要协商持续维护的频率,是每个Sprint都要做还是每N个Sprint做一次?然后团队可以估算需要的工作量,然后分配相应的时间。比如说,团队和Product Owner决定每4个Sprint做一次性能测试,团队估算出每4个Sprint大概需要6个用户故事点来做性能测试。也就是说,大约每个Sprint要1.5个故事点。如果团队的速率是30的话,1.5个故事点可以看作成是5%的税。当然,对于第一次团队的估算可能不大准确。不过值得庆幸的是,团队在几个Sprint之后可以清楚的知道他们在性能测试上具体花了多少时间,然后根据统计来修改他们对持续维护成本的估算。

原文地址:http://blog.mountaingoatsoftware.com/estimating-non-functional-requirements

 

作者:Mike Cohn

经验主义—基于已知信息做决定

经验主义是一种基于已知信息做决定的一种行为。Scrum是一种以经验为依据的流程,有些时候被称作“可能的艺术”,实际上说的就是我们要利用好我们手头上掌握的所有信息尽力做到最好。

一个PO根据当前所有已知的信息进行版本发布计划。他会列出目标和特性,以及团队交付这些特性的能力,还有可能的成本和交付日期。这样看来,PO的职责就是根据团队的能力评估可能达到的目标,然后做出最好的决定以达成目标。由于技术、市场、需求以及人力等各个方面的权衡,有时候无法在合理的成本范围内达到目标;有时候虽然达成了目标,但是和PO原来的计划有所偏差。这就是经验主义的实践。

Scrum中的团队其实也在干同样的事情。团队和PO举行会议,对PO觉得接下来最重要的事情进行评估。一旦完成以后,团队就可以朝着PO希望的方向进发。团队会根据在接下来这个Sprint中他们能够完成最大工作量对产品待办列表中的条目进行挑选。由于团队的人力成本和Sprint的长度是固定的,所以唯一可变的就是从产品待办列表中选择的条目的数量。这些条目就是版本发布目标的所有条目的子集。

在Sprint计划会议中,当团队从产品待办列表中选择条目的时候,他们承诺在当前的Sprint中完成这些条目。“承诺”的定义是:通过许诺或担保的形式进行约束或担负义务;诺言;承担自己的诺言;许诺做某件事。诺言、许诺做某件事,这就符合了我对“承诺”这个词的理解。

然而,很多Scrum团队误把承诺当作成一种“保证”。这其实是从瀑布时代遗留下来的,因为那个时候估计就等于合约。直到现在,这种概念仍然残留于很多PO和开发人员的脑海里。我发现很多团队都觉得他们不惜一切也要完成他们的承诺。而通常这么做的代价会是牺牲质量。

我在想,我们是不是应该把“承诺”说成“预测”会更好一些呢?因为这可能会引导大家认为我们就是在预报天气一样,用现有已知的所有信息尽可能地做好预测。这种实践在气象学和我们所了解事物的中已经被证实可行了。因为这种实践并不保证什么,而是根据我们所了解的信息来做最好的抉择。我们发现在销售行业中,预测同样被运用。也许,这能够帮助我们说明在Scrum中,“承诺”就是利用我们现有的一切尽力做到最好。

原文地址:http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/

 

作者:Ken Schwaber

回顾白板墙

常见到人们在回顾会议中觉得无聊,或者仅提出寥寥无几的几个优缺点。我在这儿介绍一个我们团队用起来还不错的方法。这个方法并不是比别的要好或差,只是给那些想在回顾会议中尝试新方法的人提供一点建议。 Read more

意外终止一个sprint

敏捷开发讲的就是适应变化。敏捷宣言的第二条原则明确指出“欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。”这就是为什么在scrum中PO负责维护产品backlog。PO对产品backlog条目的排序有最终发言权–包括从产品backlog中挑选一组条目作为一个sprint backlog,这也是PO适应变化的一种手段。 Read more

在合适的时间点进行估算

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

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

宣布产品backlog破产

当你坐在一间教室里,正享受着敏捷培训课程(你总会不自觉地抽空查看那些不断出现的分布在众多列表中的超级紧急任务),这时你却突然听见教练嘴巴里蹦出了一些话,它听起来感觉似乎很完美同时却又那么疯狂…
这些话就是:产品backlog是一个有序列表,里面放着各种类型的待做任务(比如:特性,bug,需求调研等等)。 Read more