Adventure Book

 在敏捷專案中，如果迭代時間被壓縮，團隊可能需要調整最小可行產品（MVP）和最小商業可行增量（MBI）的範圍。各角色應採取的行動如下： 1. **產品負責人（PO）：**    - ** 重新評估和優先排序 ：** PO需要重新評估產品待辦事項清單，確定哪些特性是必須的，哪些可以推遲或移除，以便形成新的MVP和MBI。    - **範疇調整：** 根據時間限制調整產品範疇，以適應更短的迭代期。    - **管理期望：** 與利害關係人溝通關於迭代時間變化的影響，並設置合理的期望。 2. **Scrum Master（SM）：**    - ** 流程適應 ：** 幫助團隊調整敏捷實踐，以適應更短的迭代週期，並確保流程仍然高效。    - **溝通協調：** 促進團隊內部和團隊與利害關係人之間的溝通，確保所有人對變化有共識。    - **支持決策：** 支持PO在重新評估和優先排序的決策過程，確保決策迅速且透明。 3. **開發團隊（Development Team, DT）：**    - ** 重點集中 ：** 集中精力在新的MVP和MBI上，確保團隊能在有限的時間內交付最核心的功能。    - **技術調整：** 快速調整開發計劃和技術實現策略，以應對時間的壓縮。    - **持續交付和測試：** 確保即使時間短暫，也能夠持續地交付和測試小的功能增量，以獲得快速反饋。 在這種情況下，團隊可能需要臨時放棄一些不那麼關鍵的特性，專注於交付那些能夠為用戶帶來最大價值的核心功能。敏捷團隊應該保持靈活性，並且能夠快速適應這樣的變化。 敏捷開發相關文章： [專案管理][敏捷] Agile 與Scrum有什麼差別？ [專案管理][敏捷] Scrum與Kanban 的差異 [專案管理][敏捷] Scrum 中的四個核心儀式和它們的意義

敏捷軟體開發（英語：Agile software development），又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型 軟體開發 方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調程式設計師團隊與業務專家之間的緊密協同運作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發過程中人的作用。 敏捷軟體開發（或稱快速程式開發RAD）描述了一套 軟體開發 的價值和原則，在這些開發中，需求和解決方案皆通過自組織 跨功能團隊 達成 [1] 。敏捷軟體開發主張適度的計畫、進化開發、提前交付與持續改進，並且鼓勵快速與靈活的面對開發與變更。這些原則支援許多 軟體開發方法 的定義和持續進化。 「敏捷」（Agile或agile [2] ）一詞由「敏捷軟體開發宣言」（Manifesto for agile software development）中開始推廣，「敏捷軟體開發宣言」定義了相關的價值和原則。敏捷軟體開發的 框架 不斷的發展，兩個最廣泛被使用的是 Scrum 與 Kanban 。 於是常常大家想知道你有真正用敏捷的第一個問題就是 你知道  Scrum 與 Kanban  的差異嗎？ Scrum和Kanban是兩種常見的敏捷開發和專案管理方法。它們各自有自己的特點和適用情況。以下是Scrum和Kanban之間的主要差異： 1. **迭代 vs. 連續流**:    - **Scrum**: 是一種迭代和增量的方法，通常在固定長度的迭代（稱為Sprint，通常為2-4周）中完成工作。每個迭代開始時，團隊會選擇一個工作集合來完成，並在迭代結束時交付可用的產品增量。    - **Kanban**: 是一種連續流的方法，不是按迭代來組織工作，而是在工作項目準備好時就開始進行。它強調將工作視覺化並限制正在進行中的工作項目的數量，以保持流動性並降低交付時間。 2. **角色**:    - **Scrum**: 有明確定義的角色，如Scrum Master、Product Owner和Dev...

