本文做者：HelloDeveloper分佈式
InfoQ 和百度共同舉辦的第七期百度技術沙龍中，特邀嘉賓百度項目管理部高級工程師宋金永和淘寶搜索廣告引擎團隊的 Scrun Master 鄒磊與參會者分享了各自的敏捷開發實踐經驗。本文將簡要總結了他們的演講內容，並提供相關音視頻、演講資料下載。工具
首先是百度項目管理部高級工程師宋金永給咱們分享他們引進敏捷後，結合自身實際作出一系列準備和推動過程當中的體驗。性能
百度技術團隊在開始引進敏捷的時候，你們也在疑惑敏捷會水土不服嗎？但其實敏捷是一種思想，主要包括溝通、簡單、反饋、勇氣等四個要素。敏捷思想的核心精髓是小勝 + 反思，這和百度的價值觀有些相似，即簡單，可依賴。另外百度技術開發還有另一個原則：迅速迭代，越變越美，容許試錯等也與之相吻合。因此，總體上來講，百度一向堅持的文化核心和技術開發原則與敏捷思想的精髓是一致的，水土不服的問題是不存在。單元測試
那麼在開始正式實施以前，百度技術團隊作了哪些準備呢？測試
簡單來講，先是對照敏捷的思想，找出本身的優點，好比項目基本都是迭代開發，也執行了分級；測試實現部分自動化；具有項目管理和開發平臺；擁有簡單可依賴的文化等。而後再找出本身的不足，好比迭代規劃方法不太合理；項目溝通與協做機制有待增強；存在一些低效的流程環節；單元和自動化測試在工具方法上欠缺；強化的組織結構影響團隊目標的一致性等。最後，在發現本身的優點和不足後，肯定目標，找到最佳突破點。經過以上分析，他們最終找準了本身引進敏捷的目標——提高效率。同時也找到了兩個關鍵切入點，一是充分發揮人的主動性和能動性；第二就是創建自適應方法集和項目管理體系。就這樣，最終的結果就是，經過一系列的調研他們把握住了真正須要提高的核心，取得了上級領導的支持，開始了試點並逐步擴大。優化
那他們又是如何推動敏捷實施的呢？搜索引擎
他們針對業務需求型和技術型項目分別採起了不一樣的措施：針對業務需求型項目統一團隊目標，優化需求管理，提升流程效率的方式；而對技術型的項目則在單元測試、自動化迴歸等方面作功夫。spa
固然在執行的時候也碰到了很多問題，但由於事先準備的充分，也都一一被有效的解決掉。最後他對百度引進敏捷後帶來的變化進行了總結，第一，引進敏捷以後，原有的 SQA 團隊轉型成項目管理結構，造成一個堅強的組織來實現敏捷開發；第二，在產品的研發效率和改進思想上找到一些具體的點，讓他們變得更有體系。設計
在演講報告的問答環節上，聽衆對如何創建目標團隊一致上和項目部如何才能落實提出了疑問。宋金永作了這樣的回答：code
百度在創建目標團隊一致上有不少作法，其中把相關強職能部門結合成一個事業部的作法最有效果，固然不是全部強職能部門都適合這樣，對仍然須要強職能部門分佈式團隊的產品線，沒有具體的一我的負責的時候，就引入一個有效的活動或者方法來完成。另外就是項目部的必須有一個至關的地位，否則太末端的話，項目管理部不可能充分的發揮其職能。
以後是在淘寶廣告搜索引擎團隊的鄒磊和咱們分享了 Scrum 在他們團隊中的實施狀況，以及做爲一名 Scrum Master 在整個 Scrum 實施過程當中的困惑和思考。
淘寶廣告搜索引擎團隊的業務特色很是適合 Scrum 的開發模式，在演講的一開始鄒磊就向咱們介紹了他們團隊業務的特色：
支持的業務多；需求變化頻繁；產品發佈頻繁；對產品的穩定性和性能要求高等。
針對他們業務的特色結合 Scrum 模式，他們團隊分紅四個部分：產品經理、開發團隊、測試團隊和 PE 團隊。開發流程分爲四個階段：需求、設計、開發和上線。
在需求階段，產品經理提出具體需求，根據優先級進入需求池；開發團隊確認項目經理統籌安排，結合產品經理、開發和測試團隊進行需求和功能的羅列，三方通力合做，進行功能列表的 review，作出設計計劃，並郵件通知全體。進入設計階段，項目經理創建項目 twiki，設計人員開始進行迭代 review，達成一致後，項目經理組織全體人員進行 review，隨時把出現的狀況通知到相關負責人。一切穩當以後，設計人員開始開發階段，對項目進行人日估算，包括開發、code review、開發測試、開發人員內部集成測試等，調動資源，確認項目時間。上線前一週，項目經理通知 PE 團隊，作好上線前的準備，進行風險評估、冒煙測試等工做，確保產品完成上線。
整個實施的過程能夠說是痛並快樂着，剛剛開始的時候，各個環節都不一樣的存在着這樣或那樣的問題，晨會、項目計劃會、code review、設計、項目總結會都不一樣程度的存在着不和諧。不斷的發現問題不斷的解決問題，痛苦與快樂交織並存。
最後，鄒磊提出了他做爲 Scrum Master 在工做中的困惑：
目前他 70% 的時間在作開發，不知業內是否是其餘 Scrum Master 也這樣作；還有 SCRUM 講究主動性，由團隊成員領取任務，可是將最合適的任務分配給最合適的人，是否是就是最佳的方式？另外就是沒法估出複雜項目的準確人日，給團隊帶來負面的影響的困擾等。
在最後的互動環節裏，有人問道 Scrum Master 的技術操做和背景以及項目若是是兩地合做的話應該怎樣處理的問題，鄒磊一一作出了詳細的回答：
在咱們的部門裏 ScrumMaster 的開發任務是偏重的，瞭解不少 Scrum Master 都存在這樣的問題。Scrum Master 不必定是部門裏技術背景最強的，可是必需要對產品線有充分的瞭解，以及對團隊人員的熟悉，不然會影響對整個開發時間的統籌。
至於兩地合做項目問題，他們本身就是在杭州和北京並行，許多項目就是兩個地方的技術力量合做完成的。這就牽扯的項目經理責任制，解決辦法就是會議和郵件。他我的偏向郵件，經過郵件把進度點公佈給相關人員，尤爲是領導們知道，更有利於本身開發的進展，也有利於你們對進度的把握。
這次會後，有些參會者在博客上發表的本身的感覺，好比來自「綠城社區」的一篇博客：做者感受這樣的活動豐富了本身的週末生活，文中寫道：「而最吸引個人，是沙龍中的 Open Space 環節，極富互動性！」。能夠看出做者對 OpenSpace 的互動環節由衷的喜好。