編輯導(dǎo)語：產(chǎn)品在經(jīng)由市場定位、戰(zhàn)略規(guī)劃、產(chǎn)品設(shè)計(jì)等流程之后，便可以進(jìn)入正式的開發(fā)環(huán)節(jié)。在這一環(huán)節(jié)中，產(chǎn)品團(tuán)隊(duì)?wèi)?yīng)當(dāng)注意哪些事項(xiàng)、以避免造成生產(chǎn)活動的浪費(fèi)或是團(tuán)隊(duì)工作的不協(xié)調(diào)？本文作者對敏捷開發(fā)進(jìn)行了總結(jié)分享，一起來看一下。

至此，我們可以進(jìn)入產(chǎn)品開發(fā)（生產(chǎn)）階段了。

在工業(yè)領(lǐng)域，MVP開發(fā)一般在實(shí)驗(yàn)室或研究中心完成，經(jīng)過測試驗(yàn)證后，按照產(chǎn)品文檔標(biāo)準(zhǔn)要求在特定的工廠進(jìn)行批量生產(chǎn)。

實(shí)物產(chǎn)品在批量生產(chǎn)過程中遵循“精益管理”的思想，精益管理要求企業(yè)的各項(xiàng)活動都必須運(yùn)用“精益思維”，“精益思維”的核心就是以最小資源投入，包括人力、設(shè)備、資金、材料、時間和空間，準(zhǔn)時地創(chuàng)造出盡可能多的價值，為顧客提供新產(chǎn)品和及時的服務(wù)。

精益管理的目標(biāo)可以概括為：企業(yè)在為顧客提供滿意的產(chǎn)品與服務(wù)的同時，把浪費(fèi)降到最低程度。

企業(yè)生產(chǎn)活動中的浪費(fèi)現(xiàn)象很多，常見的有：

• 錯誤——提供有缺陷的產(chǎn)品或不滿意的服務(wù)；
• 積壓——因無需求造成的積壓和多余的庫存；
• 過度加工——實(shí)際上不需要的加工和程序；
• 多余搬運(yùn)——不必要的物品移動；
• 等候——因生產(chǎn)活動的上游不能按時交貨或提供服務(wù)而等候；
• 多余的運(yùn)動——人員在工作中不必要的動作；
• 提供顧客并不需要的服務(wù)和產(chǎn)品。

努力消除這些浪費(fèi)現(xiàn)象是精益管理的最重要的內(nèi)容。

由于我在實(shí)物產(chǎn)品的規(guī)模化生產(chǎn)領(lǐng)域缺乏實(shí)戰(zhàn)經(jīng)驗(yàn)，在此就不再為大家做太多的講述。在互聯(lián)網(wǎng)領(lǐng)域，精益的思想同樣適用，并在敏捷開發(fā)中體現(xiàn)得淋漓盡致。

本小節(jié)，我著重地為大家講解關(guān)于敏捷開發(fā)的精髓知識內(nèi)容，幫助互聯(lián)網(wǎng)/軟件產(chǎn)品經(jīng)理實(shí)現(xiàn)提高顧客滿意度、降低成本、提高質(zhì)量、加快流程速度和改善資本投入，使組織社會性的價值實(shí)現(xiàn)最大化。

一、敏捷開發(fā)宣言

敏捷開發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行產(chǎn)品開發(fā)。在敏捷開發(fā)中，產(chǎn)品項(xiàng)目在構(gòu)建初期被切分成多個子產(chǎn)品，各個子產(chǎn)品的成果都經(jīng)過測試，具備可視、可集成和可運(yùn)行使用的特征。

換言之，就是把一個大產(chǎn)品分為多個相互聯(lián)系，但也可獨(dú)立運(yùn)行的小產(chǎn)品模塊或功能，并分別完成，在此過程中產(chǎn)品一直處于可使用狀態(tài)。

