BUILD

You may be feeling like we've already covered a great deal of work more than one person's full time job.

你可能会觉得我们已经涵盖了大量的工作，超过了一个人全职工作的范畴。

However, this is product management and as we've discussed it's broad and multifaceted.

然而，这就是产品管理，正如我们所讨论的，它广泛而多方面。

Believe it or not we haven't yet discussed the area where most technology product managers spend the majority of their time , the build phase.

信不信由你，我们还没有讨论到大多数技术产品经理花费大部分时间的领域，即构建阶段。

So let's get started.

所以，开始吧。

Agile

Most technology product development organizations have embraced some version of agile development.

大多数技术产品开发组织都采用了敏捷开发的思路。

In agile, there is a product owner who prioritizes the work.

在敏捷开发中，有一个产品负责人负责安排这些工作。

In most product companies, product managers paly the role of product owner, though the title may vary.

大多数公司，产品经理扮演产品负责人的角色，尽管职称可能有所不同。

Henrik Knibery created an excellent animation to explain what a product owner does, which we'll take a look at now.

Henrik Kniberg创作了一段出色的动画，解释了产品负责人的工作内容，我们现在来看一下。

This is also available on Youtube, and I encourage you to share it with your team. We've included the links in the resources at the end of this coures.

这个视频也可以在YouTube上找到，我鼓励你与你的团队分享。我们已经在本课程末尾的资源中包含了链接。

Let's talk about the agile software development from the perspective of the product owner.

让我们从产品负责人的角度来谈谈敏捷软件开发。

Here is Pat, she is a product owner.

这是Pat，她是一个产品负责人。

She has a product vision that she is really passionate about.

她有着产品视角，并且非常热衷于此。

She doesn't know the details of what a product is going to do, but she knows why we building a product, and what problems it's gonna solve and for whom.

她并不知道产品的具体细节，但她知道为什么我们要构建这个产品，以及它将解决什么问题，为谁提供价值。

She talks about it all the time.

她总是不断地谈论这个愿景。

Here is the stakeholders, they're the people who are gonna use and support or anyway be affected by the system being developed.

这里是利益相关者，他们是使用、支持或以其他方式受到正在开发的产品影响的群体。

Pat's vision it that these people here will love our system and use it all the time and tell their friends about it.

Pat的愿景是这些人将会爱上我们的系统并一直使用它，并会将它推荐给他们的朋友

The stakeholder needs and Pat's ideas are expressed as user stories here.

利益相关者的需求和Pat的想法将以用户故事的形式表达出来。

For example if this was a flight booking system, people need to be able to search for a flight and maybe that would be one user story.

例如，如果这是一个航班预订系统，人们需要能够搜索航班，这可能是一个用户故事。

Both Pat and the stakeholders have lots of ideas, so Pat helps turn these into concrete user stories.

Pat和利益相关者都有很多想法，所以Pat会将这些想法转化为具体的用户故事。

Now somebody has to actually build a system.

现在需要有人来实际构建这一系统。

So here there, a small, co-located, cross-functional, self-organizing development team.

所以在这里，有一个小型的、共同定位的、跨职能的、自主的开发团队。

Since this is an agile team, they don't save up for a big bang release at the end, instead they release early and often.

由于这是一个敏捷团队，他们不会为了在最后进行一次大规模发布而积攒功能，相反，他们会尽早、频繁地发布产品。

In this case they usually release about 4 to 6 stories per week so that is their capacity.

在这种情况下，他们通常每周发布大约4到6个用户故事，所以这是他们的能力范围。

Capacity is easy to measure, just count the number of stories released per week.

能力是容易测量的，只需要计算每周发布的用户故事数量即可。

Some stories are big so they count as two, some are smaller and count as half.

一些故事可能很大，所以它们被视为两个，而一些较小的故事则被视为半个。

But all in all it adds up to 4 to 6 stories per week.

但总的来说，每周总共有4到6个故事。

Some people call these stories points, but I'm just going to call them stories per week .

有些人称之为故事点数，但我将简称为每周故事数。

In order to maintain these pace and not get bogged down by manual regression testing, the team invests heavily in automated testing and continuous integration.

为了保持这种节奏并避免被手动测试拖慢速度，团队在自动化测试和持续集成方面进行了大量投入。

So every story has at least one automated acceptance test at the feature level and most of the code has automated unit tests.

因此，每个故事至少具有一个能在功能级别进行的自动验收测试，并且大部分代码都具有自动化测试单元。

The problem is here are a bunch of stakeholders asking for all kinds stuff, and they sure aren't going to be limited to 4 to 6 ideas per week.

问题在于，因为有许多利益相关者提出了各种需求，它们的数量肯定不止每周4到6个。

They have lots of ideas and lots of wishes.

确实，利益相关者可能有很多想法和愿望。

And everytime we deliver something to them, they'll get even more ideas and ask for even more stuff.

每次我们向他们交付一些东西，他们都会产生更多的想法并要求更多的东西。

So what happens if we try to please them, try to do everything they ask for.  

那么，如果我们试图取悦他们，试图做他们要求的一切，会发生什么呢？

We'll get overflow.

我们会不堪重负。

Suppose the team starts working on 10 new stories per week, if the inputs is ten, and the output is 4 to 6.

假设团队每周开始处理10个新的故事，如果输入是10个，输出是4到6个。

The team will get overloaded, that will cause multitasking, demotivation and all kinds of bad stuff and ultimately at a lower output and lower quality.

团队会超负荷工作，这会导致多任务处理、动力下降以及其他一系列问题，最终导致产出下降和质量降低。

It's a lose-lose proposition.

这是一种双输的情况。

It's kind of like trying to shove more paper into a printer to make it print faster or shoving more cars onto an already crammed highways.

这就好像试图往打印机里塞更多纸张来加快打印速度，或者往已经拥挤不堪的高速公路上挤入更多车辆一样。

It just doesn't work, it just make things worse.

它不仅无效，还会让事情更糟。

So what we do about this.

所以当我们遇到这种情况是该做什么。

Well, the scrum and xp way of avoiding this problem is called Yesterday's Weather.

Scrum和XP（极限编程）正是用来避免这种被称为"昨天的天气"的问题的。

The team says: well, the past few weeks, we've finished 4 to 6 features per week.

团队会说："嗯，过去几周，我们每周完成了4到6个功能。"

