敏捷開發
敏捷研發歷史
敏捷軟件開發的實踐最早出現在上世紀 90 年代。當時，一批輕量的軟件工程方法和框架相繼誕生，它們共同的特點是，相對傳統軟件工程，都遵循演進和迭代的模型，過程更加輕量靈活。其中 Scrum 和極限編程 (ExtremeProgramming）在實踐上最為成功，影響最大。它們都是迭代和增量的軟件開發框架，區別在于Scrum 只包含管理實踐，而極限編程則同時涵蓋工程和管理實踐。
2001 年 2 月，17 位輕量級軟件工程方法的代表人物，齊聚美國發布了后來產生巨大影響的敏捷宣言（參見 http://agilemanifesto.org/），敏捷宣言陳述了他們共同認可的關于軟件的開發方法的理念，同樣重要的是他們找到了敏捷這個詞來總領這些理念。
敏捷宣言發布后，敏捷成為了一場運動，被迅速的推廣和應用。敏捷專注研發交付階段，站在業務的角度，目標是幫助產品和研發團隊提升敏捷響應能力，也就是：“更早地交付價值，更靈活地應對變化”。
敏捷研發12條原則
敏捷宣言提出的12條原則已經應用于管理大量的業務以及與IT相關項目中，包括商業智能（BI）。12條原則包括：
最高優先級的是：通過盡早和持續交付有高價值的軟件，滿足客戶。
欣然面對需求變化，即使是在開發階段的后期，敏捷流程就是用變化來為客戶獲得競爭優勢。
頻繁交付可工作的軟件，從數周到數月，交付周期越短越好。
在項目過程中，業務人員、開發人員必須每天在一起工作。
以受到激勵的個體為核心構建項目，為他們提供所需的環境和支持，相信他們可以把工作做好。
最有效的、最高效的溝通方法是面對面的交談。
可工作的軟件是衡量進度的首要標準。
敏捷流程倡導可持續開發，客戶、開發人員、用戶要能夠共同、長期維持步調（節奏）、穩定向前。
持續地追求技術卓越和良好的設計，以此增強敏捷的能力。
簡單：盡最大可能減少不必要的工作，簡單是敏捷流程的根本。
最佳架構、需求和設計，來自組織型的團隊。
團隊定期反思如何提升效率，并調節和調整自己的工作方式。
在工具層面，云效核心輔助企業解決12條原則中的第1條、3條、8條。
敏捷研發的3個不等式
敏捷研發，提升研發效能，首先要弄清楚要解決的問題是什么，然后才是落地解決問題的實踐方法。否則問題沒定義清楚，就很難有好的結果。
那實現敏捷研發、提升研發效能究竟要解決什么問題？《精益產品開發》作者何勉老師將提升效能要解決的問題，歸納為3個效能不等式。
第一個不等式，局部效率不等于高效交付？
這一點，大家應該會有同感。當我們去問各個部門或者個人時，都覺得他們很忙，效率很高。但是，我們去問業務部門或用戶，卻是另外一回事，他們會抱怨產品研發響應慢、交付遲、質量也不好。
這就是組織內部視角的局部效率并不等于用戶視角的高效交付。這個是提升研發效能要面對的首要問題。解決它需要更有效的組織協同、更合理的交付模式，和更好的過程質量。
接下來的問題是，高效交付就夠了嗎？這就引出了第二個效能不等式。
第二不等式，高效交付能不等于持續高效
有的時候，為了高效的交付，我們可以采取臨時動作，比如把一群人關在一起，成立一個臨時項目，這樣溝通協作會更便捷，這可能會達成一時的高效。但是，如果缺乏長期質量思維，當我們在做下一個項目，往往會發現問題，之前的代碼和設計存在各種問題，比如可修改性、可復用性很差，它們成為后續項目的負債而不是資產，長期的效率無法維持。
如何從高效交付轉變成持續的高效，這是研發效能要解決的第2個問題。它對我們的工程和技術能力和實踐都提出了要求。
第三個不等式，高效交付不等于業務成功
產品交付的目的是支持業務發展和業務創新。我們必須保證交付的東西，能解決用戶問題，并構建可持續的商業模式，否則交付再多也沒有意義。
我們認為，研發效能提升的本質就是要解化解上面的三個不等式，從而把組織內的局部效率轉化為用戶可感知的高效交付，并保障持續的高效和帶來業務的成功。最終實現：“持續地順暢高質量交付有效的價值”。這是效能提升的根本目標。
落地敏捷開發，需要企業里核心角色的參與，我們就以產品、開發、測試3個核心角色為例，講解他們需要如何推進和支持敏捷開發在企業落地。
接下來我們將一步步講解業務、產品、技術如何落地敏捷研發，走向持續交付有用價值；
負責角色 | 目標 | 管理對象 | 工作職責 | 工作空間及事項 | 工作流 （供參，企業可自定義） | 數據度量 （供參，企業可自定義） | |
業務層 | 業務人員 | 響應和滿足業務訴求 達成業務目標 | 以業務需求為核心，同時關注其下屬產品需求 | 業務團隊：
產品團隊：
| 業務工作空間 可用云效“業務反饋管理空間”
| 已提出-已接受-已分析-已規劃-實現中-待驗收-已驗收（滿意度）-已發布 | 度量交付過程 需求交付率 需求交付準時率 需求交付滿意度 度量資源投入 以業務視角看研發資源投入 以研發視角看業務需求來源占比 備注：原始訴求和主題的度量即將上線 |
產品層 | 產品交付團隊 (含產品經理 及技術團隊） | 規劃和交付產品需求 滿足業務交付的短期和長期需求 | 以產品需求為核心，同時關注其下屬的技術任務 | 產品團隊：
| 產品交付空間 可用云效“產品規劃空間”
| 待排期-已排期-開發中-待測試-已完成 | |
技術層 | 技術開發 | 完成技術任務并高質量和即時的交付需求 | 系統變更及其它個人任務 | 產品團隊：
技術研發團隊：
| 技術交付空間 可用云效“Scrum敏捷交付空間”
| 待開始-已開始-已完成 | |
測試開發 | 完成測試任務，確保高質量交付 | 測試用例和缺陷 | 測試研發團隊：
| 缺陷交付空間
| 待確認-已確認-修復中-已修復 | ||
總體目標 | 拉通端到端的交付過程，確保過程質量，對齊各個層次的工作，最終實現業務需求的順暢和高質量交付。 | ||||||
敏捷開發的流程和場景
那么如何具體來落地，接下來我們將帶著大家深入到敏捷開發落地過程中，以Scrum 為例來介紹敏捷開發的流程和場景（如下圖）：
敏捷開發之 Scrum 方法大圖
我們接下來將詳細從這4個大維度詳細講解如何在幫助企業的業務人員、產品經理、技術開發、測試開發在云效上落地實施敏捷研發協同。
首先產品經理會進行：
需求的收集、調研和分析，形成按優先級排序的產品待辦列表，詳情請參考產品經理/PM如何做好需求管理。
對高優先級的需求，進行詳細設計和澄清，詳情請參考PM如何設計工作流和創建看板。
通過迭代排期會，形成按優先級排序的迭代待辦列表，詳情請參考如何做好迭代排期。
排期完成后，需求從產品經理側流向技術同學側，詳情請參考技術如何做好缺陷管理。
在需求澄清的情況下，研發團隊來會：
以 1～4 周的迭代周期進行持續開發和交付迭代待辦列表中的內容，詳情請參考如何做好迭代跟進。
采用每日站會來跟進計劃和發現問題，并在迭代過程中持續或間歇性地交付可工作的軟件，詳情請參考如何做好測試用例管理。
與此同時，產品經理會在這個階段，進行下一迭代的需求設計和澄清。
迭代待辦列表開發完成后，產品經理和研發團隊一起進行迭代演示，交付可工作的軟件，詳情請參考如何做好研發效能度量。
最后，通過迭代復盤度量驅動團隊持續改進，詳情請參考如何做好迭代復盤。
更多場景案例請參考：