在2001年，17位敏捷方法論的擁護(hù)者和倡議者聚集在猶他州的雪鳥滑雪場，起草了一份陳述敏捷組織原則的文件。這份文件基本上代表了不同敏捷方法論的共同點(diǎn)，我們稱之為“敏捷宣傳”，也叫做敏捷軟件開發(fā)宣言，是指導(dǎo)以人為中心的迭代軟件開發(fā)方法，具體四個核心價值內(nèi)容如圖5-14所示。

圖5-14 敏捷開發(fā)宣傳

1. 個體和互動高于流程和工具

項(xiàng)目是通過人來完成的，流程和工具可以幫助人，但絕不能自行完成工作。

雖然，過程和工具都是好東西，但是它們有時也會成為障礙。面對面的直接溝通，比一些流程性的文件和工具溝通，效率要高出很多。

當(dāng)然最好的是，在溝通后就多方達(dá)成的共識形成一個簡要性的文檔備錄。

2. 工作的軟件高于詳盡的文檔

可用軟件的價值是很重要的，因?yàn)檐浖菫闃I(yè)務(wù)目標(biāo)提供支持的，是可用軟件（而不是文件）為客戶和也會傳遞了高價值。

一般來說，一個敏捷項(xiàng)目的進(jìn)展情況是由開發(fā)了多少可用軟件來跟蹤和報告的。但不是說文檔一無是處，適量的文檔在絕大多數(shù)的項(xiàng)目中是有益的和必要的。

敏捷通過尋求“剛好足夠”的文檔來避免這種情況。其中的原則是任何文件的創(chuàng)建都應(yīng)與為客戶創(chuàng)造的價值直接掛鉤，且不論該價值體現(xiàn)在現(xiàn)狀還是將來。

3. 客戶合作高于合同談判

這個價值觀的核心是越接近你的客戶越好?？蛻糇钋宄胍裁?，即使在需求明確過程中也會包含一些試驗(yàn)和錯誤。在合同談判期間，試圖避免所有的嘗試和錯誤不發(fā)生是不現(xiàn)實(shí)的，也是徒勞的。

定位你與客戶的關(guān)系很重要，你是選擇對抗你的客戶還是選擇與你的客戶一起為接近方案努力而使每個人都受益？敏捷團(tuán)隊(duì)更愿意和客戶在同一方向一起使勁而不是把力氣花在背離客戶的方向。

4. 響應(yīng)變化高于遵循計(jì)劃

任何一個曾在軟件項(xiàng)目工作過的人都知道這些項(xiàng)目的本質(zhì)就是變化。即使底層的技術(shù)也在快速變化，新的途徑和可能性在不斷地被打開。對變化響應(yīng)的速度就決定你在市場上的靈活性，循規(guī)蹈矩的做事將被市場甩在后面，永遠(yuǎn)慢市場半拍，慢慢你的市場會被蠶食掉。

當(dāng)你讀到這個宣言，你會發(fā)現(xiàn)它具有最高原則性，因?yàn)槊艚莘椒ㄕ撛谧罡邔用嫔鲜且恢碌?，但到具體細(xì)節(jié)上每種方法都會不同。除了敏捷宣言之外，還有12條準(zhǔn)則的支持文件，為敏捷宣言提供了更多的擴(kuò)充細(xì)節(jié)。

準(zhǔn)則1

我們的最高目標(biāo)是，通過盡早和持續(xù)地交付有價值的軟件來滿足客戶。敏捷團(tuán)隊(duì)可以很快將可用軟件交付到客戶手中，并且是開放式地快速更新，給客戶帶來優(yōu)先級最高地價值。

準(zhǔn)則2

歡迎對需求提出變更，即使在項(xiàng)目開發(fā)后期；要善于利用需求變更，幫助客戶獲得競爭優(yōu)勢。

傳統(tǒng)項(xiàng)目管理中的一個原則是設(shè)法去影響和控制會導(dǎo)致變化地因素。敏捷項(xiàng)目管理預(yù)期到需求會發(fā)生變化，并在實(shí)際過程中歡迎擁抱這些變化，即使這些變化發(fā)生在項(xiàng)目后期。