So which 4 or 6 features shall we build this week.

那么这周我们应该构建哪4到6个功能呢？

And the product owner's job is to figure out of all possible stories in the whole universe, which 4 to 6 stories shall we deliver next.

产品负责人的工作是在所有可能的用户故事中，确定我们下一步要交付的是哪4到6个故事。

The combat way is to limit work in progress or limit WIP .

方法是限制正在进行的工作或限制在制品

Suppose the team decides that five is the optimal number of stories to be worked on simultaneously.

假设团队决定同时处理的故事数量为五个，他们认为这是最佳数量。

They've learned that, that's just enough to keep everybody busy without causing overload.

他们发现这样恰好能让每个人保持忙碌，而不会造成负荷过重。

So they decide that 5 is their wip limit.

所以他们决定将同时进行的故事数量限制为5个。

Whenever they finish one story they'll accept one new story.

每当他们完成一个故事，他们就会接受一个新的故事。

Thereby make sure that they never break the limit of 5 ongoing stories.

从而确保他们永远不会超过5个进行中的故事的限制。

Both of these approaches work fine in the sense that the team will have just enough work to do and they'll be able to work fast and effectively.

这两种方法在某种意义上都很有效，因为团队将有足够的工作量，并且能够快速高效地工作。

A side effect though is that there will be a queue forming in front of the team and that queue in scrum is called a product backlog.

然而，这样做的一个副作用是团队前面会形成一个队列，而在Scrum中，这个队列被称为产品待办列表。

The queue needs to be managed.

这个队列需要进行管理。

Suppose stakeholders keep asking for ten new stories every week, and the team deliver 4 to 6 stories every week.

假设利益相关者每周都要求提供十个新的用户故事，而团队每周只能完成4到6个用户故事。

That means the queue will just keep getting longer ang longer right .

这意味着这个队列将会越来越长

So before you know it, you have a 6 months long wish list in the backlog and growing.

所以在你察觉之前，你的产品待办列表就会变成一个持续增长的、长达6个月的愿望清单。

That means that on average every story that the team delivers is something that somebody asked for 6 months ago.

这意味着，平均而言，团队交付的每个需求都是有人在6个月前提出的。

How agile is that.

敏捷开发不能这样

So there is really only one way to stop the queue from getting out of control and that word is NO.

确实，要阻止队列失控，唯一的方法就是说“不”。

It's the most important work for product owner and Pat practices it every day in front off the mirror.

这对于产品负责人来说是最重要的工作，Pat每天都在镜子前练习这个技能。

Saying "yes" to a new feature request is easy, especially if it only means adding it to an ever-growing backlog.

是的，对新的功能请求说"是"很容易，尤其是只是将其添加到不断增长的待办列表中。

The most important job for product owner is to decide what not to build and take the consequences of that decision.

产品负责人最重要的工作之一是决定不去构建什么，并承担这一决定的后果。

And that's why it's hard of course.

这就是困难的原因

The product owner decides what goes in and what goes out.

产品负责人决定哪些项目被接纳，哪些被排除。

The product owner also decides the sequencing what do we build now and what do we build later.

产品负责人还决定了开发优先级，即现在建设什么，以及将来建设什么。

And how long does this list actually need to be.

这个列表实际上需要多长呢？

That is a hard job, so Pat doesn't do it alone, she does it in collaboration with the team and the stakeholders.

这是一项困难的工作，所以Pat并不是独自完成，她与团队和利益相关者一起合作进行决策。

To be able to prioritize, the product owner must have some ideas of the value of each story as well as the size.

为了能够进行优先排序，产品负责人必须对每个故事的价值和规模有一些见解。

Some stories are critical important another are just bonus features.

有些故事非常重要，而另一些则只是附加功能。

Some stories take just a few hours to build another take months.

有些故事只需几个小时即可完成，而其他故事可能需要数月时间。

Now guess what the correlation is between story value and story size.

现在猜猜用户故事的价值和大小之间的关联是什么。

That's right, none, bigger doesn't mean better.

没错，确实如此。用户故事的大小并不意味着它们的价值更高。

Think of any system that you've used and i bet you can think of, at least, one really simple feature that is very important that you use everyday.

想想你使用过的任何系统，我敢打赌，你至少能想到一个非常重要但非常简单的功能，你每天都在使用它。

And i bet you can think of at least one huge, complicated feature that is totally unimportant.

我敢打赌你至少能想到一个巨大而复杂的功能，但它实际上并不重要。

Value and size is what helps Pat prioritize intelligently.

价值和规模是帮助Pat进行明智的优先级排序的因素。

Like here these two stories are roughly the same size but different value, so build this one first.

就像这里，这两个故事的规模大致相同，但价值不同，首先构建这个故事。

And over here, these two stories have roughly the same value but different size, so build this one first and so on.

而在这里，这两个故事的价值大致相同，但大小不同，首先构建这个故事，依此类推。

Ok, that sounds easy enough, but wait a second.

好的，听起来很简单，但等一下。

How does she know the value of a story and how does she know the size or here is the bad news she doesn't.

她怎么知道一个故事的价值，她怎么知道大小，或者说坏消息是她不知道。

It's a guessing game, and it's a game that everyone is involved in.

这是一个猜测的游戏，而且每个人都参与其中。

Pat continuously talks to stakeholders to find out what they value, and she continuously talks to the team to find out what they think is big or small.

Pat不断与利益相关者进行交流，了解他们如何衡量产品价值；同时，她也不断与团队进行沟通，了解他们对工作量的评估，无论是大还是小。

In terms of implementation effort, these are relative guesses not absolute numbers.

在实施方面的估计是相对的猜测，而不是绝对的数字。

I don't know what this apple weights or that strawberry, but I'am pretty sure that the apple weights at least 5 times as much, and that strawberry tastes better to me at least.

我不知道这个苹果有多重或者那个草莓有多重，但是我非常确定这个苹果至少比草莓重5倍，并且对我来说草莓的味道更好。

And that's all Pat needs to know in order to prioritize the backlog, it's pretty cool that way.

是的，这就是Pat在优先处理待办事项时所需了解的全部内容，这种方式相当不错。

At the beginning of a new project, our guesses will inevitably suck.

在一个新项目的开始阶段，我们的猜测必然会出现偏差。

But that's OK, the biggest value is really in the conversations rather than in the actual numbers.

