經(jīng)典案例
  • 金融大數(shù)據(jù)解決方案
  • 汽車大數(shù)據(jù)解決方案
  • 政府大數(shù)據(jù)解決方案
  • 鐵路大數(shù)據(jù)解決方案
  • 電力大數(shù)據(jù)解決方案
  • 軍工大數(shù)據(jù)解決方案
  • 解放軍總裝備部
  • 中國航天科工集團(tuán)
  • 航天科技集團(tuán)

北京軟件開發(fā)公司敏捷開發(fā)的6個實戰(zhàn)經(jīng)驗總結(jié)

發(fā)布于:2020-01-03 21:01來源:北京軟件開發(fā)公司 作者:北京軟件開發(fā)公司 點(diǎn)擊:



 

北京軟件開發(fā)公司華盛恒輝認(rèn)為,在大型企業(yè)中經(jīng)常是各種軟件開發(fā)模式混用,一些采用敏捷開發(fā),一些則是采用傳統(tǒng)的瀑布式或RUP(統(tǒng)一軟件開發(fā)過程)。敏捷開發(fā),相對傳統(tǒng)軟件開發(fā)模式,它主要是針對快速變化的需求,不斷優(yōu)化管理流程,終推出優(yōu)質(zhì)軟件。 原文作者Ulf Eriksson,是一家在線問題跟蹤軟件公司的創(chuàng)始人之一,他是敏捷開發(fā)的忠實粉絲,已經(jīng)進(jìn)行了多年敏捷開發(fā)的實踐。下面內(nèi)容主要是作者根據(jù)自己多年經(jīng)歷進(jìn)行的經(jīng)驗總結(jié)。

1. 快速迭代 相對那種半年一次的大版本發(fā)布來說,小版本的需求、開發(fā)和測試更加簡單快速。一些公司,一年僅發(fā)布僅2~3個版本,發(fā)布流程緩慢,它們?nèi)圆捎闷俨奸_發(fā)模式,更嚴(yán)重的是對敏捷開發(fā)模式存在誤解。 由一年發(fā)布2個版本轉(zhuǎn)到一個月發(fā)布2個版本,這也不太可能。但是現(xiàn)在來看,快速迭代已經(jīng)成為事實標(biāo)準(zhǔn),關(guān)鍵是要比目前的版本發(fā)布速度更快一些。 快速迭代,可以逼迫團(tuán)隊不斷優(yōu)化流程、提升工作效率,不要在無足輕重的事情上浪費(fèi)時間。如果離deadline還有6個月,那么整個工作節(jié)奏必然悠哉。如果每月發(fā)布一個版本,那么較以前效率必然會更高。如果發(fā)布周期過長,導(dǎo)致無法盡快發(fā)現(xiàn)用戶需求,進(jìn)而無法及時改進(jìn)產(chǎn)品。

2. 讓測試人員和開發(fā)者參與需求討論 需求討論以研討組的形式展開有效率。研討組,需要包括測試人員和開發(fā)者,這樣可以更加輕松定義可測試的需求,將需求分組并確定優(yōu)先級。 同時,該種方式也可以充分利用團(tuán)隊成員間的互補(bǔ)特性。如此確定的需求往往比開需求討論大會的形式效率更高,大家更活躍,參與感更強(qiáng)。 確定需求時,不要過度盯在細(xì)節(jié)上。需求報告過于詳細(xì),就是一種不敏捷的習(xí)慣,還浪費(fèi)大家的時間。當(dāng)然,不能錯過好點(diǎn)子,但就是不要太細(xì),因為項目真正實施起來時需求將會產(chǎn)生很大的變動。

3. 編寫可測試的需求文檔 開始就要用“用戶故事”(User Story)的方法來編寫需求文檔。這種方法,可以讓我們將注意力放在需求上,而不是解決方法和實施技術(shù)上。過早的提及技術(shù)實施方案,會降低對需求的注意力。 敏捷項目中編寫用戶故事有一個常用模板:作為一名[用戶類型],我想要[需求],以便于[原因]。應(yīng)用到這個例子,就是:作為一名用戶,我想要將歸檔程序數(shù)字化,以便于增強(qiáng)溝通、提高分享效率。 多數(shù)情況下,需求內(nèi)容需要更加充實和詳細(xì),這一步要放到后面做,開始不要這樣。用戶故事的方法有時會因過于簡短、不斷重復(fù)而受到批評。這里我們必須明白:需求文檔不是散文或詩歌,應(yīng)該清晰、簡明地描述用戶需求;需求文檔的重點(diǎn)也在于此,不要管形式多變或內(nèi)容是否重復(fù)這樣的問題。

