起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識敏捷開發方法
一句話評論：復習一下敏捷的12條原則，然后看看，Marty如何理解產品經理在“敏捷團隊”里的角色定位。
Marty Cagan 發表于2009年6月1日，原文地址，譯者：蔣彬 / 審校：周舜莉 徐定翔
許多產品開發機構都嘗試過所謂的“敏捷軟件開發”方法，其中最為流行的是“極限編程”（XP），此外還有其它一些敏捷方法，比如Crystal、Adaptive、Scrum和Pragmatic Programming等。
在使用這些敏捷方法時，產品經理常常弄不清自己的角色定位。有些產品經理甚至擔心采用敏捷方法會影響產品質量。
我打算首先總結敏捷開發的核心原則，然后以極限編程（XP）?為例，指出極限編程的難點，以及如何更好地發揮它的作用。
敏捷方法一覽
各種敏捷方法的要求千差萬別，但是它們都遵循以下12條原則。?
1、最重要的是通過盡早地、頻繁地交付有價值的軟件來滿足客戶——盡早交付有價值的軟件。
2、?頻繁地交付可運行的軟件，數周或者數月交付一次——頻繁發布新版本。
3、可運行的軟件是衡量進展的主要標準——軟件比文檔更重要
4、接受?需求變更，即便是在開發最后階段——傾聽，并快速學習
5、項目期間業務人員與開發者共同工作——緊密協作?
6、找積極主動的人來開發項目——為他們提供所需的環境和支持，相信他們能做好自己的工作
7、開發團隊里最節省時間最有效的信息傳遞方式是面對面的交流
8、?自發組織的團隊才能做出最好的架構、和設計——架構要敏捷，好主意無處不在
9、?持續關注先進的技術和優秀的設計能促進敏捷性——頻繁地重構
10、?敏捷過程促進可持續的開發——此舉應能維持相對穩健的節奏——而不是?導致失敗
?11、簡潔是一切的基礎——少即是多
12、?團隊定期反思如何提高效率，并調整?工作流程——事后反思?
極限編程概覽?
要闡述?遵循敏捷方法到底意味著什么，?不妨看看敏捷方法中最為流行的極限編程的詳細規范。該方法的發明者強調，極限編程并非萬能，應該有選擇性地加以使用。其主要原則如下。
-結對編程——兩位程序員使用同一臺電腦開發同一款軟件
-簡單設計——只設計和開發你現在就需要的東西，不考慮將來的潛在需求
-現場客戶——客戶代表入駐開發團隊，他代表了所有產品的需求，在開發過程中不斷的說明需求并幫助決策
-增量開發——頻敏小規模發布產品?，快速推動產品?進入理想狀態
-做好規劃——工程師只做評估，客戶決定?每次發布的功能和時間
-持續評審代碼——基于結對編程的模式，兩位開發者相互評審對方的工作
-持續測試——開發者在編碼時就撰寫單元測試，客戶則撰寫用例中規定的功能測試，?這些測試均是自動、持續地進行
-持續構建——持續開發和整合軟件，這樣能及早發現問題，系統也一直處于可構建的狀態
-持續重構——軟件開發人員不懈努力，通過重構代碼來簡化和改進工作，同時保證所有測試正常運行?
-代碼共有——與每個開發人員“獨享”?自己的代碼這一模式不同的是，極限編輯模式中每個開發人員只要認為有機會有必要，就可以優化系統中任意處的任意代碼?
-開放的工作場所——指整個團隊都在一個在房間里共同工作，其中開發人員坐在中間
-每周工作40小時——限制加班以提高工作質量?
-代碼即文檔——最有用的文檔就是軟件本身，整個團隊應該遵循編碼規范
當然了，這種方法是從軟件開發人員的角度提出來的。在他們看來，除了程序員和用戶（客戶），就不需要其他工作人員了。這正是讓產品經理感受擔憂的地方。?
產品經理的工作至少包含以下三個方面。?
定義產品
首先弄清楚要開發什么產品。極限編程方法是針對定制化軟件項目提出來的，目的是滿足特定客戶的特定需求（比如內部員工薪資系統），它并不適用于通用產品。事實上，在描述極限編程方法的圖書和文章里，幾乎很少提及產品管理或是界面設計。
最讓人擔憂的通常產品經理能否代替現場客戶的作用。只有在深入研究目標用戶、理解用戶需求、使用環境以及競爭格局，產品經理才能發揮最大的作用。
更讓人擔心的是產品設計（界面設計）角色的缺失。對于產品來說（不同于那些簽署合同后開發的定制軟件），用戶界面和用戶體驗至關重要，需要專業設計師運用其專業技能進行設計，因此在工作流程中引入這一重要職位非常重要。
只要把最初的迭代作為持續演進的原型并不斷檢驗，以確保開發團隊能開發出正確的產品，然后再在接下來的迭代中實施產品執行，就能更好地利用極限編程方 法。關鍵是確保你開發的產品是客戶想要購買的，而且客戶能搞清楚該如何使用。只有一個客戶或是產品經理理解這個產品并不足夠，它應該為目標市場的廣大群體 所檢驗。
開發產品
其次要考慮的是，??這些用來開發可擴展、?高性能、可靠、易維護產品的技術會帶來什么樣的后果。這些擔憂使人馬上陷入一種近乎宗教狂熱的爭論，爭論的重 點是，什么才是開發和測試軟件的最佳方法，而這完全在產品管理職責之外。?產品經理?只需要清晰地確定需求，然后讓技術團隊按自己認為最合適的方式來控制 風險。?
極限編程過程依靠客戶來定義用例（又被稱為用戶故事）?，以此作為功能測試的基礎。這用在小型項目上或許還不錯?，但如果是大型、通用產品的話，有必要請 專人來負責設計必要的測試用例，以確保可擴展性、功能、性能、容錯性和本地化特性等。這些通常都是QA的職責，極限編程的方法完全也可以借鑒。關鍵是讓開 發人員負責單元測試，QA人員負責其它測試（比如系統、集成和功能測試等）?。?
部署產品
最后一個為人們所關注的，是產品的發布。人們長期以來一直認為隨著時間的推移，做出改變的成本也越來越高，但極限編程挑戰了這一看法。換言之，只要遵循極 限編程實踐，你可以降低開發中系統需要變更帶來的影響。這對于定制化軟件來說這沒錯，但對于許多商業軟件產品來說，變更帶來的影響仍然很大，尤其是對于擁 有大量活躍用戶群體的互聯網服務來說。
我曾經探討過“平滑部署”的?策略，這些方法有助于降低極限編程項目所提倡的頻繁發布和更新策略所帶來的負面影響。
?總結
大到敏捷開發，小到極限編程方法，都是為了解決傳統軟件開發方法中的實際問題而創造的，尤其是致力于增強開發人員與客戶的溝通，節省時間及早弄清楚你所開發的產品是否正是客戶需要的，并減少增量開發過程中的風險，同時優先開發高優化級的功能。此外還有另外一些頗有價值的技術，尤其是結對編程、增量開發、持 續集成與自動化測試等。?
?然而，對于提供商用產品及服務的公司來說，更重要的是將這些方法與產品管理、產品設計、質量保證結合起來，確保你開發的產品能為廣大用戶和消費者使用。這樣的話才能覆蓋較廣的消費者群體。
本文節選自《啟示錄：打造用戶喜愛的產品》作者Marty Cagan的博客。該書從人員、流程、產品三個角度介紹了現代軟件（互聯網）產品管理的實踐經驗和理念。特此感謝Marty Cagan先生授權。
Via：蘇杰
- 目前還沒評論，等你發揮！