但没关系，最大的价值实际上在于对话本身，而不仅仅是具体的数字。

And every time the team delivers something to real users, we learn something and get better at guessing both value and size.

每当团队向真实的用户交付产品时，我们都会学到一些东西，并在评估价值和规模方面变得更加准确。

That's why we continuously prioritize and estimate.

这就是为什么我们持续进行优先级排序和评估的原因。

Trying to get it all right from the beginning is pretty dumb because that's when we know the least.

从一开始就试图完全正确是相当愚蠢的，因为那时我们知道的最少。

So the feedback loop is our friend.Priorization is not enough though.

所以反馈循环是我们的助手。不过，仅仅优先排序是不够的。

In order to deliver early and often, we need to break stories down into bite-sized pieces, preferably just a few days of work per story.

为了早期和频繁地交付，我们需要将故事拆分成易于处理的小块，最好每个故事只需要几天的工作量。

We want this nice funnel shape with small clear stories at the front and more vague stories at the back.

我们希望形成一个漏斗状的结构，前面是小而清晰的故事，后面是更模糊的故事。

By doing this break down in a just-in-time fashion, we can take advantage of our latest insights about the product and user needs.

通过及时进行这种分解，我们可以充分利用我们对产品和用户需求的最新见解。

All these stuff I've been talking about, estimating the value and size of stories, prioritizing, splitting all that is usually called backlog grooming.

所有我所提到的东西，估算故事的价值和大小，优先级排序，分解等，通常被称为待办需求梳理（backlog grooming）。

Pat runs a backlog grooming workshop every Wednesday from 11 to 12. One hour per week.

Pat在每周三的上午11点到12点之间组织待办事项梳理需求池。每周一小时

The whole team is usually there, and sometimes few stakeholders as well.

整个团队通常都会参加，有时候还会有一些利益相关者参与进来。

The agenda varies a bit but sometimes it focus on estimation, sometimes on splitting stories and sometimes on writing acceptance criteria for a storiy, etc.

议程是不固定的，有时会集中讨论估算，有时会讨论拆分故事，有时会讨论为故事编写验收标准等等。

So I hope you're noticing the theme here: communication, product ownership is really all about communication.

是的，你指出了一个重要的主题：沟通。产品开发实际上就是围绕沟通展开的。

When I ask experienced product owners what it takes to succeed.

每当我问那些富有经验的产品负责人：什么铸成了他们的成功

They usually emphasis passion and communication.

他们通常强调热情和沟通

So it's no coincidence that the first principle of the agile manifesto is individuals and interactions over processes and tools.

因此，敏捷开发的首要原则是个人和交互而不是流程和工具，这并非巧合。

So the product owner's job is not to spoon feed the team with stories, that's boring and ineffective.

所以产品负责人的工作不是直接把用户故事递给团队，那是无聊和无效的。

Pat instead makes sure everybody understands the vision, that the team is in direct contact with stakeholders and that there is a short feedback loop in terms of frequent deliveries to real users.

相反，Pat 让团队与利益相关者保持直接联系，并且在频繁交付给真实用户方面有一个简短的反馈循环，以保证团队每一个人都知道产品的愿景。

That way the team learns and can make daily trade-off decisions on their own.

这样，团队就可以进步并可以自己做出日常权衡决策。

So Pat can focus on the big picture.

所以Pat可以专注于大局。

Let's take a look at a few of the trade-offs that need to be made by Pat and the team.

让我们来看看Pat和团队需要做出的一些权衡。

First of all these is a trade-off between different types of value.

首先，是不同类型的价值之间的权衡。

Early on in a project, uncertainty and risk is our enemy.

在项目的早期，不确定性和风险是我们的敌人。

There's business risk, are we building the right thing?

是否存在业务风险，我们是否构建了正确的东西？

There is social risk, can these people build it?

是否存在社会风险，这些人有能力构建起来吗？

And there is technical risk, will it work on the platform that we want to run it on will it scale.

是否存在技术风险，它能否会在我们想要的平台上运行，并且可扩展。

And there is cost and schedule risk, can we finish the product in a reasonable amount of time, for a reasonable amount of money.

是否存在资金和计划风险，我们能否在合理的时间和资金范围内完成这一产品？

Knowlege can be seen as the opposite of risk, so when uncertainty is high, our focus is knowlege acquisition.

知识是风险的对立面，因此当不确定性很高时，我们的重点是获取知识。

We focus on things like user interface, prototypes and technical spikes or experiments.

我们专注于用户界面，原型和技术峰值或实验等内容。

Maybe not to exciting for their customers but still valuable because we're reducing risk.

也许不会让他们的客户感到兴奋，但仍然很有价值，因为我们正在降低风险。

From a customer value perspective, the curve looks like this in the beginning.

从客户价值的角度来看，曲线一开始是这样的。

As uncertainty is reduced, we gradually focus more and more on customer value.

随着不确定性的减少，我们会越来越关注客户价值。

We know what we're going to build and how so just do it.

我们知道我们将要构建什么以及如何构建它。

And by doing the highest value stories first, we get this nice steep value curve.

通过首先做最高价值的故事，我们得到了这个漂亮的陡峭的价值曲线。

And then gradually the value curve starts flattening out.

然后逐渐地，价值曲线开始变平。

We've built the most important stuff and now we're just adding the bonus features, the toppings on the ice cream.

我们已经构建了最重要的东西，现在我们只是添加了附加功能，如冰淇淋上的浇头。

This is a nice place to be, because at any point Pat and the team may decide to trim the tail,  to cut right here and move on to another more important project or maybe start on a whole new feature area within the same product.

此时产品到了不错的境地，因为在任何时候，Pat 和团队都可以进行收尾，在这里切入并继续另一个更重要的项目，或者可能在同一产品中开始一个全新的功能区域。

That's is business agility.

这就是业务敏捷性。

So when i talked about value here, i actually mean knowledge value plus customer value.

因此，当我在这里谈论价值时，我实际上指的是知识价值加上客户价值。

And we need to continuously find a trade-off between these two.

当然我们仍需要不断在这两者之间找到权衡。

Another trade-off is short-term versus long-term thinking.

另一个权衡是短期与长期。

What should we build next.

我们接下来要开发什么

Should we do that urgent bug fix, or build that awesome new feature that will blow the user away, or do that difficult platform upgrade that'll enable faster development in the future sometime.

