軟件工程之美5講——敏捷開發到底是想解決什麼問題?

軟件工程之美5講——敏捷開發到底是想解決什麼問題?

什麼是敏捷開發

也就是說,當你開發做決策的時候,遵守了敏捷開發的價值觀和原則,不管你是不是用 Scrum 或者極限編程,那麼都可以算是敏捷開發。

敏捷開發想解決什麼問題?

瀑布模型的典型問題就是週期長、發佈煩、變更難,敏捷開發就是快速迭代、持續集成、擁抱變化。

敏捷開發和瀑布模型的差異

直到近些年,我完整的在日常項目中反覆實踐敏捷開發,才逐步領會到瀑布模型和敏捷開發的一些差別。這些年敏捷開發,已經逐步發展出一套 “Scrum + 極限編程 + 看板” 的最佳實踐,Scrum 主要用來管理項目過程,極限編程重點在工程實踐,而看板將工作流可視化。我將基於 Scrum 和極限編程的實踐,來對比一下敏捷開發模型和瀑布模型的差異。

  1. 敏捷開發是怎麼做需求分析的?

瀑布模型的一個重要階段就是需求分析,要有嚴謹的需求分析,產生詳盡的需求分析文檔。而敏捷開發的需求,主要是來源於一個個小的用戶故事,用戶故事通常是寫在卡片上的一句話,在 Sprint 的開發中,再去確認需求的細節。比如一個用戶登錄網站的需求,在用戶故事裏面就是一句話:作爲用戶,我想登錄網站,這樣可以方便瀏覽。好處是減少了大量需求文檔的撰寫,可以早些進入開發。但這個對開發人員在需求理解和溝通的能力上要求更高了。
3. 敏捷開發是怎麼做架構設計的?

瀑布模型在需求分析完了以後,就需要根據需求做架構設計。而在敏捷開發中,並不是基於完整的用戶需求開發,每個 Sprint 只做一部分需求,所以是一種漸進式的架構設計,當前 Sprint 只做適合當前需求的架構設計。這種漸進式的架構設計,迭代次數一多,就會出現架構滿足不了需求的現象,產生不少冗餘代碼,通常我們叫它技術債務,需要定期對系統架構進行重構。
5. 敏捷開發怎麼保證項目質量?

瀑布模型在編碼完成後,會有專門的階段進行測試,以保證質量。在敏捷開發的 Sprint 中,並沒有專門的測試階段,這就依賴於開發功能的同時,要編寫單元測試和集成測試代碼,用自動化的方式輔助完成測試。相對來說,這種以自動化測試爲主的方式,質量確實是要有些影響的。微軟的 Windows 就是個很好的例子,在 Windows 10 之前,Windows 的開發模式是傳統的類瀑布模型,有很長一段測試的時間,質量有很好的保障,Windows 10 開始,採用的是敏捷開發的模式,每月發佈更新,穩定性要稍微差一些。
4. 敏捷開發是怎麼發佈部署的?

瀑布模型通常在編碼結束後,開始部署測試環境,然後在測試階段定期部署測試環境。測試驗收通過後,發佈部署到生產環境。在敏捷開發中,這種持續構建、持續發佈的概念叫持續集成,因爲整個過程都是全自動化的,每次完成一個任務,提交代碼後都可以觸發一次構建部署操作,腳本會拿最新的代碼做一次全新的構建,然後運行所有的單元測試和集成測試代碼,測試通過後部署到測試環境。持續集成是一個非常好的實踐,極大的縮短和簡化了部署的流程,而且自動化測試的加入也很好的保證了部署產品的質量。前期搭建整個持續集成環境需要一定技術要求。

該不該選擇敏捷開發?

可以肯定,敏捷開發是一種非常好的軟件開發模式。但在應用上,也確實需要滿足一些條件才能用好,例如:
團隊要小,人數超過一定規模就要分拆;
團隊成員之間要緊密協作,客戶也要自始至終深度配合;
領導們的支持。
敏捷需要扁平化的組織結構,更少的控制,更多的發揮項目組成員的主動性;寫代碼時要有一定比例的自動化測試代碼,要花時間搭建好源碼管理和持續集成環境。所以在選擇敏捷開發這個問題上,你先要參考上面這些條件。因爲敏捷開發對項目成員綜合素質要求更高,做計劃要相對難一些。如果團隊大、客戶不配合、領導不支持,再好的敏捷方法也很難有效實踐起來。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章