敏捷開發詳解(含義、原則、目標、機制、skycto JEEditor)

書寫人生發表於2019-09-08
原文連結: https://blog.csdn.net/An1090239782/article/details/80262796

我們理解東西習慣從已知連線未知,首先我們來對比一下。我們最先了解到的是瀑布模型,那麼它就是不敏捷的。瀑布開發模式把開發分成一系列階段,如需求、設計、開發、測試,就像下圖它畫出來的,看起來很像瀑布,所以叫瀑布開發。
問題是需求的交付難道不都是要經歷這些階段嗎?

瀑布開發的本質問題並不是階段,而是批次。需求批次地在一起進行設計,然後是批次地開發,批次地測試、交付等等。批次有什麼問題? 首先,批次讓價值交付延遲,所有需求在最後的階段才能交付,價值交付比較晚。Google執行董事長施密特提出過反摩爾定律,表述為:“如果18個月之後我們只能賣出跟今天一樣的東西,我們就只能得到一半的收入。”價值的交付時間將直接影響收入。

敏捷的目標1:

敏捷開發有第一個目標就是更快的交付價值,這裡的快指的不是絕對速度,而是更早的交付。
在專案結束的時候,一定是對產品和專案的知識理解最充分的時候。這顯而易見,我們在專案程式中積累了知識,特別是當向使用者交付產品後,使用者反饋:“我要的不是這個啊,我說的明明是……”,這時候你瞬間狂漲知識,並感嘆道“你怎麼不早說呢?”。這中間可能有溝通問題,但更多可能的是,使用者這時才清楚或能夠描述他們要的是啥,更有甚者,我們可能一開始連使用者是誰也未必能準確地定義。產品和業務開發本來就是一個探索的過程,開始時一定是最無知的時刻。
專案中的大部分決策也一定是在專案開始的時刻做出的,這將有一個重大的悖論,在最無知的時刻,做出了最重要而且是絕大部分的決策,並把它作為隨後執行的依據。面對不確定的技術、市場環境,傳統開發模式已無法適應要求,悖論越發突出。
敏捷開發將透過迭代應對這一問題,只做初始決策,定大致的方向。透過市場反饋不斷修正對產品的認知,增量的決策和調整。

敏捷的目標2:

產品開發過程中,技術環境、市場環境、競品策略、團隊認知都會發生變化。面對變化的環境,我們必須承認自己的無知,在開發過程主動有效地學習,不斷地汲取反饋,靈活地調整。這也是敏捷的第二個業務目標,有效學習和靈活響應變化。

敏捷過程

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

在這一過程中,軟體專案的構建被切分成多個子專案,各個子專案的成功都經過測試,具備整合和可執行的特徵。

在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-2條在下一個迭代實現)?

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69947338/viewspace-2656394/,如需轉載,請註明出處,否則將追究法律責任。

相關文章