Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Ähnlich wie Scrum介紹
Ähnlich wie Scrum介紹 (20)
Scrum介紹
- 2. 敏捷軟體開發 價值觀 個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 回應變化 重於 遵循計劃 適用性 組織文化必須支持談判 人員彼此信任 人少但是精幹 開發人員所作決定得到認可 環境設施滿足成員間快速溝通之需要
- 3. 敏捷專案開發精神
- 4. Scrum 概觀 維基簡介 搞笑談軟工: Scrum 的內涵 Scrum懶人包 – 10分鐘讀懂Scrum與敏捷軟體 開發入門
- 5. 維基簡介 Scrum是一種敏捷軟體開發的方法學，用於疊代式增量軟體開發過程。Scrum在 英語是橄欖球運動中爭球的意思。 雖然Scrum是為管理軟體開發項目而開發的，它同樣可以用於運行軟體維護團隊， 或者作為計劃管理方法。Scrum之間的合作稱為「Scrum of Scrums」。
- 7. Scrum懶人包 – 10分鐘讀懂Scrum與敏捷軟體開發入門 瀑布式開發是法家，法為主，人為 輔，強調「不別親疏，不殊貴賤， 一斷於法」。只要規則定下去，照 著做就會有好產品，鐵打的營盤流 水的官，人的因素要盡可能排除以 利產出的一致性。 敏捷式開發是道家，人為主，法為 輔，主張「道法自然」。道是沒有 一定的形式，要觀察目前的情境， 考量人的天性，因勢利導，以求功 成事遂，百姓皆謂我自然。
- 9. Scrum的三種角色 1. 產品負責人（Product Owner）：其實，產品負責人這個角色有點像是客戶代 表。他會站在比較接近客戶的立場，去設定產品待辦項目的優先順序，以及為 團隊說明客戶的需求。 2. Scrum教練（Scrum Master）：顧名思義，Scrum教練必須熟知整個Scrum敏 捷開發，以便能夠協助產品負責人和團隊的運作。 3. 團隊（Team）：就是一般的開發團隊，通常是跨職能的組成，也就是團隊成員 混合著架構師、分析師、設計師、程序員、測試員等等。
- 10. Scrum的四個會議 1. 衝刺計畫會議（Sprint Planning Meeting）：每個衝刺期間的一開始必須先舉 行衝刺計畫會議，主要用來決定該衝刺期間的待辦項目，以及團隊的衝刺任務。 2. 每日站立會議（Daily Standup Meeting）：衝刺期間的每一天早上，都要執 行15分鐘的站立會議，主要可以用來了解團隊的工作執行狀況。 3. 衝刺審查會議（Sprint Review Meeting）：每個衝刺的最後一天會先執行衝刺 審查會議，隨後執行衝刺回顧會議。在衝刺審查會議中，主要用來展示並了解 該衝刺的待辦項目達成狀況。 4. 衝刺回顧會議（Sprint Retrospective Meeting）：相較之下，前述的衝刺審 查會議，其討論的主題鎖定在「產品」上頭。而此處的衝刺回顧會議，其討論 的主題則聚焦在團隊的「開發程序」上頭，主要用來討論並調整下一期衝刺的 開發程序。
- 11. Scrum的三項產出 1. 產品待辦清單（Product Backlog）：其實，產品待辦清單的概念很簡單，它主 要包含了一般常見的功能性需求和非功能性需求；不過，比較特別的是，它還 包含了技術團隊提出的需求，而不只是照顧到客戶的需求而已。也因此， Scrum敏捷開發特別採用了「產品待辦清單」（Product Backlog）的字眼，用 來跟傳統作法上只照顧客戶的系統需求，做字面上的分野。 2. 衝刺待辦清單（Sprint Backlog）：衝刺待辦清單中的待辦項目，其實是產品待 辦清單的子集。在每一次的衝刺規畫會議中，才會開會決定要處理哪些待辦項 目。 3. 燃盡圖（Burndown Chart）：簡單來說，我們可以繪製燃盡圖，來呈現一個時 間區段中，剩餘的工作量。所以，有些文章或書籍中，也將「Burndown Chart」 中譯為「剩餘工作圖」或者是「剩餘時間圖」，原因正是如此。
- 12. Scrum 的八項缺點 Scrum 的八項缺點 (1/2) Scrum 的八項缺點 (2/2)
- 13. Scrum 的八項缺點 (1/2) 1. No technical practices - Scrum只給了管理上的建議, 但是沒有給開發人員技術上的建言 - Scrum必須借助XP的practices, 像是:TDD, Continuous Integration, Acceptance Testing, Pair Programming, Refactoring. 2. 30 day sprints are too long - 很多團隊認為2 weeks比較合適, 會比較快得到feedback 3. The tendency of the scrum master to arrogate project management powers. - 有很多Scrum Master把Scrum搞成micro management - 也許是不應該用master這個字, 改成用coach也許比較不會讓Scrum被誤用 4. The Certification in CSM is unfortunate - 在Scrum中常把這個role搞成變成一個person.常常都是同一個人當scrum master - 應該要學XP的coach觀念, 要輪替到不同的團隊, 而不是都是同一個scrum master
- 14. Scrum 的八項缺點 (2/2) 5. Scrum provides insufficient guidance regarding the structure of the backlog. - Scrum對backlog的structure著墨很少 - 經過一段時間的學習, 我們了解到要對backlog做拆解: Epics->Themes->Stories- >Tasks 6. Scrum carries an anti-management undercurrent that is counter-productive. - Scrum過度強調團隊自我管理. 自我管理的團隊固然很好, 但是有其侷限性. - 仍然需要管理團隊適時輔助 7. Automated Testing. - 沒有高品質的test automation, 很難縮短iteration的時間, 並且也不知道甚麼時候會做 完 8. Multiple teams - Scrum 和agile都對於scalability沒有很好的處理. - 雖然很多實踐者都有一套做法, 但是並沒有一致的結論
- 15. Scrum + Kanban 「消除浪費、過程透明、交付正確成果」的系統 性作法 Kanban方法的六個實務做法: Visualize & Limit WIP
- 16. 「消除浪費、過程透明、交付正確成果」的系統性作法 Scrum 裡面提到的 User Story，其實是來解決「規格被各自解讀」的問題。 Kanban 的 Story Board，是解決「時間就不知不覺被揮霍掉」的問題。 Daily Standup 是解決「大家都不溝通，結果執行方向歪掉」的問題。 Integrate Early & Integrate Often 是解決「最後一個月才開始看到成果，所有 人包括金主看到最後成果都大憤怒」的問題。
- 17. Kanban方法的六個實務做法: Visualize & Limit WIP
- 19. 使用者故事 1. 首先，了解你的User、定義你的角色（利用Pesonas） 2. 從角色出發，粗略但簡明的寫出 User Stories .... in Epic! 3. 拆解Epic，成為可執行的 Ready User Stories 4. 加入驗收標準 (Acceptance Criteria) 5. 用有效率的工具或平台管理這些Story
- 20. 使用者故事地圖 「使用者故事地圖」是用來組織和對需求排列優先順序的最佳工具。 User Story Mapping is an an approach to Organizing and Prioritizing user stories 1. 敏捷開發的浮現式開發方式 — 容易遺漏全貌 2. 使用者故事的缺點 — 見樹不見林
- 21. 影響地圖 影響地圖的特點 結構性：從業務目標到交付的結構化梳理和 挖掘的方法，目標–角色–影響–產出物。 整體性：連接目標和具體交付物之間的樹狀 邏輯圖譜。 協作性：利益相關人一起溝通討論協作，把 隱藏在個人頭腦中的預設的思維邏輯挖掘出 來共用。 動態性：動態調整、反覆運算演進、經驗證 的學習。 視覺化：一個清晰的視圖，關聯性的結構一 眼可以望穿、易讀。
- 22. 流程與工具 專案優先順序 vs. 需求複雜估算 持續整合/交付 & 自動化測試 共同編程 & Issue Tracking System
- 24. 持續整合/交付 & 自動化測試
- 25. 共同編程 & Issue Tracking System Issue Tracking system ，顧名思義就是 紀錄、追蹤 問題的系統。 BugZilla、Trac、Redmine、JIRA、 lighthoustapp、Basecamp …
- 26. 思維與方法 敏捷思維模式 & 系統導入方法 順應組織架構 & 符合公司文化 適時向上管理 & 時常自我檢視
- 27. 敏捷思維模式 & 系統導入方法
- 28. 順應組織架構 & 符合公司文化
- 29. 適時向上管理 & 時常自我檢視