碎碎念研發01：敏捷簡史和幾種軟體開發模型
- 2022 年 5 月 21 日
- 筆記
- [00]產品-管理-業務-工作, 產品, 研發管理, 管理
一、敏捷開發簡史
敏捷簡史 1975-2010：
- 1957年，增量軟體開發方法出現。
- 1975年，Fred Brooks 提出「No Silver Bullet」，出版《人月神話》，相關概念和內容已與敏捷方法極其類似。
- 1986年，竹內弘高和 野中郁次郎在New New Product Development Game文章首次提到將Scrum應用與產品開發。
- 1993年，Jeff Sutherland在Easel公司首次將Scrum方法用於軟體開發。
- 1995年，在OOPSLA『95 會議上，Sutherland和Schwaber共同發表論文介紹Scrum方法。
- 1996年，Martin Fowler,Kent Beck,Ward Cunmingham將XP方法引入C3項目，是第一個被正式的XP項目。
- 1999年 Martin Fowler 著作《Refactoring: Improving the Design of Existing Code》出版，對敏捷開發中的「重構」實踐首次進行系統化闡述。
- 2001年2月，由17位軟體開發專家起草的敏捷宣言發表，敏捷聯盟成立。
- 2001年，Ken Schwaber和Mike Beedle推出第一本Scrum書籍《Scrum敏捷軟體開發》
- 2003年，《Lean Software Development: An Agile Toolkit》出版，精益開發方法被業界廣泛認知，並完善了敏捷方法。
- 2010年，ScrumBan(The first article on Scrumban)方法發表，綜合了Scrum和Kanban
- 2010年，ThoughtWorks Jez Humble出版《Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation》首次正式提出構建流水線(Build Pipeline)的概念，通過從根本上改變開發團隊與運維團隊的協作方式，達到敏捷軟體交付，創造軟體價值。
來自 csdn:敏捷十年簡史回顧，我略有精簡。csdn 這個鏈接地址已經失效。另外有效地址：有效地址。
二、敏捷宣言和12條原則
大家更為熟悉的應該是《敏捷宣言》。
2001年2月，Martin Fowler，Jim Highsmith 等 17 位著名的軟體開發專家齊聚在美國猶他州雪鳥滑雪聖地，舉行了一次敏捷方法發起者和實踐者的聚會。
在這次會議上面，他們正式提出了 Agile(敏捷開發) 這個概念，並共同簽署了《敏捷宣言》。
看敏捷簡史我們可以了解到，雖然敏捷宣言是 2001 年提出，但它其實是對前面幾十年軟體開發實踐探索的一個總結。
2.1 敏捷宣言
我們一直在實踐中探尋更好的軟體開發方法，身體力行的同時也幫助他人。
由此我們建立了如下價值觀：
《敏捷軟體開發宣言》：
個人和交互 高於 流程和工具
軟體產品 高於 綜合文檔
客戶協作 高於 合約協商
應變 高於 遵循計劃
換言之，儘管右邊各項也具有重要價值，但是我們更注重左邊各項。
©敏捷宣言。2001 年。版權所有：Kent Beck、Mike Beedle、Arie van
Bennekum、Alistair Cockburn、Ward Cunningham、Martin Fowler、James
Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、Jon Kern、Brian
Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、Jeff Sutherland 和
Dave Thomas。
來自：//agilemanifesto.org/iso/zhchs/manifesto.html
2.2 敏捷宣言遵循的12條原則
1.我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。
2.欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
3.經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的周期。
4.業務人員和開發人員必須相互合作，項目中的每一天都不例外。
5.激發個體的鬥志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
6.不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
7.可工作的軟體是進度的首要度量標準。
8.敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
9.堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
10.以簡潔為本，它是極力減少不必要工作量的藝術。
11.最好的架構、需求和設計出自自組織團隊。
12.團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。
來自：//agilemanifesto.org/iso/zhchs/principles.html
敏捷宣言和 12 條原則，都是很好的對軟體開發過程有用的價值觀。比如 1，2，4，5，6，10，11 等都是開發好軟體必不可少的原則，都是我們努力的方向。
三、瀑布開發模型
瀑布模型(Waterfall Model) 是 Royce 在 1970 年提出的。它強調軟體開發的一個完整周期。
瀑布模型將軟體生命周期劃分為 6 個階段：
1.制定軟體計劃
2.需求分析
3.軟體設計
4.程式編寫
5.軟體集成與測試
6.軟體發布與維護
並且是自上而下的順序，如同瀑布一樣，開發步驟逐級往下流動。
瀑布模型把軟體開發的各個階段分解的很清楚很明白。
不論後來的什麼開發方法開發模型，都是對這幾個軟體開發階段進行優化。
早期軟體功能不複雜，需求也比較簡單，瀑布模型很實用。
隨著時間發展，軟體功能越來越複雜，軟體協作人數越來越多，瀑布模型也暴露了一些缺點：
1.整個軟體開發到最後階段才能看到軟體運行結果
2.各個軟體開發階段之間較少的回饋
3.有時客戶也不能明確自己的需求，如果需求變了，那這種開發模式導致的返工量就比較大
後來又出現了原型模型、增量模型和迭代模型。
原型模型又叫快速原型模型，它是增量模型的另外一種形式。它是在編碼開發真實系統之前，構建一個產品原型。現在是產品經理要掌握的技能。
在下面一節簡要介紹下增量模型和迭代模型。
四、增量模型和迭代模型
4.1 增量模型
增量模型(Incremental Model)，也叫增量式開發，增量是指在軟體開發過程中，先開發主要功能模組，再開發次要功能模組，逐步完善整個軟體功能。
增量式開發，就是把大型程式分解成若干個小的模組，然後對這些模組進行開發，最後把這些模組集成到一起，成為一個完整的軟體。
現在用程式語言寫軟體基本都是用的這個方法。
有人畫一張圖來形象說明增量開發：
(來自：//blog.csdn.net/chktsang/article/details/87010449)
4.2 迭代模型
迭代模型(Iterative Model)，也叫迭代進化式開發。迭代模型把整個開發工作組織為有固定長度工期的小項目，被稱為一次迭代。經過多次迭代完善整個軟體。
每一次迭代都包括需求分析、設計、軟體實現、集成與測試。這樣開發工作可以在需求被完整確定前啟動，因為有時候客戶也不能明確功能需求。在一次迭代中完成系統的一部分功能，或業務邏輯的開發工作。再通過客戶/用戶的回饋來細化改進需求，進行下一輪的迭代工作。這個與瀑布模型是相反的，瀑布模型是計劃整個項目，然後一次性開發完成。
迭代模型圖：
迭代模型形象圖：
(來自：//blog.csdn.net/chktsang/article/details/87010449)
