在做了大量研究後，我發現“障礙”有壹些很好的定義:
？Scrum中的障礙指的是阻止開發團隊在Sprint中產生有價值的軟件增量，或者限制開發團隊實現其固有的進度目標的因素。
？壹個自組織開發團隊無法解決的問題。
？阻止開發團隊成員根據預期的生產能力在Sprint中工作的事件。
關於“障礙”有壹個很好的引語如下:
？壹個好的Scrum大師創造壹個可以報告障礙的環境，而壹個優秀的Scrum大師創造壹個創造性的環境。
？壹個好的Scrum大師會努力獲得許可來消除團隊生產力障礙，而壹個優秀的Scrum大師總是準備好被團隊原諒。
到目前為止，妳已經知道了障礙最常見的定義，妳壹定想看壹些障礙的具體例子。以下是可能存在的障礙的例子:
？壹名團隊成員生病了。
？團隊構成中不可預測且不受歡迎的變化。
？開發團隊使用的工具有問題。
？缺乏技能
？大量的技術債務
？供應商的問題。
？難以協調的產品負責人
？來自管理層的壓力
？團隊成員之間的沖突
？開發團隊必須參加的大量不重要的會議。
？團隊環境的約束
？猶豫不決的產品所有者
根據Scrum指南，Scrum Master為開發團隊服務的職責之壹就是清除阻礙開發團隊工作進度的障礙。作為壹個面向服務的領導者，Scrum Master旨在建立壹個自組織的、跨職能的開發團隊。Scrum Master鼓勵、支持和授權開發團隊，讓團隊充分發揮潛力和才能。
為了實現以上目標，Scrum Master應該在清除障礙之前仔細考慮以下問題:
？真的是障礙嗎？還是可以由開發團隊自己解決？
？我們真的需要消除這個障礙嗎？
？這裏最根本的問題是什麽？
壹定要知道，上面這些“可能”障礙的例子並不壹定會成為障礙。壹個障礙只有在自組織團隊自身無法解決的情況下，才能稱之為障礙。
缺乏技能可能是壹個障礙，但是要相信開發團隊的自組織特性，然後再去思考開發團隊的其他可能性:也許團隊成員想學習這個技能，把它當成壹個難得的機會。另外，團隊成員之間的沖突不壹定會成為障礙。Scrum Master通過健康的沖突和辯論引導團隊進行激烈的討論，最終團隊會變得更加強大。
Scrum Master應該創造壹個環境，讓開發團隊感到報告障礙是安全的。就團隊的自組織能力而言，Scrum Master應該鼓勵團隊嘗試解決自己的問題，從而將障礙扼殺在搖籃中。
消除障礙是壹項挑戰。下面我將分享壹些策略和思路，供Scrum Master在遇到障礙時參考。
？不要等到每天的常務會才匯報障礙。眾所周知，Scrum指南建議在每日站問壹個問題:“我看到了哪些可能阻止我或開發團隊實現Sprint目標的障礙？”。然而，這並不意味著開發團隊只能在每日例會上討論障礙。
？設定沖刺目標。壹個明確的沖刺目標是檢測某件事是否是真正障礙的指標。如果有什麽東西會阻礙開發團隊實現Sprint目標，那無疑是壹個障礙。
？理解“阻擋”和“障礙”的區別。“阻礙”壹般只影響單個任務，而“障礙”則像降落傘壹樣減緩整體進度。壹般來說，“堵”可以由團隊自己解決，而“障礙”只能由ScrumMaster解決。
？通過“障礙看板”？透明度高。只需移動手指，就可以直觀地在板上顯示障礙。增加壹些泳道，比如“待辦”、“進行中”、“完成了”等，讓障礙物的狀態對所有人都是透明的。當然，妳也可以在Scrum板上添加障礙。因為任務板上的障礙信息，狀態的可視化和？透明度變得更加重要。
？跟蹤已識別的障礙。這將是Sprint審查和評審的重要輸入。
？了解組織。Scrum Master應該了解組織的文化，知道如何在這個組織裏做事，用正確的方式，那麽很多障礙就很容易解決。
？勇敢地、創造性地清除障礙。當妳需要做出壹些大膽的決策來保證團隊的生產力時，妳要做好請求團隊原諒妳可能出現的決策失誤的準備。
？與產品負責人合作。障礙往往與產品管理團隊、利益相關者和供應商之間的合作密切相關。產品負責人是其中的關鍵角色。所以壹定要和產品負責人保持良好的關系。
？不要浪費精力去解決錯誤的問題。遇到障礙時，Scrum Master必須忍住定位問題、解決問題並立即提供解決方案的沖動。Scrum Master應該專註於解決現實問題，而不是遇到的每壹個問題。通過不斷的詢問了解詳細的情況，可以區分哪些障礙是真正需要解決的，哪些是開發團隊可以抓住的學習機會。
經過大量的研究和思考，我總結了Scrum Master作為清道夫的簡單性。狀態。大量資料表明，這無疑是Scrum Master能力的重要組成部分。我學到的經驗是尊重開發團隊的自組織能力。試想壹下，如果每壹個微小的障礙都要Scrum Master來解決，那怎麽會有機會讓團隊整體提升呢？
敏捷中的三個朋友開發策略是什麽？
三個朋友提到了在業務、開發期間和開發之後測試和檢查增量的主要視角。他們在非正式的啟動會議上回顧每壹個故事，以提供對將要交付的內容的共同願景，並幫助確保這是團隊的聲音，而不是單壹的意見。(三友指的是業務期間、開發期間、開發後測試和檢查工作增量的主要視角。例如，業務分析師、開發人員和測試人員在非正式的動員會上審查每個故事，給出* * *要交付的內容的共同願景，並幫助確保它是團隊的聲音，而不是單壹的意見。)
什麽是敏捷？Scrum是什麽？
敏捷是壹種軟件開發方法，通過頻繁交付可交付的軟件來關註客戶滿意度。Scrum是實現敏捷的眾多方法之壹。Scrum適合於需求快速變化的特定類型的項目。(敏捷是壹種軟件開發方法，通過頻繁交付可交付的軟件來關註客戶滿意度。Scrum是實現敏捷的眾多方法之壹。Scrum適合於需求快速變化的特定類型的項目。)
Scrum中的速度是什麽？
Scrum中的速度是壹個團隊在單次沖刺中可以完成的工作量的度量，也是Scrum中的關鍵指標。速度是在sprint結束時通過合計所有完全完成的用戶故事的分數來計算的。(速度是衡量壹個團隊在壹次沖刺中能夠完成的工作量，也是Scrum中的壹個關鍵指標。在沖刺的最後，速度是通過將所有完全完成的用戶故事的點相加來計算的。)
為什麽Scrum易學卻難掌握？
Scrum是壹個框架，人們可以在其中解決復雜的適應性問題，同時富有成效和創造性地交付盡可能高價值的產品。雖然它是輕量級的並且容易理解，但是它很難實現並且很難掌握。這篇文章告訴妳為什麽嗎？(Scrum是壹個框架，人們可以在其中解決復雜的適應性問題，並富有成效和創造性地交付具有最高價值的產品。雖然輕量級，容易理解，但是很難實現和掌握。這篇文章告訴妳為什麽。)
傳統項目管理與敏捷項目管理
傳統的項目管理強調對項目進行詳細的前期規劃，重點是確定範圍、成本和進度，並管理這些參數。然而，Scrum鼓勵基於數據的、叠代的決策，其中主要的焦點是交付滿足客戶需求的產品。(傳統的項目管理強調詳細的項目前期規劃，確定範圍、成本和進度，並管理這些參數。然而，Scrum鼓勵基於數據的叠代決策，其中主要關註的是交付滿足客戶需求的產品。)
Scrum如何進化？
Scrum也不能避免爭議，它的發明歷史是壹個經常爭論的話題。壹些專業人士認為，Jeff Sutherland、John Scumniotales和Jeff McKenna在1993年發明了scrum。然後還有其他人證明竹內博孝和野中郁次郎在1986發明了scrum。(Scrum並不是沒有爭議的，它的發明歷史是壹個經常爭論的話題。壹些專業人士認為，Jeff Sutherland、John Scumniotales和Jeff McKenna在1993年發明了Scrum。其他人可能認為竹內博孝和野中郁次郎在1986年發明了Scrum。)
five Scrum的核心價值觀是什麽？
框架所基於的5個核心Scrum價值觀不像Scrum的過程那樣為人所知，也可能沒有得到充分的重視，但卻同樣重要:承諾——專註——開放——尊重——勇氣。這些價值觀與scrum的倫理相關，從社會的角度來看，將Scrum變成了壹個價值體系。(與scrum的過程相比，人們對它知之甚少，可能會低估它，但同樣重要的是，該框架基於scrum的五個核心價值觀:承諾-關註-開放-尊重-勇氣。這些價值觀與Scrum的倫理有關，所以從社會的角度來看，Scrum轉化為壹個價值體系。)
什麽是敏捷軟件開發？
當談到敏捷時，我們經常談到“敏捷”和“Scrum”，但是，它們到底是如何聯系在壹起的，又有什麽不同呢？在這篇文章中，我們來看看這個問題。(說到敏捷，我們經常會談到“敏捷”和“scrum”，但是它們之間的關系和區別是什麽？我們在本文中介紹了這個問題。)
Scrum在3分鐘內完成。
這篇文章涵蓋了scrum框架的所有關鍵概念，使妳可以隨時從妳的頭腦中很容易地回憶和應用作為系統的知識結構(這篇文章涵蓋了Scrum框架的所有關鍵概念，以便妳可以隨時從妳的頭腦中很容易地回憶和應用作為系統的知識結構)。
Scrum的三大支柱是什麽？
(英文版)(日文版)Scrum的三大支柱是什麽？SCRUM使用經驗主義方法(或者有時被稱為經驗主義)來適應客戶不斷變化的需求。經驗主義是根據實際經驗的內容進行決策的行為。經驗方法意味著在事實、經驗和證據的基礎上工作。尤其是進步是基於對現實的觀察，而不是前期需要的大量虛構計劃。？[…]