講師: 李智樺 職稱: 架構師 Waveface corp. 崴峰科技 AAP301 研發主管的管理實踐 - 建立敏捷開發的團隊 講師: 李智樺 職稱: 架構師 Waveface corp. 崴峰科技

Scrum / Agile 敏捷開發 1. Scrum 敏捷開發是什麼? 解決哪些專案管理上的 2. 開發團隊如何管理及適當的管理工具。 問題? 2. 開發團隊如何管理及適當的管理工具。 3. 從版本管控到持續產出(Continuous Delivery)， 進而到使用者的持續回饋(Continuous Feedbacks) 如何進行。 參考場次: AAP302 徐鈞安 Scrum 敏捷開發與 Team Foundation Server 2012 新功能 AAP303 胡百敬軟體測試實務與 Visual Studio 2012

SCRUM 的歷史 •1986年, 竹內弘高 和 野中郁次郎闡述了一種新的整體性的方法 ，該方法能夠提高商業新產品開發的速度和靈活性：他們將這種新的'整體性方法與橄欖球相比較, 前者各階段相互重疊，並且由一個跨職能團隊在不同的階段完成整個過程, 而後者整個團隊"tries to go to the distance as a unit, passing the ball back and forth"。 ◦他們對來自汽車，照片機器，計算機和印表機等產業的案例進行了研究。 •1991年, Peter DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一書中將這種方法稱為 [ Scrum ]，在竹內弘高和 野中郁次郎的文章中提到的橄欖球術語。 •1990年代初, 肯•施瓦伯在其公司使用了一種方法Advanced Development Methods(先進開發方法)，這種方法後來發展為Scrum。 •同時，傑夫•薩瑟蘭在Easel公司開發了一種類似的方法，並首次稱之為Scrum。 •1995年，在奧斯汀舉辦的OOPSLA '95上，薩瑟蘭和施瓦伯聯合發表了論文首次提出了Scrum概念。施瓦伯和薩瑟蘭在接下的幾年裡合作，將上述的文章，他們的經驗，以及業界的最佳實踐融合起來，形成我們現在所知的 Scrum。 •2001年，施瓦伯與 麥克·比竇（Mike Beedle）合著了《敏捷軟體開發-使用Scrum過程》一書，介紹了Scrum方法。

SCRUM 的歷史 •1986年, 竹內弘高 和 野中郁次郎闡述了一種新的整體性的方法 ，該方法能夠提高商業新產品開發的速度和靈活性：他們將這種新的'整體性方法與橄欖球相比較, 前者各階段相互重疊，並且由一個跨職能團隊在不同的階段完成整個過程, 而後者整個團隊"tries to go to the distance as a unit, passing the ball back and forth"。 ◦他們對來自汽車，照片機器，計算機和印表機等產業的案例進行了研究。 •1991年, Peter DeGrace和 Stahl在《Wicked Problems, Righteous Solutions》一書中將這種方法稱為 Scrum，在竹內弘高和 野中郁次郎的文章中提到的橄欖球術語。 •1990年代初, 肯•施瓦伯在其公司使用了一種方法Advanced Development Methods(先進開發方法)，這種方法後來發展為Scrum。 同時，傑夫•薩瑟蘭在Easel公司開發了一種類似的方法，並首次稱之為 Scrum。 •1995年，在奧斯汀舉辦的OOPSLA '95上，薩瑟蘭和施瓦伯聯合 發表了論文首次提出了Scrum概念。施瓦伯和薩瑟蘭在接下的幾 年裡合作，將上述的文章，他們的經驗，以及業界的最佳實踐融 合起來，形成我們現在所知的 Scrum。 •2001年，施瓦伯 與 麥克·比竇（Mike Beedle）合著了《敏捷軟體開發-使用Scrum過程》一書，介紹了Scrum方法。

SCRUM framework 肯•施瓦伯 傑夫•薩瑟蘭 2012 Microsoft