我们应该做那个紧急的错误修复，或者构建那个很棒的新功能，让用户大吃一惊，或者做那个困难的平台升级，以便在未来的某个时候实现更快的开发。

We need to continuously balance between reactive work and pro-active work or fire fighting or fire prevention.

我们需要在被动工作和主动工作或消防或防火之间不断取得平衡。

And, this relates to another trade-off.

而且，这又与另一种权衡有关。

Should we focus on building the right thing or building the thing right or perhaps building it fast.

我们是应该专注于构建正确的东西还是正确地构建东西，或者快速构建。

Ideally we want all three, but it's hard to find the balance.

理想情况下，我们想要这三者，但很难找到平衡。

Suppose we are here, trying to build the perfect product with the perfect architecture.

假设我们在这里，试图用完美的架构构建完美的产品。

If we spend too much time trying to get it perfect we may miss the market window or run into cash flow problems.

如果我们花太多时间试图做到完美，我们可能会错过市场窗口或遇到现金流问题。

Or Suppose we are here, rushing to turn a prototype into a usable product, greater for the short term perhaps.

或者假设我们在这里，急于将原型变成可用的产品，也许对于短期项目是有益的。

But in a long term, we might be drowning in technical depth and our velocity will approach zero.

但从长远来看，我们可能会淹没在技术深度中，我们的速度将接近于零。

Or suppose we are here, building a beautiful cathedral in record time.

或者假设我们在这里，在创纪录的时间内建造一座美丽的大教堂。

Except that the users didn't need the cathedral, they needed a camper van.

然而用户不需要大教堂，他们需要一辆露营车。

So there is a healthy tension here between the scrum rules.

因此，Scrum规则之间存在健康的紧张关系。

Product owners tend to focus on building the right thing.

产品负责人倾向于构建正确的产品。

Development team tend to foucus on builing the thing right.

开发团队倾向于正确地构建产品

And scrum masters or agile coaches tend to focus on shortening the feedback loop.

Scrum主管或敏捷教练倾向于专注于缩短反馈循环。

Speed is actually worth emphasising because a short feedback loop will accelerate learning, so you'll more quickly learn what the right thing is and how to build the right.

速度确实值得强调，因为简短的反馈循环将加速学习进度，因此你将更快地了解什么是正确的东西以及如何正确地构建。

However all three perspectives are important, so keep trying to find the balance.

然而，所有三个观点都很重要，所以要继续努力找到平衡点

Finally there is a trade-off between new product development and old product improvement.

最后，在新产品开发和旧产品改进之间进行权衡。

Product backlog is actually a slightly confusing term because it implies that there is only one product.

产品需求列表实际上是一个有点令人困惑的术语，因为它意味着只有一个产品。

And project is a confusing term too because it implies that product development ends.

项目也是一个令人困惑的术语，因为它意味着产品开发结束。

A product is just never really finished there is always maintenance and improvements to be done.

一个产品永远不会真正完成，总有维护和改进需要做。

All the way until the product reaches enf of life and is shut down.

直到产品达到使用寿命。

So when a team starts developing a new product, what happens to their last one.

因此，当一个团队开始开发新产品时，他们的最后一个产品会发生什么。

Handing off a product from one team to another is expensive or risky.

将产品从一个团队移交给另一个团队是昂贵且有风险的。

So in more common scenario is that the team continues maintaining the old product, whild developing the new one.

因此，在更常见的情况下，团队继续维护旧产品，同时开发新产品。

So it's not like a product backlog anymore, it's more like a team backlog.

所以它不再像一个产品待办事项列表，它更像是一个团队待办事项列表。

A list of stuff that the product owner wants this team to build.

产品负责人希望团队共同构建的内容列表。

And it can be a mix of stuff from different products.

它可以是来自不同产品的需求混合。

And the product owner needs to continuously make trade-offs between these.

产品负责人需要在两者之间不断做出权衡。

Once in a while a stakeholder will call Pat and say: Hey, when will my stuff be done or how much of my stuff will be done by Christmas.

当利益相关人偶尔给 Pat 打电话问：“嘿，我的东西什么时候完成？或者到圣诞节时，我的东西完成了多少？”时。

As product owner, Pat is responsible for expectations management, or more importantly realistic expectations management.

作为产品负责人，Pat负责管理预期，或者更重要的是管理现实的预期。

And that means no lying. I know it's tough but who said agile was easy.

确实，这意味着不撒谎。我知道这很困难，但是谁说敏捷开发容易呢？

It's not really that hard to make a forecast as long as it doesn't have to be exact.

确实，做出预测并不难，只要不要求精确性。

If you measure the velocity of your team or the combined velocity of all your teams.

如果你测量团队的速度，或者所有团队的综合速度。

You can draw a story burn up chart like this.

你可以像这样绘制一个故事燃尽图。

This chart shows the cumulative number of stories delivered over time or story points if you prefer.

这张图显示了随着时间推移交付的累积用户故事数量，或者也可以是故事点。

Note the difference, this curve shows output.

请注意，这条曲线显示的是产出的情况。

That curve shows outcome.

那条曲线显示的是结果的情况。

That's the output and that's the outcome we hope it will achieve.

那是输出，那是我们希望实现的结果。

Our goal is not to produce as much outputs as possible, our goal is to reach the desired outcome.

我们的目标不是尽可能产生更多的输出，而是实现期望的结果。

Happy stakeholders using the least possible outputs, less is more.

使用尽可能少的输出让利益相关者满意，少即是多。

Now look at the burn up chart, and you can draw an optimistic and pessimistic trend line.

现在看一下燃尽图，你可以画一个乐观的和悲观的趋势线。

You can do it using fancy statistics voodoo or you can just draw it visually.

你可以使用复杂的统计学方法，也可以通过直观地绘制来完成。

And the gap between these lines is of course related to how wavy and unpredictable your velocity is.

这两条线之间的差距当然与你的速度的波动和不可预测性有关。

Luckily that tends to stabilize over time, so our cone of uncertainty should get tighter and tighter.

幸运的是，随着时间的推移，这种情况通常会稳定下来，因此我们的不确定性范围应该会越来越小。

Okay, so back to expectations management.

好的，回到期望管理的话题上。

Suppose stakeholders ask Pat when will all of these stuff be done.

