BUILD

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

你可能會覺得我們已經(jīng)涵蓋了大量的工作，超過了一個人全職工作的范疇。

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

然而，這就是產(chǎn)品管理，正如我們所討論的，它廣泛而多方面。

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.

信不信由你，我們還沒有討論到大多數(shù)技術產(chǎn)品經(jīng)理花費大部分時間的領域，即構(gòu)建階段。

So let's get started.

所以，開始吧。

Agile

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

大多數(shù)技術產(chǎn)品開發(fā)組織都采用了敏捷開發(fā)的思路。

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

在敏捷開發(fā)中，有一個產(chǎn)品負責人負責安排這些工作。

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

大多數(shù)公司，產(chǎn)品經(jīng)理扮演產(chǎn)品負責人的角色，盡管職稱可能有所不同。

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

Henrik Kniberg創(chuàng)作了一段出色的動畫，解釋了產(chǎn)品負責人的工作內(nèi)容，我們現(xiàn)在來看一下。

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上找到，我鼓勵你與你的團隊分享。我們已經(jīng)在本課程末尾的資源中包含了鏈接。

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

讓我們從產(chǎn)品負責人的角度來談談敏捷軟件開發(fā)。

Here is Pat, she is a product owner.

這是Pat，她是一個產(chǎn)品負責人。

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

她有著產(chǎn)品視角，并且非常熱衷于此。

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.

她并不知道產(chǎn)品的具體細節(jié)，但她知道為什么我們要構(gòu)建這個產(chǎn)品，以及它將解決什么問題，為誰提供價值。

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.

這里是利益相關者，他們是使用、支持或以其他方式受到正在開發(fā)的產(chǎn)品影響的群體。

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的愿景是這些人將會愛上我們的系統(tǒng)并一直使用它，并會將它推薦給他們的朋友

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.

例如，如果這是一個航班預訂系統(tǒng)，人們需要能夠搜索航班，這可能是一個用戶故事。

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

Pat和利益相關者都有很多想法，所以Pat會將這些想法轉(zhuǎn)化為具體的用戶故事。

Now somebody has to actually build a system.

現(xiàn)在需要有人來實際構(gòu)建這一系統(tǒng)。

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

所以在這里，有一個小型的、共同定位的、跨職能的、自主的開發(fā)團隊。

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.

由于這是一個敏捷團隊，他們不會為了在最后進行一次大規(guī)模發(fā)布而積攢功能，相反，他們會盡早、頻繁地發(fā)布產(chǎn)品。

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

在這種情況下，他們通常每周發(fā)布大約4到6個用戶故事，所以這是他們的能力范圍。

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

能力是容易測量的，只需要計算每周發(fā)布的用戶故事數(shù)量即可。

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 .

有些人稱之為故事點數(shù)，但我將簡稱為每周故事數(shù)。

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.

為了保持這種節(jié)奏并避免被手動測試拖慢速度，團隊在自動化測試和持續(xù)集成方面進行了大量投入。

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.

問題在于，因為有許多利益相關者提出了各種需求，它們的數(shù)量肯定不止每周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.

每次我們向他們交付一些東西，他們都會產(chǎn)生更多的想法并要求更多的東西。

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

那么，如果我們試圖取悅他們，試圖做他們要求的一切，會發(fā)生什么呢？

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.

團隊會超負荷工作，這會導致多任務處理、動力下降以及其他一系列問題，最終導致產(chǎn)出下降和質(zhì)量降低。

It's a lose-lose proposition.

這是一種雙輸?shù)那闆r。

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.

這就好像試圖往打印機里塞更多紙張來加快打印速度，或者往已經(jīng)擁擠不堪的高速公路上擠入更多車輛一樣。

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.

那么這周我們應該構(gòu)建哪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.

產(chǎn)品負責人的工作是在所有可能的用戶故事中，確定我們下一步要交付的是哪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.

假設團隊決定同時處理的故事數(shù)量為五個，他們認為這是最佳數(shù)量。

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

他們發(fā)現(xiàn)這樣恰好能讓每個人保持忙碌，而不會造成負荷過重。

So they decide that 5 is their wip limit.