迅速應(yīng)對和適應(yīng)變化能給客戶帶來顯著地競爭優(yōu)勢，從而應(yīng)對新的機(jī)遇。

準(zhǔn)則3

要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。

不同的敏捷方法論采用不同的迭代周期，但都是相對較短的，關(guān)鍵是能快速把可用的軟件交付到客戶手上并能利用軟件獲得有意義的回報。較短的迭代周期可以使團(tuán)隊(duì)持續(xù)關(guān)注客戶的價值。

準(zhǔn)則4

在項(xiàng)目過程中，業(yè)務(wù)人員、產(chǎn)品經(jīng)理與開發(fā)人員必須在一起。敏捷項(xiàng)目管理，讓業(yè)務(wù)人員、產(chǎn)品經(jīng)理和開發(fā)人員彼此靠近，并時常讓他們在同一個地方一起工作。

通過這樣的方式讓業(yè)務(wù)人員和開發(fā)人員之間沒有隔閡，是因?yàn)闃I(yè)務(wù)人員和開發(fā)人員的共同目標(biāo)就是通過可用的軟件向客戶傳遞價值。

準(zhǔn)則5

要善于激勵項(xiàng)目人員，給他們所需要的環(huán)境和支持，并相信他們能夠完成任務(wù)。

傳統(tǒng)項(xiàng)目管理，常對員工進(jìn)行微觀管理，不僅告訴他們要做什么，還告訴他們?nèi)绾巫?，無意間形成自上而下的管理方式。

敏捷項(xiàng)目建立了一支強(qiáng)有力的團(tuán)隊(duì)并積極避免微觀管理，要求一個自律的團(tuán)隊(duì)，自發(fā)告知開發(fā)人員做什么。提供相關(guān)資源，給予鼓勵，相信團(tuán)隊(duì)能夠完成任務(wù)。

準(zhǔn)則6

無論是團(tuán)隊(duì)內(nèi)還是團(tuán)隊(duì)間，最有效的溝通方法是面對面的交談。非正式口頭的溝通在敏捷項(xiàng)目管理中遠(yuǎn)比正式的書面溝通更普遍。其想法是兩個人坐在一起為一個解決方案努力會比他們用郵件來來往往或交換文件更有效率。

面對面溝通是敏捷項(xiàng)目管理的精髓。這種溝通是公開的，任何團(tuán)隊(duì)成員都可以自由參與對話。

準(zhǔn)則7

可用的軟件是衡量進(jìn)度的主要指標(biāo)。計(jì)劃和文件可能是有用的，但是當(dāng)最根本的目標(biāo)發(fā)生變化時，它們就可能失去應(yīng)有的價值。

傳統(tǒng)項(xiàng)目往往極其糾結(jié)的是，項(xiàng)目的不斷更新使得文件成為一種負(fù)擔(dān)。真正的價值是通過結(jié)果來表達(dá)的，結(jié)果又是通過可用的軟件來呈現(xiàn)的。

準(zhǔn)則8

敏捷過程提倡可持續(xù)的開發(fā)。項(xiàng)目方、開發(fā)人員和用戶應(yīng)該能夠保持恒久穩(wěn)定的進(jìn)展速度。

可持續(xù)開發(fā)的焦點(diǎn)是在團(tuán)隊(duì)身上，他們會努力保持一個穩(wěn)定的可持續(xù)的進(jìn)展速度，從而使得團(tuán)隊(duì)成員不會在迭代周期的尾端匆忙趕工。

理想的目標(biāo)是保持一種可持續(xù)的速度，使團(tuán)隊(duì)成員不會感到過度的壓力和筋疲力盡，而是能夠保持在一個理想的強(qiáng)度下工作。

準(zhǔn)則9

對技術(shù)的精益求精及對設(shè)計(jì)的不斷完善將提升敏捷性。設(shè)計(jì)得越完善，維護(hù)起來就越簡單，即使遇到變化，穩(wěn)定和優(yōu)質(zhì)的項(xiàng)目會比劣質(zhì)的項(xiàng)目更加允許團(tuán)隊(duì)快速應(yīng)對變化。