假设利益相关者问Pat所有这些东西何时完成。

When will we be here, that's a fixed scope, variable time question.

我们何时能达到这个里程碑，这是一个固定范围、时间变动的问题。

So Pat uses the two trend lines to answer.

所以Pat使用这两条趋势线来回答。

Most likely sometime between April and mid-May.

最有可能是在四月底到五月中旬之间。

Suppose the stakeholders ask Pat how much will be done by Christmas.

假如利益相关者问Pat，在圣诞节之前能够完成多少

That's a fixed time, variable scope question.  

那是一个固定时间，范围变动的问题

The trend lines tell us, i will most likely finish all of these by Christmas, some of those and none of those.

根据趋势线的信息，预计我将在圣诞节前完成所有这些任务，其中一些任务可能会完成，而另一些可能无法完成。

And finally suppose the stakeholders say can we get these features by Christmas, now that's a fixed time, fixed scope question.

最后假设利益相关者说：“我们能在圣诞节前获得这些功能吗？”这是一个固定时间和固定范围的问题。

Looking at trend lines, Pat says: no, sorry, it can't happen.

通过查看趋势线，Pat说：“不好意思，不可能实现。”

Followed by here's how much we can get done by Christmas, or here is how much time we will need to get everything done.

然后，Pat会说明到圣诞节我们能完成多少工作，或者需要多长时间来完成所有工作。

It's generally better to reduce scope than to extend time.

通常情况下，减少范围要比延长时间更好。

Because if we reduce scope first, we still have the option to extend the time later, and add the rest of the stories.

因为如果我们先减少范围，我们仍然有选项可以稍后延长时间，并添加其余的故事。

Vice versa doesn't work because darn it we can't turn the clock back backwards.

反之则行不通，因为我们不能让时钟倒流。

No time is rather annoying that way, isn't it.

是的，时间有时候确实令人烦恼。

So, Pat puts it this way, we could deliver something here and the rest later.

所以，Pat这样解释，我们可以在这里交付一部分，然后稍后交付剩余部分。

Or we could deliver nothing here and the rest later.

或者我们可以在这里什么都不交付，然后稍后交付剩余部分。

Which do you prefer. These calculations are pretty simple to do so Pat updates the forecate every week.

你更倾向于哪一个呢？这些计算相当简单，所以Pat每周都会更新预测。

The important thing here is that we are using real data to make the forecast and that we are being honest about uncertainty.

重要的是我们正在使用真实数据来进行预测，并且我们对不确定性保持诚实。

I said no lying right? So this is a very honest way of communicating with stakeholders and they usually appreciate that a lot.

我已经说过了不要说谎。这种与利益相关者之间的沟通方式非常诚实，通常他们会非常欣赏。

If your organization doesn't like truth and honesty, it probably won't like agile.

如果你的组织不喜欢真实和诚实，那么可能不会喜欢敏捷开发。

Now a word of warning, if the team is accumulating technical debt, if they're not writing tests and not not continuously improving the architecture, then they will get slower and slower over time and the story burn up curve will gradually flatten out.

现在需要警告一下，如果团队积累了技术债务，如果他们不编写测试代码，不持续改进架构，那么随着时间的推移，他们的工作速度会越来越慢，故事完成曲线将逐渐变平。

That makes forecasting almost impossible for Pat.

这将使得 Pat 几乎无法进行准确的预测。

So the team is responsible for maintaining a sustainable pace and Pat avoids pressuring them into taking shortcuts.

所以团队要负责保持可持续的节奏，而Pat则避免对他们施加压力以采取捷径。

OK, what if we have a large project with multiple teams and we have several product owners each with their own backlog for a different part of the product.

好吧，如果我们有一个包含多个团队的大型项目，并且我们有几个产品负责人，针对这个产品的不同部分，每个产品负责人都有自己的产品需求管理，该怎么办？

Overall the model is really the same.

总的来说，模型是一样的。

We still need capacity management, we still need stakeholder communication, we still need product owner who can say no, we still need backlog grooming, we still need a short feedback loop etc.

我们仍然需要能力管理，我们仍然需要与利益相关者沟通，我们仍然需要可以说不的产品负责人，我们仍然需要待办需求梳理，我们仍然需要一个简短的反馈循环等。

Velocity is really the sum of all output, so that can be used for forecasting.

速度实际上是所有输出的总和，因此可用于预测。

Or make a separate forecast for each term if that makes more sense.

或者，如果更有意义，请为每个术语进行单独的预测。

In a multiple team scenario however the product owners have an important additional responsibilities to talk to each other.

但是，在多团队方案中，产品负责人具有相互交流的重要附加责任。

We should organize the teams and backlogs to minimize dependencies, but there will always be some dependencies that we just can't get rid of.

我们应该组织团队和积压需求以最大程度地减少依赖项，但总会有一些我们无法摆脱的依赖项。

So there needs to be some kind of sync between the product owners so that they build things in a sensible order and avoid sub-optimizing.

因此，产品负责人之间需要有某种同步，以便他们以合理的顺序构建事物并避免负优化。

In large projects this usually calls for some knid of cheif product owner role to keep the prodcut owners synchronized.

在大型项目中，这通常需要一些首席产品负责人角色，以保持产品负责人的同步。

Ok, that is agile product ownership in a nutshell . Hope this is usaful to you.

好的，简而言之，这就是敏捷产品开发。希望这对你有用。

User Stories

Let's take a step back and talk through how we get to stories.

让我们退一步，讨论一下我们如何得到用户故事。

Everyone on the team should understand the vision fro the company, which may be several years out.

团队中的每个人都应该理解公司的愿景，即使它可能是几年后的事情。

Let's use a example of Fitbit.

以Fitbit为例

In their job descriptions, they talk about wanting to make it both easy and fun for consumers to be more active eat smarter and get enough sleep.

在他们的工作描述中，他们希望让消费者更容易、更有趣地积极参与，更聪明地进食和获得足够的睡眠。

Underlying your vision, you should have a set of higher level goals, that may be reevaluated and agreed upon periodically.

在你的愿景下，你应该有一系列更高层次的目标，这些目标可以定期重新评估和达成共识。

And typically are consistent for 6 months or a year.

并且通常持续 6 个月或一年。

Hypothetically a goal for Fitbit this year, may be to double the sales of Fitbit trackers to corporations for use in their wellness programs.