SCRUM framework

Scrum 肯•施瓦伯 A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is: Lightweight Simple to understand Extremely difficult to master

Scrum 過程 Scrum是一個包括了一系列實踐和預定義角色的過程框架。 Scrum中的主要角色包括與專案經理有一點類似的Scrum Master角色，負責維護過程和任務，產品負責人(Product Owner)代表利益所有者，開發團隊 包括了所有開發人員。 在每一次衝刺 Sprint（一個15到30 天週期 ，長度由開發團隊決定），開發團隊開發可用的（可以隨時推出）軟體的一個增量。 每一個衝刺所要實現的特性來自產品訂單（product backlog)， 產品訂單是按照優先順序排列的要完成的工作的概要的需求。那些訂單項會被加入一次衝刺由衝刺計劃會議決定。 在會議中，產品負責人告訴開發團隊他需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次衝刺中他們能夠承諾完成多少訂單項。在衝刺的過程中，沒有人能夠變更衝刺訂單(sprint backlog)，這意味著在一個衝刺中需求是被凍結的。 管理Scrum過程有很多實施方法，從白板上的即時貼到軟體工具。 Scrum最大的好處是它非常容易學習，而且應用Scrum不需要太多的投入(才怪~)。

Scrum 也可以用在其他地方 《用作行銷專案管理方法》 由於市場行銷通常以專案的方式運作，許多一般專案管理的原則應用在市場行銷上。市場行銷也可以像專案管理技術那樣進行優化。 以Scrum方法進行市場行銷被認為有助於克服市場營銷經理們所遇到的問題。短時和固定的會議對於小的市場營銷團隊來說很重要，這是因為團隊的每一個成員都可以了解其他人在做些什麼，以及整個團隊在朝著什麼方向前進。Scrum在市場行銷中應用可以： •在早期發現可能的問題，可以更快地，最小損失地應對問題。 根據Scrum的主要原則 「沒有問題被掃入地毯下」，Scrum鼓勵每一個團隊成員描述他所遇到的困難，而這個困難可能會對整個團隊的工作造成影響。 •降低財務風險。 在每一個衝刺周期的開始，企業所有者可以不付出任何代價的改變任何市場營銷的因素：包括增加投資以誇大顧客數量，減少投資直至未知風險被減輕，或用於支持其他活動。 •使得市場行銷計劃更靈活。 採用衝刺的短期市場營銷計劃可以更加有效。如果一種促銷方法在衝刺過程中顯示無效，市場營銷經理有機會將其換成另一種促銷方法。向每一個團隊成員說明每一個小的，但重要的任務的交付時間也變得更容易。 •使得客戶以不同的方式參與。

從哪裡開始 Scrum角色和職責 產品負責人 (Product Owner) Scrum Master 團隊 定義開發目標，需要實現的feature和優先順序 Scrum Master 保證團隊高效而不受打擾地工作，優化工作條件、過程 團隊 自組織地完成專案開發，使用一切可行手段保證進度和品質

Scrum 的精髓 Scrum是一個“檢查並適應”的框架，在三個角色（產品負責人/Scrum Master/團隊）、 四種會議（Sprint計畫/Sprint展示/ Sprint回顧/每日例會）和三種製品（產品Backlog/Sprint Backlog/燃盡圖 Burn down chart）的基礎上。 你可以根據公司或者專案的情況，因地制宜引入任何有利於縮短開發週期、提高產品品質的實踐。

實施Scrum — Sprint 前 產品負責人（PO）收集整理產品需求，形成產品Backlog。 產品負責人可以通過任何管道、方式獲取和確認需求。