準(zhǔn)則10

要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術(shù)，被所有的敏捷方法所擁護(hù)，尤其是精益方法。關(guān)鍵點(diǎn)對客戶價值保持關(guān)注和毫無猶豫的削減不增加價值的活動。保持簡單不只是一種愿望，它使最基本的原則。

準(zhǔn)則11

最佳的架構(gòu)、需求和設(shè)計(jì)出自自我組織的團(tuán)隊(duì)。

自我組織是敏捷團(tuán)隊(duì)的核心元素之一。當(dāng)一個團(tuán)隊(duì)是自我組織型的時候，說明該團(tuán)隊(duì)自己去決定工作如何分配及誰去做某個特定的工作，而不是人力資源部門或管理層來決定。不僅小團(tuán)隊(duì)是自我組織的，較大的跨職能團(tuán)隊(duì)也可以是自我組織的。

準(zhǔn)則12

團(tuán)隊(duì)要定期反省如何能夠做到更有效，并相應(yīng)地調(diào)整團(tuán)隊(duì)的行為。

敏捷項(xiàng)目中最可預(yù)見的事情就是變更。傳統(tǒng)項(xiàng)目里當(dāng)項(xiàng)目或階段完成時開會總結(jié)是最常見的做法，而敏捷試著通過更頻繁的回顧來完成這項(xiàng)工作。在一個回顧活動中，團(tuán)隊(duì)查看各迭代周期中已完成的工作或發(fā)布，并評估下一次如何改進(jìn)他們的做法。每日站立會議即每天簡單碰頭15分鐘是另一項(xiàng)協(xié)調(diào)團(tuán)隊(duì)努力方向、團(tuán)隊(duì)自我評定和自我調(diào)整的重要方式。

敏捷開發(fā)的業(yè)務(wù)目標(biāo)是更早地交付價值，價值的交付不僅僅是早晚上線兩天的問題，而是更早上線能夠給自己和客戶帶來更大的價值。越晚交付，價值越低。更快不是絕對速度的快，而是指時間上的早，即通過迭代交付實(shí)現(xiàn)分批和更早的交付。

同時靈活地響應(yīng)變化。當(dāng)今世界跨界顛覆的案例數(shù)不勝數(shù)，一個企業(yè)的核心能力不再是已有的能力有多強(qiáng)，而是靈活響應(yīng)變化，快速學(xué)習(xí)的能力有多好。

注意：在新產(chǎn)品開發(fā)中使用敏捷，一定要考慮整體價值的交付，這種交付是可以交付到用戶手中使用的交付，是面向市場的交付。

我曾遇到過一個創(chuàng)業(yè)團(tuán)隊(duì)花了一年半的時間，迭代了26個版本，依然沒有完成用戶交付，沒有將產(chǎn)品推向市場，這種悲劇盡量避免。采用做最小可行性產(chǎn)品（MVP）方法可以有效地避免這種情況的發(fā)生。

二、Scrum敏捷開發(fā)

在敏捷實(shí)踐體系中，迭代交付模式是敏捷開發(fā)的核心要素。

敏捷開發(fā)方法有很多，Scrum提供了迭代管理和持續(xù)改進(jìn)的框架，如圖5-15所示。Scrum中的主要角色包括同項(xiàng)目經(jīng)理類似的Scrum主管角色負(fù)責(zé)維護(hù)過程和任務(wù)，產(chǎn)品負(fù)責(zé)人代表利益所有者，開發(fā)團(tuán)隊(duì)包括了所有開發(fā)人員。

圖5-15 Scrum敏捷開發(fā)流程

Scrum是一個包括了一系列的實(shí)踐和預(yù)定義角色的過程骨架（是一種流程、計(jì)劃、模式，用于有效率地開發(fā)軟件）。