假设 Fitbit 今年的目标可能是将 Fitbit 追踪器的销售额翻一番，以供企业在其健康计划中使用。

Ideally your company or division should have three to seven of these types of strategic goals during any giving period.

理想情况下，您的公司或部门在任何给定时期内应该有三到七个这类战略目标。

And these are often set at the executive level.

这些战略目标通常被设定在可执行的层级。

Below each goal, the agile team works collectively to identify projects or large features that they believe would allow them to achieve the goal.

在每个目标下面，敏捷团队共同努力，确定他们认为能够实现目标的项目或重要特性。

In agile these are referred to as Epics.

在敏捷开发中，这些被称为Epics（史诗）。

And some epics will bigger than others.

一些Epics比另一些更大

Continuing the hypothetical example, let's say that Fitbit's corporate wellness team decides that it's important to make it easy for companies to create challenges and many competitions within the companies.

继续刚刚假设的例子，假设Fitbit的企业健康团队决定让公司能够轻松创建内部挑战和竞赛。

While that's good to brainstorm all of the possible projects that could support a given goal.

用头脑风暴来激发可以胜任的特定目标的各种可能是一个很好的方法。

Not all epics will be prioritized.

并非所有的Epics都会被优先考虑。

As a product owner you play a critical role in bringing the team data and information to help set priorities.

作为产品负责人，你在为团队提供数据和信息以帮助设定优先级方面起着关键作用。

And we will talk that process shortly.

我们会简短的讨论这一过程

For each epic, you break that down into stories and that again happens as a team or at least with representatives from design, development and test.

对于每个 Epic，你将其拆分为用户故事，这个过程通常由团队或至少由设计、开发和测试代表参与进行。

Again not all storise will be prioritized.

再一次，并非所有的故事都会被排优先级

As the animation about product owners described, large stories need to be breaking down so that they fit within a single sprint.

正如关于产品负责人的动画所描述的，需要将大型故事进行拆分，以便它们适应单个快速迭代周期。

In my experience, it's best practice to break down the story into the smallest possible shippable increment.

根据我的经验，最好将故事拆分为最小可交付量。

Even if those are a single day or less.

即使这些最小可交付量只需要一天或更短的时间来完成

Doing so increases the accuracy of your developer's estimates, thereby reducing the risk of running into a major unforeseen issue.

这样做可以提高开发人员估计的准确性，从而减少遇到重大意外的风险。

Additionally it provides a greater sense of accomplishments for the team if they can clear through several stories or cards each day.

此外，如果团队能够每天完成几个用户故事或任务，这会给他们带来更大的成就感。

Finally, stories are often breaking down further into tasks.

最好，故事通常会被进一步拆分成具体的任务。

Typically this is done by the engineer who is working on that story, or it could be done by the scrum master or the dev leader on the team.

这通常由正在开发该用户故事的工程师来完成，或者由Scrum主管或团队的开发负责人来完成。

Let's talk a bit more about user stories.

让我们进一步讨论用户故事。

You'll find that you spend quite a lot of time as a product owner writing user stories and moving them around, whether physically or in an agile project tracking system.

作为产品负责人，您会发现自己花费大量时间编写用户故事并进行调整，无论是在物理形式上还是在敏捷项目追踪系统中。

Such as *****.

You move them through various stages of backlog and sprint development where they are categorized as either to do in progress, verify or done.

你会将这些用户故事在待办事项和迭代开发的各个阶段之间进行移动，将它们分类为待办、进行中、验证或已完成。

There are entire classes and book about how to write great requirements or user stories, and won't be getting into that level of detail now.

有很多关于如何编写优秀需求或用户故事的课程和书籍，现在我们不会深入讨论这个层面的细节。

But the basic concept of a user story focuses on the goal, or job of the end user.

但用户故事的基本概念是关注最终用户的目标或任务。

Without being very prescriptive about how the designer and developer should build it.

而不对设计师和开发人员如何构建它进行具体规定。

The most common structure to writing a user story is: as a user or a type of persona, i want a goal so that i can achieve this benefit.

最常见的编写用户故事的结构是：作为一个用户或特定类型的角色，我想要一个目标，以便能够获得这个好处。

Let's take the fictional example of the Fitbit epic to allow companies to create many challenges or competitions.

让我们以虚构的 Fitbit 的 epic为例，允许公司创建多个挑战或竞争。

Some user stories for that might be as a wellness administrator in HR, i want to publicize a new fitness challenges so that lots of employees participate.

作为人力资源部门的健康管理员，我希望宣传新的健身挑战，以便让更多员工参与。

And as an employee i want to say my status in a current challenge relative to my co-workers.

作为员工，我希望在当前挑战中与我的同事比较我的状态。

So that i can have fun with the competition and push myself.

这样我可以享受比赛并激励自己。

And as an account manager working at Fitbit, i want to know which of my accounts are creating challenges, so that i can give them encouragement and inspire inactive accounts to paticepate more.

作为一名在Fitbit工作的客户经理，我希望了解哪些账户正在创建挑战，这样我可以给予他们鼓励，并激励不活跃的账户更多地参与。

As you can see, users can be end users, company administrators, or your internal staff.

正如你所看到的，用户可以是最终用户、公司管理员或你的内部员工。

I should note that these example stories are probaly to large as written and could be broken down further.

我应该指出，这些示例故事可能写得过于庞大，可以进一步细分。

But they illustrate the high level format of a user story.

但它们展示了用户故事的高级形式。

In addition to the user story, as the product owner you'll want to specify what is called acceptance criteria.

除了用户故事，作为产品负责人，你还需要指定所谓的验收标准。

Including what metrics you and your team will use to measure success and what events will provide the data to your reporting system to do so.  

包括你和团队将用来衡量成功的指标以及哪些事件将提供数据给你的报告系统来进行测量。

And if there are certain pass/fail criteria that developers and testers should keep.

以及开发人员和测试人员应该注意的某些通过/不通过的标准。

For example, you might need to clarify that the HR administrate interface needs to be available in all supported languages.

例如，你可能需要明确指出人力资源管理界面需要支持多种语言。

It's also helpful if you work with your design teams to note any non-obvious exception cases, such as what to do when the user is not logged in.

此外，如果你与设计团队合作，记录任何非明显的异常情况也会很有帮助，比如当用户未登录时该如何处理。

Prioritization

