一句話評論：復(fù)習(xí)一下敏捷的12條原則，然后看看，Marty如何理解產(chǎn)品經(jīng)理在“敏捷團隊”里的角色定位。

Marty Cagan 發(fā)表于2009年6月1日，原文地址，譯者：蔣彬 / 審校：周舜莉 徐定翔

許多產(chǎn)品開發(fā)機構(gòu)都嘗試過所謂的“敏捷軟件開發(fā)”方法，其中最為流行的是“極限編程”（XP），此外還有其它一些敏捷方法，比如Crystal、Adaptive、Scrum和Pragmatic Programming等。
在使用這些敏捷方法時，產(chǎn)品經(jīng)理常常弄不清自己的角色定位。有些產(chǎn)品經(jīng)理甚至擔心采用敏捷方法會影響產(chǎn)品質(zhì)量。

我打算首先總結(jié)敏捷開發(fā)的核心原則，然后以極限編程（XP）?為例，指出極限編程的難點，以及如何更好地發(fā)揮它的作用。

敏捷方法一覽

各種敏捷方法的要求千差萬別，但是它們都遵循以下12條原則。?

1、最重要的是通過盡早地、頻繁地交付有價值的軟件來滿足客戶——盡早交付有價值的軟件。

2、?頻繁地交付可運行的軟件，數(shù)周或者數(shù)月交付一次——頻繁發(fā)布新版本。

3、可運行的軟件是衡量進展的主要標準——軟件比文檔更重要

4、接受?需求變更，即便是在開發(fā)最后階段——傾聽，并快速學(xué)習(xí)

5、項目期間業(yè)務(wù)人員與開發(fā)者共同工作——緊密協(xié)作?

6、找積極主動的人來開發(fā)項目——為他們提供所需的環(huán)境和支持，相信他們能做好自己的工作

7、開發(fā)團隊里最節(jié)省時間最有效的信息傳遞方式是面對面的交流

8、?自發(fā)組織的團隊才能做出最好的架構(gòu)、和設(shè)計——架構(gòu)要敏捷，好主意無處不在

9、?持續(xù)關(guān)注先進的技術(shù)和優(yōu)秀的設(shè)計能促進敏捷性——頻繁地重構(gòu)

10、?敏捷過程促進可持續(xù)的開發(fā)——此舉應(yīng)能維持相對穩(wěn)健的節(jié)奏——而不是?導(dǎo)致失敗

?11、簡潔是一切的基礎(chǔ)——少即是多

12、?團隊定期反思如何提高效率，并調(diào)整?工作流程——事后反思?

極限編程概覽?

要闡述?遵循敏捷方法到底意味著什么，?不妨看看敏捷方法中最為流行的極限編程的詳細規(guī)范。該方法的發(fā)明者強調(diào)，極限編程并非萬能，應(yīng)該有選擇性地加以使用。其主要原則如下。

-結(jié)對編程——兩位程序員使用同一臺電腦開發(fā)同一款軟件

-簡單設(shè)計——只設(shè)計和開發(fā)你現(xiàn)在就需要的東西，不考慮將來的潛在需求

-現(xiàn)場客戶——客戶代表入駐開發(fā)團隊，他代表了所有產(chǎn)品的需求，在開發(fā)過程中不斷的說明需求并幫助決策

-增量開發(fā)——頻敏小規(guī)模發(fā)布產(chǎn)品?，快速推動產(chǎn)品?進入理想狀態(tài)

-做好規(guī)劃——工程師只做評估，客戶決定?每次發(fā)布的功能和時間

-持續(xù)評審代碼——基于結(jié)對編程的模式，兩位開發(fā)者相互評審對方的工作

-持續(xù)測試——開發(fā)者在編碼時就撰寫單元測試，客戶則撰寫用例中規(guī)定的功能測試，?這些測試均是自動、持續(xù)地進行

-持續(xù)構(gòu)建——持續(xù)開發(fā)和整合軟件，這樣能及早發(fā)現(xiàn)問題，系統(tǒng)也一直處于可構(gòu)建的狀態(tài)

-持續(xù)重構(gòu)——軟件開發(fā)人員不懈努力，通過重構(gòu)代碼來簡化和改進工作，同時保證所有測試正常運行?

-代碼共有——與每個開發(fā)人員“獨享”?自己的代碼這一模式不同的是，極限編輯模式中每個開發(fā)人員只要認為有機會有必要，就可以優(yōu)化系統(tǒng)中任意處的任意代碼?

-開放的工作場所——指整個團隊都在一個在房間里共同工作，其中開發(fā)人員坐在中間

-每周工作40小時——限制加班以提高工作質(zhì)量?

-代碼即文檔——最有用的文檔就是軟件本身，整個團隊應(yīng)該遵循編碼規(guī)范

當然了，這種方法是從軟件開發(fā)人員的角度提出來的。在他們看來，除了程序員和用戶（客戶），就不需要其他工作人員了。這正是讓產(chǎn)品經(jīng)理感受擔憂的地方。?

產(chǎn)品經(jīng)理的工作至少包含以下三個方面。?