MSCW（Must, Should, Could, Won't）是一種常見的需求分類和優先順序估計方法，但它不是特定於Scrum的。在這種方法中，需求被分為四個類別： 1. **Must（必須）**：這些需求是項目成功的關鍵，它們是非常重要且不可缺少的。 2. **Should（應該）**：這些需求也很重要，但如果缺少它們，項目仍然可以成功。 3. **Could（可以）**：這些需求不是必要的，但如果時間和資源允許，可以考慮包括它們。 4. **Won't（不會）**：這些需求不會在當前的項目周期中被考慮。 在Scrum環境中，MSCW方法可以幫助團隊識別和分類需求，以便更好地理解和計劃將來的冲刺（Sprints）。通過使用MSCW，團隊可以更有效地分配資源，並確保首先滿足最重要的需求。這種方法也有助於與利益相關者溝通，以確保他們明白哪些需求將被優先考慮，以及哪些需求可能會延期或不會被包括在內。 以上搭配費式數列的故事點數，可以互相對應嗎？例如多少點數應該放在Must？ 在將MSCW方法與費式數列的故事點數相結合時，沒有固定的規則或標準來明確指定應將多少點數分配給"Must"、"Should"、"Could"和"Won't"這些類別。MSCW方法和費式數列的故事點數是兩種不同的工具，分別用於需求的優先排序和工作的估算。 在Scrum和敏捷環境中，費式數列的故事點數通常用來估算用戶故事的相對大小或複雜性。這種估算方法幫助團隊理解每個用戶故事所需的工作量，並使他們能夠相對準確地計劃未來的冲刺（Sprints）。 另一方面，MSCW方法是一種需求分類和優先順序估計方法，它幫助團隊識別哪些需求是最重要的，哪些是次要的，哪些可以延遲，以及哪些不會在當前的項目周期中考慮。通常，"Must"類別的需求是最重要且不可忽視的，而"Won't"類別的需求則是最不重要的。 如果想將這兩種方法相結合，可能需要根據團隊的具體需求和情況來自定義一些規則。例如，可以決定所有"Must"類別的需求都應該有較高的故事點數，以反映它們的重要性和優先級。然而，這種結合可能需要一些實驗和調整，以找到最適合您的團隊和項目的方法。 PMP...

Q: 敏捷開發Scrum 與Agile 兩種模式有什麼差異 敏捷開發（Agile）是一個軟體開發的方法論，其中包括了多種不同的開發模式，而Scrum則是其中一種敏捷開發的方法之一。下面是Scrum和Agile兩種模式之間的幾個主要差異： 開發模式： Scrum是一種基於迭代開發的模式，包括了一個特定的開發週期（Sprint），每個Sprint的目標是產出一個可用的軟體版本。 Agile則是一個更為廣泛的開發方法論，並沒有特定的開發週期或模式。 團隊組成： Scrum要求團隊成員在開發週期中進行密切合作，包括開發人員、Scrum Master和產品負責人。 Agile方法論則強調整個團隊的自組織和自主性，並且將客戶或用戶也納入團隊之中。 角色定義： Scrum具有明確的角色定義，包括Scrum Master、產品負責人和開發團隊成員。 Agile則沒有特定的角色定義，每個團隊可以根據自己的需求和結構來定義角色。 工作流程： Scrum有明確的工作流程，包括Sprint計劃、每日Scrum、Sprint回顧和Sprint Demo等階段。 Agile方法論則更加靈活，每個團隊可以根據自己的需求來設計自己的工作流程。 總的來說，Scrum是一種較為具體和規範化的敏捷開發方法，而Agile方法論更加靈活和開放，能夠適應不同的團隊和項目需求。 === 實務分享： 1. 比較有規則/規模的公司會採用Scrum，其中主要在開發團隊中進行Scrum 而把設計如UX/UI 作為input 。 2. 新創團隊比較小型規模的組織，就會用Agile 但主要是因為成員可能兼具兩個角色，如PM+UI。 也會因為合作模式，例如兩家公司要做API對接，兩個公司進行一個合作案，從一家出product spec搭配UI 以客戶角色加入另一家開發團隊。 3. 傳統的project manager 角色，負責訂schedule 做issue review 以及溝通測試部門做quality review。這樣的角色在scrum team 中，要嘗試融入到開發團隊中，實際執行與scrum master 還是有些差異。傳統project manager應轉型，嘗試做為開發團隊中負責整合及執行release 的角色。 PMP 及專案管理相關文章請見： 專案管理 更多科技業名詞解釋請見： 名詞解釋 長宏PMP課程及...

