1. 程式人生 > >移動應用開發部,實施敏捷開發3個月後的一些經驗和教訓。

移動應用開發部,實施敏捷開發3個月後的一些經驗和教訓。

部門採用敏捷開發了3個月,這3個月利用敏捷的思想在部門實施了敏捷開發的大部分實踐和嘗試,這裡總結一下這3個月實施敏捷開發的一些工作狀況。

一、敏捷開發的具體工作;

1. 整體人員進行敏捷開發培訓,在部門內選擇不同的人員擔任產品負責人(PO)、ScrumMaster;

2. 敏捷團隊的人員架構:敏捷團隊到底是1個組(20人)好,還是分為多個開發小組(每個組5-8人)好,網上敏捷實施教練各說各的好,沒有統一答案,我們嘗試過、根據功能模組分為三個小組進行第一期開發、然後第一期開發完成後進行缺陷修復的時候,把團隊分為1個大團隊;

3. 敏捷開發的週期的時間,嘗試過2周和1週一個Sprint週期;

4. 敏捷開發專案管理軟體:Excel、RTC 、ScrumWorks 、禪道、白板。最終選定禪道來進行專案管理;

5. 利用Product BackLogs方式進行需求管理,採用故事敘述的方式進行需求描寫;

6. 每日早會、工作估算

7. 其他等等

二、敏捷開發中的不足之處:

1. 實施敏捷的範圍太大:錯誤的低估了敏捷開發的管理難度,當時我們認為相對與整個公司來說,部門20幾個人實施敏捷開發已經是很小的一部分,我們沒有敏捷教練、公司沒有敏捷實施經驗的人、所有的嘗試都是摸著石頭過河,導致實施敏捷過程中很多沒有做到位,對整個過程來說效果不好,最直接的影響就是缺陷比較多、加班比較多等;

2. 團隊磨合不足:部門剛成立,團隊成員彼此之間的相互瞭解程度與整體磨合還不夠,在分為多個小組進行開發時,小組之間的銜接不夠好,開發、測試、需求之間的銜接做得不好,以往都是通過詳細的需求文件、評審、設計文件進行溝通,忽然之間這些東西都弱化了,導致開發沒有按照需求的設計開發、需求變更或通知不及時、需求沒有驗證開發產品、測試摸不著路。

3. 個人素質:敏捷開發要求人員的素質非常高,假如團隊內有10個人,9個人很努力,但是有1個不努力然後又拿著同樣的待遇,這個團隊的生產效率絕對不會是90%,團隊目前的大部分成員都沒有達到敏捷開發所需要的素質;

4. 績效管理:在實施敏捷開發中,個人績效怎樣和團隊貢獻結合,缺少針對團隊績效考核機制和細則,對團隊考核機制實施的經驗不足,帶來的激勵也不足。

5. 需求的管理:需求缺少一個總體的產品負責人對整個產品的需求從版本、整體需求管理進行把控,組內需求人員不足,更多的是UI人員充當需求的角色,出現的問題主要是在溝通的環節,需求的變更不能有效的通知到開發等我難題。

6. 開發:開發過程中首先犯的一個錯誤就是完美主義,開發這邊在架構上花費的時間較多,導致很多重複工作,我們的架構儘量的簡單,應該儘早進入開發,儘早的交付工作成果、通過不斷的重構進行完善架構,我們想先把架構做得完美,做了很多現在還用不著的。

三、敏捷開發中較好的地方:

1. 敏捷開發中,發現了能夠適合敏捷開發人員,這些人都能積極的溝通、發現問題、主動幫助部門成員。

2. 原型工作方式、在這3個月之中,我們不斷的嘗試怎樣利用較好的原型方式加快開發和減少溝通的成本。

3. 部門內部的氣氛較好,相互之間的溝通、幫助比之前好了非常多。

4. 溝通意識的提高、例如每日晨會(5-10分鐘)的方式,這個習慣一直保持,養成了在團隊內部能夠快速響應,現在慢慢養成了一種比較好的快速溝通方式。

5. 部門核心心人員的素質提高、雖然敏捷開發過程中遇到了非常多的困難,但是部門核心人員之間能夠主動提出問題、一起討論和溝通、及時把偏差的問題糾正,在政民通第一期結束後,發現缺陷和問題較多,馬上根據資料進行問題總結,提出解決了方案。

四、是否適合用敏捷:

1. 績效考核:目前公司的績效制度與敏捷開發的有一定衝突,公司的考核制度更注重考核個人,並不是說用來敏捷開發就不考核個人,而是選擇了敏捷開發,就意味著需要選擇比考核個人更有效的提升績效的方法敏捷開發更注重考核團隊,敏捷開發對於提升績效的主要機制:不是依靠一個有強大控制能力的領導或一個固定的流程,而是一種能自我適應和改進的機制,進而讓團隊進入自組織狀態,以自己的方法解決問題。

2. 激勵機制:移動網際網路人員工作需要很多外部的激勵,如:工作成就感、晉升機會、較好的工作環境、他們天生需要很好的激勵機制,但是對於我們公司目前的狀況和所做開發的專案對於開發人員來說成就感不高,所以我們需要在做我們自己的專案之餘努力尋找能夠找到一些公眾專案,然後利用20%的資源進行開發,建立更為有效的激勵措施和機制實行。

3. 從前2個月來看,不適應全範圍內實施敏捷開發,可以精選少部分人員進行創新型新產品開發(1-3個月的產品),如我們後期要做的幾個專案;

4. 後期的社群類產品的開發,不能走敏捷開發的老路, 需要把CMMI和敏開發結合,敏捷開發中確實有一部分能夠加快開發效率,比如原型工作方式、晨會、Sprint週期等。可以把CMMI進行裁剪適合移動應用開發的流程模式