所以他們決定將同時進行的故事數(shù)量限制為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中，這個隊列被稱為產(chǎn)品待辦列表。

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.

所以在你察覺之前，你的產(chǎn)品待辦列表就會變成一個持續(xù)增長的、長達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.

敏捷開發(fā)不能這樣

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.

這對于產(chǎn)品負責人來說是最重要的工作，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.

產(chǎn)品負責人最重要的工作之一是決定不去構(gòu)建什么，并承擔這一決定的后果。

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

這就是困難的原因

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

產(chǎn)品負責人決定哪些項目被接納，哪些被排除。

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

產(chǎn)品負責人還決定了開發(fā)優(yōu)先級，即現(xiàn)在建設什么，以及將來建設什么。

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.

為了能夠進行優(yōu)先排序，產(chǎn)品負責人必須對每個故事的價值和規(guī)模有一些見解。

Some stories are critical important another are just bonus features.

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

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

有些故事只需幾個小時即可完成，而其他故事可能需要數(shù)月時間。

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

現(xiàn)在猜猜用戶故事的價值和大小之間的關聯(lián)是什么。

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.

想想你使用過的任何系統(tǒng)，我敢打賭，你至少能想到一個非常重要但非常簡單的功能，你每天都在使用它。

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.

價值和規(guī)模是幫助Pat進行明智的優(yōu)先級排序的因素。

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

就像這里，這兩個故事的規(guī)模大致相同，但價值不同，首先構(gòu)建這個故事。

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

而在這里，這兩個故事的價值大致相同，但大小不同，首先構(gòu)建這個故事，依此類推。

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不斷與利益相關者進行交流，了解他們?nèi)绾魏饬慨a(chǎn)品價值；同時，她也不斷與團隊進行溝通，了解他們對工作量的評估，無論是大還是小。

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

在實施方面的估計是相對的猜測，而不是絕對的數(shù)字。

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在優(yōu)先處理待辦事項時所需了解的全部內(nèi)容，這種方式相當不錯。

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

在一個新項目的開始階段，我們的猜測必然會出現(xiàn)偏差。

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

但沒關系，最大的價值實際上在于對話本身，而不僅僅是具體的數(shù)字。

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

每當團隊向真實的用戶交付產(chǎn)品時，我們都會學到一些東西，并在評估價值和規(guī)模方面變得更加準確。

That's why we continuously prioritize and estimate.

這就是為什么我們持續(xù)進行優(yōu)先級排序和評估的原因。

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.

所以反饋循環(huán)是我們的助手。不過，僅僅優(yōu)先排序是不夠的。

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.

我們希望形成一個漏斗狀的結(jié)構(gòu)，前面是小而清晰的故事，后面是更模糊的故事。

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.

通過及時進行這種分解，我們可以充分利用我們對產(chǎn)品和用戶需求的最新見解。

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

所有我所提到的東西，估算故事的價值和大小，優(yōu)先級排序，分解等，通常被稱為待辦需求梳理（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.

是的，你指出了一個重要的主題：溝通。產(chǎn)品開發(fā)實際上就是圍繞溝通展開的。

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

每當我問那些富有經(jīng)驗的產(chǎn)品負責人：什么鑄成了他們的成功

They usually emphasis passion and communication.

他們通常強調(diào)熱情和溝通

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

因此，敏捷開發(fā)的首要原則是個人和交互而不是流程和工具，這并非巧合。

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

所以產(chǎn)品負責人的工作不是直接把用戶故事遞給團隊，那是無聊和無效的。

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 讓團隊與利益相關者保持直接聯(lián)系，并且在頻繁交付給真實用戶方面有一個簡短的反饋循環(huán)，以保證團隊每一個人都知道產(chǎn)品的愿景。

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?

是否存在業(yè)務風險，我們是否構(gòu)建了正確的東西？

There is social risk, can these people build it?

是否存在社會風險，這些人有能力構(gòu)建起來嗎？

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.

是否存在資金和計劃風險，我們能否在合理的時間和資金范圍內(nèi)完成這一產(chǎn)品？

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.

我們專注于用戶界面，原型和技術峰值或?qū)嶒灥葍?nèi)容。

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.

我們知道我們將要構(gòu)建什么以及如何構(gòu)建它。

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.