Scrum的最大特色是靈活和增量交付，要求團(tuán)隊(duì)之間有開放的溝通和協(xié)作。首先是由產(chǎn)品經(jīng)理收集和整理需求，然后和開發(fā)團(tuán)隊(duì)確定開發(fā)列表，接著進(jìn)入開發(fā)沖刺狀態(tài)，后面就是日常開會、后期改善。在實(shí)際應(yīng)用中，我們通常將其分為以下5個步驟。

1. 步驟1：創(chuàng)建用戶需求列表

一個產(chǎn)品的需求可能來自客戶、團(tuán)隊(duì)或者產(chǎn)品經(jīng)理的想法，這些需求的描述必須符合：作為_______，我希望_______，以完成______。這樣的好處是讓整個團(tuán)隊(duì)更容易理解需求，達(dá)成共識，圖5-16所示為一個實(shí)例。

圖5-16 用戶需求列表（產(chǎn)品功能需求）

2. 步驟2：召開計(jì)劃會議和制定開發(fā)計(jì)劃（計(jì)劃版）

Scrum Master負(fù)責(zé)組織召開計(jì)劃會議，產(chǎn)品經(jīng)理和團(tuán)隊(duì)一起根據(jù)需求的重要性、開發(fā)量來確定開發(fā)優(yōu)先級，做工作量預(yù)估，制定迭代開發(fā)計(jì)劃（從需求列表中挑選出高優(yōu)先級 Story（用戶需求）作為本次迭代完成的目標(biāo)。

這個目標(biāo)的時間周期是1~4個星期，然后把這個Story進(jìn)行細(xì)化，形成一個Sprint Backlog（迭代代辦事項(xiàng)））。

開發(fā)團(tuán)隊(duì)一旦接受這些開發(fā)任務(wù)，就應(yīng)該準(zhǔn)時完成，不得修改交付標(biāo)準(zhǔn)。

3. 步驟3：執(zhí)行迭代計(jì)劃（任務(wù)板）

首先，你需要確定每次Sprint（開發(fā)沖刺）的周期，短的周期可以更頻繁地發(fā)布產(chǎn)品版本，因此可以從客戶那里更迅速地收到反饋，修正錯誤。

這個周期一般為1~4周。當(dāng)然，你可以根據(jù)團(tuán)隊(duì)成熟程度或迭代任務(wù)確定一個合適的迭代周期，比如2周，這樣可以讓開發(fā)人員更投入地工作。

所謂Sprint，就是在一定時間內(nèi)全身心投入開發(fā)。這個階段通常用看板來管理需求，每個卡片就是一個開發(fā)任務(wù)，工作完成后，可以將卡片移到下一個階段，用看板管理需求。

如圖5-17所示：你也可以使用專門的軟件來管理看板，例如國外的Jira、國內(nèi)的明道。

圖5-17 敏捷開發(fā)項(xiàng)目管理看板

在沖刺中，每一天都會舉行項(xiàng)目狀況會議，被稱為“每日站會”。會議在固定地點(diǎn)和每天的同一時間舉行，對于遲到者團(tuán)隊(duì)常常會制定懲罰措施（例如罰款、做俯臥撐、在脖子上掛橡膠雞玩具）。

不論團(tuán)隊(duì)規(guī)模大小，會議被限制在15分鐘。所有出席者都應(yīng)站立，每個人都必須發(fā)言。

會議的目標(biāo)是討論當(dāng)前的任務(wù)的狀態(tài)，一個推薦的匯報形式是：我昨天已經(jīng)做了什么？我接下來準(zhǔn)備做什么？現(xiàn)在遇到什么阻礙和問題？

注意在會議中團(tuán)隊(duì)成員不必要針對每個問題進(jìn)行探討，只是作為一個重要信息的反饋通道，具體問題相關(guān)成員在會后私下當(dāng)面溝通解決，這樣更加高效，避免浪費(fèi)問題無關(guān)成員的時間。

4. 步驟4：產(chǎn)品測試和演示

因?yàn)槊看蔚腟print目標(biāo)就是交付一個可以用的產(chǎn)品特性，所以測試工作非常重要。

有不少方法可以減少測試周期，比如，你可以減少需求數(shù)量，或者讓開發(fā)參與測試。

