大型軟體產品的敏捷案例 -分享

• 分割及組織團隊
• 分割及編排計劃
• 立即開始並持續改進
• 逐步克服長期挑戰

分割及組織團隊

tips：1.把團隊組織在一個開放空間中
2.儘可能在多放置白板
3.調轉座椅就能開會 分享１：跨職能團隊＋特性團隊  跨職能團隊：

1. 完成一項功能的設計，開發與測試的過程不需要進行文檔化的握手過程
2. 極大的減少了溝通和傳遞中的噪音和偏差，並且大大降低了溝通成本
3. 群體決策成為可能，使得集體的智慧（Wisdom of the crowds)得以發揮，給了每個成員更大的技術視野

特性團隊：

1. 同一團隊關注在同一功能模組，在同一時間段大家聯合做同一個功能。
2. 成員間通過幫、傳、帶使領域知識不只是積累在文檔中，而且積累在團隊中，使得每個人都不是不可替代的。

是否一定要由Senior成員構成的團隊才能發揮Scrum的作用?：

1. 不一定。更多的Senior的成員能提升團隊的效率，但是團隊的最終效率是由團隊成員的配合度來決定。
2. Scrum方法中大家高度協作，每個人的主動性被激發起來後，能很好的提升團隊的整體作戰能力，Junior成員也能很快的從Senior成員那邊學到很多東西。
3. 由於同一個團隊關注的是相近的功能，採用ＰＰ的方法，能很好的促進學習，並能極大的營造團隊的學習氣氛。

分享２：做好開發服務是發揮作用的關鍵 工程基礎設施專人專職：

1. 專人負責開發測試環境的維護，持續整合體系的構建和看護
2. 使得每個Team Dev不需要分心於基礎設施
3. ＰＯ及使用者故事團隊全程參與，隨叫隨到：
4. 對需求的澄清隨時可以進行
5. 需求人員在開發過程中即參與需求的驗證和糾正

專職教練： 　　旁觀者清，需要一個看得清楚，並一直思考的人來持續的發現問題並促進集體思考專職教練能很好的協助團隊對抗團隊慣性（或者叫“組織重力”）2.分割及編排計劃
　　　　1.嚴格的保證10個工作日的Sprint長度，節假日不例外
　　　　2.如果一個Sprint不能在固定時間長度內結束，在中間要進行內容的調整，但是不能延長時間
　　　　3.Scrum執行成功的關鍵是協助團隊找到固定的節奏感
分享３：基於”客戶價值“的計劃 編排目標，而非編排任務：

1. 先把每一個Subrelease和每一個Sprint的營運目標定下來，根據營運目標來分解使用者故事。
2. 永遠先做優先順序高的事情，優先順序低的事情由使用者故事團隊持續的與客戶協商。

及早開始，逐步清晰，及時調整：

1. 讓使用者故事的細化與開發並行起來，儘早開始開發，為開發工作騰出更多的時間使用Sprint0來解決大的方案和技術風險
2. 在每個Sprint中預留１０％～２０％的時間準備下一個Sprint

不斷調整，不停檢視：

1. 每個Subrelease結束前一個Sprint重新進行Release planning，進行大的變更管理
2. 每個Sprint review結束後，調整Product backlog的內容及優先順序

• 立即開始並持續改進

分享４：改進，改進，再改進

  定義清晰的ＤＯＤ：

1.   DOD是一種Commitment，而不是一種監管手段
2.   Owner of DOD的使命是讓團隊理解，而不是強迫團隊執行
3.   品質來自於團隊意識，而不是來自於測試

  讓團隊自學習：

1.   Sprint不是微型的瀑布，讓團隊成員自己打配合
2.   盡量多的ＰＰ
3.   允許團隊犯錯誤，協助團隊分析原因

  穩定然後再提高：

1.   Scrum不會加快開發速度，團隊配合效率的提高才能提高速度
2.   假設一個Velocity然後不斷的較正
3.   盡量確保團隊穩定

• 逐步克服長期挑戰

  技術債務

1.   慢慢的補齊欠缺的單元測試及自動化
2.   週期性組織重構活動
3.   每個Sprint的review中加入defect review and summarize

  協調敏捷的方法與ＰＭＯ監管

1.   爭取公司管理層的認同
2.   將使用者故事測算轉化成傳統PMP的測算值
3.   鼓勵PMO參與Sprint review

  打造高效的團隊

1.   團隊發展的三個層次:forming, storming, performing
2.   給團隊適中的壓力
3.   組織長效的培訓計劃，鼓勵學習與分享
4.   保持團隊穩定