接觸Scrum時間不長，開發中遇到的問題比預想的要多很多。

Scrum上面說了，每一個Sprint的時間設定在2——6周是比較合理的。我認為一般的專案一個Sprint4周比較合理。由於我們的pj專案不是很大，真正開發起來一月個差不錯專案就哦了。所以第一個Sprint採用的是一週時間，這樣能動性強了，但是暴露出了更多問題：

1、由於第一個迭代過程中，涉及到開發環境的配置及搭建，這些如果分別算是一個story，那麼時間怎麼評估怎麼算呢？其實這些東西挺花費時間的。算的話，時間怎麼計算合理？不算就肯定得讓團隊加班加點兒。結果我們採取的方式比較折中。以大家每天的工作時間*0.6為有效編碼時間，以拍撲克的方式去平均數，估算每個story時間，留出足夠的時間空餘；

2、傳統開發方式的影響。評估過程中，每個story的顆粒過細，建立story應該是站在使用者的角度去考慮需求，然後一會兒就又去建立一個story：這個xx專案除錯的除錯工作。我認為：既然敏捷開發是每個人在開發的過程中再確定系統具體的需求，那麼就應該綜合考慮某一條線功能的複雜性與粒度問題。不用每個功能都分得特別細；

3、由於第一個迭代時間非常短，可以說，完成的都是一些準備工作與已知的技術攻堅，直接導致第一個迭代沒有出任何可視的專案成果。這裡是有悖于敏捷精神的。第一個迭代中，最好出一些可視的專案成果，領導查問起來，儘管團隊成員都做了很多，但是不至於拿不出可視的東西。

另外，儘管我們第一個Sprint沒有出項目成果，但是出色的完成了準備工作，使我們過分樂觀了客觀現實，導致我們第二個sprint的開發大大受阻。

年前因為趕時間，由於與jc系統互動的webservice中的方法，並不是全部通過了單元測試，也就是說，有些實現方法編碼還是有問題的。由於系統之間彼此互動的東西很多，做假資料繼續進行開發不是沒有可能，但是非常浪費開發人員的時間，不然就得等jc那邊除錯好相應方法；如果僅僅是這樣還算是幸福的，如果修改方法名或者引數，那麼不僅jc系統那邊對應的方法重新改、重新部署，我們這邊所有開發人員都得跟著重新換介面。

4、彼此依賴，無法進行。由於我們pj系統的現有需實現的功能，都需要與jc系統做互動。之前的實現是將我們pj系統中需要的資料，從jc拷貝到我們系統中來，這樣設定，我們前期工作比較好開展。而現在是jc系統那邊維護唯一一份資料，而我們這邊與jc做溝通除錯webservice的人員沒有完成，我們組其他成員就無法正常進行開發。影響專案程序。

5、會議太頻繁。儘管我們第一個Sprint只有一週時間，但是由於出現了上面依賴問題，我還是召開了Sprint實施中召開了迭代計劃會議。商討其他story以及時間。每日的站立會議以及後期的評審會議、反思會議……

6、照貓畫貓、生搬硬套之嫌。第一個Sprint，由於大家對Scrum還不是很熟悉，實施起來有些呆板有些生硬，這也是剛開始實施敏捷開發過程時，很容易犯的問題。

7、開發過程中，好多人都在看別人寫的程式碼，時不時就會傳來抱怨聲一片片~~~這裡只想說兩句話：一、快速看懂別人程式碼的思路，是一種能力；二、寫單元測試，從我做起。

目前專案中亟待解決的問題：

專案組成員應坐一起開發，溝通不及時會浪費更多的時間；

jc那邊webservice方法的單元測試；

查詢效率問題以及連帶產生的hibernate優化、程式碼優化、思路優化問題。

敏捷團隊之所以敏捷，是因為專案組中有：具有大局觀令人敬服的組長、各有專攻溝通能力強的組員以及和諧的團隊。然後堅持“以人為本”的方針，實現有限時間內的最大價值。提高團隊成員的主觀能動性，這是敏捷開發最基礎的。不能做到這一點，就又回到了之前的呆板的開發模式中，敏捷開發就無法敏捷。