實施 Scrum — Sprint (1) 產品負責人、Scrum Master和團隊成員（包括QA）召開Sprint會議，Scrum Master主持會議。 Sprint會議上詳細溝通產品負責人選定的重要性高的產品Backlog細節，確保團隊對需求的理解無誤。 團隊就對需求的理解將Backlog拆分成任務，並給出每個Backlog的估算時間。 產品負責人和團隊根據Sprint內可用的人天和Backlog的時間估算，選定需要排入本次Sprint的Backlog 。 Scrum Master和團隊分派任務，制定Sprint計畫。 一個Sprint的週期是兩周；一次Sprint會議時間大約一個下午。

實施 Scrum — Sprint (2) 整理一面任務牆，將Sprint內的Backlog和任務按照待辦事項(To do)、進行中(In progress)、已完成(Completed)等狀態進行歸類；同時展示Sprint的燃盡圖。 Scrum Master每日早上固定時間組織團隊的每日例會，確認每個成員前一天完成的工作、當天要進行的工作、工作中碰到的困難或issue，並更新任務牆。 任何需求變更都進行即時評估，超過規劃人天的Backlog視情況進行拆分或者推遲其他重要性低的Backlog。 任何完成的Backlog都需要演示給產品負責人和QA後才能夠交付測試。

SCRUM 的任務牆 任務牆: 傳統白板+便利貼 任務牆: 瀏覽器

Scrum — Sprint後 Scrum Master召集、組織Sprint展示會議 展示會議: 展示這個Sprint的開發結果。 回顧會議以頭腦風暴的方式Review Sprint過程和結果，發現和列舉存在的問題。 與會人員投票決定需要在下個Sprint中解決的1-3個問題， 探討解決方案，確定實踐方式。

Scrum 精神 團隊目標重於個人職責 團隊工作優於獨立作戰 高效溝通強於標準化的文件 高動能性的、自組織的團隊勝於角色劃分清晰的流水線 務實的解決問題的方法好於經典理論 快速實踐，快速回饋，持續優化

scrum in pseudo code DEMO 三個角色 四個會議 三種 工作物件

需求: 「開發一個開發專案的架構」 開發團隊可以專心的從事開發的作業，而不受到外部的干擾。如此一來便能夠擁有良好的開發進度。（團隊） “As a <role> , I want <goal/desire> so that <benefit>“ 身為 ，我希望 從此以後 開發團隊可以專心的從事開發的作業，而不受到外部的干擾。如此一來便能夠擁有良好的開發進度。（團隊） 控管專案的人員可以每天都清楚的知道專案的進度及是否遇到困難。如此便能盡快排除這些障礙，讓專案順利進行。（scrum master) 使用者可以盡早看到那些項目已經被完成，並給予回饋讓方向不致錯誤。（product owner)

