【Scrum敏捷】scrum反模式
軟體領域中使用的反模式術語大多數最初都是吸引人的，易於實施的解決方案。但事實上，遠遠沒有解決實際問題，最終反而導致更大的問題。
正如Scrum指南中所說的Scrum是一個框架，在這個框架內，人們可以處理複雜的適應性問題，同時高效地創造並交付最高價值的產品。Scrum是：
• 輕量級的
• 容易理解的
• 難以精通的
在不到一個小時的時間裡，你可以向他人說出Scrum的所有要素。
因為很容易理解，初學者會輕鬆地使用甚至誤用框架。他們可能從整體上使用一些實踐，並以機械的方式重複它們，而不理解它們背後的原理。不做任何適應性改變，不挑戰自我，這樣，能期望提高工作效率嗎？
我們需要牢記，Scrum不會一夜之間化腐朽為神奇。人們要適應於新的工作模式，尤其是需要時間適應文化轉型。 要有耐心，不要過早的急於表現，從敏捷教練的角度開始應用它，挑戰自己，改變你的工作方式並理解原則。
現在我來談談最常見的“反模式”，希望能給你帶來一些想法。這可以幫助你檢視你自己和你的團隊。在敏捷團隊評估中，我觀察到了一些這樣的情況，這些公司正在努力找出為什麼他們已經開始應用Scrum了卻還是沒有改進的原因。
• 團隊等待分配任務或要求PO(產品負責人)分配任務，從而破壞其自組織性和決策能力的發展。
• ScrumMaster中的“Master”部分被視為技術或領域專業知識，因此，這個職位通常被團隊中最有經驗的軟體開發人員擔任。 這對團隊的發展產生負面影響。
• PO(產品負責人)和團隊僅在 Sprint計劃和回顧會議時見面。 這通常意味著產品負責人在sprint期間沒有花時間與團隊和客戶在一起，因此決策和學習過程很慢。
• 在Sprint計劃會議上，所有任務都是個人認領，每個人對自己的任務負責，因此他們不作為團隊合作，獨立工作，在整個sprint過程中不能相互協作。
• 如果他們是按照上面描述的方式工作，那麼，每日Scrum（允許協作和作為團隊做出日常決策）放棄每日站會也並不奇怪。
• 團隊和PO(產品負責人)專注於完成任務而不是交付價值。
• 他們不做回顧，他們實際上並沒有挑戰自己變得更好。
• 沒有Sprint的審查，或者當團隊展示了在Sprint中完成了什麼，而不是檢查交付的價值和sprint目標反饋。
• 會議不尊重“時間盒”原則。
• 隨著Sprint的不斷推進，Sprint待辦事項的變化也越來越大。
• 團隊將來自Sprint的使用者故事傳遞給Sprint並針對同一個故事進行多個Sprint，表明存在切割問題或他們不瞭解迭代和增量工作方式。
• 在Sprint計劃中，團隊只討論“什麼”部分，而忘記討論如何拉動專案的開發。
• 由於缺乏待辦事項列表優化會議，所以Sprint計劃會議時間很長（即超過時間盒）。
• 團隊表現以“速度”作為衡量標準。
如果你發現你的團隊存在這些反模式， 有方法可以幫助他們恢復，比如結構化教練方法，並向經驗豐富的敏捷教練尋求幫助。