Download as PDF, PPTX
Uploaded by東城 楊
敏捷開發分享
本报告由Tony Yang分享，探讨了采用Scrum模式开发云端服务的经验。文中强调了敏捷开发在解决IT项目高失败率中的重要性，以及如何通过敏捷方法提高团队生产力和应对需求变化。还讨论了敏捷和传统瀑布模式的对比，以及敏捷方法在风险管理和需求变更控制中的优势。
敏捷開發分享
- 1. 使用 Scrum 模式 開發雲端服務經驗分享 報告人：Tony Yang 日 期： 2017 1
- 2. Agenda 為什麼敏捷會有用 我個人的體會 專案團隊如何使用敏捷開發 敏捷的誤解 我們怎麼做 2
- 3.
- 4. IT 專案成功不容易 40%IT專案不能滿足商業需求 (from TechRepublic Inc./ Gartner Group) 74% IT專案不是超支便是延誤...，28% IT專案全 盤失敗… ，每年有$75 billion美元是花在失敗專案 之上 (from The Standish Group) 31.1% 專案在限期前被飭令中止 (或無法結案) (from The Standish Group) 50% 以上IT專案不能達到預期成效 (from Gartner Group, “Project Management: A New Look for a New Economy”) 4
- 5. 軟體開發是一個成熟的產業嗎？ 有任何成熟的產業的產品成功完成比例只有 14% 嗎？ ProjectSuccess Rates: Agile vs Waterfall The Standish Group measured CHAOS resolution results of both Waterfall and Agile projects from 2002 to 2010 5
- 6.
- 7. 所以，問題是？ 軟體公司觀點 需求沒有弄清楚 客戶需求變更 永遠都有沒想到的雷 到後期才發現重大的技術問題 當初的設計或技術架構最後才發現並不可行 跟客戶其他系統整合的問題 資料量或客戶環境的問題 團隊成員的能力或運作有問題 專案時間太趕，根本做不完 專案成員還沒有 Ready，沒有開發人員 產品花長時間做出來，客戶卻不買單 亂接案子
- 8. 所以，問題是？ 客戶觀點 廠商沒有弄清楚我們的需求 廠商的品質不好，Bug 太多，最後才冒出來 重要的需求到最後才處理，還要大改系統 廠商能力或人力不足 廠商做了之後才告訴我們，沒有在過程中跟我 們討論 廠商設計的架構不夠有彈性，無法面對真實的 需求調整 期初見業務，期末見法務
- 9. 不是我們做的不夠好，而是選錯方法了？ 軟體的開發在過去一直沒有找到真正適合自 己的方法？所以一直用工程的作法來參考？ Project SuccessRates: Agile vs Waterfall The Standish Group measured CHAOS resolution results of both Waterfall and Agile projects from 2002 to 2010 9 我們要一直改善 Waterfall 的方法或是選擇一個真正適合的方法？
- 10.
- 11.
- 12.
- 13.
- 14. 對廠商的風險-不確定性錐 軟體計畫無用論-初期的差異是 16 倍 FromRuddy Lee 分享空間 14
- 15.
- 16. Cynefin 框架 A. 簡單(Simple) 因果關係十分明顯, 每個人都能要用最佳實務 (Best Practice) 去解決問題. 感受 —> 歸類 —> 反應 (Sense-Categorise-Respond） B. 繁雜 (Complicated) 因果關係需要透過分析和調查來處理, 需要應用現有專門知識和技能, 有些好的 實務 (Good Practice) 可以幫忙 感受 —> 分析 —> 反應 Sense-Analyze-Respond） C. 複雜 (Complex) 因果關係在事後才明朗, 需要新作法, 很難控制和計畫. 與其產生複雜的解決方 案, 倒不如制定簡單的規則. 所以他需要一些湧現的實務(Emergent Practice) 試探 —> 感受 —> 反應 (Probe-Sense-Respond） D. 混亂 (Chaotic) 因果關係之間沒有關係. 為了生存, 必須要去採取行動, 想辦法把狀況拉到複雜 的階段. 這裡需要一些新穎的實務 (Novel Practice) 行動 —> 感受 —> 反應 (Act-Sense-Respond） From : David Ko 的學習之旅 16
- 17.
- 18.
- 19.
- 20. CMMI v.s. Scrum 559頁 CMMI 本身並不提供實際的流程制度與 作法，導入 CMMI 的企業，必須自行設 計適合組織的流程制度，以符合 CMMI 的要求 （武林招式大全）-> 走火入魔或 武林大師 16 頁 連開會的次數、長度、方法都有建議 很容易懂但很難做得好與做的有效 （甩手功指引） 20
- 21.
- 22. Scrum 模式 團隊– 開發團隊 3-9 人，另含 SM, PO 每個週期都要計畫與回顧 2-4 weeks 角色 – 沒有主管（自組織） Development Team Product Owner Scrum Master 專案管理 – 沒有長期完整計畫, 不使用甘特圖 Product Backlog Sprint Backlog Potentially Shippable Product 沒有派工，團隊自己認領工作 每天開會 Scrum Daily Review 22
- 23. 美國聯邦調查局(FBI)案例 $575 milliondollars wasted on the first two attempts at the project Scrum Studio was set up in the basement of the Hoover Building Staff reduced from 400 to 40, and in 1 year and $30 million, they were code complete, at a cost savings of more than 90 percent If an organization like the FBI can do this, why can’t yours? 23 http://www.scrumcasestudies.com/fbi/
- 24.
- 25.
- 26. 不是最佳化，而是最有效 傳統模式：divide and conquer 前提：如Tasks 彼此是有關聯的，還會 有相依性的考量 Divide and conquer 對問題的分析與 處理很棒，但拆解 Task 時須考量更多 26
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39. 傳統 Resource Plan方式 40
- 40.
- 41.
- 42.
- 43.
- 44.
- 45. Methodology Project CostValue Stream Technical Debt Traditional $354,600 $300,000 -$161,000 Agile Matured $650,400 $1,550,000 -$8,600 使用相同資源時 理想狀況下，Waterfall 的成本最小 但一旦加入 Rework, 慘案的風險後就不一定了 Agile 的產出價值最高 用較少的資源執行 Agile 是可行且合理的嗎？ 3-5 個全職投入 (FBI 的例子)
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53. Plan Driven 的後遺症– TOC 限制理論 要求準時完成一個專案 產生一個計畫 (可能有很大的誤差) 要求每一個工作都能夠準時 <- 準交率 KPI 每一個工作都能準時 -> 專案就能準時 ？ 人的行為 為每一個工作都留下緩衝時間 每一個工作都會花光緩衝時間，就算它比預估要早 4 倍完成 原本可作為整個專案的緩衝時間消失 -> 任何一個工作發生問題就 造成專案的 Delay 時間不夠時，先有做完就好 產生技術債，造成專案後期的延誤 一直補洞一直到無法補時才爆出來 一直加班到專案結束或中途就離職
- 54.
- 55. 對控制風險的不同看法 相同點 如何在項目或者企業一個肯定有風險的環境里把風險 減至最低的管理過程 不同點 傳統風險管理 – 把風險當成獨立要處理的項目 風險識別 風險分析 風險計畫 風險監控 風險應對 敏捷風險管理 – 把風險納入流程思維中 把風險高的事情先做 把對客戶最有用的東西先做 58
- 56. 將風險高跟價值核心先做 採用 Iteration的模式 花三個月得到一個小失敗， 也比花三年得到一個大失敗划算 59
- 57. 發生慘案的風險 • 如果每個環節發生問題的機率都是 1/10 •有 10 個環節的系統發生問題的機率是 100% • 你希望他在什麼時候發現問題？ • 使用 Scrum 可以讓潛在問題提早爆發 60
- 58.
- 59. 不是確認再確認，而是擁抱改變 凍結需求是困難的，就算有 RFP但是一樣文字各 自解讀，或是產品開發到中期，發現當初的想法 是錯的，或是有更好的想法要怎麼辦？ 人們總是看到實際的東西出來後，才知道他真正 要的是什麼？ 一個軟體產品，有 30％ 以上的功能是幾乎沒有 人使用的 62 Rework ?
- 60.
- 61.
- 62.
- 63. 沒有 Technical Practice敏捷不起來 Technical Debt 66
- 64.
- 65.
- 66.
- 67.
- 68. 傳統的專案 – 組織控管 啟動會議 派工 定期會議（月/雙週/週） 對外 對內 對上 驗收會議 結案會議 專案計劃書 需求規格書 系統分析書 系統設計書 程式規格書 … 會議記錄 待辦清單 JIRA 結案報告 71
- 69. Scrum 模式 –自組織且跨功能 Sprint（衝刺） : 2-4 weeks Sprint Planning（衝刺規劃會議） Product Backlog Refinement / PBR（產品待 辦清單精煉會議） Daily Scrum（每日站立會議）10-15mins 昨天做了什麼？今天打算做什麼？有遇到什麼困難？ Sprint Review（衝刺檢視會議） Sprint Retrospective / Sprint Retro（衝刺回顧 會議，我偏好稱為『自省』會議） 72
- 70. 每天開會 15 分鐘的好處 更短週期的溝通，避免重工，增加合作，快速學 習 增加互動的次數，培養夥伴關係 更快速的調整作法 減少隨時的打斷次數 還記得昨天的事，用簡單的小黃標就可以追蹤 省去一兩週開會半天的時間 增加知識型衝突、降低情感型衝突 共同目標，一同努力 73 你可以把兩個人安排在同一個專案，但你無法命令他們好好合作
- 71.
- 72.
- 73.
- 74. 問題是… 軟體工程教育的一個基本問題是，在他們 相信一個新的方法行得通以前，他們不會 採用它。 而更重要的是，在他們親身驗證這些方法 以前，他們不會相信這些方法 --W.S. Humphrey 77 當某人已經對其工作發展出一 定程度的舒適與熟悉感，他最 不想做的事情就是有人跑過來 讓他採用一個新的做事方式
- 75. 使用敏捷 or ? 如果你們團隊不理解他們的價值和 原則 那麼你最終只會走過一回 並且得到只比沒做好一點的結果 78 Scrum 的方法內涵與影響比你想像的更多 不只是軟體開發，也涵蓋了組織管理，企業文化等觀點 甩手功的內功心法是？
- 76.
- 77.
- 78. 敏捷開發模式在亞洲的挑戰 (一) 有人希望有人告訴自己該做什麼，也有人總想指 揮別人做事，整個組織工作井然有序 敏捷開發需要大家當面直言問題所在，而這有悖 於亞洲文化，因為亞洲人特別注意對別人表示尊 重、給別人留面子，這一點與西方文化特別不同 ，而西方正是敏捷思想的發源地 https://kknews.cc/news/3jjrk8.html 81
- 79. 敏捷開發模式在亞洲的挑戰 (二) 對於那些習慣了可預見性的人們來說，他們希望 可以預見未來。那麼他們的工作就是動用人力物 力來使自己預見的未來成為現實。 而具有敏捷思想的人們卻深知對於軟體研發這種複雜 的、創造性工作的來說，可預見性這種事情是不可能 的，結果通常是很糟的：軟體質量差、計劃延期、資 金浪費和士氣低迷等 亞洲的教育都是為了考高分、定級別，而不是為了嘗 試、自我發現和試錯，可這些卻正是敏捷實踐的目的 所在 https://kknews.cc/news/3jjrk8.html 82
- 80.
- 81. 敏捷的疑問？ 敏捷不做計畫 ？ 敏捷不寫文件 ？ 敏捷會讓你更輕鬆的工作 ？ 敏捷會讓你更快完成工作？ 敏捷就是不管理 ？ Iteration 就是 mini waterfall ? Scrum 跟技術無關？ 敏捷能保證成功嗎？ 85
- 82.
- 83. 我該使用敏捷開發嗎？ Yes 敏捷是更適合軟體開發的本質與世界的趨勢 從分工的方式、團隊的組成、風險、透明度、組織管理、問題 的複雜性的觀點等 對廠商、員工與客戶都能帶來更好的價值 因為救慘案很苦 因為現在很苦 87
- 84. 我該使用敏捷開發嗎？ No 直覺上要花更多的人力 改變是有風險的 敏捷可能只是另一種不一定有用的流行而已 我現在的作法也沒有不好啊 客戶跟老闆不一定會同意 目前的專案，要不是先天太不良，其實也還好 如何跟現有的專案合約時程搭配？ 其實是需要更高的技術要求 執行 Scrum 不保證成功，甚至會造成早期失敗 88
- 85. 我可以從哪裡開始呢？ 讀 ScrumGuideline – 17 頁 將需求列出優先順序 使用 Iteration 方式 提早進入開發，優先處裡風險高，對客戶價值高 的部份 讓系統可用，先解決「限制」，而非先開發「底層」 的部份，也非先完成一組相同的功能 底層應該是用現成的，或是在過程中才逐漸發展出來 的 與團隊與客戶對話 開始試試看 有面對失敗的勇氣 89
- 86. 我會遭遇什麼困難？ 成員感受不到敏捷軟體開發模式帶給他們什麼改 變 成員為了維持和諧，不會反映組織所面臨的問題 部份成員不喜歡共享資訊，不喜歡參與協同合作 成員不知道如何有效進行工作規劃 程式開發的範圍不能確定 開發的程式品質不佳 部份管理人員習慣性提出決策，而成員會視其為 命令 開發模式轉換的不適應 90 From:中央大學用限制理論探 討軟體開發組織進行敏捷轉型 之研究論文
- 87.
- 88.
- 89. 混合合約 該合約既包括固定金額，又包括一個按小時收取 的費率。開發人員會估算工作要用多久，比如80 個小時。然後開發人員會用該時間乘以他們“通 常”每小時收費的數目，比如200美元1小時；這 樣得到的金額會拆分成兩部分：一部分是固定金 額，另一部分是較低的每小時費率。比如：固定 部分可能是8000美元，每小時的費率降低為100 美元。 如果項目按預計時間完成，那麼價格就是 8000+80*100=16,000美元 如果項目時間超出預期，開發人員就只按100美 元一小時來收取額外的費用。該方法試圖在開發 人員和客戶之間平分風險。 94
- 90. 滾動合約（Rolling contracts） 伴隨著每次交付，客戶會付款給供應商，同時面 臨一個選擇：繼續下一個迭代，還是就此停止。 客戶簽訂的是服務合約，而且可以思考他們購買 的服務的數量。是4個人月，還是200個工作點數 ？ 雖然這種方式聽起來很激進，很多IT部門和供應 商已經在相關領域使用服務合約了。舉個例子， IT支持部門和軟件維護合約一般都是採取服務合 約的形式編寫。 95
- 91. 不勞而獲，變更免費（Money for Nothing, Changefor Free） 維護一個大合約，也就是說要完成一些概括的前期需求分 析。但是，合約中加入了兩個額外條款。 第一個變化是：要確保總是在開發優先級最高的工作，而 且允許加入新工作。客戶同意定期與供應商碰面，調整剩 餘工作的優先級。這時，他們可以向Backlog中加入更多 工作，同時要明白：這麼做的話，有些工作就得丟掉，再 也不會完成了。 “不勞而獲”條款讓客戶在任何階段都可以取消剩餘的工 作，並保留目前已經完成的工作。在這種情況下，客戶要 為未完成的工作支付20%款項。 假如有一個1200萬美元、為期12個月的合約已經完成了 一半，這時客戶希望取消剩餘的工作，除了必須要付的 600萬美元之外，他們還要多付出120萬美元。這樣相對 於整個合約金額，客戶還能省下480萬美元。 96
- 92.
- 93.
- 94. 團隊建立與溝通 將瀑布所需要的但 Scrum沒有的也列入 Iteration 中當成一個 Task 一併安排資源與時間 將非開發但須關注的 milestone 也納入 一開始就能建立一個較完整的團隊，可以提早開 時進行專案建構階段 將高風險與專案核心功能優先開發並與客戶確認 提早讓核心客戶開始使用 釐清與確認專案範圍與未來改善的差異 加入需求必須拿掉一些現有的需求 100
- 95. 第一个信封-提早進行敏捷開發軟體建構 初始 計畫 需求軟體建構 使用者 測試 上線 需求 分析 設計 開發 測試 1.迭代計劃 2.軟體建構 3.迭代演示 4.迭代回顧 101
- 96. 第二个信封-已知的其他專案工作 合約 專案計畫 需求訪談 < 軟體建構 > - 第一個信封 使用者測試/上線/訓練 … Milestone & 交付項目 硬體的採購與安裝 … 初始 計畫 需求 軟體建構 使用者 測試 上線 https://www.smartsheet.com/agile-project- management-excel-templates 102
- 97. 第三个信封-企業整合 & 專案監控 初始計畫 需求 軟體建構 使用者 測試 上線 企業整合 & 專案監控 1.專案啟動會議 2.專案月會 – 客戶 3.專案彙報 – 公司高層 4.與其他專案整合 5.專案結案會議 6.... 103
- 98. 結對編程 (PairProgramming) 每日站會 (Daily Stand up) 自組織團隊 (Self Organizing Team) 自省 (Retrospective) 引導 (Facilitation) 等... 團隊中每個人都要是領導者 104
- 99.
- 100. Vital CRM愛客戶 協助企業使用視覺化 的標籤對客戶進行分 類、掌握客戶區隔、 利用簡訊與 eDM 針 對不同的客戶提供「 精準行銷」，輕鬆記 錄客戶聯絡事項、發 覺久未聯絡的客戶， 透過客戶人脈關係開 拓商機。 服務簡介與使用情境 2012年雲端創新應用傑出獎 106
- 101. 由 2008/10 開始使用Scrum 至今
- 102.
- 103. Planning Meeting Product Owner決定需求優先順序，開發團隊決定 Effort 109
- 104.
- 105. Retrospective Meeting Good& Learn: 假如我們 再做一次相同的Sprint， 我們哪些事情可以 保持相 同的作法。 Could have done better: 假如我們再做一次相同的 Sprint， 我們哪些事情的 做法可以改變 Improvement: 有關未來 我們如何改進的具體方法 111 每個人都要先想好，會議中 只是討論與分享
- 106.
- 108. 由 CI ->CD -> DevOps 114
- 109.
- 110.
- 111.
- 112.
- 113.
- 114. 參考資料 Scrum Scrum官方指南 Scrum 懶人包 兩萬字談敏捷開發 其他 重新發明組織演講 – 無主管組織 工具：Slack - 找到正確的團隊溝通之道 120
- 115.
- 116.