4. 多溝通,盡量減少文檔 任何項目中,溝通都是一個常見的問題。好的溝通,是敏捷開發(fā)的先決條件。在圈子里面混得越久,越會強(qiáng)調(diào)良好高效的溝通的重要性。 團(tuán)隊要確保日常的交流,面對面溝通比郵件強(qiáng)得多。 敏捷開發(fā)鼓勵日常的協(xié)調(diào)會議和碰頭會,5~7人參與的會議盡量控制在10分鐘內(nèi)。碰頭時,要過一遍昨天完成了什么,今天要做什么,哪些問題仍待討論??梢杂肂urndown Chart(燃盡圖)來形象展示工作進(jìn)度。每次迭代的時候也都要開一個計劃會議和評審會議,一般需要的時間可能會長些,比如半天。這些會議的目的就是對工作查缺補(bǔ)漏。 評審會議很重要,傳統(tǒng)開發(fā)模式往往略過該環(huán)節(jié),導(dǎo)致一些錯誤做法不斷重復(fù),好的做法無法推廣。 開會時,可以將原先的分組打散,讓整個團(tuán)隊都參與到項目的需求討論和測試中來,這樣可以突出成員個人,讓大家更樂意參與。

5. 做好產(chǎn)品原型 建議使用草圖和模型來闡明用戶界面。并不是所有人都可以理解一份復(fù)雜的文檔,但人人都會看圖。 一個常見的問題是軟件新的功能與用戶想要的不一致。為了避免這一問題,可以模擬真實操作,改進(jìn)模擬操作過程中難以理解和不清楚的操作行為。

6. 及早考慮測試 及早地考慮測試在敏捷開發(fā)中很重要。傳統(tǒng)的軟件開發(fā),測試用例很晚才開始寫,這導(dǎo)致過晚發(fā)現(xiàn)需求中存在的問題,使得改進(jìn)成本過高。較早地開始編寫測試用例,當(dāng)需求完成時,可以接受的測試用例也基本一塊完成了。 敏捷開發(fā)中一個常見問題就是開發(fā)者沒有對已有的代碼庫進(jìn)行充分的回歸測試。迭代周期很短,從開始到交付就是4周的時間,這樣可以對迭代的設(shè)計、實現(xiàn)和底層測試一塊進(jìn)行回歸測試。 一系列迭代之后,可以只針對測試活動再補(bǔ)充一個迭代。這個迭代可以將重點(diǎn)放在系統(tǒng)測試、與其他系統(tǒng)的集成度、性能等方面。敏捷開發(fā)過程中,可能會導(dǎo)致過少的測試文檔。如果迭代周期為1個月左右,可以不必對測試文檔過于要求,但要制定好測試策略。 最后 可能大多數(shù)公司或團(tuán)隊還沒有開始嘗試敏捷開發(fā),不過可以開始從點(diǎn)滴做起,比如開碰頭會、為項目管理采用一個更加高效的管理工具等等。最后,希望上面的建議能夠為大家的軟件開發(fā)管理帶來幫助。

聯(lián)系方式:北京華盛恒輝科技有限公司

電話:010-52895342

郵件:service@hivekion.com

QQ 615179746

網(wǎng)址:http://m.sjzgqxxzx.cn

【北京華盛恒輝科技有限公司 ——hivekion)是一家軟件定制開發(fā)公司,專注IT產(chǎn)品研發(fā)與服務(wù),堅持穩(wěn)健經(jīng)營、持續(xù)創(chuàng)新、開放合作,在安全生產(chǎn)、大數(shù)據(jù)處理等領(lǐng)域構(gòu)筑了端到端的解決方案優(yōu)勢,為企業(yè)客戶提供有競爭力的IT解決方案、 產(chǎn)品和服務(wù)

------分隔線----------------------------
------分隔線----------------------------
QQ客服熱線