《敏捷軟件開發實踐：估算與計劃》第21章 關于計劃的溝通，重點和要點的思維導圖及文字內容。

第21章 關于計劃的溝通

The more elaborate our means of communication the less we communicate.?

我們希望所有的溝通(尤其是有關估算和計劃的溝通)是頻繁的、坦誠的和雙向的。

因為敏捷計劃是頻繁更新的，所以頻繁地就計劃進行溝通很重要。

如果開發團隊和客戶團隊希望彼此信任，坦誠的溝通就很重要。

我們鼓勵針對計劃展開對話和討論，并根據反饋和新知識對計劃進行迭代和細化。

我們要承擔起讓所有接收者都理解我們所傳遞的信息的責任。他們不僅需要聽到有關的信息，還需要理解它。

敏捷開發團隊通常使用大幅的、可見的圖表作為溝通手段，即在團隊的工作區中懸掛幾張大幅的、可見的圖表，項目團隊的每個人都能了解每張圖表顯著傳遞的信息(信息發射源)。

21.1 就計劃進行溝通

當我們就項目進度表與相關方進行溝通時，應該包含團隊對這個估算的確信程度，或者包含可能的日期范圍，或者兩者都包含。

在傳統項目中，甘特圖通常用于預測、編排和協調任務。在敏捷項目中，我們可以利用甘特圖很好地顯示分派到各次迭代的特性。

在敏捷項目中，我們將甘特圖停留在特性層面，不把每個用戶故事分解成它的組成任務。即顯示項目的特性分解結構(feature breakdown structure)而不是工作分解結構(work breakdown structure)。因為產品價值的增加是來自于特性的完成，而不是由組成特性的任務的完成所帶來的，所以只顯示到特性即可。

敏捷項目的甘特圖中，每個特性都占據了它所編排進的迭代的整個長度。因為無論特性在迭代中任何時候完成，都不會在迭代結束前就提供。

敏捷項目的甘特圖中不顯示對資源的分配。因為在敏捷項目中，由整個團隊負責交付所有的特性。

21.2 就進度進行溝通

溝通項目進度的主要方法是發布燃盡圖。

發布燃盡圖上顯示的進度是剩余工作量和團隊速度的一個函數。

預測剩余迭代次數的簡單方法就是將還要開發的點數除以團隊的速度，然后把它向上舍入到最近的整數。

團隊對速度的測量是不精準的，而且我們預期速度會發生波動。

在預測剩余迭代次數時，通常最好是使用可能的速度范圍。

選擇速度范圍的方法，是使用團隊在過去 8 次迭代中的速度。在選擇速度值范圍時，建議最多考慮過去 8 次迭代。如果團隊沒有 8 次迭代，就使用所有的迭代。

在 8 次迭代中尋找 3 個值：

1. 最近一次迭代的速度。

2. 平均速度。

3. 最慢的 3 次迭代的平均速度。

這 3 個值很好地描繪出剛發生的情況、“長期”平均的情況和最壞條件下可能發生的情況。使用這 3 個不同的速度值來預測在給定日期之前可以完成工作的大致數量。

21.3 迭代結束總結

每次迭代結束后可以用不到 30 分鐘的時間來完成小結。對于使用 2 周長度的迭代，意味著每周花在寫報告上的時間最多只有 15分鐘。

21.4 小結

我們希望針對估算和計劃進行的溝通是頻繁的、坦誠的和雙向的。

甘特圖可以用作對計劃進行溝通的有益工具，在甘特圖中應采用特性分解結構而不是工作分解結構，并且圖中的特性應該顯示為在整個迭代持續期內都在進行處理。

燃盡圖是對進度進行溝通的主要手段，但還需要有一個圖顯示開發團隊在每次迭代中的速度。

把速度考慮成一個取值范圍而不是單個值是有益的。

考慮速度的取值范圍的好方法是同時使用最近一次迭代的速度、前 8 次迭代的平均速度和前 8 次迭代中最差的 3 次迭代的平均速度。這 3 個值很好地描繪出剛發生的情況、長期平均的情況和最壞條件下可能發生的情況。

迭代結束總結可以傳遞當前信息，也可作為供將來使用的歷史文檔。

---

版權聲明

本人所讀圖書的版權屬于原著者和譯者。這里僅為個人學習使用。但由本人學習整理所形成的音頻、圖片、文字和視頻等的版權為本公眾號擁有，任何人不得未經授權轉載。如果你覺得本文有用，歡迎分享給其他人。謝謝。

---

總結

以上是生活随笔為你收集整理的软件开发计划_敏捷软件开发实践：估算与计划读书笔记123第21章 关于计划的沟通...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。