我們已經(jīng)構(gòu)建了最重要的東西，現(xiàn)在我們只是添加了附加功能，如冰淇淋上的澆頭。

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.

此時產(chǎn)品到了不錯的境地，因為在任何時候，Pat 和團隊都可以進行收尾，在這里切入并繼續(xù)另一個更重要的項目，或者可能在同一產(chǎn)品中開始一個全新的功能區(qū)域。

That's is business agility.

這就是業(yè)務敏捷性。

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.

當然我們?nèi)孕枰粩嘣谶@兩者之間找到權衡。

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

另一個權衡是短期與長期。

What should we build next.

我們接下來要開發(fā)什么

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.

我們應該做那個緊急的錯誤修復，或者構(gòu)建那個很棒的新功能，讓用戶大吃一驚，或者做那個困難的平臺升級，以便在未來的某個時候?qū)崿F(xiàn)更快的開發(fā)。

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.

我們是應該專注于構(gòu)建正確的東西還是正確地構(gòu)建東西，或者快速構(gòu)建。

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.

假設我們在這里，試圖用完美的架構(gòu)構(gòu)建完美的產(chǎn)品。

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

如果我們花太多時間試圖做到完美，我們可能會錯過市場窗口或遇到現(xiàn)金流問題。

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

或者假設我們在這里，急于將原型變成可用的產(chǎn)品，也許對于短期項目是有益的。

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.

或者假設我們在這里，在創(chuàng)紀錄的時間內(nèi)建造一座美麗的大教堂。

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規(guī)則之間存在健康的緊張關系。

Product owners tend to focus on building the right thing.

產(chǎn)品負責人傾向于構(gòu)建正確的產(chǎn)品。

Development team tend to foucus on builing the thing right.

開發(fā)團隊傾向于正確地構(gòu)建產(chǎn)品

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

Scrum主管或敏捷教練傾向于專注于縮短反饋循環(huán)。

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.

速度確實值得強調(diào)，因為簡短的反饋循環(huán)將加速學習進度，因此你將更快地了解什么是正確的東西以及如何正確地構(gòu)建。

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

然而，所有三個觀點都很重要，所以要繼續(xù)努力找到平衡點

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

最后，在新產(chǎn)品開發(fā)和舊產(chǎn)品改進之間進行權衡。

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

產(chǎn)品需求列表實際上是一個有點令人困惑的術語，因為它意味著只有一個產(chǎn)品。

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

項目也是一個令人困惑的術語，因為它意味著產(chǎn)品開發(fā)結(jié)束。

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

一個產(chǎn)品永遠不會真正完成，總有維護和改進需要做。

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

直到產(chǎn)品達到使用壽命。

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

因此，當一個團隊開始開發(fā)新產(chǎn)品時，他們的最后一個產(chǎn)品會發(fā)生什么。

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

將產(chǎn)品從一個團隊移交給另一個團隊是昂貴且有風險的。

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

因此，在更常見的情況下，團隊繼續(xù)維護舊產(chǎn)品，同時開發(fā)新產(chǎn)品。

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

所以它不再像一個產(chǎn)品待辦事項列表，它更像是一個團隊待辦事項列表。

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

產(chǎn)品負責人希望團隊共同構(gòu)建的內(nèi)容列表。

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

它可以是來自不同產(chǎn)品的需求混合。

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

產(chǎn)品負責人需要在兩者之間不斷做出權衡。

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 打電話問：“嘿，我的東西什么時候完成？或者到圣誕節(jié)時，我的東西完成了多少？”時。

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

作為產(chǎn)品負責人，Pat負責管理預期，或者更重要的是管理現(xiàn)實的預期。

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

確實，這意味著不撒謊。我知道這很困難，但是誰說敏捷開發(fā)容易呢？

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.

這張圖顯示了隨著時間推移交付的累積用戶故事數(shù)量，或者也可以是故事點。

Note the difference, this curve shows output.

請注意，這條曲線顯示的是產(chǎn)出的情況。

That curve shows outcome.

那條曲線顯示的是結(jié)果的情況。

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

那是輸出，那是我們希望實現(xiàn)的結(jié)果。

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