當(dāng)一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成。這時，我們要進(jìn)行演示會議，也稱為評審會議。

產(chǎn)品負(fù)責(zé)人和客戶都要參加（最好本公司老板也參加），每一個Scrum團(tuán)隊(duì)的成員都要向他們演示自己完成的軟件產(chǎn)品（這個會議非常重要，一定不能取消）。

5. 步驟5：回顧會議和下一個Sprint計(jì)劃

每一個沖刺完成后，都會舉行一次沖刺回顧會議。

回顧會議也稱為總結(jié)會議，會議的時間限制在4小時，以輪流發(fā)言方式進(jìn)行，每個人都要發(fā)言，哪里做得好、哪里不好都可以提出，總結(jié)并討論改進(jìn)的地方，放入下一輪Sprint計(jì)劃。

三、Sprint沖刺會議

沖刺（Sprint）計(jì)劃是Scrum中的事件。Sprint計(jì)劃的目的是定義在Sprint中可以交付什么，以及如何實(shí)現(xiàn)該工作。

Sprint計(jì)劃是由整個Scrum團(tuán)隊(duì)協(xié)作完成的。與體育界不同的是，Scrum鼓勵總是全速前進(jìn)，這樣就可以在不斷學(xué)習(xí)和改進(jìn)的同時交付可用的軟件。

在Scrum中，Sprint沖刺是完成所有工作的固定時間段，即一個迭代周期。在采取行動之前，必須設(shè)置沖刺時間，需要確定時間間隔將是多長時間，沖刺目標(biāo)以及開始的位置。

沖刺計(jì)劃會議通過設(shè)置議程和重點(diǎn)來開始沖刺。如果做得正確，它還將為團(tuán)隊(duì)創(chuàng)造動力，提供取得成功的環(huán)境。不良的沖刺計(jì)劃可能會因設(shè)定不切實(shí)際的期望而使團(tuán)隊(duì)脫軌。

為了確保沖刺的順利進(jìn)行，在沖洗計(jì)劃中要包含若干會議為沖刺過程提供支持，如圖5-18所示。

圖5-18沖刺計(jì)劃包含會議

運(yùn)行一個偉大的Sprint計(jì)劃事件需要一些紀(jì)律。產(chǎn)品負(fù)責(zé)人必須做好準(zhǔn)備，結(jié)合之前Sprint評審的經(jīng)驗(yàn)教訓(xùn)、涉眾的反饋以及他們對產(chǎn)品的愿景，從而為Sprint做好準(zhǔn)備。

為了增加透明度，產(chǎn)品待辦事項(xiàng)列表應(yīng)該是最新的和細(xì)化的，以提供清晰的信息。

Backlog細(xì)分在Scrum中是一個可選的事件，因?yàn)橛行〣acklog不需要它。然而，對于大多數(shù)團(tuán)隊(duì)來說，最好是在Sprint計(jì)劃之前讓團(tuán)隊(duì)一起檢查和細(xì)化Backlog。

輸入Sprint計(jì)劃的一個很好的起點(diǎn)是產(chǎn)品Backlog，因?yàn)樗峁┝艘粋€“東西”的列表，這些“東西”可能是當(dāng)前Sprint的一部分。團(tuán)隊(duì)還應(yīng)該查看在增量中完成的現(xiàn)有工作，并查看容量。

輸出Sprint計(jì)劃會議最重要的結(jié)果是團(tuán)隊(duì)可以描述Sprint的目標(biāo)，以及他們將如何開始朝著這個目標(biāo)工作。這在Sprint Backlog中是可見的。

沖刺計(jì)劃應(yīng)該限制在每周沖刺不超過兩小時。因此，例如，為期兩周的Sprint計(jì)劃會議將不會超過兩個小時。這被稱為“時間限制”，或者為團(tuán)隊(duì)完成一項(xiàng)任務(wù)設(shè)置最大時間量，在本例中是規(guī)劃Sprint。

