建站
咨詢
售后
建站咨詢
新聞中心
合理的項(xiàng)目迭代流程是軟件高質(zhì)量可持續(xù)生產(chǎn)的保障，只有擁有一套完整合理的項(xiàng)目迭代流程才能確保即使是不同團(tuán)隊(duì)開發(fā)不同項(xiàng)目，也能最大限度的保障項(xiàng)目開發(fā)質(zhì)量。
匯總流程圖如下，后面是各階段的詳細(xì)介紹：
創(chuàng)新互聯(lián)專注于企業(yè)營銷型網(wǎng)站建設(shè)、網(wǎng)站重做改版、孟連網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5場景定制、商城系統(tǒng)網(wǎng)站開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為孟連等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
圖片
1.需求評審階段：
需求評審是從理論上對項(xiàng)目可行性進(jìn)行評審，著重于需求的合理性、價值點(diǎn)、投入產(chǎn)出比分析，同時確保PD和開發(fā)方對于項(xiàng)目的相關(guān)信息認(rèn)知一致，以免產(chǎn)生不必要的資源損耗。
項(xiàng)目需求一般由產(chǎn)品經(jīng)理進(jìn)行提出，以PRD(需求文檔)的形式進(jìn)行呈現(xiàn)，需求文檔以清晰完整的描述整個項(xiàng)目需求為準(zhǔn)，具有一定的規(guī)范，通常應(yīng)包括需求背景、需求目標(biāo)、原型圖、動線圖、需求概括、功能點(diǎn)、數(shù)據(jù)分析等內(nèi)容。
為提高需求評審質(zhì)量以及效率，評審會議建議按照以下流程進(jìn)行：
- 在評審會議開始前1天將相關(guān)會議文檔發(fā)送到各參會者，進(jìn)行提前閱讀留評
- 會議開始時首先快速的過一遍整體會議內(nèi)容，然后再針對留評內(nèi)容進(jìn)行重點(diǎn)討論
- 在評審過程中參會人提出的針對需求內(nèi)容無法在評審時解決的問題，或者待確認(rèn)的點(diǎn)需要記錄會議Action，會議Action一般情況下又可分為非阻塞型Action以及阻塞型Action，非阻塞型Action一般為參會人對于需求的建議、或者疑問，產(chǎn)品可選擇性聽取，阻塞型Action為參會人針對需求提出的產(chǎn)品在會后必須要確認(rèn)解決的問題，評審會議的通過最終以所有阻塞型Action都已解決為準(zhǔn)。
區(qū)分阻塞型Action以及非阻塞型Action的原因如下：
根據(jù)以往需求評審的會議經(jīng)驗(yàn)，在會議時參會者往往會提出很多關(guān)于需求方面的建議、疑問，產(chǎn)品往往在會后會優(yōu)先確認(rèn)解決那些自己認(rèn)為比較重要的問題，這樣就在參會者以及產(chǎn)品經(jīng)理之間出現(xiàn)了信息差，導(dǎo)致會后對于需求而言重要的問題沒有解決就進(jìn)入開發(fā)階段或者是將大量的精力用在不重要的問題上造成資源浪費(fèi)。
1.1需求初評：
產(chǎn)品經(jīng)理產(chǎn)出需求文檔后，產(chǎn)品團(tuán)隊(duì)內(nèi)部成員對需求進(jìn)行的評審稱之為需求初評，需求初評可以很大程度上提前識別那些價值不夠高的需求，以免進(jìn)入后續(xù)的流程，提高迭代效率，主要著重于評審需求的價值點(diǎn)以及合理性，評審會議應(yīng)按照規(guī)定根據(jù)上面的評審會議流程進(jìn)行，當(dāng)所有阻塞型Action解決后方可進(jìn)入下一流程。
1.2正式評審：
正式評審是產(chǎn)品、交互、開發(fā)、測試核心針對需求實(shí)現(xiàn)難度以及性價比進(jìn)行的評審，當(dāng)然開發(fā)人員根據(jù)以往上線功能的數(shù)據(jù)，認(rèn)為本次需求價值、合理性存在問題的地方也可以提出建議或疑問作為阻塞型Action，阻塞需求評審不予通過。
這里說一點(diǎn)自己的看法，現(xiàn)在軟件開發(fā)推崇的敏捷迭代一個開發(fā)周期只有2-3周的時間，特點(diǎn)是迭代周期短需求數(shù)量多，很多沒有進(jìn)行長期規(guī)劃的項(xiàng)目上線后往往會造成效果不理想或者破壞整個產(chǎn)品完整性的情況，所以一定要投入更多的精力在需求評審中，對于開發(fā)人員而言切記并不是所有評審的需求都需要投入開發(fā)，要結(jié)合實(shí)際情況進(jìn)行判斷。
1.3交互評審：
針對交互稿進(jìn)行評審，評審時核心關(guān)注交互實(shí)現(xiàn)的難易度、完整性、性價比，To B需求應(yīng)優(yōu)先以現(xiàn)有的組件庫進(jìn)行交互設(shè)計(jì)，提高開發(fā)效率。
2.項(xiàng)目開發(fā)階段：
項(xiàng)目評審階段結(jié)束時應(yīng)確保以下兩件事都已完成：
- 項(xiàng)目需求文檔、交互文檔關(guān)于項(xiàng)目所需開發(fā)功能點(diǎn)描述都已清晰完整，邊界情況都有涉及
- 項(xiàng)目所有待開發(fā)功能點(diǎn)相關(guān)信息等產(chǎn)品和開發(fā)都已達(dá)成一致
- 與開發(fā)內(nèi)容所依賴的二方業(yè)務(wù)資源都已就位，不會在開發(fā)過程中因其他資源問題導(dǎo)致項(xiàng)目延期等問題
2.1確定排期
在項(xiàng)目需求都已清晰完整后接下來就進(jìn)入了排期階段，各端開發(fā)需要根據(jù)需求文檔進(jìn)行人日預(yù)估，確定設(shè)計(jì)時間、開發(fā)時間、聯(lián)調(diào)時間、bugfix時間、提測時間，之后項(xiàng)目PM再根據(jù)各端預(yù)估人日和資源排期情況，確定項(xiàng)目用例評審時間點(diǎn)、冒煙時間點(diǎn)、驗(yàn)收時間點(diǎn)、發(fā)布時間點(diǎn)、放量節(jié)奏等來完成項(xiàng)目最終的Roadmap，接下來就是各端開發(fā)根據(jù)項(xiàng)目Roadmap進(jìn)行開發(fā)了。
2.2設(shè)計(jì)評審
對于耗費(fèi)人日較多的項(xiàng)目一定要遵循設(shè)計(jì)先行原則，先有完整的設(shè)計(jì)文檔然后再投入開發(fā)寫代碼。根據(jù)以往的經(jīng)驗(yàn)開發(fā)前先完成方案設(shè)計(jì)可以很大程度上避免開發(fā)過程中的返工、線上故障、代碼質(zhì)量不高的問題，提高開發(fā)效率，減少資源浪費(fèi)，尤其對新同學(xué)很有幫助，同時項(xiàng)目設(shè)計(jì)文檔也可作為公司資源的一部分沉淀下來，為后續(xù)開發(fā)人員接手項(xiàng)目提供幫助。
設(shè)計(jì)評審一般由服務(wù)端進(jìn)行發(fā)起評審人員包括各端開發(fā)，核心確認(rèn)項(xiàng)目實(shí)現(xiàn)方案完整合理，以及將各端需要對接的資源進(jìn)行同步，這其中比較重要的就是項(xiàng)目接口評審，好的接口設(shè)計(jì)應(yīng)遵循一定的規(guī)范，比如大小寫命名方式、是否具有語義化。
補(bǔ)充一點(diǎn)就是對于各端開發(fā)來說，如果遇見耗時較久或者開發(fā)較復(fù)雜的項(xiàng)目建議也最好先提前做好要開發(fā)內(nèi)容的設(shè)計(jì)，這樣對最終的代碼可維護(hù)性很有幫助。
2.3用例評審
在正式投入開發(fā)的2-3天后，測試應(yīng)根據(jù)本次迭代所要開發(fā)內(nèi)容完成用例文檔并向開發(fā)提供，最終項(xiàng)目開發(fā)完成所有交付功能以滿足用例文檔所有用例為準(zhǔn)。
3.項(xiàng)目測試階段：
3.1冒煙預(yù)演
在項(xiàng)目所有功能開發(fā)完成后，開發(fā)應(yīng)根據(jù)用例文檔對項(xiàng)目所有功能進(jìn)行預(yù)演，當(dāng)所有用例通過后交付給測試進(jìn)行其他內(nèi)容回歸、邊界測試等內(nèi)容，此時便進(jìn)入提測階段。
3.2項(xiàng)目驗(yàn)收
當(dāng)項(xiàng)目測試完成后便來到了最終的上線驗(yàn)收階段，該過程是最后一次對項(xiàng)目所有功能點(diǎn)進(jìn)行check，除此之外還需要確認(rèn)清楚各相關(guān)應(yīng)用的發(fā)布順序、發(fā)布流程、回滾方案、灰度節(jié)奏，發(fā)布順序的確認(rèn)可以有效避免因應(yīng)用發(fā)布順序有誤導(dǎo)致項(xiàng)目出現(xiàn)故障。
4.項(xiàng)目上線階段：
4.1數(shù)據(jù)觀察
在項(xiàng)目上線后開發(fā)人員應(yīng)及時根據(jù)項(xiàng)目當(dāng)中的相關(guān)數(shù)據(jù)埋點(diǎn)對項(xiàng)目功能的使用情況進(jìn)行統(tǒng)計(jì)分析，該數(shù)據(jù)將對后續(xù)該產(chǎn)品迭代的相關(guān)決策提供幫助。
4.2項(xiàng)目迭代Reivew
以月為周期，在月底的時候我們一般會針對這一個月內(nèi)的相關(guān)項(xiàng)目開發(fā)情況進(jìn)行項(xiàng)目迭代Reivew會議，希望通過Review會議找出在這一個月的項(xiàng)目開發(fā)過程中，項(xiàng)目開發(fā)流程本身是否存在改進(jìn)的地方，項(xiàng)目迭代流程是否存在執(zhí)行不到位的情況，從而對項(xiàng)目迭代流程不斷地進(jìn)行優(yōu)化，提高產(chǎn)研效率，同時對在開發(fā)中做的比較好的點(diǎn)進(jìn)行倡導(dǎo)鼓勵。
最后
剛開始工作時個人也對項(xiàng)目迭代流程產(chǎn)生過困惑，為什么一定要有這么復(fù)雜的流程，是不是有些過于形式主義了？但后來理解從大的方向上講公司任何流程相關(guān)的東西本質(zhì)上都是為了生產(chǎn)可以規(guī)范標(biāo)準(zhǔn)化的進(jìn)行，核心是可持續(xù)生產(chǎn)價值，從實(shí)際出發(fā)在經(jīng)歷一年多的項(xiàng)目開發(fā)后也深刻的明白了上面所講的每一步都是為了保障項(xiàng)目迭代開發(fā)可以安全、高效的進(jìn)行，每一步都具有存在的意義：比如設(shè)計(jì)評審就是因?yàn)樵谖覀兊拇a中經(jīng)常出現(xiàn)因沒有提前的設(shè)計(jì)導(dǎo)致代碼的維護(hù)性、健壯性出現(xiàn)問題，從而導(dǎo)致更多的bug，嚴(yán)格進(jìn)行用例評審的原因是往往會出現(xiàn)在進(jìn)行提測時開發(fā)所開發(fā)的功能與最終PD所設(shè)想的內(nèi)容不符，后來就增加了這一環(huán)節(jié)，比如我們也曾因發(fā)布順序未進(jìn)行約定好而導(dǎo)致線上故障，后來就在項(xiàng)目驗(yàn)收時增加了這一流程。
名稱欄目：聊聊軟件迭代管理的一般流程
本文路徑：http://www.5511xx.com/article/djidcdo.html
