敏捷如何應對變化：敏捷團隊檢查和適應

在任何項目開始時建立的計劃都不能保證會發生什麼。事實上，這只是一個時間點的猜想。不少事情會合謀使計劃失效，項目人員可能來或去，技術會比預期更好或更糟，用戶會改變主意，競爭對手可能會迫使咱們作出不一樣或更快的反應，等等。敏捷團隊認爲每個這樣的變化都會帶來機會，而且須要更新計劃以更好地反映當前狀況的現實。

在每個新的迭代開始時，一個敏捷團隊整合在前面的迭代中得到的全部新知識，並相應地進行調整。若是一個團隊學到了一些可能影響計劃準確性或價值的東西，他們就會調整計劃。計劃的準確性可能會受到團隊發現他們過分或低估了進展速度的影響。或者他們會發現，某種類型的工做比之前想象的要耗費更多的時間。

計劃的價值可能會因產品全部者對潛在用戶的需求所得到的知識而改變。也許，根據從早期迭代中看到軟件的反饋，產品全部者已經瞭解到，用戶但願看到更多的一種特性，而且他們沒有像之前想象的那樣重視另外一種特性。在這種狀況下，計劃的價值能夠經過將更多所需的特性移動到發佈中來增長，而犧牲了一些價值較低的特性。

經過在Scrum中檢查和採用來處理需求的變化

也許Scrum和Agile最重要的因素是對溝通，開放和透明的熱情。這些因素是咱們在平常工做中使用敏捷和Scrum實踐所作的一切的基礎; 這就是爲何咱們重視合同談判中的客戶協做以及爲何咱們不懼怕迴應變化，由於咱們知道反饋很是重要。

敏捷方法只要求咱們從錯誤中吸收教訓和/或找出改進的新方法。做爲敏捷宣言的原則之一：

「團隊按期反思如何變得更有效，而後相應地調整和調整其行爲。」

正是經過這種開放式溝通的呼籲，Scrum鼓勵咱們在Sprint期間舉辦五項重要活動，旨在幫助咱們高效，緊密地合做，以及提升咱們的知識，並在將來變得更加有效。

這五個事件是：

• Sprint計劃 (Sprint Planning)
• 每日Scrum (Daily Scrum)
• Sprint評論 (Sprint Review)
• Sprint回顧 (Sprint Retrospective)
• 衝刺 (Sprint)

下面的摘要顯示了在各類Scrum事件中的檢查和調整。

全部這些對於他們本身的權利相當重要，正由於如此，我將在這裏簡要地研究每個。

Sprint計劃 (Sprint Planning)

這是啓動每一個Sprint的事件，也是產品負責人和開發團隊討論哪些產品待辦事項項目（PBI）將包含在Sprint中的地方。雖然產品負責人有權優先考慮每一個PBI以肯定是否可能包含在Sprint中，但咱們鼓勵開發團隊在必要時作出迴應，提出問題並進行回擊。而後，開發團隊預測他們能夠在Sprint中提供多少PBI，由於他們瞭解速度，資源以及可能影響其可用時間和資源的任何因素。

Sprint計劃會議的結果是得到Sprint目標和Sprint Backlog，每一個人都贊成這是現實和可實現的。

每日Scrum (Daily Scrum)

Scrum尋求有效利用您的時間和資源，Daily Scrum活動也不例外。每日Scrum的時間限制爲15分鐘。站起來不是強制性的。然而，許多團隊認爲這是一種有用的技術，可使會議保持簡短和重要。

每日Scrum爲開發團隊提供了一個機會，能夠檢查，評估實現Sprint目標的進度，並在接下來的24小時內審覈和規劃他們的活動。

Sprint評論 (Sprint Review)

從敏捷宣言再次看上述原則 - 「按期，團隊反思如何變得更有效，而後相應地調整和調整其行爲。」_這一原則自己就總結了咱們接下來兩次會議背後的緣由，Sprint回顧和Sprint回顧。

這兩項活動都在Sprint結束時舉行。敏捷方法的目標不是第一次讓全部東西「完美」，而是持續改進。這些事件有助於實現這一目標。

Sprint評審一般在Sprint的最後一天進行，讓您有機會向利益相關者（客戶，管理層以及任何其餘被認爲相關和感興趣的人）展現「完成」增量。除了展現Sprint期間產生的工做特徵外，您還能夠得到有用的反饋，這些反饋能夠包含在產品Backlog中，能夠幫助指導將來衝刺的工做。

Sprint回顧 (Sprint Retrospective)

Sprint的最後一次會議是Sprint Retrospective。這是Scrum團隊審查將來Sprint能夠改進的內容以及他們應該如何作的事情。Scrum的精神要求不管Scrum團隊有多好，總會有機會改進，Sprint Retrospective給團隊一個專門的時間來識別，討論和計劃。整個Scrum團隊應該參與其中，包括開發團隊，Scrum Master和產品負責人。會議應該是一個協做努力，就像整個Scrum和敏捷過程同樣。

衝刺 (Sprint)

Sprint自己就是一個事件，它包含全部工做以及在開箱時間內發生的全部其餘事件。

更多推薦的 scrum 文章

• Scrum的基本功 - 集合中英文版本 (Scrum事件)
• Scrum的基本功 - 集合中英文版本 (Scrum工件)
• Scrum的基本功 - 集合中英文版本 (角色和責任篇)
• Scrum的基本功 - 集合中英文版本 (基礎篇)

---

1. 它爲客戶提供了一個在開發週期早期看到軟件的機會，並提供反饋和輸入，以便可以快速、輕鬆地進行更正。
2. 工做軟件是一個很好的進度度量。從實際完成、測試和交付到用戶滿意程度的增量軟件功能方面衡量進展要準確和有效得多，而不是試圖衡量未完成的大型開發項目的完成百分比。