解釋Scrum 敏捷式儀式 四個活動的意義，包含衝刺規劃、每日站立會議、衝刺審查、衝刺回顧會議。 當我們提到 Scrum 時，這是一種敏捷開發的框架，其中包含了幾個主要的儀式（或稱為活動、事件）來確保團隊能夠有效、透明且持續地交付價值。以下是 Scrum 中的四個核心儀式和它們的意義： 1. **衝刺規劃 (Sprint Planning)：**    - **意義**：此儀式的目的是為即將開始的衝刺（Sprint，通常為2-4周的開發週期）計劃工作。在這次會議中，產品擁有者 (Product Owner) 將從產品待辦清單 (Product Backlog) 中選擇最高優先級的項目，然後和開發團隊一起討論，確定在接下來的衝刺中可以完成的工作範疇。     2. **每日站立會議 (Daily Stand-up 或 Daily Scrum)：**    - **意義**：每天開始工作時，團隊成員會集合起來，分享他們前一天的工作成果、當天的工作計劃以及他們遇到的任何障礙。此會議促使團隊保持對目標的專注，同時確保早日識別和解決問題。 3. **衝刺審查 (Sprint Review)：**    - **意義**：在衝刺結束時，團隊會展示他們在該衝刺中完成的工作。這不只是給團隊成員看，也是給產品擁有者和利害關係人看的，這樣他們可以提供反饋，確保產品正朝正確的方向發展。 4. **衝刺回顧 (Sprint Retrospective)：**    - **意義**：此會議的目的是反思上一個衝刺的過程，找出什麼地方做得好、什麼地方可以改進。透過此會議，團隊不斷地自我調整和優化他們的工作方式，以持續改善效率和效果。 總的來說，這些儀式為 Scrum 團隊提供了一個結構化的框架，幫助團隊保持目標明確、互相協作並持續地學習和改進。 敏捷方法論中的MVP, MMF及MBI 當我們談論敏捷方法論時，MVP、MMF和MBI是三個相關的概念，但它們在專案和產品開發中有不同的應用和目的。以下是對這三個概念的簡單介紹： 1. **MVP (Minimum Viable Product) - 最小可行產品**：    - **定義**：MVP是一種策略和產品，使你可以學習到最大...

 當我們提到 Scrum 時，這是一種敏捷開發的框架，其中包含了幾個主要的儀式（或稱為活動、事件）來確保團隊能夠有效、透明且持續地交付價值。以下是 Scrum 中的四個核心儀式和它們的意義： 1. **衝刺規劃 (Sprint Planning)：**    - **意義**：此儀式的目的是為即將開始的衝刺（Sprint，通常為2-4周的開發週期）計劃工作。在這次會議中，產品擁有者 (Product Owner) 將從產品待辦清單 (Product Backlog) 中選擇最高優先級的項目，然後和開發團隊一起討論，確定在接下來的衝刺中可以完成的工作範疇。     2. **每日站立會議 (Daily Stand-up 或 Daily Scrum)：**    - **意義**：每天開始工作時，團隊成員會集合起來，分享他們前一天的工作成果、當天的工作計劃以及他們遇到的任何障礙。此會議促使團隊保持對目標的專注，同時確保早日識別和解決問題。 3. **衝刺審查 (Sprint Review)：**    - **意義**：在衝刺結束時，團隊會展示他們在該衝刺中完成的工作。這不只是給團隊成員看，也是給產品擁有者和利害關係人看的，這樣他們可以提供反饋，確保產品正朝正確的方向發展。 4. **衝刺回顧 (Sprint Retrospective)：**    - **意義**：此會議的目的是反思上一個衝刺的過程，找出什麼地方做得好、什麼地方可以改進。透過此會議，團隊不斷地自我調整和優化他們的工作方式，以持續改善效率和效果。 總的來說，這些儀式為 Scrum 團隊提供了一個結構化的框架，幫助團隊保持目標明確、互相協作並持續地學習和改進。 幾個簡單的摘要給大家，不過切記，重點是團隊自動自發、有自主權的精神和背後的道理，倒不是這些規則喔！ 【團隊】3 Product Owner管Product Backlog，負責讓Development Team做的事發揮最大的價值 Scrum Master提倡、觀察、指導、協助團隊用Scrum  Development Team決定Sprint Backlog，負責達成Sprint Goal、每個Sprint產出可以使用、上線的產...