我們的目標不是盡可能產(chǎn)生更多的輸出，而是實現(xiàn)期望的結(jié)果。

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.

現(xiàn)在看一下燃盡圖，你可以畫一個樂觀的和悲觀的趨勢線。

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

你可以使用復雜的統(tǒng)計學方法，也可以通過直觀地繪制來完成。

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.

幸運的是，隨著時間的推移，這種情況通常會穩(wěn)定下來，因此我們的不確定性范圍應該會越來越小。

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，在圣誕節(jié)之前能夠完成多少

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.

根據(jù)趨勢線的信息，預計我將在圣誕節(jié)前完成所有這些任務，其中一些任務可能會完成，而另一些可能無法完成。

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

最后假設利益相關者說：“我們能在圣誕節(jié)前獲得這些功能嗎？”這是一個固定時間和固定范圍的問題。

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

通過查看趨勢線，Pat說：“不好意思，不可能實現(xiàn)?！?/span>

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會說明到圣誕節(jié)我們能完成多少工作，或者需要多長時間來完成所有工作。

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.

因為如果我們先減少范圍，我們?nèi)匀挥羞x項可以稍后延長時間，并添加其余的故事。

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.

重要的是我們正在使用真實數(shù)據(jù)來進行預測，并且我們對不確定性保持誠實。

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

我已經(jīng)說過了不要說謊。這種與利益相關者之間的溝通方式非常誠實，通常他們會非常欣賞。

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

如果你的組織不喜歡真實和誠實，那么可能不會喜歡敏捷開發(fā)。

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.

現(xiàn)在需要警告一下，如果團隊積累了技術債務，如果他們不編寫測試代碼，不持續(xù)改進架構(gòu)，那么隨著時間的推移，他們的工作速度會越來越慢，故事完成曲線將逐漸變平。

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.

所以團隊要負責保持可持續(xù)的節(jié)奏，而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.

好吧，如果我們有一個包含多個團隊的大型項目，并且我們有幾個產(chǎn)品負責人，針對這個產(chǎn)品的不同部分，每個產(chǎn)品負責人都有自己的產(chǎn)品需求管理，該怎么辦？

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.

我們?nèi)匀恍枰芰芾?，我們?nèi)匀恍枰c利益相關者溝通，我們?nèi)匀恍枰梢哉f不的產(chǎn)品負責人，我們?nèi)匀恍枰k需求梳理，我們?nèi)匀恍枰粋€簡短的反饋循環(huán)等。

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.

但是，在多團隊方案中，產(chǎn)品負責人具有相互交流的重要附加責任。

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.

因此，產(chǎn)品負責人之間需要有某種同步，以便他們以合理的順序構(gòu)建事物并避免負優(yōu)化。

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

在大型項目中，這通常需要一些首席產(chǎn)品負責人角色，以保持產(chǎn)品負責人的同步。

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

好的，簡而言之，這就是敏捷產(chǎn)品開發(fā)。希望這對你有用。

User Stories

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

讓我們退一步，討論一下我們?nèi)绾蔚玫接脩艄适隆?/span>

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.

并且通常持續(xù) 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 追蹤器的銷售額翻一番，以供企業(yè)在其健康計劃中使用。

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

理想情況下，您的公司或部門在任何給定時期內(nèi)應該有三到七個這類戰(zhàn)略目標。

And these are often set at the executive level.

這些戰(zhàn)略目標通常被設定在可執(zhí)行的層級。

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

在每個目標下面，敏捷團隊共同努力，確定他們認為能夠?qū)崿F(xiàn)目標的項目或重要特性。

In agile these are referred to as Epics.

在敏捷開發(fā)中，這些被稱為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.

繼續(xù)剛剛假設的例子，假設Fitbit的企業(yè)健康團隊決定讓公司能夠輕松創(chuàng)建內(nèi)部挑戰(zhàn)和競賽。

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

用頭腦風暴來激發(fā)可以勝任的特定目標的各種可能是一個很好的方法。

Not all epics will be prioritized.

并非所有的Epics都會被優(yōu)先考慮。

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

作為產(chǎn)品負責人，你在為團隊提供數(shù)據(jù)和信息以幫助設定優(yōu)先級方面起著關鍵作用。

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，你將其拆分為用戶故事，這個過程通常由團隊或至少由設計、開發(fā)和測試代表參與進行。