Scrum Master（敏捷教練）負(fù)責(zé)確保會議的時間安排被理解。如果團(tuán)隊(duì)在時間框內(nèi)完成之前感到高興，那么事件就結(jié)束了。時間框是允許的最大時間，沒有最小時間限制。

在制定沖刺計(jì)劃的過程中，很容易陷入“困境”，專注于哪個任務(wù)應(yīng)該先做，誰應(yīng)該做，以及需要多長時間。

對于復(fù)雜的工作，您在開始時所知道的信息水平可能很低，而且大部分信息都是基于假設(shè)的。Scrum是一個經(jīng)驗(yàn)主義的過程，這意味著你不能預(yù)先計(jì)劃，而是在實(shí)踐中學(xué)習(xí)。

Sprint計(jì)劃需要一定程度的評估。團(tuán)隊(duì)需要定義在Sprint中可以做什么，不可以做什么：估算工作量和團(tuán)隊(duì)能夠承受的容量。

良好的評估需要一個基于信任的環(huán)境，在這個環(huán)境中，信息可以自由提供，并且在過程中討論假設(shè)。如果評估中使用負(fù)面的，對抗性的方式完成工作,那么很有可能估算的工作量將很大，會造成不必要的資源浪費(fèi)。

我們很容易陷入沖刺計(jì)劃的細(xì)節(jié)，忘記沖刺計(jì)劃的重點(diǎn)是為下一個沖刺建立一個“剛剛好”的計(jì)劃。這個計(jì)劃不應(yīng)該成為團(tuán)隊(duì)背后的搗亂者，相反，它應(yīng)該將團(tuán)隊(duì)的注意力集中在有價值的結(jié)果上，并為組織提供保護(hù)。

Scrum的一個關(guān)鍵原則是承認(rèn)客戶可以在項(xiàng)目過程中改變主意，變更他們的需求，而預(yù)測式和計(jì)劃式的方法并不能輕易地解決這種不可預(yù)見的需求變化。

同樣，Scrum采用了經(jīng)驗(yàn)方法——承認(rèn)需求無法完全理解或定義，因此關(guān)注如何使得開發(fā)團(tuán)隊(duì)快速響應(yīng)不斷出現(xiàn)的需求。

四、Bocklog用戶故事

Sprint目標(biāo)在高層次上描述了Sprint的目標(biāo)，但是也可以在編寫B(tài)acklog用戶故事條目時體現(xiàn)。

為了切身了解客戶的需求，有些產(chǎn)品設(shè)計(jì)的市場和研發(fā)團(tuán)隊(duì)嘗試運(yùn)用基于客戶情形，透過觀察客戶、敘說故事、編寫劇本、再現(xiàn)客戶情境和體驗(yàn)，從而溝通傳達(dá)客戶需求的劇本導(dǎo)引設(shè)計(jì)法，利用人類內(nèi)心思考、言詞表達(dá)的編故事、說故事的基本能力，將設(shè)計(jì)者及產(chǎn)品開發(fā)有關(guān)人員帶入產(chǎn)品使用時的情境，透過這種情境故事，讓設(shè)計(jì)者將與產(chǎn)品設(shè)計(jì)有關(guān)之信息自我內(nèi)化吸收，轉(zhuǎn)換對團(tuán)隊(duì)溝通。

用戶故事是從客戶的角度描述工作的一種很好的方式，如圖5-19所示。用戶描述將缺陷、問題和改進(jìn)重新集中于客戶所尋求的結(jié)果，而不是所觀察到的問題。通過向用戶故事中添加清晰的、可度量的結(jié)果，你可以此評估什么時候能完成。

圖5-19 用戶故事示例

項(xiàng)目里不同的參與者有不同的需求，產(chǎn)品經(jīng)理想跟蹤進(jìn)度，開發(fā)人員想實(shí)現(xiàn)，產(chǎn)品經(jīng)理想功能，產(chǎn)品老大有更高的視角，而用戶想要一個可用的系統(tǒng)，在這些充滿沖突的視角中，想要做出一個人人都支持、皆大歡喜的決定，并且持續(xù)保持平衡是很困難的事情。