Next we'll talk about prioritizing epics and stories.

接下来我们将讨论如何给epics和用户故事排优先级。

Ideas come from everywhere, and at all times in the product cycle, not just during planning.

想法来自各个方面，在产品周期中的任何时候，而不仅仅在规划阶段。

You'll get ideas from your development and design team, nearly every department and from customers themselves through their feedback and in their actions reflected in usage data.

你会从开发和设计团队、几乎所有部门获得想法，也会从顾客本身获得想法=，通过他们的反馈和使用数据。

Frankly most product mangers are overwhelmed with features requests and other development tasks.

坦率地说，大多数产品经理在功能需求和其他开发任务上都感到不堪重负。

However resist the urge to shut off idea generation, great ideas come from many sources.

然而，不要抑制创意的产生，优秀的创意来自于各个来源。

The role of product manager is to understand customer problems and opportunities, keep the team focus on the bigger strategic vision and goals, and not to fall prey to internal popularity contexts for features.

产品经理的角色是理解客户的问题和机遇，让团队专注于更大的战略愿景和目标，并避免陷入内部功能的流行度竞争。

Inevitably you will find that there is too much work to do, even when your high level goals and resource allocations are clear.

不可避免地，你会发现工作量很大，即使高层目标和资源分配是清晰的。

Hopefully the goal setting process allows you to say no to big chunks of work that are not stated priorities.

希望目标设定过程使你能够拒绝那些不属于优先事项的冗余工作。

But you will still need to figure out which epics to tackle first within the goals and which stories to prioritizes within that epics.

但你仍然需要确定在目标范围内首先解决哪些epics，以及在epics中优先考虑哪些用户故事。

The process is called backlog prioritization.

这一过程被称为需求优先级排序

To do this you should think both the value and cost of any given item of work, whether that be an epic or a story.

要做到这一点，你应该考虑每个工作项（无论是epic还是用户故事）的价值和成本。

Value is a function of importance of the customer and current satisfaction.

价值关乎于客户的重要性和当前满意度。

If something is important but customers are already fairly satisfied with what they have.

如果某件事情很重要，但客户对目前的情况已经相当满意。

There is not too much opportunity to add value.

在这种情况下，增加价值的机会不太多。

If something is important and there is a big gap between where your product is now and what customers really want and need.

如果某个功能很重要，并且你的产品与客户真正想要和需要的地方存在很大差距。

Then the opportunity to add value is high.

那么增加价值的技术就很高

You should be able to determine value based on your customer research and ongoing conversations with current and prospective customers in your target segment.

你应该能够根据你对目标用户群的客户调研和与现有客户以及潜在客户的持续交流来确定价值。

On the cost side, there is obviously development time.

成本方面，这显然与开发有关。

In agile it's common for development estimates to be represented in story points.

在在敏捷开发中，通常使用故事点来表示开发工作的估计。

But you can work with your dev leader to translate estimates roughly into time and salary expense.

但你可以与开发负责人合作，将估算粗略地转化为时间和薪资开销。

There may also be licensing costs, or other internal or external costs associated with providing that feature, such as hosting costs.

可能还会涉及证书成本或其他与提供该功能相关的内部或外部成本，比如托管成本。

Be careful to also consider all of the hidden cost such as time to test, the impact on customer support, and increased code complexity that may slow you down in the future.

请注意，还要考虑所有隐藏的成本，例如测试所需的时间、对客户支持的影响以及逐步增加的代码复杂性对未来开发速度的影响。

Finally, when looking at costs, there's a difference between project with well-known costs.

最后，在考虑成本时，需要区分那些具有良好预估成本的项目和那些具有不确定成本的项目。

Because it's something you or your team has done before and it's straight forward.

因为这是你或你的团队以前做过的事情，而且是直截了当的。

And projects have high risks of unknowns.

并且项目具有很高的未知风险

When a cost is being estimated with high levels of uncertainty, you should apply a penalty factor and assume that costs will be higher than the original estimate.

当成本估算具有高度不确定性时，应使用惩罚因子并假设成本将高于原始估算。

Obviously, work that is low value and high cost you shouldn't do.

显然，低价值和高成本的工作你不应该做。

And work that is high value and low cost should be done first.

高价值低成本的工作应该首先执行

The trickier projects are those that are high value and high cost.

更棘手的项目是那些高价值和高成本的项目。

In those cases you'll want to do your best to reduce scope complexity and risk, so that you can move them into the high value, low cost range.

在这些案例中你会想要尽最大的可能来降低复杂度和风险，以便把它们移动到高价值低成本的区域里

You do that through the validation process that we've discussed and by reducing scope to the essential minimally viable release.

你可以通过我们已经讨论过的验证过程以及将范围缩小到基本的最小可行版本来实现此目的。

There's also a potential trap in the low cost, lower value work items.

当然也会有一些低成本，低价值的工作项目

These seem to be worthwile, at least opportunistically.

这看起来是值得的，至少是有机会的

And there can be value for the team in shipping quick wins.

并且这对于团队快速交付是有价值的

However you should be skeptical about whether the full cost including opportunity cost is being reflected.

但是，你应该怀疑这一成本是否是反映了包括机会成本在内的全部成本。

Again there are often hidden costs including possible unintended impacts to other parts of the code base that then they require firefighting and distractions later on.

同样，通常存在隐藏的成本，包括可能对代码库的其他部分产生意外影响，导致需要在日后分心进行处理和预防。

Once you've prioritized stories they go into a backlog however there are some excepetions to the force rank process.

一旦你确定了故事的优先级，它们就会进入代办需求，当然也有一些由于其它因素导致的例外。

In some cases you may choose to bump stories up in priority based on external date driven requirements, such as trade shows or contracts.

在某些情况下，你可以选择根据外部日期的要求提高故事的优先级，比如贸易展览或者合同签订。

It's also a good idea to cluster related ideas together in order to simultaneously release a collection.

将一些相互关联的想法打包在一起作为一个集合同时发布也是一个很好的主意

That may be press worthy or more intuitive to the customers.

这可能对客户来说更有价值和或更直观。

Some stories may have unknown or very low upside from a customer perspective but are still necessary.

从客户的角度来看，有些故事可能具有未知或非常低的上升空间，但仍然是必要的。

These include technical debt and at times bug fixing.

这些包括技术债务，有时还包括BUG修复。

