敏捷過程

敏捷開發是一種以人為核心，以迭代方式循序漸進開發的方法，其軟體開發的過程稱為“敏捷過程”。
在這一過程中，軟體專案的構建被切分成多個子專案，各個子專案的成功都經過測試，具備整合和可執行的特徵。
在2001年年初，一些業界專家成立了敏捷聯盟，起草了敏捷軟體開發宣言。該宣言針對一些企業的現狀，提出了讓軟體開發團隊具有快速工作、快速應變能力的若干價值觀和原則，其中包括4個簡單的價值觀以及敏捷開發方法應遵循的12條原則。

敏捷開發的價值觀

1. 個人和互動勝過過程和工具。
2. 可以執行的軟體勝過面面俱到的文件。
3. 客戶合作勝過合同談判。
4. 響應變化勝過遵循計劃。

敏捷開發應遵循的12條原則

1. 通過儘早的、不斷地提交有價值的軟體來使客戶滿意。
2. 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
3. 以從幾個星期到幾個月為週期，儘快、不斷地提交可執行的軟體。
4. 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
5. 以積極向上的員工為中心，建立專案組，給他們提供所需的環境和支援，並對他們的工作予以充分的信任。
6. 在團隊內部，最有效、效率最高的傳遞資訊的方法，就是面對面的交流。
7. 測量專案進展的首要依據是可執行軟體。
8. 敏捷過程提倡可持續的開發，責任人、開發者和使用者應該為能夠保持一個長期的、恆定的開發速度而努力。
9. 時刻關注技術上的精益求精和好的設計，以增強敏捷能力。
10. 簡單是最根本的。
11. 最好的構架、需求和設計出於自組織的團隊。
12. 每隔一定時間，團隊要反省如何才能更有效地工作，然後相應地調整自己的行為。

敏捷組織提出的敏捷開發模型的整體框架主要有三個：
Scrum、XP（eXtreme Programming）、OpenUP 這3個敏捷實踐。

敏捷開發的原則

1. 凝聚人的力量，緊密協（合）作。包括業務負責人、開發團隊、客戶、管理者之間的關係，所有這些關係在以前都是造成專案危機的原因之一，那麼，在敏捷時代，我們需要這些角色 緊密合作，最大限度的發揮各個角色的力量.
2. 聚焦客戶價值，消除浪費（如何聚焦使用者價值，即頻繁的交付使用者可工作的軟體，快速收到使用者反饋）

敏捷團隊運作機制

1. 一個團隊有自己的代辦事項，對代辦事項進行拆小。
2. 按客戶價值進行優先順序排序，產品經理負責價值排序。
3. 小而穩定，跨職能團隊。
4. 多個團隊鬆耦合（依賴性比較低），對齊迭代時間和戰略目標。

關鍵的團隊角色

• 產品負責人
• Scrum主管（流程主管）
• 開發團隊

產品負責人（Product Owner）

• 負責管理產品backlog（代辦事項）的唯一負責人
• 代表客戶/專案如責任人
• 定義產品的所有特性
• 負責產品的投入產出
• 負責最大化產品和開發團隊工作的價值

Scrum Master（流程主管）

• 起到教練的職責，領導團隊完成Scrum的實踐以及體現其價值。
• 排除團隊遇到的困難，使得團隊緊密合作，使得團隊個人具有多方面職能的工作能力。
• 確保團隊能勝任其工作，並保持高效的生產率。
• 保護團隊不受到外來無端影響

關鍵的團隊活動

• 每日例會：每日5分鐘左右的一個簡單例會，儘可能多的開發人員參與進來對緊要問題的討論。
• 評審會：需要在迭代週期的最後一天召開，1個小時左右就可以了，需要客戶出席，如果客戶不能出席，則需要產品經理出席
• 迭代回顧會：迭代回顧會是在每個迭代結束時進行，總結工作中的經驗和教訓，時間維持在30-60分鐘內，整個團隊都需要參加（Scrum Master、Product Owner、開發團隊以及客戶）。迭代回顧會包括兩部分，第一部分是定量分析，第二部分是定性分析。其中定量分析又包含團隊是否完成了迭代目標，收集並評審迭代度量指標（包括速率、迭代燃盡圖、迭代計劃故事和實際完成故事、計劃釋出日期與實際釋出日期、客戶滿意度、團隊滿意度、生產環境Bug數、生產Bug解決時間、使用者故事等）。定性分析包含哪些工作良好（應該繼續保持），哪些做的不好（應該停止）？哪些可以改進（團隊選出１－２條在下一個迭代實現）？

敏捷開發
作者：木可大大

敏捷團隊的五個約定

約定1. 業務分析師們，我們其實是同一個角色的兩種面孔，請叫上我們參加客戶需求會議

