何時執行敏捷中的峯值

Question

在我目前的公司中，我已經開始引入敏捷實踐，並且我們的開局不錯。我們正在通過我們的第一個版本，並很快開始我們的第二個版本。雖然管理層已同意在迭代期間不推出任何新工作，但對版本/功能規劃進行範圍界定仍在進行中。話雖如此，我發現我們在何時/何時適應在迭代期間需要執行的尖峯，以便進行以下迭代。

在目前的時間，管理層/項目經理正在收集高峯，並在迭代開始時向每個相關開發人員提供所需的高峯期，開發人員將在接下來的星期三產生高峯任務，工作可以安排到下面的迭代中。

儘管如此，似乎有更好的方法來收集尖峯周圍的要求。其他人如何安排時間來執行峯值？我們不會安排所有開發人員80小時進行一次迭代，因此會議/電子郵件/尖峯等有一點喘息空間。

這就是說，我想確保管理不是除非他們知道該工作將在下面的迭代中執行。有幾次，他們要求提供一些尖峯，以便不安排工作的執行。

任何建議將不勝感激！

Answer 1

我們在迭代計劃中直接包含尖峯信號。他們的優先級很高，主要是因爲他們是固定的時間。請記住，峯值並不總是會導致更多的發展。這對於管理層來說是一個相當快捷的方法，可以知道某個特定的想法是否值得。我們發現最好是限制開發人員在每次迭代中花費的時間，以阻止我們稱之爲兔尾（即最終追逐數百條路徑而沒有完成任何事情）的時間。還要確保開發人員知道何時停止。高峯只是爲了確定一個估計值，而不是爲該估計值提供代碼。它就像其他用途的原型。你不想使用它，你只是想更多地瞭解它。

Answer 2

當我們需要調查一些我們不太瞭解實際進度和估計任務的事情時，我們會使用峯值。這就是爲什麼峯值通常被時間限制的原因。這意味着如果後續任務從未安排完畢，因爲獲得的知識可能會讓您重新考慮。它可能還希望您延遲實際實施，直到完成先決條件或更重要的任務。基本上我說：你的尖峯也是敏捷的，不斷重新評估你的情況。還有一件事：我們通常會在實際執行任務之前執行一項設計任務，以確保開發人員瞭解問題和適當的解決方案。

Answer 3

當一個新的故事進入並且團隊需要一個峯值才能估計它時，我們的產品負責人將峯值和故事添加到積壓並優先考慮它們。

我們的峯值計劃爲迭代中的任何其他積壓項目。我們從來沒有發生過這樣的事情，即我們安排了高峯，並開始在相同的迭代中實施積壓項目。

令人驚訝的是，您只說到管理層，而不是現場客戶或產品負責人。 尖峯是該項目的一部分，因此應該在項目時間上進行。因此，決定將團隊時間花在高峯或故事上。

Answer 4

在我工作的地方，峯值往往是一個不容易估計的時間框架調查。這可能需要一個小時，或者可能需要100個小時，在做高峯作業之前還不清楚。當時間到了或工作得到適當估計時，峯值就完成了。

如何處理錯誤？某種程度上，bug在某些方面可能與峯值相似，比如不知道需要多長時間，因爲不清楚需要改變什麼。

Answer 5

尖峯是一個調查故事，當沒有足夠的或者有多種方法來解決，增強或實現某個產品或功能時就會完成。

尖峯需要根據您試圖達到的最終用戶功能來定義，您必須執行哪些操作才能執行峯值功能。

一個高峯應該有接受標準，它定義了高峯的結​​果是什麼，即DONE的定義。

秒殺時間應該是盒裝時間，通常少於40小時。如果某些事情確實需要更多時間，則會執行初始峯值以確定基於第一次峯值結束時提供的信息需要多少次額外峯值。

峯值或者在時間結束時完成，或者當滿足接受條件時完成。

下面是一個尖峯故事的一個例子 -

故事： 作爲用戶角色 我想執行的ABC 穗，這樣我可以做XYZ

驗收： 鑑於我執行ABC 當我完成秒殺 然後我應該產生/附加XYZ的故事原型/神器。

注意：您可以與技術架構師或產品負責人一起請求尖峯針對接受標準進行更具體的描述，以清楚地列出應在哪些工件中列出哪些類型的工件和哪些細節以實現XYZ。