There are a few ways to address tech debt and bug buildup including dedicated cleanup sprints and allocating a consistent percentage of effort.

有几种方法可以解决技术债务和BUG积累的问题，包括专门BUG修复计划和分配一定工作时间进行此工作。

For example 10 to 15 percent in every sprint to these work items.

例如，在对这些工作项的每个快速开发计划中利用 10% 到 15%进行BUG修复。

Roadmaps

In addition to the backlog which is a collection of stories,

除了管理需求池（一系列用户故事的集合）外

the product owner is also responsible for producing the roadmap which is a visual representation over time of the major projects or epics that a team is focusing on.

产品负责人还负责制作路线图，该路线图是团队关注的主要项目或epics随时间推移的可视化表示。

Roadmaps are the subject of our next lesson.

路线图是我们下一课的主题。

Roadmaps are something of a necessary evil in product development.

路线图是产品开发中必要的工具

You'll find that many internal and external groups want insight into what the development team is working on and what is coming in the future.

您会发现，许多内部和外部团队都希望深入了解开发团队正在做什么以及未来做什么。

A roadmap simply shows on a calendar when you expect to be focused on particular feature product areas or epics.

当你希望专注于特定的功能产品领域或epics时，路线图会把它们简单的显示在日历上

You typicall update roadmaps every month or two.

通常情况下你一到两个月更新一次路线图

Marketing will want to see the roadmap so that they can plan their messaging including press releases and events.

市场营销部门希望看到路线图，以便他们可以计划他们的消息传递，包括新闻稿和活动。

Sales will want to see the roadmaps so that they can convince current and prospective customers that you're innovative and competitive.

销售团队希望看到路线图，以便他们可以让当前和潜在的顾客相信你们具有创新性和竞争力

Executives will want to share this with investors and key partners.

高管们会希望与投资者和主要合作伙伴分享它。

The problem of course is that no one who is actually building the product likes to share the roadmap.

当然，问题在于，没有一个真正构建产品的人喜欢分享路线图。

Roadmaps are by their nature date driven, and looks suspiciously like the old Gantt charts that you've see in a multi-month waterfall development project.

路线图本质上是日期驱动的，它看起来很可疑，就像你在数月瀑布开发项目中看到的旧甘特图一样。

When the development team gives you estimates on how long they expect work to take to complete, there is a margin of error.

开发团队估算他们需要多长时间来完成工作也存在误差。

And that gets much bigger when you're looking more than a month or two out.

当你觉得要超过一两个月时，它会变得更久。

And user stories have yet to be probably broken down and sized.

用户故事可能还没有被分解和调整规模。

When you communicate a target date with the roadmap, other groups, including customers, will take that as a commitment.

当你通过路线图与客户、其他群体沟通目标日期时，这将被视为承诺。

And many teams get into trouble when they miss communicated dates.

若是错过沟通日期，许多团队会遇到麻烦。

Dates become deadlines and deadlines mean having to work evenings and weekends if you're behind schedule.

日期变成了截止日期，截止日期意味着如果你落后于计划，则必须在晚上和周末工作。

One way to mitigate this is to provide date ranges for projects to be complete.

缓解此问题的一种方法是提供项目完成的日期范围。

And that was described in the agile product owner in a netshell animation that we saw at the beginning of this section.

在本节开头看到的 netshell 动画中对此进行了描述。

A more extreme approach is to not assign any dates at all.

更加极端的做法是完全不分配任务日期

But instead have a roadmap that simply communicates what you're working on now, what is next and what is in the later bucket.  

但是，要有一个路线图，简单地传达你现在正在做什么，下一步是什么以及后面的开发内容。

Unfortunately many organizations insist on some form of a date schedule.

不幸的是，许多组织坚持使用一些固定形式的日期计划表

Despite the downsides of roapmaps, there are benefits internally for the product team, even if the roadmap is never shared outside of the core team.

尽管路线图有缺点，但它对于产品团队内部也有好处，即使路线图从未在核心团队之外共享。

Roadmapping helps to ensure that you're looking at the bigger picture and aligning work with the goals that you've set.

路线图有助于确保你着眼于大局，并使工作与你设定的目标保持一致

Also by clustering work into thematic release, you make product marketing and customer communication much easier and more effective.

此外，通过将工作聚类成一个主题发布，你可以使产品营销和客户沟通变得更加轻松和有效。

Groups of related features that launch together make for a compelling stories, rather than a random collection of features.

一组相关功能构成了引人入胜的故事集合，而不是随机的功能集合。

Additionally roadmaps can make interdependencies more obvious.

此外，路线图可以让相互依赖性更加明显。

For example, if two epics relying on the same individuals at the same time, and finally they serve as a reality check.

例如，如果两个epics同时依赖同一个人，最后它们会充当实例检查。

Roadmaps can make clear what you won't be able to get to.

路线图可以明确你无法达到的目标。

So that you could properly discuss and set expectations.

这样你就可以正确讨论以及设置期望

In general, you'll want to provide very conservative estimates to external teams, such as marketing and sales.

通常，你会想要给一些外部团队提供非常保守的估计值，例如营销和销售

And keep your roadmap communication outside of the core team at a high level.

并在核心团队之外，将你的路线图沟通保持在一个较高的水平

For example, these teams don't typically need to know about the work that you're doing to improve development efficiency.

例如，这些团队通常不需要了解你为提高开发效率所做的工作。

Also remind your audiences that these are estimates and that the actual dates will vary.

同样，提醒你的顾客这些都是预估的，真实日期会变动

In fact it's a good practice to include that disclaimer on the roadmap document itself.

事实上，在路线图文档本身中包含免责声明是一种很好的做法。

Lastly if you're working on software, try to keep roadmaps fairly short, ideally a 6 month view and no longer than one year.

最后，如果你是开发软件，尽量保持路线图相对短暂，6个月是理想情况，不要超过一年

There's simply too much uncertainty beyond a few months and estimating projects that far out is quite likely to be a waste of time.

几个月之后的不确定性实在太多了，预测这么远的项目很可能是浪费时间。

Given the probability that priorities will shift.

考虑到优先事项变更的可能性。

We've included a downloadable roadmap template that you can use or there are also several companies that offer roadmaping software that are worth investigating.

我们提供了一个你可以直接下载使用的路线图模板，或是这还有几家公司提供的值得研究的路线图软件。