我們的團隊需要讓客戶頻繁的得到可用的軟體，客戶的不斷反饋會給軟體的未來做出最正確的方向指引。

如果我們交付的軟體有很多質量的問題，存在大量的缺陷，客戶會被這些缺陷的奇怪行為干擾，沒有辦法把注意力放在軟體本身的價值是否符合他們的真正需求上，
不能給出最有價值的反饋。所以，我們只有頻繁的做測試，在每次交付之前都把質量問題找出來告訴我們的團隊，問題才能及時的得到改正。

而我堅信“prevention is better than
cure”（預防勝於治療），我會要把工作的重點放在預防缺陷上，這樣可以節省Dev們很多修復缺陷的時間與精力。

為了達到這個目的，我需要跟你一起參加客戶需求會議，儘早的瞭解客戶需求與使用軟體的慣常行為。那麼在你完成需求的驗收條件的定義的時候，我也基本完成了測試用例的準備。

我們可以趕在開發人員們寫程式碼之前就告訴他們我要測什麼，讓他們減少因為過於樂觀而漏掉的一些重要的有破壞性的情況，減少缺陷的發生。這是我測試的一項重要任務。

如果你們在大部分需求都整理好了再交給我們，我會浪費掉等待的時間。更重要的是，開發好的軟體裡面已經有很多本來可以不存在的缺陷在裡面了，開發人員們可能需要加班加點來保證在專案最終交付時間之前把它們改好。這樣很容易產生新的缺陷的。

所以，請讓我儘早瞭解需求，請不要讓我到專案後期才能開始測試。

約定5. 測試人員們，那些敏捷實踐對於我們也是有用的。

如果你發現開發人員們做出的架構決定使測試工作變得更困難。那麼請大聲地告訴他們，design for testability（提高你們設計的可測性）。

如果你發現業務分析師寫的需求無法驗證，定義的客戶行為不夠具體，一個使用者故事中包含太多了功能點，等等，那麼也請大聲地告訴他，INVEST（獨立，可協商，價值，可估算，短小，可測）。

也請你們多跟開發人員結對寫自動化測試，既可以幫助你們學習怎樣更好的編寫自動化測試，也能幫助開發人員們結對更多的瞭解使用者行為。

敏捷開發的前置條件

比較固定的流程，文件，需求

1. 需求是控制穩定性的根本，對於需求一定是整體可控的，並且是可以由迭代內進行調整的，而不是定死的
2. 流程是指什麼時間什麼人該做什麼事是高效的，明確的
3. 文件是指每個流程階段具有可交付或者可查閱參考文件，不是口頭或者個人評定。

可靈活調整，允許試錯

• 檢查

檢查是指在每天的站會中檢查每個人的工作狀態，是否能完成自己的任務，存在什麼問題，完成效果如何。另外就是保證整體在每天的進度，是否有有整體效果，如果沒有完成今天的整體效果，需要檢查是否符合整體迭代。

• 調整

調整是指檢查發現迭代的進度或者外界環境發生變化時，及時調整當前迭代的開發任務，保證迭代最終產物的準確及時性變動。當然，這種變動是不允許太多的，一般情況下在需求沒有做詳細分析時，不接受；在當前有風險的情況下，撤銷某些需求；其他情況不做描述。

• 試錯

正是由於檢查以及調整的策略，保證了迭代的靈活性，我們可以在敏捷團隊中嘗試一些較革新、新的功能點或者技術點，如果實驗成功則可以對外拓展；如果不行，可以快速切換方案。

問題場景&&錯誤認識

• 一個團隊閉關開發一個專案就是敏捷

正確理解：敏捷不等於閉關，只是可能坐一起效率更高，其倡導的是何時都可以發生溝通，並準備一白板可以隨時討論方案；敏捷團隊質量以及效率高於一般團隊；敏捷團隊開發的是以迭代為單位，不是專案；

• 有了任務細分，開發白板，站會就是敏捷

正確理解：任務細分、白板、站會都是其形式，關鍵還是其將迭代的內容進行細化，可執行化，用高頻的溝通反饋提高開發、溝通、理解的效率。

• 敏捷團隊沒有特殊前置條件

正確理解：前面有講到敏捷對團隊，需求，文件，流程，調整等都有比較完整的規定。

• 敏捷團隊做的事情沒有差別性

正確理解：敏捷完成的任務具有明細化，分階段性，可調整性。所以在開發相關任務時，也具有類似的特點。

• 敏捷團隊會完整完美的交付產物

正確理解：敏捷在迭代結束只交付該階段的可交付產物，很可能不完整不完美，對於可交付也有不同的理解。

敏捷開發入門
作者：RobinsonZhang