Run Scrum() 三個角色，四個會議，三種 工作物件 { const int Sprint_Length = 2*5; // 設定 2周為一個 Sprint 週期 int velocity = get_past_performance(); // 依據過去的紀錄 // Scrum 中的三個角色 Role team=new Role(), product_Owner=new Role(), ScrumMaster=new Role(); // Scrum 中的artifacts製品 Product_Backlog product_backlog = new Product_Backlog(); Sprint_Backlog sprint _backlog=new Sprint_Backlog(); Burndown_Chart sprint_burndown_chart=new Burndown_Chart(), release_burndown_chart=new Burndown_Chart(); Product_Increment product_increment=new Product_Increment(); //開始專案的三個準備條件 setup_team(team); define_Definition_of_Done(team, product_owner); initial_project(); //每一次while 迴圈為一次反覆運算 while( product_backlog_item_hasvalue() && time_remaining()) run_sprint_planning_meeting(product_backlog, velocity, product_backlog); //daily 迴圈為一個工作日 for (num_of_day = 1; num_of_day <= Sprint_Length; num_of_day++) run_daily_scrum_meeting(sprint_burndown_chart); do_development_activity(sprint_backlog, product_increment); } run_sprint_review_meeting(product_backlog, product_increment); run_retrospective_meeting(); update_product_backlog(product_backlog, release_burndown_chart); update_velocity( velocity);

一些你一定會遇到的問題 專案完成時間如何估計? 加班有用嗎? 真的可以做到在Sprint周期內不受外部打擾嗎? 客戶真的能加入開發團隊嗎? - 使用者故事太抽象了。 進度不佳如何是好? 品質不佳如何是好? 離職/交接?

開發團隊持續交付價值 - 滿足使用者及企業目標 開發團隊持續交付價值 - 滿足使用者及企業目標 需求 使用者/ 關鍵人物 定義 具體概念 PRODUCT BACKLOG 實務學習及 有效回饋 App 及系統維運人員 監控 實作 開發 建置軟體 的理念 持續交付價值 營運 使用中的App或上 線的系統 實現價值 Identifying and eliminating team integration barriers and impediments enable organizations to deliver a continuous flow of value with their software investments. Addressing such is not an all or nothing investment. Organizations can identify the value delivery impediments that impact them the most and apply contextual solutions to address. Over time, organizations can explore and adopt broader practices to further optimize value delivery cycle times. Presenter TODO : Switch back to the prior slide, have audience select impediments of interest, and discuss solution options to address. See the ALM Solutions section of this deck for information on solution patterns to address impediments across the Define, Develop, and Operate lifecycle phases. 開發 & 測試 OPERATIONS BACKLOG 使用中的App或系統 - 共享模組與平台

<Conference/Group Name> 9/11/2017 持續增值的開發 定義 價值的定義與概念 營運 部署持續的改善 管理 Backlog 和 sprint 視覺化工作面板 Storyboard 工具 MEAN TIME TO REPAIR CYCLE TIME PRODUCT BACKLOG OPS BACKLOG Sprint 監控 開發 將概念化為軟體 © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

為何需要工具? -- 傳統使用白板/便利貼不是很好嗎?為何還需要數位化管理工具。   要與Work Item, Version Control & CI 系統整合 – 以 免又要重key一次，有重工。      多人/多地協同工作。 除了 Burndown Chart外，一些基本的指標 (Active Workitem, bugs, feedbacks ….)    成員資訊透通 (TFS 2012 的Web  Dashboard連接小組)

Code Review 程式碼檢閱 程式碼檢閱是維繫程式碼品質的基本功，團隊必須要盡早建立此種習慣與文化。 透過「Team Explorer」視窗發出「要求檢閱」程式碼的需求 檢閱者的 Team Explorer 會自動呈現所收到的「程式碼檢閱要求」工作項目。

《敏捷宣言》 我們通過身體力行和幫助他人來揭示更好的軟體發展方式。經由這項工作，我們形成了如下價值觀： 個體與交互 重於 過程和工具 可用的軟體 重於 完備的文檔 客戶協作 重于 合同談判 回應變化 重於 遵循計畫   在每對比對中，後者並非全無價值，但我們更看重前者。

《敏捷宣言》的12準則 我們的最高目標是，通過儘早和持續地交付有價值的軟體來滿足客戶。 歡迎對需求提出變更——即使是在專案開發後期。要善於利用需求變更，説明客戶獲得競爭優勢。 要不斷交付可用的軟體，週期從幾周到幾個月不等，且越短越好。 專案過程中，業務人員與開發人員必須在一起工作。 要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務。 無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。 可用的軟體是衡量進度的主要指標。 敏捷過程提倡可持續的開發。專案方、開發人員和用戶應該能夠保持恒久穩定的進展速度。 對技術的精益求精以及對設計的不斷完善將提升敏捷性。 要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。 最佳的架構、需求和設計出自於自組織的團隊。 團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行為。

Reference 團隊成員、個人 http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches/ Lisa crispin Mike Cohn 企業、遠地開發: http://www.mountaingoatsoftware.com/books/7-succeeding-with-agile http://www.mountaingoatsoftware.com/books/2-user-stories-applied http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning 微軟開發團隊的Scrum Visual Studio ALM Ranger Projects Scrum Guide http://msdn.microsoft.com/en-US/