定義產(chǎn)品

首先弄清楚要開發(fā)什么產(chǎn)品。極限編程方法是針對定制化軟件項目提出來的，目的是滿足特定客戶的特定需求（比如內(nèi)部員工薪資系統(tǒng)），它并不適用于通用產(chǎn)品。事實上，在描述極限編程方法的圖書和文章里，幾乎很少提及產(chǎn)品管理或是界面設(shè)計。

最讓人擔憂的通常產(chǎn)品經(jīng)理能否代替現(xiàn)場客戶的作用。只有在深入研究目標用戶、理解用戶需求、使用環(huán)境以及競爭格局，產(chǎn)品經(jīng)理才能發(fā)揮最大的作用。

更讓人擔心的是產(chǎn)品設(shè)計（界面設(shè)計）角色的缺失。對于產(chǎn)品來說（不同于那些簽署合同后開發(fā)的定制軟件），用戶界面和用戶體驗至關(guān)重要，需要專業(yè)設(shè)計師運用其專業(yè)技能進行設(shè)計，因此在工作流程中引入這一重要職位非常重要。

只要把最初的迭代作為持續(xù)演進的原型并不斷檢驗，以確保開發(fā)團隊能開發(fā)出正確的產(chǎn)品，然后再在接下來的迭代中實施產(chǎn)品執(zhí)行，就能更好地利用極限編程方 法。關(guān)鍵是確保你開發(fā)的產(chǎn)品是客戶想要購買的，而且客戶能搞清楚該如何使用。只有一個客戶或是產(chǎn)品經(jīng)理理解這個產(chǎn)品并不足夠，它應(yīng)該為目標市場的廣大群體 所檢驗。

開發(fā)產(chǎn)品

其次要考慮的是，??這些用來開發(fā)可擴展、?高性能、可靠、易維護產(chǎn)品的技術(shù)會帶來什么樣的后果。這些擔憂使人馬上陷入一種近乎宗教狂熱的爭論，爭論的重 點是，什么才是開發(fā)和測試軟件的最佳方法，而這完全在產(chǎn)品管理職責(zé)之外。?產(chǎn)品經(jīng)理?只需要清晰地確定需求，然后讓技術(shù)團隊按自己認為最合適的方式來控制 風(fēng)險。?

極限編程過程依靠客戶來定義用例（又被稱為用戶故事）?，以此作為功能測試的基礎(chǔ)。這用在小型項目上或許還不錯?，但如果是大型、通用產(chǎn)品的話，有必要請 專人來負責(zé)設(shè)計必要的測試用例，以確?？蓴U展性、功能、性能、容錯性和本地化特性等。這些通常都是QA的職責(zé)，極限編程的方法完全也可以借鑒。關(guān)鍵是讓開 發(fā)人員負責(zé)單元測試，QA人員負責(zé)其它測試（比如系統(tǒng)、集成和功能測試等）?。?

部署產(chǎn)品

最后一個為人們所關(guān)注的，是產(chǎn)品的發(fā)布。人們長期以來一直認為隨著時間的推移，做出改變的成本也越來越高，但極限編程挑戰(zhàn)了這一看法。換言之，只要遵循極 限編程實踐，你可以降低開發(fā)中系統(tǒng)需要變更帶來的影響。這對于定制化軟件來說這沒錯，但對于許多商業(yè)軟件產(chǎn)品來說，變更帶來的影響仍然很大，尤其是對于擁 有大量活躍用戶群體的互聯(lián)網(wǎng)服務(wù)來說。

我曾經(jīng)探討過“平滑部署”的?策略，這些方法有助于降低極限編程項目所提倡的頻繁發(fā)布和更新策略所帶來的負面影響。

?總結(jié)

大到敏捷開發(fā)，小到極限編程方法，都是為了解決傳統(tǒng)軟件開發(fā)方法中的實際問題而創(chuàng)造的，尤其是致力于增強開發(fā)人員與客戶的溝通，節(jié)省時間及早弄清楚你所開發(fā)的產(chǎn)品是否正是客戶需要的，并減少增量開發(fā)過程中的風(fēng)險，同時優(yōu)先開發(fā)高優(yōu)化級的功能。此外還有另外一些頗有價值的技術(shù)，尤其是結(jié)對編程、增量開發(fā)、持 續(xù)集成與自動化測試等。?

?然而，對于提供商用產(chǎn)品及服務(wù)的公司來說，更重要的是將這些方法與產(chǎn)品管理、產(chǎn)品設(shè)計、質(zhì)量保證結(jié)合起來，確保你開發(fā)的產(chǎn)品能為廣大用戶和消費者使用。這樣的話才能覆蓋較廣的消費者群體。

本文節(jié)選自《啟示錄：打造用戶喜愛的產(chǎn)品》作者Marty Cagan的博客。該書從人員、流程、產(chǎn)品三個角度介紹了現(xiàn)代軟件（互聯(lián)網(wǎng)）產(chǎn)品管理的實踐經(jīng)驗和理念。特此感謝Marty Cagan先生授權(quán)。

Via：蘇杰