Scrum 是一種敏捷軟體開發的框架，它的核心包含了三個支柱 (Pillars)、五個價值觀 (Values) 和十個原則 (Principles)。
三個支柱 (Pillars) 包括：
- 透明度 (Transparency)：所有的工作都必須對所有人可見，這樣才能確保所有人都對工作的進度有共識。
- 檢驗 (Inspection)：Scrum 團隊必須定期檢查進行中的工作和工作成果，以確保向著目標前進。
- 調整 (Adaptation)：如果在檢驗過程中發現實際的結果與預期的結果有偏差，團隊必須調整他們的行為或者計劃。
五個價值觀 (Values) 包括：
- 承諾 (Commitment)：團隊成員對於達成共同目標的承諾。
- 勇氣 (Courage)：面對困難和挑戰時，團隊成員需要有勇氣去做出改變。
- 專注 (Focus)：團隊成員專注於工作和目標，並且優先處理最重要的事情。
- 開放 (Openness)：團隊成員對於工作、挑戰和進度要保持開放的態度。
- 尊重 (Respect)：團隊成員相互尊重，認識到每個人都是獨一無二的，並且有他們自己的技能和能力。
敏捷宣言 (Agile Manifesto) 的四個核心價值包括：
- 個人和互動高於流程和工具 (Individuals and interactions over processes and tools)
- 可用的軟體高於詳盡的文件 (Working software over comprehensive documentation)
- 客戶合作高於合約談判 (Customer collaboration over contract negotiation)
- 回應變化高於遵循計劃 (Responding to change over following a plan)
敏捷宣言的十二個原則包括：
- 我們最高優先的是透過提早並持續地交付有價值的軟體來滿足客戶。
- 即使在開發的後期，我們也歡迎改變需求。敏捷流程利用變化為客戶獲得競爭優勢。
- 經常地交付可工作的軟體，交付的頻率可以從幾週到幾個月，交付的時間間隔越短越好。
- 業務人員和開發人員必須每天都要一起工作，直到項目完成。
- 建立項目周圍的人們的熱情，給他們所需要的環境和支持，並且信任他們能完成工作。
- 最有效且最有效率的傳遞信息的方法，就是面對面的交談。
- 可工作的軟體是進度的主要度量標準。
- 敏捷流程提倡可持續的開發。贊助者、開發者和使用者應該能夠保持恆定的步伐。
- 持續關注技術優秀性和良好的設計增強敏捷性。
- 簡單——使未完成的工作最大化的藝術——是必要的。
- 最好的架構、需求和設計出自自組織的團隊。
- 團隊定期反思如何能夠更有效，然後調整和改變其行為。
刺蝟原則 (Hedgehog Concept) 是由吉姆·柯林斯 (Jim Collins) 在他的書《從優秀到偉大》(Good to Great) 中提出的。這個概念源於古希臘詩人伊索的寓言，故事中的狐狸雖然有許多聰明的策略來捕捉刺蝟，但刺蝟只做一件事，且做得很好：捲成一個球來保護自己。柯林斯將這個故事用來形容公司和個人應該專注於他們可以做得最好的事情。
刺蝟原則包含三個部分：
- 你最熱衷什麼？（What are you deeply passionate about?）
- 你在什麼能力上可以成為世界最頂尖的人？（What can you be the best in the world at?）
- 你的經濟引擎是什麼？（What drives your economic engine?）
Scrum 定義了五種主要的會議，每種都有其特定的目標和結構：
- Sprint 規劃會議 (Sprint Planning Meeting)：在這個會議中，團隊會決定下一個 Sprint 要完成的工作。產品擁有者 (Product Owner) 會解釋他們希望團隊在下一個 Sprint 中完成的項目，並且團隊會決定他們能夠完成多少工作。
- 每日 Scrum 會議 (Daily Scrum Meeting)：這是一個每天都會進行的短會議，通常只會持續 15 分鐘。在這個會議中，團隊會分享他們在前一天完成了什麼，今天計劃完成什麼，以及是否有任何阻礙他們工作的問題。
- Sprint 審查會議 (Sprint Review Meeting)：在每個 Sprint 結束時，團隊會舉行一個審查會議，以展示他們在 Sprint 中完成的工作。這是一個讓所有利益相關者了解項目進度的機會。
- Sprint 回顧會議 (Sprint Retrospective Meeting)：這是在每個 Sprint 結束後的一個會議，團隊會討論在過去的 Sprint 中什麼工作得，什麼不好，以及他們可以如何改進。
- 產品 Backlog 整理會議 (Product Backlog Refinement Meeting)：這是一個可選的會議，用於審查和更新產品 Backlog。在這個會議中，團隊會評估 Backlog 項目的優先順序，並可能將大的項目分解成更小、更可管理的項目。
常見的對 Scrum 的詬病：
- 過度的會議和管理：Scrum 需要定期的 Sprint 規劃、每日 Scrum、Sprint 審查和回顧會議。對於一些團隊來說，這可能會感覺像是過度的會議和管理，並可能導致工作時間的浪費。
- 難以應對變化：雖然 Scrum 是為了應對變化而設計的，但在 Sprint 進行中改變計劃可能會很困難。這可能會導致團隊在面對變化時感到壓力，或者在需要快速反應時無法做出適應。
- 過度依賴 Scrum Master：Scrum Master 的角色是幫助團隊遵循 Scrum 的規則和實踐，並解決阻礙團隊進步的問題。然而，如果團隊過度依賴 Scrum Master，可能會降低團隊的自我組織能力。
- 忽視技術實踐：Scrum 並未明確包含如測試驅動開發 (TDD)、持續集成 (CI)、重構等技術實踐。如果團隊僅僅遵循 Scrum 的流程，而忽視了這些重要的技術實踐，可能會導致軟體質量的問題。
- Scrum 不是萬能藥：Scrum 並不能解決所有的問題。它是一種工具，需要根據特定的情況和團隊來適當地使用。如果盲目地遵循 Scrum，而不考慮其是否適合特定的情況，可能會導致效果不佳。
沒有留言:
張貼留言