我一直在爲我的項目使用敏捷方法（XP和Scrum）多年，並取得了豐碩的成果。但在所有情況下，開發團隊的所有成員都承諾100％參與該項目。如何在團隊不穩定時管理敏捷開發？
現在我面對團隊不穩定的時候這樣做。例如，一個迭代可能有四個人在工作，接下來可能只有兩個或三個人工作。
我意識到這使得它很難（或不可能）使用正常速度方法進行估計，因爲它會波動很多而不穩定。接下來的是，在每次迭代結束時，人們無法真正期望能夠發佈。
也許在這裏需要另一種方法。只要從積壓的東西中抓取東西，只要有可能，就會混淆並釋放。我真的不喜歡，雖然...
任何想法？
從這個問題我假設你有一些開發者（可能是2）100％承諾項目和一些（另外2-3）只參加一次。
您可以做的一件事是爲100％承諾的核心開發人員和其他人設置不同的流程。爲核心人員使用正常的敏捷過程，並在正常的迭代週期中發佈他們的工作。對於非核心人員，不要做太多的規劃，並且假設他們（和你的）估計會成爲一次。理想情況下，他們的變更應該被隔離，並由核心成員合併成穩定的代碼分支，但並非每個項目的架構和團隊角色都允許這樣做。
問題的關鍵在於分離和隔離混沌源，讓項目和團隊的心臟不受影響。
我喜歡這種方法。仍然能夠與核心敏捷。其他「不穩定」的團隊成員的工作主要被認爲是我猜想的獎金。我認爲他們應該只是爲了支持核心團隊，也許只是爲了支持外圍的故事。 – 2009-10-31 12:31:56
讓將要在故事中工作的單個開發人員估算完成故事所需的工作量。您可以考慮該開發者估算中的歷史差異，但是您的想法是，您可以估算出他們的估算值，然後計算出您可以在該衝刺中完成的故事數量。
也許代替敏捷方法，您可以減慢其他iterative and incremental approaches。如果你不斷增加和減少團隊成員，那麼如果以周爲單位進行迭代，而不是以更長的週期進行迭代（可能在幾個月內進行測量）會更好。
這並不意味着你仍然不能使用一些敏捷技術。我仍然會維護你的積壓和燒燬圖表，意識到不是每兩週發佈一次，而是每隔6周（〜2個月）發佈一次。如果您有新開發人員加入更多經驗豐富的開發人員，請使用配對編程，將新開發人員分配給錯誤修復，或指派新開發人員維護單元測試以幫助他們學習代碼庫。
啊，但敏捷是迭代和漸進的，我認爲你的意思是使用類似RUP的東西？已經使用它，不喜歡它:-) 我認爲這將是有益的，以保持早期和持續釋放（徵求反饋等），但它可能無法準確計劃_ what_將包括在下一個版本中，只有這個星期會有一個發佈。 – 2009-10-31 19:17:58
Agile和RUP一樣是迭代和增量式的。你可以把它們全部拿出來挑選。把它看作是一個自己製造的過程。 – 2009-10-31 20:04:15
速度只是一個估計。
天真，如果你有一隊4個開發一個給定的速度v，然後安排你的迭代與(v/4)*number_of_developers
的速度，如果你正在失去成員特別是小於或強或弱您可以做傻事這個值平均。
這基本上是PivotalTracker與其團隊強度指標。
我想過這個，但是如果你有一個新的開發者（對於這個項目），他會比現有的開發者慢，只是因爲他不知道代碼庫。我不認爲你可以說每個隊員都有相同的速度。 – 2009-10-30 14:58:01
同意，這就是爲什麼我認爲你需要根據涉及的個人進行一些調整 – DanSingerman 2009-10-30 15:05:50
我不認爲這是一個正確的答案。這太不精確了。 – 2009-10-30 16:13:46
不要忘記，平均速度主要用於先行發佈計劃; 團隊負責在每次迭代中選擇需要處理多少積壓項目（儘管知道歷史速度可以幫助他們）。
如果您的團隊規模（因此速度）從迭代到迭代波動，您仍然可以使用過去N次衝刺的平均速度進行有用的版本規劃，假設團隊波動將持續，因此它們的長期平均值速度實際上是穩定的。
您的主要問題在於，從團隊從衝刺變爲衝刺，團隊會發現很難給出可預測的估算和交付。這也會傷害團隊承諾和持續改進。
這種情況實際上可能非常適合看板方式。查看Henrik Knibergs介紹看板的快速概述。
祝你好運！
感謝您的回覆，我同意。但我不明白看板如何幫助球隊給出更可預測的估計值，儘管我確信它在其他方面有所幫助。 – 2009-11-03 12:20:14
因此，你有一個不斷變化的團隊規模的項目，你的老闆希望你準確估計它需要多長時間？你可以做到這一點，只要你記住準確和精確的區別。您的精確度將主要取決於物品的數量以及每個物品的粒度（分解）如何;越多的項目你有更多的大數定律爲你工作，平均超出和低估。
您的準確性是置信度的函數。請注意，估算值不是單點值，而是包含置信度百分比的範圍。例如，適當的估計不會是「2周」，即「2周50％的置信度，4周80％的置信度」。
如果我是被賦予不值得羨慕的任務的人，他提供了一個項目的完成度估計，這個任務與原始文章中的任意管理一樣，我會嘗試根據分配的最小人數（例如，「給予2名開發人員48至66周[50％至80％自信]」）和與所分配的平均人數相關的範圍（例如，「5個開發人員25至45周[50％至80％自信]「），並使用平均數字中的低位數字和最小數字中的高位數字（例如，」從2到5名開發人員[50％到80％自信]給予25到66周「），以及即使如此，我也會對此做出免責聲明（「由於上下文切換導致的損失時間加上10％」）。
更好的是，我會解釋爲什麼這種安排是禮貌的，次優的，以及爲什麼多任務是Hell項目的主要路標。
正如其他人所建議的，將工作流程從基於迭代的改爲基於流程（看板）可能是一個很好的策略。使用看板，您可以通過更改積壓項目中的項目優先級來處理更改項目優先級;一旦項目被團隊抓住，一般會完成（在工作流程中一直流動，不允許利益相關者通過擰入正在進行的工作來破壞團隊）。我使用Kanban進行持續工程項目，效果非常好。考慮到它對估計有什麼幫助，持續流動的關鍵是嘗試讓每個工作項目的大小大致相同（1x，2x，3x，而不是10x，20x，100x）。您應跟蹤過程狀態更改的日期，例如隊列1/15，設計1/22，開發1/24，測試2/4，集成2/7等，然後生成通過工作流跟蹤項目移動一個累積的流程圖定期評估隨時間推移的狀態持續時間。考慮到你知道每個項目的大小和通過項目工作流程的時間，計算項目應該花費多長時間是一個留給讀者的微不足道的計算練習。（更有趣的問題是如何發現約束......然後如何去除它們......提示：在狀態中查找很長時間，因爲工作堆積在約束之前。）
...社區wiki ... – joshcomley 2009-10-30 14:42:10
不，不是社區wiki。在這種情況下，這個問題將有一個適用於wic和他的團隊的答案。 – 2009-10-30 14:42:50
我投票結束這個問題作爲題外話，因爲它不是關於編程 – 2017-10-20 09:40:31