文章

产品负责人的职责

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

产品负责人不是代理

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

可持续的节奏:相信你的团队

无止境的商业需求,特性需求,市场压力,总是有更多的工作要完成。有时候,你会感觉无止境的sprint就像你觉得你每次快到终点的时候,总有人告诉你还有一圈。你鼓足了劲继续前行,但是当你转过最后一个弯道准备冲线的时候,你听见场外有人在喊“还有一圈,还有一圈”,然后你试图再次给自己鼓劲但是你已经筋疲力尽。你一直在想你会有机会休息的,但是你从来没有等到那一天。一个接一个的sprint就像一圈又一圈的赛跑,你永远都看不到终点。你需要调整你的呼吸,需要补充水分,你已经慢慢开始体力透支,直到最后精疲力竭。
Read more

是有序!不是按优先级排序!

scrumcn1314947432

在过去,Scrum指南里面通常使用优先级来描述产品待办列表,或者写明产品待办列表是根据优先级来排序的。当产品待办列表必须是有序的时候,优先级排序是仅有而且难得的好办法。但最近,新的Scrum指南里面使用了有序(ordered)这个术语,而不是按优先级排序(prioritized)。这反映了很多在Scrum社区中的领导者长期以来的理解。让我们来看看改变的原因。

按优先级排序就是说根据各个项互相之间的重要程度之间的差异来进行排序。其中优先级驱动着两个在列表中的项目的比较。这很容易让人想起使用冒泡排序来进行对产品待办列表的排序:比较最顶端的两项,如果它们的顺序就是错的就交换它们,然后对接下来两项进行比较,然后重复这种操作直到所有项都到达了正确的位置上。排列优先级和排序之间的关系十分紧密。

在给产品代表列表排序时,Scrum团队和Product Owner会按照最大化投资回报率或者价值的目标进行排序。然而,很多人普遍认为投资回报率就是优先级。其实,投资回报率是对待办列表的长期投入和产出的结果,而并非简单地将待办列表中的各项的投资回报率相加。在某种程度上这是正确的,因为待办列表中的一项的投资回报率取决于其在待办列表中的位置。例如,假设有一个用户故事是要在网站的首页上显示一个会跳舞的圣诞老人。这个用户故事能够在十一月底到十二月期间带来一定的回报,但是如果是在七月或者是一月,回报就会大大减少了。当你改变用户故事在待办列表中的位置的时候,实际上你已经改变了它的投资回报率了,因为由于它的位置的改变,其发布的日期也会有所变化。

因此,产品待办列表必须要排序,顺序决定了产品待办列表中的项目的交付次序。团队可以就待办列表中的顺序和Product Owner进行讨论,但是当团队从中拿出用户故事的时候,必须先从最顶端的开始拿。其实,产品待办列表并不能保证其反映的一定就是其中各项的价值或者优先级。你不能因为某一项的投资回报率或者商业价值就直接给定其优先级,你必须要通盘地考虑待办列表中的所有项,才能够使得最终的投资回报率最大。

比如说,你要在热带里建一座房子,你要考虑到每天午后的大雨。你能够预见到一座房子必须有墙、窗户和门,但是屋顶才是你最关心的问题。然后,假如你要给你建造的房子建立一个产品待办列表,这时候很显然屋顶是最需要考虑到的,但是你真的会把建造屋顶放在第一位吗?这个就是要对代表列表进行排序来最大化长期投资回报率的时候了。这个过程需要对产品待办列表中的商业、市场以及工程学依赖关系都有清晰深刻的了解。这很明显是一个比单纯的冒泡排序要复杂得多的过程。

使用“排序”而非“排列优先级”就是为了要让Product Owner知道,他们必须要对用户故事的顺序做决定,而不是只是简单的说“这五个用户故事优先级是1,那三个优先级是2”。
Product Owner必须交付一个已经完成排序的产品待办列表。

当然,你完全可以使用优先级来作为排序的依据,因为“排列优先级”也是其中一种排序的方法。使用“优先级”来排序有可能会导致投资回报率的降低。Jeff Sutherland经常说,如果你的产品待办列表的顺序足够好的话,你甚至可以让你的投资回报率翻倍。当然,有些例外的情况,例如有时候你的团队需要给一些客户做一些固定成本的项目(详情请查阅Change for Free 和 Money for Nothing),这些只是一些特殊的情况,并不是对所有团队和公司都适用。Scrum指南也不提倡这种做法。总而言之,你不应该使用优先级来进行排序。

作者:James O. Coplien

原文地址:http://www.scrumalliance.org/articles/367-its-ordered–not-prioritized

对非功能性需求的估算

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

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

(在这里顺带说一句,如果你对如何用用户故事的形式表达非功能性需求的话可以看这里: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

scrumcn602120522

在Sprint中间改变目标

我曾经应聘过一个SCRUM Master的职位,面试官问我这样一个问题:“在一个Sprint进行中,如果用户想改变某个正在这个Sprint中实现的User Story,你觉得应不应该改变它?”SCRUM的规定在我脑海中明明白白的印着:“在Sprint里不许改变任何任务,团队在第一天承诺一系列工作,然后期望它们在整个Sprint保持不变。” Read more

杂谈Barry Boehm的软件工程七原则与敏捷实践

大概在5年以前曾经从网上搜到了Barry Boehm提出的软件工程的七原则(Seven Basic Principles of Software Engineering), 这是Barry Boehm1983年发表的文章,在网上搜到的是别人对这七个原则的转译与介绍,看后觉得怪怪的,总是觉得有些地方不能准确把握这七个原则的含义。于是去 google搜其原文,未果,最近终于搜到了原文,因此更能准确把握Barry Boehm老先生的原意。 Read more

Mike的Scrum实施日记 – 这个故事太大了

今天是第一个Sprint计划日,早上10点,所有的人都准时来到了会议室。
“好了,大家都知道今天我们要干什么。” 我开始了会议,“请每个人拿一副估算扑克。”
每个人都从我手里拿了一幅扑克,开始在手里把玩,一个个好像都是Show Hand高手。
“请Product Owner先把她希望在这次Sprint中开发的用户故事说明一下。” 我按照会议的流程开始了第一项内容。 Read more