敏捷開發的6個實戰經驗

2021-06-20 08:58:12 字數 2466 閱讀 5965

1. 快速迭代

相對那種半年一次的大版本發布來說,小版本的需求、開發和測試更加簡單快速。一些公司,一年僅發布僅2~3個版本,發布流程緩慢,它們仍採用瀑布開發模式,更嚴重的是對敏捷開發模式存在誤解。 

由一年發布2個版本轉到乙個月發布2個版本,這也不太可能。但是現在來看,快速迭代已經成為事實標準,關鍵是要比目前的版本發布速度更快一些。 

快速迭代,可以逼迫團隊不斷優化流程、提公升工作效率,不要在無足輕重的事情上浪費時間。如果離deadline還有6個月,那麼整個工作節奏必然悠哉。如果每月發布乙個版本,那麼較以前效率必然會更高。如果發布週期過長,導致無法盡快發現使用者需求,進而無法及時改進產品。 

2. 讓測試人員和開發者參與需求討論

需求討論以研討組的形式展開最有效率。研討組,需要包括測試人員和開發者,這樣可以更加輕鬆定義可測試的需求,將需求分組並確定優先順序。 

同時,該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高,大家更活躍,參與感更強。 

確定需求時,不要過度盯在細節上。需求報告過於詳細,就是一種不敏捷的習慣,還浪費大家的時間。當然,不能錯過好點子,但就是不要太細,因為專案真正實施起來時需求將會產生很大的變動。 

3. 編寫可測試的需求文件

開始就要用「使用者故事」(user story)的方法來編寫需求文件。這種方法,可以讓我們將注意力放在需求上,而不是解決方法和實施技術上。過早的提及技術實施方案,會降低對需求的注意力。 

規劃業務需求,可以採用「3w模板」,也就是: 

誰(who)

是什麼(what)

為什麼(why)

誰(who)是什麼(what)為什麼(why)

使用者希望借助乙個應用程式在不同伺服器間傳輸檔案

為了儲存專案資料

為了更加接近「使用者故事」,我們可以改寫為:

誰(who)是什麼(what)為什麼(why)

消費者/使用者

想將歸檔過程數位化

為了增強溝通,提高分享效率

敏捷專案中編寫使用者故事有乙個常用模板:作為一名[使用者型別],我想要[需求],以便於[原因]。應用到這個例子,就是:作為一名使用者,我想要將歸檔程式數位化,以便於增強溝通、提高分享效率。 

多數情況下,需求內容需要更加充實和詳細,這一步要放到後面做,開始不要這樣。使用者故事的方法有時會因過於簡短、不斷重複而受到批評。這裡我們必須明白:需求文件不是散文或詩歌,應該清晰、簡明地描述使用者需求;需求文件的重點也在於此,不要管形式多變或內容是否重複這樣的問題。 

4. 多溝通,儘量減少文件

任何專案中,溝通都是乙個常見的問題。好的溝通,是敏捷開發的先決條件。在圈子裡面混得越久,越會強調良好高效的溝通的重要性。 

團隊要確保日常的交流,面對面溝通比郵件強得多。 

敏捷開發鼓勵日常的協調會議和碰頭會,5~7人參與的會議盡量控制在10分鐘內。碰頭時,要過一遍昨天完成了什麼,今天要做什麼,哪些問題仍待討論。可以用burndown chart(燃盡圖)來形象展示工作進度。每次迭代的時候也都要開乙個計畫會議和評審會議,一般需要的時間可能會長些,比如半天。這些會議的目的就是對工作查缺補漏。 

評審會議很重要,傳統開發模式往往略過該環節,導致一些錯誤做法不斷重複,好的做法無法推廣。 

開會時,可以將原先的分組打散,讓整個團隊都參與到專案的需求討論和測試中來,這樣可以突出成員個人,讓大家更樂意參與。 

5. 做好產品原型

建議使用草圖和模型來闡明使用者介面。並不是所有人都可以理解乙份複雜的文件,但人人都會看圖。 

乙個常見的問題是軟體新的功能與使用者想要的不一致。為了避免這一問題,可以模擬真實操作,改進模擬操作過程中難以理解和不清楚的操作行為。 

6. 及早考慮測試

及早地考慮測試在敏捷開發中很重要。傳統的軟體開發,測試用例很晚才開始寫,這導致過晚發現需求中存在的問題,使得改進成本過高。較早地開始編寫測試用例,當需求完成時,可以接受的測試用例也基本一塊完成了。 

敏捷開發中乙個常見問題就是開發者沒有對已有的**庫進行充分的回歸測試。迭代週期很短,從開始到交付就是4周的時間,這樣可以對迭代的設計、實現和底層測試一塊進行回歸測試。 

一系列迭代之後,可以只針對測試活動再補充乙個迭代。這個迭代可以將重點放在系統測試、與其他系統的整合度、效能等方面。敏捷開發過程中,可能會導致過少的測試文件。如果迭代週期為1個月左右,可以不必對測試文件過於要求,但要制定好測試策略。 

最後

可能大多數公司或團隊還沒有開始嘗試敏捷開發,不過可以開始從點滴做起,比如開碰頭會、為專案管理採用乙個更加高效的管理工具等等。最後,希望上面的建議能夠為大家的軟體開發管理帶來幫助。(編譯/王殿進)     

敏捷開發的6個實戰經驗

6個實施敏捷開發的技巧 快速迭代 讓測試人員和開發者參與需求討論 編寫可測試的需求文件 多溝通 儘量減少文件 做好產品原型 及早考慮測試等。1 快速迭代 快速迭代,可以逼迫團隊不斷優化流程 提公升工作效率,不要在無足輕重的事情上浪費時間。如果離deadline還有6個月,那麼整個工作節奏必然悠哉。如...

敏捷開發的6個實戰經驗

1.快速迭代 相對那種半年一次的大版本發布來說,小版本的需求 開發和測試更加簡單快速。一些公司,一年僅發布僅2 3個版本,發布流程緩慢,它們仍採用瀑布開發模式,更嚴重的是對敏捷開發模式存在誤解。由一年發布2個版本轉到乙個月發布2個版本,這也不太可能。但是現在來看,快速迭代已經成為事實標準,關鍵是要比...

敏捷開發的6個實戰經驗

在大型企業中經常是各種軟體開發模式混用,一些採用敏捷開發,一些則是採用傳統的瀑布式或rup 統一軟體開發過程 敏捷開發,相對傳統軟體開發模式,它主要是針對快速變化的需求,不斷優化管理流程,最終推出優質軟體。1.快速迭代 相對那種半年一次的大版本發布來說,小版本的需求 開發和測試更加簡單快速。一些公司...