Again not all storise will be prioritized.

再一次，并非所有的故事都會被排優(yōu)先級

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

正如關于產(chǎn)品負責人的動畫所描述的，需要將大型故事進行拆分，以便它們適應單個快速迭代周期。

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

根據(jù)我的經(jīng)驗，最好將故事拆分為最小可交付量。

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.

這樣做可以提高開發(fā)人員估計的準確性，從而減少遇到重大意外的風險。

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.

這通常由正在開發(fā)該用戶故事的工程師來完成，或者由Scrum主管或團隊的開發(fā)負責人來完成。

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.

作為產(chǎn)品負責人，您會發(fā)現(xiàn)自己花費大量時間編寫用戶故事并進行調(diào)整，無論是在物理形式上還是在敏捷項目追蹤系統(tǒng)中。

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.

你會將這些用戶故事在待辦事項和迭代開發(fā)的各個階段之間進行移動，將它們分類為待辦、進行中、驗證或已完成。

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.

有很多關于如何編寫優(yōu)秀需求或用戶故事的課程和書籍，現(xiàn)在我們不會深入討論這個層面的細節(jié)。

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.

而不對設計師和開發(fā)人員如何構(gòu)建它進行具體規(guī)定。

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.

最常見的編寫用戶故事的結(jié)構(gòu)是：作為一個用戶或特定類型的角色，我想要一個目標，以便能夠獲得這個好處。

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

讓我們以虛構(gòu)的 Fitbit 的 epic為例，允許公司創(chuàng)建多個挑戰(zhàn)或競爭。

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.

作為人力資源部門的健康管理員，我希望宣傳新的健身挑戰(zhàn)，以便讓更多員工參與。

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

作為員工，我希望在當前挑戰(zhàn)中與我的同事比較我的狀態(tài)。

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工作的客戶經(jīng)理，我希望了解哪些賬戶正在創(chuàng)建挑戰(zhàn)，這樣我可以給予他們鼓勵，并激勵不活躍的賬戶更多地參與。

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

正如你所看到的，用戶可以是最終用戶、公司管理員或你的內(nèi)部員工。

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.

除了用戶故事，作為產(chǎn)品負責人，你還需要指定所謂的驗收標準。

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. ?

包括你和團隊將用來衡量成功的指標以及哪些事件將提供數(shù)據(jù)給你的報告系統(tǒng)來進行測量。

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

以及開發(fā)人員和測試人員應該注意的某些通過/不通過的標準。

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和用戶故事排優(yōu)先級。

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

想法來自各個方面，在產(chǎn)品周期中的任何時候，而不僅僅在規(guī)劃階段。

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.

你會從開發(fā)和設計團隊、幾乎所有部門獲得想法，也會從顧客本身獲得想法=，通過他們的反饋和使用數(shù)據(jù)。

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

坦率地說，大多數(shù)產(chǎn)品經(jīng)理在功能需求和其他開發(fā)任務上都感到不堪重負。

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

然而，不要抑制創(chuàng)意的產(chǎn)生，優(yōu)秀的創(chuàng)意來自于各個來源。

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.

產(chǎn)品經(jīng)理的角色是理解客戶的問題和機遇，讓團隊專注于更大的戰(zhàn)略愿景和目標，并避免陷入內(nèi)部功能的流行度競爭。

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

不可避免地，你會發(fā)現(xiàn)工作量很大，即使高層目標和資源分配是清晰的。

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

希望目標設定過程使你能夠拒絕那些不屬于優(yōu)先事項的冗余工作。

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

但你仍然需要確定在目標范圍內(nèi)首先解決哪些epics，以及在epics中優(yōu)先考慮哪些用戶故事。

The process is called backlog prioritization.

這一過程被稱為需求優(yōu)先級排序

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.

如果某件事情很重要，但客戶對目前的情況已經(jīng)相當滿意。

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.

如果某個功能很重要，并且你的產(chǎn)品與客戶真正想要和需要的地方存在很大差距。

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.

