中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

文章較為系統地分享了關于敏捷開發的5種方法，希望能夠給你帶來一些幫助。

一、極限編程

極限編程（ExtremeProgramming，簡稱XP）是由KentBeck在1996年提出的。極限編程是一個輕量級的、靈巧的軟件開發方法；同時它也是一個非常嚴謹和周密的方法。

XP是一種近螺旋式的開發方法，它將復雜的開發過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，并根據實際情況及時地調整開發過程。

1.1、XP的核心價值

XP的核心價值觀是溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、謙遜（Modesty）。 　XP用“溝通、簡單、反饋、勇氣和謙遜”來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定范圍內成功地打破了軟件工程“必須重量”才能成功的傳統觀念。

XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用“溝通、簡單、反饋、勇氣和謙遜”的態度來對待XP；輕松愉快地來感受XP的實踐思想；自己認真實踐后，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。

1.2、為什么稱為“Extreme”（極限）

“Extreme”（極限）是指，對比傳統的項目開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它所不提倡的，XP則一概忽略（如開發前期的整體設計等）。一個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，能夠做到一周40小時工作制而不拖延項目進度。

1.3、XP核心實踐

基于敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐

• 團隊協作：通過客戶、開發團隊、項目經理三方共同參加的會議來確定開發計劃。
• 規劃策略： 計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
• 結對編程：系統的每一行代碼都是兩個人用一個鍵盤完成的。
• 測試驅動開發：先寫測試，后寫代碼。
• 重構：不斷優化系統設計，使之保持簡單。
• 簡單設計：為明確的功能進行最優的設計，不考慮未來可能需要的功能。
• 代碼集體所有權：開發隊伍中任何人可以修改任何其他人的代碼，代碼不屬于某個個人。
• 持續集成：至少每天將整個系統集成一次，保持一個能運轉的系統。
• 客戶測試：客戶自己也是軟件開發隊伍的重要一份子。
• 小版本發布：盡快發布，盡早發布。
• 每周40小時工作制：保證休息，保持體力。
• 編碼標準：必須有統一的編碼規范，確保代碼的可讀性。
• 系統隱喻：將整個系統聯系在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的。

二、 水晶方法

水晶（Crystal）方法論由Alistair Cockburn在20世紀90年代末提出。他把開發看做是一系列的協作游戲，而寫文檔的目標是幫助團隊在下一個游戲中取得勝利。水晶方法的工作產品包括用例、風險列表、迭代計劃、核心領域模型，以及記錄了一些選擇結果的設計注釋。水晶方法也為這些產品定義了相應的角色。值得注意的是這些文檔沒有模板，描述也不太規范，但目標清晰，能夠滿足下次游戲開始的條件。

對于水晶方法論，根據方法論的輕重可以分為透明水晶和橙色水晶等。透明水晶一般適用于輕量級的團隊。不管是哪種水晶，都會對團隊的角色、團隊的工作項和產出、核心實踐、支持過程等進行定義。

三、動態系統開發方法

動態系統開發方法（DSDM）倡導以業務為核心，快速而有效地進行系統開發?？梢园袲SDM看成一種控制框架，其重點在于快速交付并補充如何應用這些控制的指導原則。

DSDM是一整套的方法論，不僅僅包括軟件開發內容和實踐，也包括了組織結構、項目管理、估算、工具環境、測試、配置管理、風險管理、重用等各個方面的內容。

3.1、DSDM的基本觀點

DSDM認為任何事情都不可能一次性圓滿完成，應該用20%的時間完成80%的有用功能，以適合商業目的為準。實施的思路是，在時間進度和可用資源預先固定的情況下，力爭最大化地滿足業務需求（傳統方法一般是需求固定，時間和資源可變），交付所需要的系統。對于交付的系統，必須達到足夠的穩定程度以在實際環境中運行；對于業務方面的某些緊急需求，也必須能夠在短時間內得到滿足，并在后續迭代階段中對功能進行完善。

3.2、DSDM的基本原則

• 活動用戶必須參與。
• 必須授權DSDM團隊進行決策。
• 注重頻繁交付產品。
• 判斷產品是否可接受的一個基本標準是符合業務目的。
• 對準確的業務解決方案需要采用循環和增量開發。
• 開發期間的所有更改都是可逆的。
• 基本要求是高層次的并區分優先級（以在低優先級的項目上獲得一定的靈活性）。
• 在整個生命周期集成測試。
• 在所有參與者之間采用協作和合作方法。

四、精益開發

精益（Lean）管理的思想起源于豐田公司，旨在創造價值的目標下，通過改良流程不斷地消除浪費。這種方法現已被廣泛用于生產制造管理，對于IT系統建設，精益開發的常用工具模型是價值流模型。

4.1、精益開發的基本原則

• 杜絕浪費：將所有的時間花在能夠增加客戶價值的事情上。
• 推遲決策：根據實際情況保持可選方案的開放性，但時間不能過長。
• 加強學習：使用科學的學習方法。
• 快速交付：當客戶索取價值時應立即交付價值。
• 打造精品：使用恰當的方法確保質量。
• 授權團隊：讓創造增值的員工充分發揮自己的潛力。
• 優化整體：防止以損害整體為代價而優化部分的傾向。

五、Scrum

Scrum 是一個用于開發和維護復雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周。

在Scrum中，使用產品Backlog來管理產品的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常為用戶故事。Scrum團隊總是先開發對客戶具有較高價值的需求。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。

挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。在每個迭代結束時，Scrum團隊將遞交潛在可交付的產品增量。 Scrum起源于軟件開發項目，但它適用于任何復雜的或是創新性的項目。

