我假設您是技術主管。

詢問優先事項

一旦您知道待辦事項清單，請向您的經理髮送電子郵件：

您好[姓名]，（或您好，先生[姓名] （如果您不那麼親密））

我已經看到了本次沖刺應該處理的任務，根據估算，我們將無法處理所有這些任務。您能否確定任務的優先級？

問候，

[BlahBlah]

（您也可以提供優先級列表並徵求協議）

這樣，如果他們回答並且您僅執行最優先任務，則可以將其用作參數。如果他們沒有回答，您將能夠告訴他們您發出了警報，而他們忽略了該警報。你做了你的工作。

停止在“暮光之城”中工作

作為公司，應該做出一個決定：您是否要朝著敏捷的方式使用Sprint及其所需要的所有其他功能？是否要採用更“經典”的方法？

如果要使用衝刺，那麼唯一可以決定衝刺將完成哪些工作的人就是Scrum團隊：產品所有者和開發人員。請注意，在這種情況下沒有“項目經理”。產品負責人是決定所有不同故事和功能的優先級的人，然後Scrum團隊在sprint計劃中決定在迭代過程中將選擇哪些項目。這裡沒有任何人可以強迫開發人員承擔更多工作。如果不同的項目經理（將成為新結構的涉眾）希望更改優先級，則需要說服產品所有者更改優先級。如果在衝刺過程中發現所有故事都已完成（包括測試）並且還有更多工作空間，則Scrum團隊將召開一次快速會議，以確定除了那些故事之外，還將將哪些故事納入衝刺中。在衝刺計劃中決定。如果多個利益相關者的優先級衝突，則產品負責人應與所有這些人舉行會議，並讓他們共同決定他們認為優先事項應該是什麼，然後他們可以嘗試說服產品負責人。

在更經典的方法中，應該發生類似的事情。由於項目經理不是從事這項工作的人，因此他們應該將在給定時間內可以完成的工作的判斷權交給專家：技術主管。他們總是可以詢問更多，但應該相信技術領先者的判斷。如果多個項目經理要依靠同一個人來完成任務，則這些項目經理應在他們之間自行決定任務的優先順序，然後信任技術人員以確保遵守該順序。在這種情況下，就沒有所謂的“延展目標”：按優先順序完成工作，如果有人碰巧沒有任務，他們就會走上眾所周知的食物鏈，詢問下一個任務應該是什麼。

通過嘗試在sprint的Agile / Scrum結構中以經典方式工作，給開發人員帶來了難以置信的巨大壓力，這實際上總是適得其反。在這樣的經典結構中，開發人員決不應該決定是否應該為一個項目經理或另一個項目經理執行任務，因為他們無法正確評估哪個任務具有最大的商業價值。這裡的問題中似乎描述了這種工作方式，這會導致開發人員精疲力盡，這會導致開發人員前往更綠色的牧場。

軟件項目經理如何使技術潛在客戶大量超載？

您需要通過建立界限來管理他們的期望。這是一個主題，您可以撰寫整本書，因此，我將只介紹您一直在運行的特定問題：經理因其不合理的要求而使您的團隊超負荷。

他們實際上的措辭方式對您有很大幫助，因為它很容易推後。下次PM詢問您為什麼X功能未完成時，您的回复應包含以下一些短語：

• 您知道我們承擔的責任比我們還多可以實現，因此我們必須優先處理X，Y和Z。

• 您記得我提到過，我們不能做的比X還要多，而我們只能做是的，如果我們明顯提前於進度。

• 我們的原始估算很準確，因此我們沒有時間去研究。

如果您承擔的是常規工作量，則PM會在此基礎上增加一些額外功能，然後抱怨為什麼這些額外功能沒有完成，請使用以下變體：

• 據我了解，X和Y被認為是多餘的東西，如果還有時間我們會承擔。我們最初的估計/目標非常準確，因此我們無法採用這一目標。

• 我不確定我是否遵循，您說這些是可拉伸的目標，對嗎？我們專注於主要目標（X，Y和Z）並已完成，但是我們沒有時間進行拉伸目標。

如果您使用的是敏捷交付模型，則可以幫助您擺脫措辭：

• ，正如所討論的那樣，這是我們的預測之外的延伸目標
• 我們必須優化積壓的訂單
• 我們必須將其推送到下一個衝刺

關鍵是要明確說明您的團隊的能力有限，並且當您的分配超出可行範圍時，您顯然必須優先考慮。

請注意，以上所有條件僅在處於半強職位時才有效，作為技術領先者應該如此。抵制不切實際的要求總是棘手的，因為它們往往來自不切實際的人。您需要知道如何與需要更多時間而不是團隊實際提供服務的人抗衡，他們在沒有合理的要求您的團隊的情況下堅持加班，他們說的是真正的目標“我不會拒絕”。處理得當需要經驗。

假設您知道自己的速度，則受可以完成多少故事點的限制。

企業需要優先考慮項目經理的工作量。

我不建議使sprint過載（因為如果您不按約定交付，則會違反計劃和敏捷的目的）。如果沒有及時提供故事，則責任最終將由項目經理承擔。

此外，假設PM是合理的（並且知道如何在敏捷環境中工作），他們應該知道，如果在sprint中添加了任何內容，則必須刪除其他內容，這也是他們的責任。

如果您擔心這是您的錯，請不要。

編輯：只需要重新閱讀您的帖子，就可以了。 stretch target 完全可以。這僅表示，如果團隊完成了所有的衝刺工作，則可以進行其他工作……但前提是您完成了約定的工作。以我的經驗，這種情況很少發生。

管理項目經理的期望是技術主管的工作。 PM的工作就是盡可能快地推進項目並使其正確完成。

作為技術帶頭人，這些是一些改善這些技巧的提示：

• 要求完成“更多點數”的所有請求均是他們希望優先看其故事的特定請求
• 說明您是按照董事會上的優先順序進行工作的。
• 如果您的PM有合理的期望，那麼您的團隊將按照合理預期的那樣快速而勤奮地工作，並且如果PM擔心特定團隊的成員沒有發揮作用，則應與團隊負責人聯繫。
• 希望看到增加的MVP點數是最好的方法，那就是增加團隊規模。請注意，如果最後期限迫在眉睫，那麼此選項不切實際。如果您還需要幾個月的工作，那就可以了。
• 當您的項目經理嘗試執行敏捷方法論之外的事情時，您會向業務經理解釋他們在做什麼，為什麼會出現問題以及如何在使用的方法中正確解決他們的擔憂。

給事物命名是成功的一半。

不要將它們稱為“拉伸目標”，而是始終將它們稱為“修飾下一個衝刺”。如果直接受到挑戰，您可以說“我們沒有敏捷的目標，我們有預測，沒有延伸預測之類的東西。”

如果最終其他人不再稱呼他們為延伸目標，您可以我可能贏了。