.NET 云原生架構(gòu)師訓(xùn)練營(yíng)（模塊二 基礎(chǔ)鞏固 敏捷開(kāi)發(fā)）--學(xué)習(xí)筆記
2.7.1 敏捷開(kāi)發(fā)
敏捷介紹
敏捷的起源
敏捷軟件開(kāi)發(fā)宣言
敏捷開(kāi)發(fā)十二原則
生命周期對(duì)比
敏捷開(kāi)發(fā)的特點(diǎn)
敏捷的發(fā)展
敏捷的核心
敏捷的起源
2001年，17個(gè)老頭子在一起一邊滑雪，一邊討論工作，制定了《敏捷軟件開(kāi)發(fā)宣言》
從60年代中期開(kāi)始到20世紀(jì)末，軟件行業(yè)得到了非常迅猛的發(fā)展，軟件系統(tǒng)的規(guī)模和復(fù)雜度也越來(lái)越高，行業(yè)普遍面臨不滿(mǎn)足需求，永遠(yuǎn)無(wú)法交付等一系列嚴(yán)重的問(wèn)題，史稱(chēng)“軟件危機(jī)”
從長(zhǎng)期積累的經(jīng)驗(yàn)看，早期階段的時(shí)間投入會(huì)影響到后期的經(jīng)濟(jì)支出，就是需求變化發(fā)生的越晚，對(duì)軟件交付的影響越大，這是瀑布模式存在產(chǎn)生的核心觀(guān)點(diǎn)，所以瀑布模式主張非常完整的設(shè)計(jì)，拒絕需求變化
拒絕變化帶來(lái)雙向的負(fù)面效應(yīng)，軟件需求方得不到自己滿(mǎn)意的產(chǎn)品，另一方面，由于過(guò)度強(qiáng)調(diào)計(jì)劃，忽視領(lǐng)導(dǎo)者和管理者在團(tuán)隊(duì)中起的作用
針對(duì)以上兩個(gè)負(fù)面效應(yīng)，敏捷軟件開(kāi)發(fā)宣言中“擁抱變化”和“尊重個(gè)體”成為兩個(gè)核心的觀(guān)點(diǎn)
敏捷軟件開(kāi)發(fā)宣言
敏捷軟件開(kāi)發(fā)宣言：https://www.scrumcn.com/agile/scrum-knowledge-library/agilevalues.html
個(gè)體和互動(dòng) 高于 流程和工具
工作的軟件 高于 詳盡的文檔
客戶(hù)合作 高于 合同談判
響應(yīng)變化 高于 遵循計(jì)劃
敏捷開(kāi)發(fā)十二原則
我們最重要的目標(biāo)，是通過(guò)及早和持續(xù)不斷地交付有價(jià)值的軟件使客戶(hù)滿(mǎn)意。
欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣。為了客戶(hù)的競(jìng)爭(zhēng)優(yōu)勢(shì)，敏捷過(guò)程掌控變化。
經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期。
業(yè)務(wù)人員和開(kāi)發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外。
激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)。
不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面的交談。
可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。
敏捷過(guò)程倡導(dǎo)可持續(xù)開(kāi)發(fā)。責(zé)任人、開(kāi)發(fā)人員和用戶(hù)要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。
堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)。
以簡(jiǎn)潔為本，它是極力減少不必要工作量的藝術(shù)。
最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)。
團(tuán)隊(duì)定期地反思如何能提高成效，并依此調(diào)整自身的行為表現(xiàn)。
生命周期對(duì)比
| 生命周期 | 需求 | 活動(dòng) | 交付 | 流程 |
|---|---|---|---|---|
| 瀑布 | 固定的，需求明確 | 整個(gè)項(xiàng)目進(jìn)行一次 | 一次交付 | 強(qiáng)調(diào)文檔，用里程碑的方式，嚴(yán)格定義各階段的輸入和輸出。不走回頭路，如果出現(xiàn)返工，付出的代價(jià)巨大 |
| 敏捷 | 動(dòng)態(tài)的，貼近客戶(hù)需求 | 重復(fù)，直到正確為止 | 頻繁小的交付 | 核心是小版本迭代。短、頻、快的溝通與反饋機(jī)制，減少客戶(hù)價(jià)值創(chuàng)造過(guò)程中的損耗 |
敏捷開(kāi)發(fā)的特點(diǎn)
小步快跑
有項(xiàng)目計(jì)劃，但也要“擁抱變化”
版本迭代周期內(nèi)盡量不加任務(wù)
團(tuán)隊(duì)配置也要敏捷
敏捷也需要反思
敏捷的發(fā)展
敏捷發(fā)展的3個(gè)階段：
在軟件行業(yè)被定義
在商業(yè)活動(dòng)中發(fā)揚(yáng)光大
軟件商業(yè)活動(dòng)匯合
后面兩個(gè)階段的開(kāi)啟受到了以下兩個(gè)概念的啟發(fā)：
精益創(chuàng)業(yè)
持續(xù)交付2.0
精益創(chuàng)業(yè)
2021年美國(guó)作家埃里克·萊斯出版了《精益創(chuàng)業(yè)》一書(shū)中的精簡(jiǎn)式反饋，以小見(jiàn)大等概念與敏捷軟件開(kāi)發(fā)迭代模型有很多相似之處
在 SCRUM 中要求每個(gè)迭代都能交付給有用價(jià)值的功能（可以工作的軟件）
埃里克在束中提到的最小可行性產(chǎn)品 MVP 強(qiáng)調(diào)用最快，最簡(jiǎn)明的方式建立一個(gè)可用的產(chǎn)品原型，通過(guò)這個(gè)最簡(jiǎn)單的產(chǎn)品原型來(lái)測(cè)試產(chǎn)品是否符合市場(chǎng)預(yù)期，并通過(guò)不斷的快速迭代來(lái)修正產(chǎn)品，最終適應(yīng)市場(chǎng)需求
定義 MVP 的關(guān)鍵在于，需要抓住用戶(hù)的核心完整需求，在之后的迭代中不斷地將核心完整需求變的好用。要求是那些必不可少的且最后是完整可用的
軟件開(kāi)發(fā)終究是為商業(yè)活動(dòng)服務(wù)的，只有在商業(yè)活動(dòng)也是敏捷的情況下，敏捷軟件開(kāi)發(fā)才能發(fā)揮最大的威力?？上У氖蔷鎰?chuàng)業(yè)的思想產(chǎn)生比軟件敏捷開(kāi)發(fā)思維晚了整整11年
持續(xù)交付2.0
國(guó)內(nèi) DevOps 專(zhuān)家喬梁在2019年出版了《持續(xù)交付2.0：業(yè)務(wù)引領(lǐng)的DevOps精要》中提出雙環(huán)模型強(qiáng)調(diào)“只有業(yè)務(wù)方能夠以“精益”方式思考，持續(xù)交付才能更顯威力”，由此軟件開(kāi)發(fā)活動(dòng)與商業(yè)活動(dòng)有了完整統(tǒng)一的方法論模型
提問(wèn)：用戶(hù)需要什么
錨定：背后的真正需求
共創(chuàng)：業(yè)務(wù)，銷(xiāo)售，開(kāi)發(fā)人員一起思考解決方案
精煉，決策
構(gòu)建
運(yùn)行
監(jiān)測(cè)：埋點(diǎn)
監(jiān)測(cè)環(huán)節(jié)為精益創(chuàng)業(yè)中產(chǎn)品的驗(yàn)證提供數(shù)據(jù)支持，通過(guò)數(shù)據(jù)來(lái)反饋產(chǎn)品是否符合用戶(hù)預(yù)期
敏捷的核心
變化來(lái)自于哪里？
從2001年的敏捷宣言核心觀(guān)點(diǎn)來(lái)看“擁抱變化”，多數(shù)的變化可以認(rèn)為是需求
需求的變化有兩種：
一種是需求沒(méi)有變，是沒(méi)有理解透（很多復(fù)雜的細(xì)分行業(yè)B端產(chǎn)品）
另外一種是提出需求的人自己沒(méi)有想清楚（很多創(chuàng)新型產(chǎn)品，互聯(lián)網(wǎng)行業(yè)居多）
課程鏈接
.NET云原生架構(gòu)師訓(xùn)練營(yíng)講什么，怎么講，講多久