5.1、Scrum 過程框架

Scrum以經驗性過程控制理論（經驗主義）做為理論基礎的過程。經驗主義主張知識源于經驗, 以及基于已知的東西做決定。Scrum 采用迭代、增量的方法來優化可預見性并控制風險。Scrum過程框架的基石包括如下三個方面：

第一：透明性（Transparency）。透明度是指，在軟件開發過程的各個環節保持高度的可見性，影響交付成果的各個方面對于參與交付的所有人、管理生產結果的人保持透明。管理生產成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內容。也就是說，當某個人在檢驗一個過程，并確信某一個任務已經完成時，這個完成必須等同于他們對完成的定義。

第二：檢驗（Inspection）。開發過程中的各方面必須做到足夠頻繁地檢驗，確保能夠及時發現過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發生變化。當規定的檢驗頻率超出了過程檢驗所能容許的程度，那么就會出現問題。幸運的是，軟件開發并不會出現這種情況。另一個因素就是檢驗工作成果人員的技能水平和積極性。

第三：適應（Adaptation）。如果檢驗人員檢驗的時候發現過程中的一個或多個方面不滿足驗收標準，并且最終產品是不合格的，那么便需要對過程或是材料進行調整。調整工作必須盡快實施，以減少進一步的偏差。

Scrum中通過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，做出調整，從而優化次日的工作價值；Sprint評審和計劃會議檢驗發布目標的進展，做出調整，從而優化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經完成的Sprint，并且確定做出什么樣的改善可以使接下來的Sprint更加高效、更加令人滿意，并且工作更快樂。

5.2、Scrum的四大支柱

第一、迭代開發。在Scrum的開發模式下，我們將開發周期分成多個1-4周的迭代，每個迭代都交付一些增量的可工作的功能。迭代的長度是固定的，如果我們選擇了1周的迭代，那么保持它的長度不要發生變化，在整個產品開發周期內每個迭代都是1周的長度。這里需要強調的是在每個迭代必須產出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設計、第三個迭代做代碼。

第二、增量交付。增量是一個 Sprint 及以前所有 Sprint 中完成的所有產品代辦事項列表條目的總和。 在 Sprint 的結尾,新的增量必須“完成”,這意味著它必須可用并且達到了 Scrum 團隊 “完成”的定義的標準。無論產品負責人是否決定真正發布它,增量必須可用。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。

第三、自組織團隊。Scrum團隊是一個自組織的團隊，傳統的命令與控制式的團隊只有執行任務的權利，而自組織團隊有權進行設計、計劃和執行任務，自組織團隊還需要自己監督和管理他們的工程過程和進度，自組織團隊自己決定團隊內如何開展工作，決定誰來做什么，即分工協作的方式。

第四、高優先級的需求驅動。在Scrum中，我們使用Product Backlog來管理需求，Product Backlog是一個需求的清單，Product Backlog中的需求是漸進明細的，Backlog當中的條目必須按照商業價值的高低排序。Scrum團隊在開發需求的時候，從Backlog最上層的高優先級的需求開始開發。在Scrum中，只要有足夠1-2個Sprint開發的細化了的高優先級的需求，我們就可以啟動Sprint了，而不必等到所有的需求都細化之后。我們可以在開發期間通過Backlog的梳理來逐步的細化需求。

5.3、Scrum團隊介紹

在Scrum的工作方式下，總共只有三個角色， 這三個角色分別是產品負責人（PO）,Scrum Master和開發團隊。

我們通?？梢砸詣濤堉鄣膱F隊角色來類比Scrum的角色，劃龍舟通常有舵手、鼓手、劃槳團隊三個角色。Scrum中的PO就是舵手的角色，他對產品的方向負責，對產品的Why和What負責，對產品的愿景，產品包括哪些主要的特性負責。Scrum中的Scrum Master鼓手的角色，他幫助團隊保持高昂的士氣，并進行良好的協作，他是一個Scrum的專家，團隊的教練，團隊的服務式領導。Scrum中的團隊，對應到龍舟賽的劃槳團隊，團隊必須協調一致，作為一個整體前進，在這樣的環境下單打獨斗，各自為政沒有任何勝算。

Scrum的開發團隊對實現Sprint目標需要做的所有事情負責，包括技術方案和決策，團隊分工（誰做什么），執行Sprint開發任務等，而且作為自組織的團隊，他們也對他們的工作進度的跟蹤和管理負責。Scrum開發團隊的主要職責包括如下五個方面：

• 執行Sprint
• 每日檢視和調整，每個開發團隊成員都應該參與每日站會，一起檢驗Sprint目標的進展情況，跟進當天的工作情況調整計劃。
• 梳理產品列表，每個Sprint都需要花一些時間來準備下一個Sprint，主要用來梳理產品列表，包括PBI的創建和細化、估算和排列優先級順序。
• sprint規劃，在Sprint計劃會議（Sprint Planning Meeting）上，在ScrumMaster的引導下，開發團隊和PO合作，為下一個Sprint建立目標。
• 檢視和調整產品與過程，每個Sprint結束后，開發團隊都要參加兩個檢視和調整的活動，即Sprint評審會議（Sprint Review Meeting）和 Sprint回顧會議（Sprint Retrospective Meeting）。

5.4、什么是用戶故事

用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：

1. 角色：誰要使用這個功能。
2. 活動：需要完成什么樣的功能。
3. 商業價值：為什么需要這個功能，這個功能帶來什么樣的價值。

用戶故事通常按照如下的格式來表達：作為一個<角色>, 我想要<活動>, 以便于<商業價值>

本文由 @PMO雜談 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Pixabay，基于CC0協議