模板
教程
環境
性能
功能
管理
我是如何和產品線溝通敏捷軟件開發方法的？
【做為敏捷教練需要和開發團隊溝通為什么需要敏捷軟件開發方法。這往往不容易講清楚，因為每個團隊的特點是不一樣的，需要根據團隊和產品的特點入手來講，要條理清晰、循序漸進、由淺入深。以下是我和百度的一個產品線溝通的方式，寫出來和大家分享?！?/p>
【首先要肯定人家已經取得的成績，確實很棒!】
接觸xxx團隊一段時間了，我非常喜歡這個團隊，也對你們取得的成績感到驕傲。下面想和大家分享一下我的一些想法和建議。
1. 如何加快產品演進速度和效率?
【用問題帶領陳述】
我們的產品目前還處在早期探索階段，在這個階段用戶需求和產品形態都還不完全明確。在這個階段最重要是如何盡快摸清用戶的需求。但如何搞清楚呢?手段有多種，不過最有效的方式肯定是真實用戶的行為反饋。這點沒有異議。這個反饋環大概是這樣的：
這是個不斷循環的過程，循環反饋的速度越快，我們就能越快達成目標：即定位用戶需求，確定解決方案。
這個階段的效率主要體現在“整個反饋速度”上面，而其中“研發”是環節之一。 加快反饋速度有兩點：
1. 單次循環的負載：每次任務越少，循環速度越快
2. 循環中每個環節的效率：效率越高，循環速度越快
a) 產品構思：PM及各老大
b) 代碼實現：RD/QA等
c) 數據驗證：PM為主，RD支撐
2. 如何實現這兩點?(降低單次循環的負載，提高各環節效率)
這個是個PM-RD各環節聯動的問題。簡單說就是：
1)輕量級的輸入
2)快速迭代，持續交付
3)需求和驗證方法同時提出，同時交付
4)統一需求管理，明確優先級
2.1. 輕量級的輸入
需求要細分成小片符合INVEST原則的條目，INVEST =
l Independent：相對獨立
l Negotiable: 可協商的，就是大家都能看懂的(PM,RD,QA,FE,以及各位老大)
l Valuable：對用戶有價值
l Estimable：交付工作量可估計
l Size properly：大小合適(根據項目特點，一般2-10人天)
l Testable：可測試的
這樣就可以以輕量級的輸入驅動每次的循環。而只有每次相對獨立的輸入才能取得最佳的驗證效果。
2.2. 快速迭代，持續交付
只有具備持續快速交付的能力，才能支持小批量的需求實現。我們有時也能快速交付，但是通過：
1)不可持續的額外努力：加班
2)犧牲一定的質量(對early adopter可以接受的)
3)技術債務(需要后期彌補，否則影響后續交付速度)
這三種方式達成的。這不是可持續的。
我們的常態還是瀑布式的大批量生產模式。原因有很多，其中一點是為了降低每次測試發布的overhead成本，因為每次改動都需要相對大的成本進行測試以便達到發布需要的質量。其實這點是可以改變的。我們在小批量生產時也可以控制每次測試和發布的overhead成本，如何做呢?有以下幾點：
l 持續集成(程序員六步提交法，代碼同源，每日構建，等等)
l 自動化功能測試(包括單元測試、自動化功能測試、quick/slow測試，等)
l 代碼評審，結對編程(內建質量)
l 每日站會，可視化管理(高效信息共享、消除浪費、流程持續優化)
l 等等
產品質量是在生產環節中內建的，而不是靠后期大規模檢測取得的。只要我們在需求、設計、編碼、自測的各個環節中都關注質量，不盲目以質量(長期利益)換時間(短期利益)，才能逐步地有計劃地增強持續交付的能力。
2.3. 需求和驗證方法同時提出，同時交付
為了保證需求能被快速驗證，可能需要做以下幾件事：
1) 每個需求都有驗證方法
2) 驗證方法是需求的一部分，要同時給RD
3) RD要確保驗證方法和需求一起實現，一起交付
4) PM依據事先制定的驗證方法進行驗證，并快速知會各方：RD等
5) PM調整需求列表，進入下一次循環 這樣我們就可以形成一個良性循環，不斷加快試錯速度。
2.4. 統一需求管理，明確優先級
在重要項目中，我們需求的來源是多方面的，那統一需求管理就變得額外重要了，否則很難系統地提高產品整體反饋速度。
特別是需要明確優先級：雖然RD等各部門的工作有各種依賴關系，但有了需求方的明確優先級，內部資源協調時，雞翅項目負責人才有法可依，否則就可能導致功能團隊的局部優化。
同時將需求細化到合適的粒度：合適的粒度是指所有利益相關人都可以理解的粒度。如果粒度太大，程序員無法對應到具體實現;如果粒度太小，PM或其他干系人無法了解進展。所以按INVEST原則進行需求拆分是關鍵。
【謙虛謹慎，不要托大】
以上是我的一些淺見，也很愿意有機會詳細交流。