整個項(xiàng)目組就像一個四驅(qū)車，一個角色的強(qiáng)勢就相當(dāng)于一個輪子轉(zhuǎn)得過快，這對產(chǎn)品都是損失，導(dǎo)致車子的方向偏移。

我們通過大家一起建立產(chǎn)品全景圖的方式，讓項(xiàng)目組所有人包括用戶站在高空俯視產(chǎn)品，這種同一空間多點(diǎn)對多點(diǎn)的共識就自然地完成了。

我們通過這種一目了然、格式一致的故事地圖，讓項(xiàng)目組所有人都獲得足夠的信息，讓項(xiàng)目有一個明朗的開發(fā)流程，如圖5-20所示。

用戶故事地圖作為一種有效的需求工具，可以做到多角色、多視角。

以合作溝通的方式來全面理解用戶需求，涉及的主題包括怎么以故事地圖的方式來講用戶需求，如何分解和優(yōu)化需求。如果通過團(tuán)隊(duì)協(xié)同工作的方式來積極吸取經(jīng)驗(yàn)教訓(xùn)，從中洞察用戶的需求，開發(fā)真正有價值的、小而美的產(chǎn)品和服務(wù)。

圖5-20用戶故事地圖示例

用戶故事地圖是一個吸引用戶參與設(shè)計(jì)他們所需產(chǎn)品的便捷手段。我們原型設(shè)計(jì)階段的所有內(nèi)容來源于用戶故事地圖，因?yàn)楣适碌貓D是用戶全程參與的，所以在我們整個設(shè)計(jì)過程中都有用戶的身影。

與參與性設(shè)計(jì)對立的是經(jīng)驗(yàn)性設(shè)計(jì)。

在進(jìn)行新產(chǎn)品設(shè)計(jì)時，經(jīng)驗(yàn)性設(shè)計(jì)高度依賴前期的用戶調(diào)研，包括用戶訪談和用戶觀察，但是用戶不會成為產(chǎn)品設(shè)計(jì)的真正參與者，后面的階段基本是靠設(shè)計(jì)師經(jīng)驗(yàn)，幾乎沒有用戶身影。

但參與性設(shè)計(jì)“用戶故事地圖”通過簡潔明了、場景還原的方式讓用戶參與其中，每個用戶故事都做到站在用戶的角度，使大家快速知道用戶想要什么，為什么要這個。

用戶故事易讀、易懂，我們邊聊故事的同時進(jìn)行頁面框架繪制，因此能激發(fā)用戶的積極性，成為產(chǎn)品設(shè)計(jì)的參與者。

同時，隨著用戶漸漸掌握如何口頭表達(dá)故事來描繪他們的需求，項(xiàng)目組成員與用戶間的關(guān)系變得更加親密主動，這種良性的循環(huán)使所有人員都獲益良多。

思考：以往我們共識用戶/產(chǎn)品需求的方式有兩種，一種是文檔，翻開一看，那些格式化的語言就變成了世界上最好的催眠曲。讀尚且如此，寫的人會怎么樣？寫文檔的產(chǎn)品經(jīng)理腦子里一定會回響一個問題：“這東西寫了有人認(rèn)真看么？”

有文檔看還是好的，還有些產(chǎn)品經(jīng)理會直接拉上團(tuán)隊(duì)成員聊，撰寫用戶故事地圖，就算交接需求了，這兩種方式你認(rèn)為哪種更加敏捷有效？這里的共識是點(diǎn)對點(diǎn)的，或者單點(diǎn)對多點(diǎn)的，信息傳遞也會帶來信息內(nèi)容的損耗，甚至錯誤的信息。

作者：長乘，公眾號：MVP-PM，歷任兩家世界500強(qiáng)企業(yè)產(chǎn)品專家！內(nèi)容摘自：人民郵電出版社《獨(dú)具匠心：做最小可行性產(chǎn)品（MVP）方法與實(shí)踐》

本文由 @長乘 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議