【51CTO專稿】我們都知道敏捷是一套流程和方法的持續改進，它能夠通過快速迭代的方式交付產品。而這個抽象的流程形式在不同項目中會根據具體的項目特征進行裁剪，這涉及到了團隊在Scrum中實施過程的規劃與拆分的問題，下面記者采訪了Thomson Reuters公司流程改進部門經理陳斌老師，給網友們分享了敏捷在項目中實施的一些主要問題。

[[68704]] 

個人簡介：陳斌老師目前任職Thomson Reuters公司流程改進部門經理，負責敏捷教練（深入開發團隊）與工具環境支持（包括工具開發及方案提供）。

10年產品/軟件開發，以及8年質量保證/流程改進經驗。經歷過無流程，重流程，輕流程的各種風格。近年來的專業領域：參與CMMI評估以全面了解軟件組織成熟度，引入敏捷原則及方法以提供應對業務挑戰的具體變革方案，應用Six Sigma方法以保證流程改進產出業務價值。

以下是采訪實錄：

記者：敏捷實踐過程中Scrum實施整個過程怎樣規劃。

陳斌老師：實施Scrum過程的第一件事情就是要明確為什么實施Scrum。目標應該是業務導向的，即解決什么痛點，預期的收益是什么，而不是敏捷轉型。通過這樣的分析，甚至可能意識到其他選擇更為適合。例如產品已進入運維期，Kanban或其他方法更適合快速響應客戶反饋。

如果確定了實施目標, 需要把信息明確傳遞給每個工作人員，作為大家共同的目標，而不僅僅是某個“工作組”的目標。

其他實施過程包括：選擇試點產品組，初期培訓，框架設立，工具選擇，組內教練，總結調整，結果度量，帶動更多產品組。選擇試點時要小心，如果試點組與其他組依賴關系很強，成功難度很高。

記者：迭代開發過程的一些困難與解決方法。

陳斌老師：最大的難點在于每個迭代都產出最有價值的產品增量，并且是有質量保證的。

前者要求能從重多需求中把握到客戶核心價值，并分解到短期可完成的完整的用戶故事。產品經理的選擇是重點。

后者要求評審，集成與測試基本同步于開發完成。測試不僅是新功能測試，還包括回歸功能測試/性能測試等。持續集成與自動化測試由此會成為高優先級任務，而不是在傳統開發模式中的“nice to have”。

記者：敏捷實踐中團隊的拆分是如何進行的？

陳斌老師：首先認清事實，同樣是合作，跨組合作遠遠難于組內合作，無論管理層如何強調。所以拆分的重點在于如何減少不必要的跨部門合作。“一站式”服務團隊是目標：從需求到上線，絕大部分環節在組內完成，協調溝通發生在組內。

當產品規模很大時（例如團隊超過100人），每個獨立團隊很難做到“什么都能做”，合理的解耦是關鍵。能夠落實到任一用戶功能能由一個團隊獨立完成（或很少的外部依賴）就可以了。

記者：如何更有效的做好開發流程估算？

陳斌老師：初始估算只能先“拍腦袋”，在迭代中參照實際調整估算，這是迭代開發的優勢之一。重點：發布計劃不能變，重大功能點不能變，具體需求細節隨時調整。

記者：敏捷實踐下的程序員工作指標將如何衡量?

陳斌老師：先衡量團隊績效。成熟的指標包括產品發布版本的缺陷數目，上線時間，與競爭對手的比較。

在團隊內部360度互評貢獻度。

記者： scrum會議，在您們的團隊中是如何進行的？

陳斌老師：管理者退一點兒，團隊成員進一點兒。

記者：團隊中是否有敏捷測試人員？需要哪些技能？

陳斌老師：有。一方面強調團隊整體對質量負責，對測試負責；另一方面在團隊真正成熟前，專職的測試人員能保證“測試”任務不被功能任務擠掉，同時測試人員的獨立視角很有幫助。

全功能團隊不是說每個人都作同樣的工作，而是沒有職能“邊界”與灰色地帶。

記者： 敏捷教練在Scrum中如何進行角色轉換？

陳斌老師：能進而作為角色榜樣，而目標在于退出團隊角色時團隊運轉良好并在自我優化。

記者：對于未來幾年敏捷開發的發展，您希望看到哪些新方向?有何建議?

陳斌老師：迭代開發，持續集成等已深入人心。難點在兩頭，也是努力的方向：組織結構（包括文化，部門劃分，績效考評）和深入的工程實踐（例如測試開發同步）。