什麼是敏捷開發?

武漢PMP  漢陽PMP  光谷PMP  武漢PMP培訓認證 武漢PMP考試中心 武漢項目管理培訓 PMP考試中心 武漢ACP培訓認證 武漢ACP考試中心 武漢PMP

我們理解東西習慣從已知連接未知，首先我們來對比一下。我們最先了解到的是瀑布模型，那麼它就是不敏捷的。

瀑布開發模式把開發分成一系列階段，如需求、設計、開發、測試，就像下圖它畫出來的，看起來很像瀑布，所以叫瀑布開發。

問題是需求的交付難道不都是要經歷這些階段嗎？

瀑布開發的本質問題並不是階段，而是批量。需求批量地在一起進行設計，然後是批量地開發，批量地測試、交付等等。

批量有什麼問題? 首先，批量讓價值交付延遲，所有需求在最後的階段才能交付，價值交付比較晚。Google執行董事長施密特提出過反摩爾定律，表述為：

「如果18個月之後我們只能賣出跟今天一樣的東西，我們就只能得到一半的收入。」價值的交付時間將直接影響收入。

敏捷的目標一

敏捷開發有第一個目標就是更快的交付價值，這裡的快指的不是絕對速度，而是更早的交付。

在項目結束的時候，一定是對產品和項目的知識理解最充分的時候。這顯而易見，我們在項目進程中積累了知識特別是當向用戶交付產品後，用戶反饋：

「我要的不是這個啊，我說的明明是……」，這時候你瞬間狂漲知識，並感嘆道「你怎麼不早說呢？」。

這中間可能有溝通問題，但更多可能的是，用戶這時才清楚或能夠描述他們要的是啥，更有甚者，我們可能一開始連用戶是誰也未必能準確地定義。產品和業務開發本來就是一個探索的過程，開始時一定是最無知的時刻。

項目中的大部分決策也一定是在項目開始的時刻做出的，這將有一個重大的悖論，在最無知的時刻，做出了最重要而且是絕大部分的決策，並把它作為隨後執行的依據。面對不確定的技術、市場環境，傳統開發模式已無法適應要求，悖論越發突出。

敏捷開發將通過迭代應對這一問題，只做初始決策，定大致的方向。通過市場反饋不斷修正對產品的認知，增量的決策和調整。

敏捷的目標二

產品開發過程中，技術環境、市場環境、競品策略、團隊認知都會發生變化。面對變化的環境，我們必須承認自己的無知，在開發過程主動有效地學習，不斷地汲取反饋，靈活地調整。

這也是敏捷的第二個業務目標，有效學習和靈活響應變化。

敏捷開發工具

敏捷開發是一種以人為核心，以迭代方式循序漸進開發的方法，其軟體開發的過程稱為「敏捷過程」。

在這一過程中，軟體項目的構建被切分成多個子項目，各個子項目的成功都經過測試，具備集成和可運行的特徵。

在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解決時間、用戶故事等）。

定性分析包含哪些工作良好（應該繼續保持），哪些做的不好（應該停止）？哪些可以改進（團隊選出１－２條在下一個迭代實現）？

來源：運維自研堂

聲明：世紀卓越所發稿件、圖片均用於學習交流使用，並在顯要位置註明文章出處和來。

若涉及版權，請通過平臺與我們取得聯繫，我們將在第一時間處理。

【世紀卓越近期項目管理培訓】

項目管理PMP培訓（2019年12月考試）>>點擊查看詳情

↑↑↑長按二維碼一鍵諮詢