簡介敏捷開發流程 其中的scrum master 與過去常見的瀑布式（waterfall）開發模式中的軟體專案經理（project manager）有什麼差異 敏捷開發流程是一種快速且靈活的軟體開發方法，其核心理念是透過不斷的迭代、持續交付和反饋來實現高品質的軟體產品。敏捷開發流程有多種方法論，其中一種較為廣泛應用的方法論是Scrum。 Scrum是一種基於敏捷開發的框架，它將軟體開發團隊組織為自主且跨職能的小組，並以Scrum Master、Product Owner和Development Team三個角色來管理開發流程。Scrum Master是Scrum團隊的領袖，負責協調和指導團隊在Scrum框架下的運作。 相較於Waterfall開發模式中的軟體專案經理（project manager)，Scrum Master的職責有所不同。在Waterfall開發模式中，軟體專案經理通常負責規劃、執行、控制和結束整個軟體開發生命週期，並且需要在每個階段都確認交付物和文件的正確性和完整性。而在Scrum中，Scrum Master則是團隊的敏捷教練和協調者，並且不會干涉團隊的決策，而是通過提供指導和支持來確保團隊能夠成功地實施Scrum框架。 此外，Scrum Master還需要負責管理Scrum事件、Scrum工件和Scrum角色，並且協調各項活動以確保團隊能夠順利地完成每個Sprint。相較於Waterfall開發模式中的軟體專案經理，Scrum Master需要更強的敏捷和溝通能力，以及更深的對Scrum框架和敏捷開發方法論的理解和實踐經驗。 敏捷開發相關文章： [專案管理][敏捷] Agile 與Scrum有什麼差別？ [專案管理][敏捷] Scrum與Kanban 的差異 [專案管理][敏捷] Scrum 中的四個核心儀式和它們的意義

Scrum Master是一項越來越受歡迎的證照，許多國際認可的機構都提供Scrum Master認證課程和考試。以下是一些推薦的地方： Scrum Alliance ：Scrum Alliance是一個全球性的Scrum社群，提供Certified ScrumMaster（CSM）認證。他們提供由訓練師提供的課程，並在課程結束後提供考試。 Scrum.org ：Scrum.org提供Professional Scrum Master（PSM）認證。他們的課程和考試都是在線上進行，不需要參加課堂培訓。 Project Management Institute（PMI） ：PMI提供Agile Certified Practitioner（PMI-ACP）認證，其中包括Scrum Master的知識和技能。PMI的課程和考試都是在線上進行，不需要參加課堂培訓。 Agile Alliance ：Agile Alliance是一個全球性的Agile社群，提供Certified Agile Leadership（CAL）認證，其中包括Scrum Master的知識和技能。他們提供由訓練師提供的課程，並在課程結束後提供考試。 Scaled Agile ：Scaled Agile提供SAFe 4.0 Scrum Master認證，這是針對大型企業實施Scrum的認證。他們提供由訓練師提供的課程，並在課程結束後提供考試。 以上這些地方都是受到國際認可的Scrum Master認證機構，你可以選擇符合自己需求的課程和考試。

【有些事你不熱愛它，還是可以收穫滿滿 - Scrum到底講什麼？】 今天考過了Scrum Master的證照！坦白說，我一直都沒有想過要去考證照，因為我是一個熱愛挑戰、有時喜歡破壞規則的人，總覺得這種規則很多的東西不適合我。但剛好 HowAgile 請我給他們的課程一些反饋、天下文化 請我做 #SCRUM敏捷實戰手冊 書評，大人學、MasterTalks 請我開產品管理、專案管理的課程，「是時候好好研究一下我沒有特別熱愛的事！」我想。 雖然面試過上百Scrum Master(敏捷導師)、陸續有十多個敏捷導師在我團隊上，也用敏捷開發十多年，但我其實沒有考過證照，也不知道竟然還有手冊！ 抱著踢館的心態，開始了證照課程，發現自己用敏捷開發就像是騎腳踏車，會騎（用敏捷十年）、也在國家隊裡（臉書），但其實不知道原理，了解原理以後，感覺事情都串連起來的感覺！  幾個簡單的摘要給大家，不過切記，重點是團隊自動自發、有自主權的精神和背後的道理，倒不是這些規則喔！ 【團隊】 📌 Product Owner管Product Backlog，負責讓Development Team做的事發揮最大的價值 📌 Scrum Master提倡、觀察、指導、協助團隊用Scrum  📌 Development Team決定Sprint Backlog，負責達成Sprint Goal、每個Sprint產出可以使用、上線的產品「Done Increment」，所有需要完成Backlog都在Development Team上，可能不只有工程師 【Sprint】不超過四週，矽谷軟體公司通常是兩週 【會議】 📌 Sprint Planning：決定Sprint要做什麼、Sprint Goal，一月不超過8小時。在業界通常分為「Backlog Grooming」讓團隊了解要做什麼、「Sprint Planning」決定Sprint 要做什麼。 📌 Daily Scrum：在業界常被叫做「Daily Standup每日站會」，固定15分鐘，只有Development Team參加。 Sprint Review：在業界常被叫做「Demo」，每月不超過4小時。不只是「看喔！我做好了！」還有評估調整剩下的東西。 📌 Sprint Retro：檢討會，每月不超過3小時。不只是檢討，還有選出一樣...