.NET 雲原生架構師訓練營(模組二 基礎鞏固 敏捷開發)–學習筆記
- 2021 年 1 月 15 日
- 筆記
- 【002】.NET Core, 【008】.NET 雲原生架構師訓練營
2.7.1 敏捷開發
敏捷介紹
- 敏捷的起源
- 敏捷軟體開發宣言
- 敏捷開發十二原則
- 生命周期對比
- 敏捷開發的特點
- 敏捷的發展
- 敏捷的核心
敏捷的起源
2001年,17個老頭子在一起一邊滑雪,一邊討論工作,制定了《敏捷軟體開發宣言》
從60年代中期開始到20世紀末,軟體行業得到了非常迅猛的發展,軟體系統的規模和複雜度也越來越高,行業普遍面臨不滿足需求,永遠無法交付等一系列嚴重的問題,史稱「軟體危機」
從長期積累的經驗看,早期階段的時間投入會影響到後期的經濟支出,就是需求變化發生的越晚,對軟體交付的影響越大,這是瀑布模式存在產生的核心觀點,所以瀑布模式主張非常完整的設計,拒絕需求變化
拒絕變化帶來雙向的負面效應,軟體需求方得不到自己滿意的產品,另一方面,由於過度強調計劃,忽視領導者和管理者在團隊中起的作用
針對以上兩個負面效應,敏捷軟體開發宣言中「擁抱變化」和「尊重個體」成為兩個核心的觀點
敏捷軟體開發宣言
敏捷軟體開發宣言://www.scrumcn.com/agile/scrum-knowledge-library/agilevalues.html
- 個體和互動 高於 流程和工具
- 工作的軟體 高於 詳盡的文檔
- 客戶合作 高於 合約談判
- 響應變化 高於 遵循計劃
敏捷開發十二原則
- 我們最重要的目標,是通過及早和持續不斷地交付有價值的軟體使客戶滿意。
- 欣然面對需求變化,即使在開發後期也一樣。為了客戶的競爭優勢,敏捷過程掌控變化。
- 經常地交付可工作的軟體,相隔幾星期或一兩個月,傾向於採取較短的周期。
- 業務人員和開發人員必須相互合作,項目中的每一天都不例外。
- 激發個體的鬥志,以他們為核心搭建項目。提供所需的環境和支援,輔以信任,從而達成目標。
- 不論團隊內外,傳遞資訊效果最好效率也最高的方式是面對面的交談。
- 可工作的軟體是進度的首要度量標準。
- 敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
- 堅持不懈地追求技術卓越和良好設計,敏捷能力由此增強。
- 以簡潔為本,它是極力減少不必要工作量的藝術。
- 最好的架構、需求和設計出自自組織團隊。
- 團隊定期地反思如何能提高成效,並依此調整自身的行為表現。
生命周期對比
生命周期 | 需求 | 活動 | 交付 | 流程 |
---|---|---|---|---|
瀑布 | 固定的,需求明確 | 整個項目進行一次 | 一次交付 | 強調文檔,用里程碑的方式,嚴格定義各階段的輸入和輸出。不走回頭路,如果出現返工,付出的代價巨大 |
敏捷 | 動態的,貼近客戶需求 | 重複,直到正確為止 | 頻繁小的交付 | 核心是小版本迭代。短、頻、快的溝通與回饋機制,減少客戶價值創造過程中的損耗 |
敏捷開發的特點
- 小步快跑
- 有項目計劃,但也要「擁抱變化」
- 版本迭代周期內盡量不加任務
- 團隊配置也要敏捷
- 敏捷也需要反思
敏捷的發展
敏捷發展的3個階段:
- 在軟體行業被定義
- 在商業活動中發揚光大
- 軟體商業活動匯合
後面兩個階段的開啟受到了以下兩個概念的啟發:
- 精益創業
- 持續交付2.0
精益創業
2021年美國作家埃里克·萊斯出版了《精益創業》一書中的精簡式回饋,以小見大等概念與敏捷軟體開發迭代模型有很多相似之處
在 SCRUM 中要求每個迭代都能交付給有用價值的功能(可以工作的軟體)
埃里克在束中提到的最小可行性產品 MVP 強調用最快,最簡明的方式建立一個可用的產品原型,通過這個最簡單的產品原型來測試產品是否符合市場預期,並通過不斷的快速迭代來修正產品,最終適應市場需求
定義 MVP 的關鍵在於,需要抓住用戶的核心完整需求,在之後的迭代中不斷地將核心完整需求變的好用。要求是那些必不可少的且最後是完整可用的
軟體開發終究是為商業活動服務的,只有在商業活動也是敏捷的情況下,敏捷軟體開發才能發揮最大的威力。可惜的是精益創業的思想產生比軟體敏捷開發思維晚了整整11年
持續交付2.0
中國 DevOps 專家喬梁在2019年出版了《持續交付2.0:業務引領的DevOps精要》中提出雙環模型強調「只有業務方能夠以「精益」方式思考,持續交付才能更顯威力」,由此軟體開發活動與商業活動有了完整統一的方法論模型
- 提問:用戶需要什麼
- 錨定:背後的真正需求
- 共創:業務,銷售,開發人員一起思考解決方案
- 精鍊,決策
- 構建
- 運行
- 監測:埋點
監測環節為精益創業中產品的驗證提供數據支援,通過數據來回饋產品是否符合用戶預期
敏捷的核心
變化來自於哪裡?
從2001年的敏捷宣言核心觀點來看「擁抱變化」,多數的變化可以認為是需求
需求的變化有兩種:
- 一種是需求沒有變,是沒有理解透(很多複雜的細分行業B端產品)
- 另外一種是提出需求的人自己沒有想清楚(很多創新型產品,互聯網行業居多)
本作品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。
歡迎轉載、使用、重新發布,但務必保留文章署名 鄭子銘 (包含鏈接: //www.cnblogs.com/MingsonZheng/ ),不得用於商業目的,基於本文修改後的作品務必以相同的許可發布。
如有任何疑問,請與我聯繫 ([email protected]) 。