隨著敏捷開發熱潮的到來，很多開發者開始了敏捷之旅！本人也不例外，正踏上敏捷的航班！
敏捷開發的模式和普通的開發模式存在幾點關鍵的不同：
@1、敏捷開發擁抱變化。
@2、是人管專案，而不是專案在牽制人。（人永遠處於主動地位，不可讓專案牽著走）。
@3、採用xp進行專案實踐。
@4、採用scrum進行過程管理。
本文主要**敏捷流程中如何確保專案的開發進度の相對估算加迭代求精法
當開發團隊第一次被問到"這個專案要多長時間能夠完成？"的時候，專案的需求不全，只知道大概的功能模組，非功能性的需求還不是很清楚。
那麼我們估計確定專案的開發時間呢？在敏捷中可以嘗試採用「@@」方法。
一、相對估算：
1、專案經理和開發人員：定義功能模組，同時賦予每乙個功能模組乙個規模係數 和難度係數 。給出乙個初步估計的分值。這個分值供相對參考使用。
比如，現在有顯示，查詢，修改三個功能模組，初步確定顯示是10分，那麼查詢可能定為15，修改可能定為20
2、專案經理和開發人員：選取乙個分值最小的模組，進一步分析，如上例中顯示為10分，最小分值的功能模組。確定，顯示需要有設計資料庫，查詢，顯示介面，顯示內容等操作，初步確定需要10人天(乙個人完成該工作的天數)。這樣，一分值對應的工作量就是1人天。那麼整個顯示，查詢，修改加在一起就是45人天。注意，這只是初步的結論。含有相當大的誤差。
這樣相對估算的過程就算完成了。接下來的任務是「迭代求精」。
二、迭代求精
1、開發團隊開始實現顯示模組，如果實際完成所用的時間是12人天，那麼根據比例關係，剩餘的工作所需的時間就為(12/10)*35=42人天。
2、開發過程中可以根據已經實現的模組，改變未實現模組的分值。然後根據修改後的分值，重新計算剩餘模組的相對分值。
三、其他總結：
1、開發過程中可以將每個模組定義乙個優先順序，按照從高到底的順序排列，對高優先順序的模組進行細分，最後確定分值最小的功能模組。
2、在估計模組工作量的時候，可以加入調整係數，開始時，調整係數可能比較高，如0.4，隨著專案的進行，各個功能模組的調整係數也在逐漸降低，經過幾次調整，可以將調整係數定為0。
3、開始的時候，調整係數可能較大，如0.4，那麼上例中專案時間就是[0.6*45~1.4*45]
後面顯示模組做過之後，經過調整，剩餘工作量是32個人天，現在可以將調整係數定為0.3，那麼剩餘的專案時間就是[0.7*32~1.3*32]。通過不斷迭代，最終對工作量的估算也越來越精確。
4、專案時間的估算是有開發人員自己確定的。那麼每個人如何估算某個模組所需要的時間呢？要求開發團隊最好能做到每天開個小例會，在會上，每個成員需要當前任務的剩餘的開發時間進行重新估計。
5、開發中在每日例會中及時解決瓶頸問題。
6、幾次迭代之後，可以確定乙個校正係數，這樣，在估算任務時間的時候，可以有效避免過於保守或者過於樂觀！
敏捷開發中對進度的把握
如何做effort的estimate?本文給出了敏捷開發模式中的乙個方法。專案經理被問到最多的問題就是，這個專案什麼時候才能完成？被問的時候，可能專案才定下來，僅僅知道大概的功能模組，非功能性需求還模糊不清，甚至團隊成員都沒到位。但是上級 銷售 客戶急切地要知道，這個專案什麼時候才能完成？被問的時候...
如何使用Worktile進行敏捷專案開發管理
worktile在任務管理上採用了看板檢視，非常適合進行敏捷專案開發管理。事實上，在開發worktile的過程中，我們也是自產自銷，使用worktile管理worktile本身的開發過程，在本文中跟大家分享一下使用worktile進行敏捷專案開發管理的一些經驗。在worktile團隊的開發管理過程中...
如何使用Worktile進行敏捷專案開發管理
worktile在任務管理上採用了看板檢視，非常適合進行敏捷專案開發管理。事實上，在開發worktile的過程中，我們也是自產自銷，使用worktile管理worktile本身的開發過程，在本文中跟大家分享一下使用worktile進行敏捷專案開發管理的一些經驗。在worktile團隊的開發管理過程中...