軟體開發和敏捷-對症下藥

每個人都有惰性，每個人都很自負，特別是對於軟體開發人員，他們總是過高的估計自我的能力，在任務的最後期限已經逐漸臨近的時候才會真正的全身心的投入任務，而往往造成的任務的延期和90%完成這種進度遊戲現象。而這也往往稱呼為學生綜合症。

敏捷方法論用很簡單的實踐來解決了這些問題，包括每日構造，每日的站立會議，短週期的迭代和細化到1-2天粒度的任務。所有這些都是為了每天視覺化的進度，可檢驗的進度。任何進度問題都會在每天暴露無遺。

帕金森定律強調，一份工作所需要的資源與工作本身並沒有太大的關係，一件事情被膨脹出來的重要性和複雜性，與完成這件事怕花的時間成正比。你以為給自己很多很多的時間完成一件事就可以改善工作的品質，但實際情況並非如此。時間太多反而使你懶散、缺乏原動力、效率低，可能還會大幅度降低效力。關鍵鏈專案管理的核心思路也正是基於這一點。

敏捷方法論中對於這點仍然是需要考慮關鍵鏈專案管理的特點和看板管理的文化，首先是要儘量講緩衝保留在專案最後，其次是對於每個任務是否完成都要有清晰準確的驗收定義，最後仍然是細粒度的粒度和任務計劃。

康威定律（Conway's Law）：“讓四個人開發編譯器，你就會得到四個（4-pass）編譯器”。原始表述更具有一般性：“產品必然是其組織通訊結構的縮影”。簡言之就是“方法決定結果”或是“過程變為產品”。這個定律無非也在告訴我們開發人員間的高效面對面的溝通對於好的產品和設計是至關重要的，由於溝通不順暢分散式的團隊往往會損害到軟體設計。

在敏捷方法論中我們強調，較之於過程和工具，應更注重人及其互動的價值。因此敏捷方法論更加強調站立會議，面對面溝通，結對程式設計，視覺化進度等最佳實踐的應用。

在人月神話裡面談到的布魯克斯定律大家都必須熟悉了，往往進度落後的專案中投入更多的人手往往使進度更加落後。這一方面是由於新人進來後的培訓成本時間，一方面是溝通不暢引起的消耗時間。

敏捷方法中強調的結對程式設計，迭代開發，小型團隊都是為了解決這些問題。通過迭代版本規劃將大專案規劃為了多個細化後的迭代版本，每個迭代版本都可以保持更加明確的輸入，輸出和介面。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-446947/，如需轉載，請註明出處，否則將追究法律責任。