一、背景
過去的一年,用在敲**上的時間越來越少,年前突然從帶乙個專案,加到帶四個專案,倍感亞歷山卓,這其中酸甜苦辣,只有自己知道。由於經驗不足,導致很多問題。所以要寫一篇文章好好總結一下。
二、酸甜苦辣,冷暖自知
我們在專案中嘗試使用敏捷開發的思想來進行管理,經過幾次簡短的培訓,我們就上馬了,當時對於敏捷開發的認識還很膚淺,秉著「先用起來再說」的原則就幹上了,時間不等人啊。
現在回想起來,我們用敏捷開發,有其形,無其神,雖然按著敏捷流程,制定迭代計畫,開立會,評審會,總結會,但都流於表面了,沒有最大化地發揮其作用。
一開始,依賴專案組成員個人水平比較高,專案進行得還算順利。當由於產品需要,忽然加入其他3個專案組後,處境就變得不那麼樂觀了,開發人員水平參差不齊,對專案環境不熟悉等等,導致了一系列問題,這也間接地暴露了管理上的缺陷。對反思會上,我們總結了如下問題:
(1)對敏捷開發調研不充足,培訓進行得不到位,對敏捷開發認識不夠充分,經驗不足
(2)沒有準備必要的措施應對從舊管理模式到新模式的過度階段可能會出現的問題
(3)各專案組各水平程式設計師配比不合理也是導致過程混亂的原因,感覺敏捷開發的開發人員的水平要求比較高,最好是跨職能人才
(4)由於迭代計畫會,組員沒有參與,story分解,任務估點等並不準確,一方面導致開發過程中,進度失控,另一方面導致開發人員積極性不高,沒有主人翁意識
(5)敏捷開發管理工具使用規範沒有得到徹底貫徹,開發人員總是不及時更新。
(6)敏捷開發不提倡冗雜的文件,不代表沒有文件,出現了需求人員一拍腦門就改需求,開發人員疲於應對,最後都不知道到底該做成什麼樣子的情況,發現問題後,我們決定採用wiki工具對文件等進行管理,對需求等核心文件進行逐步完善,使變化可追溯。
(7)對優先順序把控不好,專案b依賴專案a的介面,這些介面的實現沒有給予足夠的優先順序,各專案組協商不夠及時,我干預得也不夠及時,導致專案b延期。
(8) 任務預計耗時與開發人員可用時間配比不合適,按整個組所有可用時間統一分配到任務的方式制定本次迭代計畫,但部分任務乙個人領後,跟該任務相關的任務,別的人不適合再領,導致「有未開始的任務,有未領任務的人」的情況。story分解,估點考慮不全面導致該問題。
……(1)開發人員沒有主人翁意識,開發積極性不高。
(2)由於前期準備不充分,在增加了3個專案組後,開發環境的變更導致幾次大規模返工,開發人員產生了牴觸情緒。
(3)沒有充分考慮大規模引入新員工對團隊地影響。
……不能光說不足的地方,我認為我們整個團隊也有閃光點:
(1) 遇到問題,能夠及時解決問題,這符合敏捷開發的思想,值得推廣。
(2)管理和開發過程出現問題,能做到及時改進,符合持續過程改進的思想。 ……
三、勉勵
經過這段時間的工作,也讓我深深領悟了兩件事,其
一、面子和責任是兩碼事,千萬不可混為一談,否則結局肯定裡外不是人。其
二、團隊建設,讓每個員工都有主人翁意識,值得思考,真的不簡單。
如果敏捷開發有成熟度區分,弱弱地說一句,我們現在應該屬於敏捷開發的初級團隊,但不管怎麼說,總算是找著點門了,自己勉勵一下自己吧。
專案經驗總結
每乙個專案過後,我們總是有各種各樣的體會,這些體會就是我們的收穫,也是我們成長的源泉,也許過了一段時間我會忘記,但是,筆記能夠讓他們清晰的保留下來!綠網專案 寧肯走的慢一點,也要保證方向是正確的!注意 無論做什麼專案,首先,我們需要清晰的明確大的環境,如究竟是在哪台伺服器上 究竟連線的是哪個庫 究竟...
專案經驗總結
使用者需求就是能幫使用者解決實際問題的一套解決方案。在經歷過多年的企業專案之後,發現專案中最大的風險來自於使用者需求的變更。需求變更產生風險的最大原因在於未做好需求處理,所以在此希望和大家 下企業應用的需求處理。先給大家舉乙個未處理好需求的例子 使用者說要做乙個實時監控的功能,要監控網路中實時發生的...
專案經驗總結
1 時間元件 html js var inittime function del on click function 2 介面初始化 初始頁面 var init finction 3 初始化列表,按照條件查詢 初始化列表,按照條件查詢 var showbookresourcegrid functio...