軟件項(xiàng)目的生命周期管理, 從上個世紀(jì)八九十年代時以瀑布為主流,
到01 年時敏捷宣言的提出后, 敏捷軟件開發(fā)變得如火如荼.
也許很多人認(rèn)為, 瀑布已經(jīng)過時, 應(yīng)該被淘汰出局, 我們應(yīng)該全面的擁抱敏捷. 但現(xiàn)實(shí)中, 依然有很多公司采用的是瀑布或者部分敏捷的模式. 正如軟件行業(yè)的警示名言沒有銀彈, 我們應(yīng)該在合適的場景下, 選擇適合當(dāng)前項(xiàng)目的方法.
作為系列的開篇, 簡要介紹一下三種生命周期模型.
1. 瀑布模型(Waterfall)
- 一系列的開發(fā)階段.
-
需求(Requirement), 設(shè)計(jì)(Design), 開發(fā)(Development), 測試(Testing), 維護(hù)(Maintenance).
Paste_Image.png
-
- 每個階段都有清晰定義的交付(deliverables).
- 例如, 軟件需求規(guī)格書, 基本設(shè)計(jì), 詳細(xì)設(shè)計(jì), 代碼等等.
2. 迭代模型(Iterative,Incremental)
?迭代模式
- 遞增式地構(gòu)建系統(tǒng), 從基本功能開始, 逐漸地添加新功能, 直至整個系統(tǒng)完成.
- 面對新需求和需求變更, 能夠獲得更大的靈活性.
- 之前迭代中獲取的經(jīng)驗(yàn), 可以在下個迭代中?應(yīng)用.
3. 敏捷(Agile)
敏捷
- 將交付周期從月減到周. 每個階段都有交付.
- 敏捷的主要關(guān)注點(diǎn):
- 保持代碼簡單.
- 頻繁測試.
- 盡快地交付軟件的功能單元.
4. 個人認(rèn)為的敏捷產(chǎn)生的意義
- 使用瀑布模型時, 我們的終端用戶, 只有在最終階段完成之后, 才能看到產(chǎn)品.
- 這可能已經(jīng)是開發(fā)了幾年的產(chǎn)品.
- 客戶在項(xiàng)目開始時的需求, 可能在此時已經(jīng)發(fā)生了變化.
- 作為一個人來說,
他想象中他想要的, 跟他實(shí)際想要的, 很可能完全不是一回事. - 當(dāng)客戶看到了成品后, ?最經(jīng)常說的話可能就是,
啊, 我并不想要這個啊.
- 作為一個人來說,
- 一個規(guī)模較大的軟件, 應(yīng)對需求變更的靈活性是較差的.
- 此時對任何需求變更的對應(yīng), 都需要很多的工時.
- 敏捷最重要的意義, 是縮短了反饋周期.
- 敏捷要求我們頻繁的交付可見的功能給用戶.
-
面對真實(shí)的產(chǎn)品, 用戶能夠盡早的驗(yàn)證和矯正自己想象中的需求.- 而此時, 軟件對應(yīng)需求變更的靈活性是很強(qiáng)的.
5. 選擇
- 需求的穩(wěn)定性.
- 如果軟件的需求是有清晰定義的, 比如會計(jì)軟件, 需求是有法律明確規(guī)定的. 是可以選擇瀑布模型的.
- 如果是互聯(lián)網(wǎng)產(chǎn)品, 可能自己對項(xiàng)目的最終形態(tài)都不太清晰, 需要不停地得到用戶的反饋, 然后矯正自己的方向. 這就是敏捷最適合的場景了.
- 終端用戶是集中的還是分散的.
- 針對集中的用戶, 是比較容易采集和匯總他們的需求的. 所以瀑布模型也是可以展開的.
- time-line是?保守的還是激進(jìn)的.
- 保守的time-line, 由于有清晰定義的邊界, 瀑布模型還是可以展開的.
- 項(xiàng)目的規(guī)模
- 大規(guī)模的項(xiàng)目需要多個team 協(xié)同工作, 所以需要清晰定義的交付. 此時還是推薦使用瀑布的.
- 項(xiàng)目組的物理分布
- 敏捷需要頻繁的密切交流. 至少也要有通信工具保證大家能夠?qū)崟r的交流.
- 瀑布提供了清晰的交付和里程碑.
- ?關(guān)鍵資源.
- 有些項(xiàng)目需要一些特殊的資源, 例如有金融專業(yè)知識的測試人員.
- 而這些資源通常是不能在被需要的時候就能立馬得到的.
- 瀑布模型能夠更好的對應(yīng)這種情況.
- 在進(jìn)入下一個階段時, 每一個里程碑都已經(jīng)被滿足.
