首頁技術(shù)文章正文

什么是敏捷開發(fā)？各崗位職責(zé)與傳統(tǒng)開發(fā)有什么不同？

更新時間:2021年05月13日11時45分來源:傳智教育瀏覽次數(shù):

敏捷開發(fā)簡述

敏捷開發(fā)是一種以人為核心進(jìn)行迭代的開發(fā)方法。

在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，每一個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。

敏捷開發(fā)現(xiàn)在主要包括：極限編程、SCRUM、Crystal Methods、FDD（特性驅(qū)動開發(fā)）等。

敏捷開發(fā)簡單理解就是，開始項目的時候不追求一步到位完美的代碼，而是在盡量短的時間周期內(nèi)，開發(fā)出產(chǎn)品的核心功能。盡快上線發(fā)布，后面按照周期進(jìn)行迭代升級，完善產(chǎn)品。

在說敏捷開發(fā)的應(yīng)用之前，先聊聊為什么需要敏捷開發(fā)。

程序員大多數(shù)都會碰到需求一直變一直變，無線延。而且老項目基本是牽一發(fā)動全身，我們以為的一個BUG，會影響到另一個問題。還有各種開發(fā)文檔、產(chǎn)品文檔、接口文檔和測試報告沒有契合過等各種問題。

如果你遇到這種情況，可以開始了解敏捷開發(fā)流程了。

敏捷開發(fā)的應(yīng)用

敏捷開發(fā)的流程：需求規(guī)劃和分期，需求評審，需求講解，方案評審，每日會議，性能測試，CodeReview，Demo，測試階段，線上BUG修改流程。

一個敏捷開發(fā)小組的日常：

如果一個管理還把產(chǎn)品和開發(fā)分家成兩個部門，一定會有一些矛盾。我們比如是一個網(wǎng)站開發(fā)，基于微服務(wù)負(fù)責(zé)網(wǎng)站的某一個小模塊成立一個敏捷開發(fā)小組。標(biāo)準(zhǔn)配置應(yīng)該是：4個開發(fā)，其中一個起碼是高級程序員。一個產(chǎn)品經(jīng)理，一個測試，一個項目經(jīng)理。項目經(jīng)理主要負(fù)責(zé)網(wǎng)站的某模塊的維護(hù)和協(xié)調(diào)。

日常分工：

產(chǎn)品經(jīng)理：寫需求設(shè)計文檔，要把需求整理成Ticket，隨時和項目成員進(jìn)行確認(rèn)溝通。
開發(fā)人員：按照需求文檔的優(yōu)先級提取Ticket，完成日常的開發(fā)任務(wù)；
測試人員：測試已經(jīng)部署到測試環(huán)境的程序，如果發(fā)現(xiàn)Bug，提交到Ticket；
項目經(jīng)理：保證日常工作的正常流程，執(zhí)行反饋，并且協(xié)調(diào)組員，組織每日會議。

敏捷開發(fā)各崗位職責(zé)：

產(chǎn)品經(jīng)理：產(chǎn)品經(jīng)理的職責(zé)就不光是畫原型圖了，而是給產(chǎn)品的模塊分期，制定好優(yōu)先級和功能是最重要的。產(chǎn)品經(jīng)理要做的是證明自己的功能是合理的。

但是在敏捷開發(fā)中產(chǎn)品經(jīng)理不需要為開發(fā)進(jìn)度負(fù)責(zé)，負(fù)責(zé)開發(fā)進(jìn)度的是項目經(jīng)理或者是小組Leader。還有是要在開發(fā)團(tuán)隊開發(fā)項目的時間內(nèi)去做下一個產(chǎn)品的迭代設(shè)計。

小組Leader或者項目經(jīng)理：需要組織組內(nèi)所有成員參與，如果整個公司實行敏捷開發(fā)，那就是組織各職能的Leader開需求評審會。

這個需求評審的目標(biāo)是可以放到臺面上并且執(zhí)行下去的方案，如果這里還要繼續(xù)討論是否合理，那這個會就很糟。

項目經(jīng)理應(yīng)該負(fù)責(zé)整個項目的調(diào)控，比如人員成本，時間成本，項目是否延期，還是調(diào)整功能。

開發(fā)組員：除了日常開發(fā)，主要是當(dāng)項目完工以后，應(yīng)該交叉去做CodeReview，并且出性能測試報告，以及組織Demo。

測試人員：不是單一的做功能或者是性能測試了，應(yīng)該是做邊界測試和回歸測試。最簡單的功能測試應(yīng)該都是開發(fā)直接完成了，如果有很麻煩的功能測試，才是測試人員來測。敏捷開發(fā)中，應(yīng)該是組員全部承擔(dān)風(fēng)險。

測試人員在敏捷開發(fā)中還是很重要的，要準(zhǔn)確的記錄以及bug的統(tǒng)計。甚至測試人員可以給開發(fā)人員打績效?；貧w測試是要做的，如果可以有很多自動化測試用例就正常用，如果不能就減少回歸測試。