敏捷過程簡介
2023年，kent beck等17位程式設計大師共同發布了《敏捷軟體開發宣言》，強調：
「人」以及「人與人的互動」勝於 「過程」和「工具」。這是一種全新的軟體過程思維。最初的軟體 (1960-70 年代) 的顧客都是大型研究機構、軍方等，他們需要軟體系統來搞科學計算、軍方專案、登月專案等，這些系統相當龐大，對準確度要求相當高。到了1980-90年代，軟體進入了桌面軟體的時代，開發的週期明顯縮短，各種新的方法開始進入實用階段。但是軟體發布的媒介還是cd、***，做好乙個發布需要較大的經濟投入，不能頻繁更新版本。而進入了網際網路時代以來，大部分的服務是通過網路伺服器端實現，在客戶端有各種方便的推送渠道。同時技術更新的速度在加快, 那種乙個大型團隊用乙個固定技術開發2-3 年再發布的時代已經過去了，由於網路的轉播速度和廣度，知識的獲取更加容易，很多軟體服務可以由乙個小團隊來實現。此外使用者需求的變化也在加快，開發流程必須跟上這些快速變化的節奏。這也正是敏捷過程誕生的原因，可以說這其中有一定的時代必然性。可執行的軟體勝於 面面俱到的文件
客戶合作勝於 合同談判
響應變化勝於 遵循計畫
以快速的增量和迭代方式進行軟體開發是敏捷過程的本質，我們也能歸納出一些敏捷過程模型的主要思想：
不強調文件，轉向強調可執行的軟體片段開發者與客戶之間頻繁溝通快速開發，快速反饋，快速修改，增量交付連續不斷的短週期迭代不看重形式和工具，看重「人」和內容，保持簡潔相比於傳統方法，敏捷方法在過程的具體形式上也體現了重大的革新，xp（極限程式設計）和scrum框架是其中的典型代表。極限程式設計強調使用者故事(user story)、測試驅動的開發(tdd)、結對程式設計(pair programming)、持續整合(continuous integration)等核心實踐方法。如果你還不是很明白，下面這張圖便能夠清晰的展示極限程式設計到底「極限」在何處？
而在scrum框架中，驗收測試(acceptance testing)、衝刺/迭代(sprint / iteration)、產品清單/衝刺清單(product backlog / spring backlog)、燃盡圖(burndown chart)、每日站會(dailystand-up)等也是非常高效的核心實踐方式。
敏捷過程思想帶來的啟示
模擬一下程式語言的發展歷史，從最開始面向機器語言誕生，到面向過程的語言，再到物件導向的語言，相同的，敏捷過程模型的出現標誌著一種思維的轉變，即由傳統軟體開發中由計畫、過程主導的模式向現代軟體開發中由目標、客戶主導的模式的轉變。敏捷過程模型是隨著現代複雜的開發環境產生的，也同時提醒著所有軟體開發者——「面向客戶，擁抱改變」，因為開發軟體的最終目的是滿足客戶的需求，為了能夠讓最終的軟體能夠發揮其最大的作用，就必須做到這一點。
這裡有乙個典型的案例：某軟體開發公司有個專案組作的是乙個網遊物品交易平台。 該平台是典型的網際網路專案，在開工的時候客戶對功能需求還不明確，在開發過程中需求也可能會隨時發生變動，但需要快速推出搶占市場，時間非常緊迫。
這個時候，應用傳統的軟體開發過程模型都不免會出現兩個問題：能夠迅速開發出軟體，但面對需求的改變無法迅速調整（如傳統的rad模型）；或是能滿足需求的變化，但開發周期太長（如螺旋模型）。但是，這卻正是最適合敏捷過程的專案。設想一下在專案伊始，商務分析師和客戶做了深入的談話，了解他的商業構想，他的盈利模式，搞清楚巨集觀的結構，然後思考並整理獲得的結果，花1-2天時間將客戶需求大略整理為幾十個使用者故事。這些使用者故事並不完善，不足以做好整個系統。但對於我們開始專案的前一陣，已經足夠了。正是敏捷過程中增量交付、不斷迭代的實踐方式和面向客戶、擁抱變化的開發方式，使得開發團隊能夠迅速做出滿足前期客戶需求的的產品占領市場，獲得先機。
如何有效地進行敏捷過程的實踐
事實上，在敏捷過程模型提出之後，仍然受到了許多人的反對，而由於其面向客戶、隨時變化、不斷迭代的特點，敏捷過程無法保證軟體的質量百分之百萬無一失，確實無法應對世界上所有型別的開發專案，這是毋庸置疑的。因此，我覺得有效進行敏捷過程實踐的最重要的一點是能夠準確識別開發的專案是否適用於敏捷過程模型，試想一下如果用敏捷方式去開發軍方、航空航天相關的專案，是要出大事情的！
而在敏捷開發的過程中，保持業務人員、開發人員以及客戶的有效溝通是非常重要的，我並不認為沒有足夠的技術水平就無法使用敏捷開發方法，但是可以肯定，乙個不善於溝通協調的團隊是肯定無法利用敏捷方法完成專案的開發的。
此外乙個經驗豐富、善於溝通的領導者也是不可或缺的，就像一艘遠洋的輪船必須有乙個老練的舵手，敏捷開發過程是十分緊湊的，合理分配人力資源和各階段的進度，能夠有效地提高開發的效率與進度。而敏捷方法的核心思想決定了開發期間必須與客戶保持時刻的交流，乙個優秀的領導者也是乙個能準確捕捉客戶需求變化並準確反饋給開發人員的人，而這些高效地溝通和反饋正是整個專案推進的動力。
（完）
軟體工程 過程模型 敏捷開發
軟體的概念 軟體是在計算機系統支援下能夠完成特定功能和效能的程式 資料和相關文件 軟體 知識 程式 資料 文件 軟體危機 軟體危機是指落後的生方式無法滿足迅速增長的計算機需求，從而導致軟體開發和過程維護出現一系列嚴重問題的現象。軟體工程的概念 軟體工程定義的第一部分內容要求，軟體開發 維護 和執行的...
軟體工程 軟體過程模型
軟體過程是為了獲得高質量軟體所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。通常使用生命週期模型簡潔地描述軟體過程。生命週期模型規定了把生命週期劃分成哪些階段及各個階段的執行順序，因此，也稱為過程模型。常見的過程模型有瀑布模型 快速原型模型 增量模型 螺旋模型 噴泉模型等。1.瀑布模型...
軟體工程之敏捷過程
第五章 敏捷開發 敏捷的概念 敏捷軟體工程是哲學理念和一系列開發指南的綜合。這種哲學理念推崇 讓客戶滿意且盡早的增量發布 小而高度自主的專案團隊 非正式的方法 最小化軟體工程工作產品以及整體精簡開發。開發的指導方針強調超越分析和設計 儘管並不排斥這類活動 的發布，以及開發人員和客戶之間主動和持續的溝...