你應該能夠根據(jù)你對目標用戶群的客戶調(diào)研和與現(xiàn)有客戶以及潛在客戶的持續(xù)交流來確定價值。

On the cost side, there is obviously development time.

成本方面，這顯然與開發(fā)有關。

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

在在敏捷開發(fā)中，通常使用故事點來表示開發(fā)工作的估計。

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

但你可以與開發(fā)負責人合作，將估算粗略地轉(zhuǎn)化為時間和薪資開銷。

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

可能還會涉及證書成本或其他與提供該功能相關的內(nèi)部或外部成本，比如托管成本。

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.

請注意，還要考慮所有隱藏的成本，例如測試所需的時間、對客戶支持的影響以及逐步增加的代碼復雜性對未來開發(fā)速度的影響。

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

最后，在考慮成本時，需要區(qū)分那些具有良好預估成本的項目和那些具有不確定成本的項目。

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

因為這是你或你的團隊以前做過的事情，而且是直截了當?shù)摹?/span>

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.

高價值低成本的工作應該首先執(zhí)行

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.

在這些案例中你會想要盡最大的可能來降低復雜度和風險，以便把它們移動到高價值低成本的區(qū)域里

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

你可以通過我們已經(jīng)討論過的驗證過程以及將范圍縮小到基本的最小可行版本來實現(xiàn)此目的。

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.

但是，你應該懷疑這一成本是否是反映了包括機會成本在內(nèi)的全部成本。

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.

同樣，通常存在隱藏的成本，包括可能對代碼庫的其他部分產(chǎn)生意外影響，導致需要在日后分心進行處理和預防。

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

一旦你確定了故事的優(yōu)先級，它們就會進入代辦需求，當然也有一些由于其它因素導致的例外。

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

在某些情況下，你可以選擇根據(jù)外部日期的要求提高故事的優(yōu)先級，比如貿(mào)易展覽或者合同簽訂。

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

將一些相互關聯(lián)的想法打包在一起作為一個集合同時發(fā)布也是一個很好的主意

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.

例如，在對這些工作項的每個快速開發(fā)計劃中利用 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.

產(chǎn)品負責人還負責制作路線圖，該路線圖是團隊關注的主要項目或epics隨時間推移的可視化表示。

Roadmaps are the subject of our next lesson.

路線圖是我們下一課的主題。

Roadmaps are something of a necessary evil in product development.

路線圖是產(chǎn)品開發(fā)中必要的工具

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.

您會發(fā)現(xiàn)，許多內(nèi)部和外部團隊都希望深入了解開發(fā)團隊正在做什么以及未來做什么。

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

當你希望專注于特定的功能產(chǎn)品領域或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.

銷售團隊希望看到路線圖，以便他們可以讓當前和潛在的顧客相信你們具有創(chuàng)新性和競爭力

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.

當然，問題在于，沒有一個真正構(gòu)建產(chǎn)品的人喜歡分享路線圖。

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.

路線圖本質(zhì)上是日期驅(qū)動的，它看起來很可疑，就像你在數(shù)月瀑布開發(fā)項目中看到的舊甘特圖一樣。

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

開發(fā)團隊估算他們需要多長時間來完成工作也存在誤差。

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.

用戶故事可能還沒有被分解和調(diào)整規(guī)模。

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.

在本節(jié)開頭看到的 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. ?

但是，要有一個路線圖，簡單地傳達你現(xiàn)在正在做什么，下一步是什么以及后面的開發(fā)內(nèi)容。

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.

盡管路線圖有缺點，但它對于產(chǎn)品團隊內(nèi)部也有好處，即使路線圖從未在核心團隊之外共享。

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.

此外，通過將工作聚類成一個主題發(fā)布，你可以使產(chǎn)品營銷和客戶溝通變得更加輕松和有效。

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

一組相關功能構(gòu)成了引人入勝的故事集合，而不是隨機的功能集合。

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.

例如，這些團隊通常不需要了解你為提高開發(fā)效率所做的工作。

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.

最后，如果你是開發(fā)軟件，盡量保持路線圖相對短暫，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.

考慮到優(yōu)先事項變更的可能性。

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.

我們提供了一個你可以直接下載使用的路線圖模板，或是這還有幾家公司提供的值得研究的路線圖軟件。