資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法學敏捷軟體開發流程及其原則？
介紹
在軟體工程中，軟體開發佔據了整個過程的大部分。軟體開發本身意味著將整個開發過程劃分為多個階段，例如設計、產品管理、專案管理等。世界各地的組織遵循各種軟體開發方法來成功地進行專案管理。
不同的組織使用各種方法，例如敏捷方法、瀑布模型、DevOps 部署、快速應用程式開發等，它們各有優缺點。然而，由於其迭代開發方法，敏捷軟體開發方法在全球範圍內被廣泛使用。
什麼是敏捷軟體開發流程？
在我們瞭解敏捷方法是什麼之前，讓我們先看看傳統的瀑布模型。在瀑布模型中，整個開發過程以更順序的方式進行，專案被劃分為多個階段。在初始階段，定義需求，然後進入構建階段。構建過程完成後，產品進入測試階段，然後是部署。
雖然瀑布模型在初始需求分析期間為需求和專案範圍的變更提供了充足的餘地，但在後期階段卻缺乏靈活性。同樣，由於客戶在構建過程中參與度不高，當測試階段開始並且不幸發現一些嚴重的錯誤時，有時整個過程需要從頭開始。
為了避免瀑布模型中遇到的所有這些問題，組織開始採用敏捷模型。在敏捷開發中，整個過程以更迭代的方式進行，專案被劃分為不同的衝刺。敏捷允許持續改進和更好的客戶互動和參與，並且在任何階段都非常靈活地應對需求變化。
瀑布模型主要關注產品完成，而敏捷模型主要關注客戶參與和滿意度。敏捷不關注階段，而是關注按衝刺進行的小規模釋出，並優先考慮客戶反饋。與瀑布模型不同，瀑布模型將所有流程劃分為各個階段，一個階段接著一個階段，而敏捷模型的所有流程都是迭代的，並在每個衝刺中重複。
例如，在瀑布模型中，設計階段後是開發階段，開發階段後是測試階段，而在敏捷開發中，每個衝刺都包含設計過程、開發過程和測試過程。在每個衝刺結束時進行使用者驗收測試。這使得團隊互動得到增強和提高，客戶參與專案更多。與瀑布模型不同的是，瀑布模型在開發階段完成後才進行測試，而在敏捷開發中，開發人員和測試人員一起工作。
敏捷軟體開發流程的型別 -
雖然敏捷本身可以定義為一種軟體開發方法，它有一套自己的思想和原則，或者更像是一份宣言，但有不同型別的模型可以將其應用於實際的開發過程中。雖然所有這些方法中都體現了敏捷的核心思想，但執行方式和關注點卻使一種方法與另一種方法區別開來。讓我們看看不同型別的敏捷流程：
Scrum -
Scrum 是一種廣為人知且常用的敏捷型別，通常在小型團隊中使用。它主要關注於管理開發團隊中的流程。它使用 Scrum 看板，並將整個開發過程劃分為衝刺。雖然衝刺的持續時間可能在 2 周到 1 個月之間變化，但每個衝刺都由分析、開發和使用者驗收定義。
Scrum 還關注團隊互動和有效的客戶參與。Scrum 團隊中的人員扮演著不同的角色，例如：
**Scrum Master** - Scrum Master 負責安排會議、團隊組建以及整個衝刺式開發的整體管理。他還負責處理開發過程中遇到的任何障礙。
**產品負責人** - 產品負責人負責建立和維護產品待辦事項列表，這是一個包含特定衝刺所有開發計劃或需求的儲存庫或儀表板。產品負責人還根據每個衝刺中任務的優先順序順序分配和管理需求。
**Scrum 團隊** - 負責開發或完成任務併成功執行每個衝刺的開發團隊。
對於每個衝刺，產品負責人都會準備產品待辦事項列表，其中包含該特定衝刺的需求或任務以及使用者故事。一旦為該衝刺待辦事項列表選擇任務，開發團隊就會處理這些任務並按衝刺將其執行為產品。Scrum Master 管理整個衝刺過程，並確保計劃順利執行。
每天都會舉行大約 15 分鐘的簡短會議，稱為每日 Scrum 或站立會議，Scrum Master 在此會議上獲取有關產品待辦事項列表的狀態更新，並嘗試找出是否有任何阻礙進一步行動的障礙。一些非功能性測試型別包括負載測試、相容性測試、可用性測試、可擴充套件性測試等等。
看板
看板方法在某種程度上類似於 Scrum。由大野耐一開發，它來源於日語單詞“看板”，指的是在產品生產週期中遵循的指令卡。它是一種更直觀的視覺化方法，非常依賴於它的看板，類似於 Scrum 看板，其中包含開發過程的完整工作流程安排。
與 Scrum 不同的是，Scrum 只將衝刺任務新增到看板中，而看板將所有與生產計劃相關的任務都以卡片的形式新增到看板中。通常，任務被分為三列，例如已完成的任務、待辦事項、正在進行的任務。與 Scrum 不同的是，看板中基於優先順序的任務完成是可選的，它可以在一個地方包含與整個開發週期相關的所有任務。
極限程式設計 (XP)
極限程式設計，簡稱 XP，優先考慮客戶滿意度。由 Kent Beck 開發，XP 要求客戶和開發人員有更高水平的參與。客戶需求頻繁變化的開發案例可以選擇 XP，因為它在生產的任何時間都靈活地應對變化。
它專注於短期交付，並在整個專案中設定檢查點，以分析需求是否發生變化並相應地採取行動。小的交付和迭代開發週期以更混亂的方式發生，沒有任何清晰的畫面。然而，一旦整個開發完成，它就變得有意義了。XP 在很大程度上取決於其開發團隊的協調能力。極限程式設計有五個階段：
規劃 -
初始階段，客戶和開發人員會面，討論開發的需求和範圍。根據客戶的輸入，開發團隊為整個開發準備簡短的迭代使用者故事或開發週期。根據建立的故事，定義專案的持續時間和成本。
設計 -
在此階段，所有使用者故事都被分解成更小的任務，並對執行進行進一步的分析。甚至在設計過程中也會規劃開發標準，例如類和方法名稱、體系結構和格式等。同時為這些迭代任務準備測試用例。對於可能出現的問題，甚至還會討論應急計劃和解決方案。
編碼 -
最重要的階段，根據計劃進行開發，包括基於需求的編碼以及同時進行的文件更新，以便向客戶更新當前狀態。設計過程中定義的編碼標準和體系結構得到嚴格遵守，每週工作時間嚴格控制在 40 小時以內。
測試 -
編碼完成後，開始進行使用者驗收測試。XP 將測試整合到編碼階段本身，以便測試和開發同時進行。根據測試結果，消除錯誤，然後產品經過基於客戶需求的客戶驗收測試。測試通過後，產品連同測試結果一起交付給客戶。
結束 -
在此階段，產品交付後，團隊等待客戶和管理層的反饋。根據反饋，他們再次遵循相同的計劃-編碼-測試迭代，直到客戶驗收測試透過。團隊還在生產過程中提供技術支援，以防出現進一步的問題。
水晶方法
水晶方法更像是一個通用術語，包含多種敏捷方法。根據水晶方法，應根據團隊規模、專案的重要性、專案優先順序等因素選擇不同的方法框架。
不同型別的水晶方法包括：
**水晶清晰** - 團隊成員少於 8 人
**水晶黃色** - 團隊成員 10 至 20 人
**水晶橙色** - 團隊成員 20 至 50 人
水晶紅 (Shuǐjīng Hóng) − 由 50 到 100 名團隊成員組成
與其他敏捷方法類似，水晶方法也從計劃開始，其中根據客戶需求和可行性分析定義任務。然後是實際的開發週期。水晶交付也提倡快速和短期的交付。整個過程中計劃安排大約 2 個或更多個交付週期，並整合同步測試。測試結束後，交付產品以及測試結果。開發完成後，團隊將處理客戶反饋以及生產支援。
精益開發 (Jīngyì Kāifā)
雖然精益本身是一種獨立於敏捷的方法，但基於其原則和工作機制，它也被認為是一種敏捷型別。精益方法誕生於豐田，專注於價值、原則以及更好的編碼標準和實踐。其主要目標是以更低的生產成本加快開發速度。精益方法基本上有 7 個原則，它們是：
刪除所有對客戶需求無用的內容。
鼓勵具有完整性和紀律性的高質量開發。
記錄整個開發過程以建立知識。
在對客戶需求有完整了解之前，不要開始計劃和設計。
專注於更快地交付給客戶。
專注於最佳化程式碼，消除錯誤和 bug。
尊重、激勵和賦能團隊。
特性驅動開發 (Tèsè Qūdòng Kāifā) −
特性驅動開發方法（FDD）依賴於並優先考慮其開發人員，因為它更注重設計和開發。與其他敏捷方法類似，它專注於多個小型開發週期，其中重點嚴格在於設計、編碼和分析。
因此，基於特性需求，計劃設計和開發週期，並在每個週期結束時執行單元測試和程式碼檢查。它更注重嚴格的文件編制和計劃。一旦特性列表得到充分記錄和理解，團隊就開始進行開發。
動態系統開發方法 (Dòngtài Xìtǒng Kāifā Fāngfǎ) −
動態系統開發方法（DSDM）是一種快速行動開發 (RAD) 模型，其重點更多地放在開發上，而不是計劃和設計。DSDM 是基於對通用 RAD 框架的需求而形成的。雖然團隊承擔了大量的責任並積極參與其中，但所有開發工作都具有靈活性，可以在需求變更的情況下進行調整。
與其他敏捷方法類似，DSDM 也專注於更好的團隊參與和互動、迭代開發週期中的最佳產品交付、客戶滿意度和頻繁交付。
敏捷原則 (Mǐnjié Yuánzé) −
雖然敏捷本身更像是一種思想或宣言，但如上所述，它有不同的實現形式。然而，仔細觀察這些方法，可以發現它們都有一些共同的框架或一些基本思想，所有這些方法都是基於這些思想的。根據敏捷宣言，共有 12 條原則或指導方針，所有敏捷方法都遵循這些原則：
敏捷提倡儘早並持續地交付有價值的軟體。這意味著雖然客戶滿意度是敏捷的主要關注點之一，但客戶總是希望更快地交付，儘早或按時交付是讓客戶滿意的一種方式，因為歸根結底，他們主要關心的是最終產品，而不是整個過程。
在開發的任何階段都靈活應對變化。敏捷的主要關注點之一是客戶滿意度，敏捷的全部內容都是關於客戶的投入和參與，包括在開發過程中的任何時間點整合需求變化。
在整個開發過程中進行頻繁且短期的交付。這些交付可以根據週期/衝刺持續時間每週或每月進行，以便定期向客戶更新開發的當前狀態。
敏捷提倡業務人員和開發人員之間的透明度，並要求他們一起工作，這有助於更好地協調、風險管理以及從技術和業務角度理解產品開發流程。
敏捷提倡激勵團隊中的個人。透過提供更好的生產環境併為他們提供所有支援、動力和尊重，將會有一個充滿動力並相互信任的團隊，這對於提高生產力非常有效。
雖然技術進步為我們提供了許多替代的溝通方式，但敏捷認為面對面的溝通是開發團隊之間以及與開發團隊溝通的最有效方式。
敏捷專注於周密的計劃和設計，以便清楚地瞭解使用者需求。敏捷鼓勵持續關注有效的設計和技術卓越，透過遵循最佳程式碼標準來實現這一點。這可以透過定期進行程式碼檢查、技術評審和基於評審的重構來實現。
敏捷提倡可持續發展。開發人員、使用者和贊助者應該一起工作，以便以恆定的速度交付產品。由於需求變化以及開發過程中的阻塞是不可避免的，因此整個團隊必須一起工作，以便持續進行交付過程。
工作的軟體是衡量進展的主要標準。簡單來說，如果最終產品無法正常工作，那麼任何計劃、設計或整體開發過程都沒有意義。正常工作的最終軟體產品是敏捷過程成功的關鍵。
簡潔——最大限度地減少未完成的工作量——至關重要。簡單來說，就是用最少的努力獲得最大的成果。敏捷提倡去除不必要的任務，優先處理能夠以較少而有效的工作量產生最大影響的活動。
最佳的架構、需求和設計源於自組織團隊。敏捷提倡鼓勵和欣賞團隊中那些對整個開發過程充滿熱情、承擔任務責任並在彼此之間透過有效的溝通分享想法的積極分子。這將導致一個由積極進取、高價值的團隊成員組成的團隊，他們擁有主人翁意識，共同努力提高生產力。
定期團隊反思如何提高效率，然後調整其行為。改進和變化總是有空間的。敏捷提倡團隊成員應該專注於自我改進。他們應該定期進行分析並努力改進整體交付或開發過程。
結論 (Jiélùn) −
敏捷方法誕生於 90 年代的技術困境。敏捷宣言是在考慮健康的開發環境和快樂的客戶的情況下制定的。沒有什麼是完美的，即使在敏捷過程中，人們仍然面臨一些問題。然而，在一個不斷變化的技術競爭激烈的世界中，我們仍然可以期待敏捷宣言中不斷改進和變化，以獲得更好的開發體驗。
5K+ 次瀏覽
