我們現在正在我們部門採用Scrum。但是，上層管理結構是傳統的，如項目經理（PM），開發經理（DM），組長（TL）和測試組長（TTL）。傳統管理結構中的Scrum
團隊負責人擔任Scrum大師，他負責控制團隊中的所有事務：與PM/DM/TTL溝通，開發管理......我們的PO負責維護PBL。
我們的經理和團隊成員習慣於傳統的管理類型，他們不關心Scrum，他們說一些Scrum規則是隱藏的。 我充當另一個SM，我想改變當前狀態。
但我沒有任何頭銜，只是我們部門的普通開發者。有人也有這種麻煩嗎？
提前致謝！
如果您沒有從其他開發人員那裏購買它不會工作。期。
Scrum需要一堆紀律，尤其是在早期採用階段。
我不會爲管理層不在乎而煩惱。如果你可以自由地開展軟件開發工作，並且他們關心的只是結果，那麼每天早上你是否有10分鐘的時間站起來並不重要，並且將小塊的工作計劃成可管理的只要你擊中他們希望你擊中的目標。
如果你不是團隊成員，但你真的很難使其工作，並且它可能會失敗並且會造成更多的影響而沒有嘗試過。
如果您可以嘗試在一個小型項目中開始創作，只有少數開發人員參與創意，那麼您可以向開發團隊的其他人報告您是如何找到它的，好處和負面影響（反映畢竟是Scrum的重要組成部分）。
如果你想讓自己的管理工作在船上，你可能會發現，通過這種方式完成一些項目後，你可以更好地估計開發項目管理人員提出的要求所需的時間，希望能夠更準確地達到最後期限。
請記住，PM和BA仍然可以以正常的方式工作，一旦他們向您提交了需求，您就可以使用Scrum構建它們。它並不理想，但缺乏對每個人的購買意願，並且能夠直接與用戶交流，並讓他們幫助編寫用戶故事，這將是您獲得的最佳選擇。
當被問及估計完成項目所需的時間時，您可以應用Scrum技術。您可以將規格分解成更小的塊，將它們分組並衝刺並相應地開發它們，希望能產生更好的結果。
「我作爲另一SM，我想改變現狀」
嗯，這是一個良好的開端就在那裏，想改變這種狀況。雖然我必須說，如果沒有管理層買進，這將是艱難的。嘗試安排一位經驗豐富的Scrum演講者或敏捷教練來參加貴公司的演講或研討會，這涉及所有高層管理人員。一旦你的管理層相信Scrum，它將會從這裏一路走下坡路。
「組長充當Scrum Master的，他控制着所有的事情，是我們的團隊」
這違背了自組織和自授權團隊的原則在Scrum中。一個好的Scrum Master將會在Scrum規則中以一種嚴謹的方式賦予團隊以適當的級別，團隊應該能夠獨立運行。一個建議是，作爲高級開發人員工作時，團隊領導需要有不同的思維模式，而在Scrum團隊中沒有團隊領導，只有Scrum團隊成員。你不能指派真正的領導力，這是一種可以通過創造幫助別人和指導別人的聲譽而獲得的相互作用。讓他們在SM與開發職責之間吐出30％，70％或50-50或任何您認爲合適的任何時間。指揮和控制可能會對團隊產生反作用。
我們的管理者和團隊成員們習慣了傳統的管理型，他們不關心的Scrum
一個Scrum培訓師告訴曾經告訴我，「不要犯Scrum的自殺」。如果你的經理不關心Scrum，不要試圖說服他們。無論你們遵循什麼方法或「不」遵循什麼方法，你都必須認識到所有這些都是一項業務。如果你的老闆或經理不關心Scrum，那麼你的薪酬檢查取決於你的老闆的批准，那麼不要這麼做。如果他們關心瀑布，切換到它，像你一樣關心它，但是不要在一半的地方做Scrum，並把它稱爲混亂。
我聽到一句可愛的話，不記得是誰說的。 「他們希望敏捷，但他們不知道它是什麼 - 所以我們給他們敏捷，但我們不知道他們想要什麼。」
聽起來好像這是發生在您的公司。有人希望團隊使用Scrum，但這不是團隊。
這對SM來說肯定是一項艱鉅的工作，尤其是如果你非正式地做這件事！我可以爲你提供一些建議。首先，學習一些基本的指導技巧：積極的語言，GROW framework和giving and receiving feedback。這會給你一些額外的工具，這些工具在Scrum之外，並支持領導者而不是管理職位的人（即使是非官方的SM也可以成爲領導者）。
然後，不要擔心實際操作。如果有人授權Scrum，那麼該團隊將不得不這樣做。相反，請專注於Scrum的價值觀和原則 - 特別是協作，溝通和透明度。幫助團隊彼此合作，而不是孤注一擲。你將不得不成爲他們的榜樣。不要強制結對編程，但要重新結對。不要強制站立，但在早上首先進行對話，然後儘可能吸引隊中儘可能多的人。看看「持續改進」的原則。瞭解如何做root cause analysis and the 5 Why's，這樣團隊就能更好地理解爲什麼事情很難並自己採取行動。我也推薦Mary Lynn Manns and Linda Rising "Fearless Change"。這將幫助您確定還有誰能夠幫助您。
最後，我會回覆@sjt。不要讓Scrum自殺。但是，如果這是你真正想要的，而你的公司並沒有以正確的方式去做，那麼別害怕去其他地方看看。學習一些基礎知識，自己練習TDD並找到新工作。
不管你做什麼，祝你好運！改變的第一步是渴望。
過去的工作是識別和溝通痛點。當然，你絕對不應該這樣做，因爲Kent Beck告訴你，特別是那些會讓你被解僱的東西。然而，一些聰明人開始研究一系列具有凝聚力的實踐，與這些實踐的分歧幾乎總是會導致痛點。僅作爲一個例子：如果您在需要迭代，設計迭代，實現迭代和測試迭代的地方進行Scrum，理論上可以工作，但在實踐中從來不會這樣做。 （當它結束時，它最終成爲瀑布，而「迭代」概念變得毫無意義。）指出你的老闆，你在QA測試期間學到了關於需求的東西，可能會幫助他意識到讓QA參與需求是有價值的。或者通過做一個小原型在軟件設計中發現風險可能有助於說明爲什麼它可能有助於摺疊設計迭代。
與編程無關 – stillstanding 2010-11-22 05:25:38
SO中有很多與Scrum相關的問題。 – Makis 2010-11-22 06:36:35
這個問題是脫離主題，因爲它不在本網站的範圍內，如[我可以在這裏詢問什麼主題？]（// stackoverflow.com/help/on-topic）中定義的。另請參閱：[什麼類型的我應該避免提問？]（// stackoverflow.com/help/dont-ask）您可以在[另一個Stack Exchange站點]（// stackexchange.com/sites#name）上詢問，例如[pm。 se]或[softwareengineering.se]。請務必閱讀幫助中心中針對您打算髮布問題的任何網站的主題頁。 – Makyen 2017-10-03 23:52:07