全栈工程师?
嗯.....目前并不是!

軟件開發:敏捷開發模式,無論是產品還是運營都要懂

本文筆者將從軟件工程的角度來聊一聊敏捷開發模式,會涉及瀑布,V字、RUP、迭代、螺旋等開發模型,同時重點分享下敏捷模式的核心思想。

文章分兩部分:

  1. 通過舉例和對標其他行業,聊聊軟件開發模型的發展演進。
  2. 聊聊敏捷的核心思想。

敏捷開發是互聯網界比較流行的軟件開發模式,產品、技術、項目管理、運營、美術和測試等各崗位對其理解后都大有益處,運用得當可以事半功倍。現在信息爆炸、良莠不齊,網上很多講敏捷的文章,Scrum詞意沒理解到位。去年看了敏捷革命的原版《Scrum:The Art of Doing Twice the Work in Half the Time》,結合大學所學的軟件工程聊一聊這個話題,here we go~

第一部分

瀑布模型

先上定義:瀑布模型是將軟件生存周期的各項活動規定,為按固定順序而連接的若干階段工作軟件概念,主要分為:需求分析、架構設計、詳細設計、實現、單元測試、集成部署、系統測試、運營維護。

瀑布模型要求每一個階段都有明確的文檔產出,對於嚴格的瀑布模型每一個階段都不應該重疊。

敏捷開發是個啥

為什麼會有瀑布模型?

如果一個人接項目,他也許不需要這麼麻煩,但規模稍微大一些,就需要多人協作,這時候就需要有標準有規範。

最開始的時候,大家用了建築工程領域的模型來對標軟件工程。是蓋住宅還是蓋工廠,或是商廈或是辦公樓或是博物館,都需要有嚴謹的建築設計圖,水電管道布線甚至裝修方案,才可以開始施工。

瀑布模型就是這個思維,所以瀑布模型對軟件架構師的要求很高。在瀑布模型下,如果把開發軟件作為蓋棟建築的話,coder只需要“搬磚”就可以了(在敏捷開發過程中,對研發團隊人員的要求會較高。瀑布重視流程、文檔,敏捷強調團隊內人員能力,特別是cross-functional,要有跨領域的能力)。

也有人把瀑布模型摺疊起來,變成了V字型,目的是每個階段都有要去驗證的東西,看起來是有跡可循的,前後階段是對應的。

個人覺得瀑布模型最重要的是給大家樹立了軟件工程的基本觀念:

  1. 前期做足功課很重要;
  2. 編碼只是軟件工程中的一部分。

敏捷開發是個啥

V字模型

瀑布模型有什麼問題?

慢慢大家發現:瀑布模型有很多限制和問題,最主要的是不能擁抱變化

蓋大樓畢竟跟開發軟件不一樣,軟件的需求往往是不斷變化的,瀑布模型往往會導致牽一髮而動全身,這就導致絕大多數瀑布模型是延期的,而且出來的東西也不是用戶最初想要的——客戶想要一把瑞士軍刀,最終只出來一把螺絲刀,甚至只是一根小木棍兒。

於是,人們逐漸想辦法克服了這個問題——這就是統一軟件開發過程(RUP:Rational Unified Process)

統一軟件開發過程:

RUP是瀑布模型的改進,可以這樣理解,這個模型把軟件開發過程的類比從建築行業改到了汽車行業。

主要認清了兩點:

  1. 軟件是不斷迭代的;
  2. 軟件應該是面向對象的。

當然,還有很多其他方面的改進細節,就不展開了。

一個車型可以是系列的,舒適版、技術版、豪華版,不同年份還不一樣,是不斷迭代更新的。要想造一輛車,團隊可以分頭行動。

簡化一下,比如:要做一個四隻腳的木凳,甲可以先去做凳子面,乙去做凳子腿。前提是兩個人定義好怎樣連接(接口),用什麼樣的螺絲,多大的孔,在什麼位置連接,凳子腿多高等等,也可以有個專門的丙(項目經理)去協調這些事情。這樣凳子腿可以在這個基礎上自由地塗些花紋,加個皮套,做些鏤空等等。

敏捷開發是個啥

改進后的瀑布模型

這個模型已經具備了高內聚低耦合的思想。但還是有個問題,客戶或領導通常想看到一些進展,也許一輛車從設計到出廠需要兩年,但每幾個月大家可以看到一些實實在在的東西。

以上面做凳子為例:我們是可以看到凳子腿和凳子面的,也可以想象它們連接起來的樣子。而軟件不一樣,只要各個模塊還沒有效的連接起來,那基本上啥都沒有,特別是對於大多數沒有計算機知識的人,基本上是一個“黑盒”過程。這個模型同樣面臨著延期超預算的風險,同時做出來的也不一定是客戶想要的。

隨着互聯網的發展,對軟件的變化需求越來越高,就產生了大家最熟悉的迭代模型——inception,elaboration,construction,transition,四個階段形成閉環,不斷循環往複,其核心理念是軟件是增量開發的,每次迭代都能看到些進展。敏捷開發就是在這個生命周期模型下演變而來。

敏捷開發是個啥

迭代模型

螺旋模型

接着,就有了螺旋模型,螺旋模型並不是推翻了瀑布和RUP,是一種改進。從某種角度來說,螺旋也是遵循瀑布模型的——每一次螺旋迭代都要有清晰的目標,明確的需求,規劃實現,交付條件等,這個循環也是迭代模型的迭代周期演變。

比如說要做一輛汽車,我們可以先做一個自行車,再逐漸地在自行車上加個鈴鐺,加上發動機,變成4個輪子,加個篷,車把變成方向盤……在各方面持續地螺旋迭代下去,最終會出來一個跟汽車差不多的東西

這個例子有一些原型法的味道,螺旋模型往往是較大較複雜的系統使用,目的是減小風險,每一次投入能看到一些東西的產出,希望把整個過程“白盒化”。

敏捷開發是個啥

螺旋模型

總結

以上是關於軟件工程的三個主要生命周期模型,逐漸地又出現了極限編程、原型開發、敏捷開發等模型。

嚴格來講,瀑布模型、迭代模型是生命周期層面的模型(當然,通常也包含了一系列開發層面的工具集),敏捷開發是基於迭代模型發展起來的一整套軟件開發指導原則。個人觀點是在實際操作中應重視指導原則,弱化方法論。

迭代模型在學術上很早就有人提出,敏捷開發的作者之所以能從不同的視角去看待軟件開發,並有獨特的思維和管理方法,這跟他的個人經歷有很大關係,因為他不是做計算機出身,為了理解他的思想,我特意購買了《敏捷革命》的英文原版《Scrum,The Art of Doing Twice the work in Half the Time》來閱讀,下面部分分享其核心觀點。

第二部分

我們可以看看《Scrum》的作者傑夫·薩瑟蘭的經歷,他之所以能以全新的視角來認識和理解軟件工程這件事情,很重要的原因在於他不是做這個行業出身。

作者的經歷

傑夫·薩瑟蘭畢業於著名的西點軍校,他以戰鬥機飛行員的身份去參加越南戰爭,在他的隊伍里50%的飛行員會被擊落,一些會被營救,一些再也回不來。在這個環境里他構建了自己的行動模型——即OODA(Observe,Orient,Decide,Act)執行任務的每時每刻都在重複着這個循環,猶豫就會死。這個行為模式在他的著作里能感受到已經深入骨髓。

參加完越南戰爭后,他去斯坦福進修了統計學碩士學位。後來邊在空軍學院做數學教授,邊讀了一個生物統計學博士,研究細胞、癌症相關的一些東西,學習了系統論方面的東西。

在研究細胞的時候,他會不斷考慮一個問題:whether the new state is better than the old one——現在這個狀態是不是比上一個好。《敏捷革命》原文中多次提到state這個詞,這也是作者非常重要的一種思考方式。

其離開大學的第一份工作是做美國的ATM,這個時候他把自己在戰爭和研究細胞中的方法應用於IT領域,后通過大量實踐(其中有為FBI構建犯罪嫌疑人數據庫,著作中的重要案例)逐步總結髮展出了敏捷模型理論。

另外,Scrum不是作者的首創,作者是根據日本兩個教授的理論發展總結而來。在學術界,日本的兩個教授質疑瀑布,他們認為:最好的團隊應該像打橄欖球一樣,球在隊伍中間穿梭,隊伍整體快速向目標移動(這才是Scrum想要表達的意思),日本的大企業最開始用這種指導思想(細算一下正是日本IT大發展的時代)。

理論早就有了,但很少有美國人這樣去實踐,作者為了理解日本人的Scrum思想,練習了多年合氣道,並用合氣道來類比Scrum,並再次用到了“state”思維方式來解釋。

說到Scrum,我們來聊聊cross-functional。

橄欖球大家可能不熟,我們來聊聊籃球:

球隊里最吃香的是哪種人,當然是那種什麼位置都能打且都打得好的,俗稱萬金油。勒布朗·詹姆斯號稱可以從1號位打到5號位,這種人可以體會到在各個位置的人的“不容易”,從而更有利於團隊發展。奧尼爾給人籃下巨無霸的印象,但其實他有靈活的運球技巧和出色的娛樂表演天賦,這些綜合到一起才成為球迷心中大鯊魚的人設。

NBA里那些最受人崇拜的頂級後衛,基本都會多種絕學,喬丹科比韋德等人,控球、得分、突破、搶板、分球等各項技能均能登堂入室,有些方面甚至前無古人。有一項技能特別突出基本就可以獨步武林,但想成為頂級選手,一定是cross-functional的。

而作為球隊老闆,希望在有限的資源下,儘可能多地把這種選手招致麾下,才有可能對拉里·奧布萊恩杯發起衝擊。勇士的“死亡五小”更是將這種理念發揮到了極致,場上隊員幾乎都能快攻、投籃和搶板。

回頭來看,軟件開發也是,cross-functional是對團隊人員素質要求的提高,正所謂不會寫代碼的產品不是好美術。軟件開發也是個跨兵種共同協作的同時不斷面臨變化的事情,從這個角度來看,跟打籃球和橄欖球是相同的,還記得NBA賽場上暫停時大家是怎麼解決問題的么?

結合上面說的場景“球在隊伍中間穿梭,隊伍整體快速向目標移動”,這是Scrum中非常重要的理念。

敏捷作者的一些核心觀點(為保原汁原味,摘抄部分原文):

傳統的瀑布模型其實是由一大堆圖表構成,作者表達了對圖表的一些觀點:

“Planning is useful.Blindly following Plans is stupid.”——計劃是有用的,但盲目的按計劃走是愚蠢的。這跟作者的從軍經歷有關,其執行任務的時候都是隨機應變,也應了中國的那句老話“計劃沒有變化快”。

“Every project involves discovery of problems and bursts of inspiration,scrum embraces  uncertainty and creativity.”——任何一個項目都包含了未發現的問題以及隨着項目進行的靈感爆發,圖表會限制這些,Scrum“擁抱”這些不確定性和創造性。

“Stop doing what you’re doing,review what you’ve done.”——放下手中的事情,想一想我們在幹啥。

作者對“敏捷”的一些觀點:

MVP:“Minimum viable products to get immediate feed back from consumers,rather waiting until a project is finished.”——最小化可行產品Minimum viable products,也簡稱MVP(搜索這個短語會有大量方法論)。用最小化的可行產品來從用戶那裡快速獲得回饋,而不是一直等項目完成,就是我們通常說的“小步快跑”。

InspectandAdapt cycle:上面說的OODA行動模型的抽象,“觀察—適應”,這兩個過程不斷循環。

這裡面作者提到了一個常用的方法5W2H,在每一個階段(state)都問自己:

What:我們要做的是什麼,有什麼意義,現在是什麼狀態;

Why:我們為什麼要做這個,可不可不做,有替代方案么;

When:什麼時候做,deadline是什麼;

Where:在哪做,哪裡要用;

Who:誰來做,誰對此負責;

How:怎麼來做,如何配合;

Howmuch:多少、程度,多大開銷,做到什麼程度;

敏捷革命可以應用在各行各業,作者已經在汽車製造、開洗衣店、學生培訓、製造宇宙飛創、婚禮策劃等領域展開實踐。所以說,Scrum模型不只是一套軟件開發工具集,是具有普世性的價值觀:

“Agile Manifesto,It declared the following values:people over process;products that actually work over documenting what that product is suposed to do;collaborating with customers over negotiating with them;and responding to change over following a plan,Scrum is the framework I built to put those values into practice.There is no methodology.”

這就是敏捷宣言的所有原文,後來被各種媒體放大和解讀,其實它非常簡潔——敏捷宣言,它強調了以下價值觀:

  • 人重於過程;
  • 產品真正好用重於文檔里的設計;
  • 跟用戶合作重於跟他們談判;
  • 對變化做回應重於按計劃去做;
  • 我建立Scrum模型就是為了把以上價值觀揉進一套工具集以方便更好地實踐,敏捷模型沒有方法論(沒有方法論,沒有方法論,沒有方法論,這是作者的原話啊,啪啪啪打臉有木有)。

總結

Scrum原著以案例來表達了他對圖表、文檔、對計劃、對團隊、對過程管理的一些觀點,而Scrum正是這一系列價值觀的合集,這才是Scrum的精髓所在。

為了快速實踐和方便理解這些價值觀,作者提供了一些方法,比如:每日立會、sprint、backlog等。

具體方法不贅述了,網上有很多介紹。這些方法都是為了落實上面的觀點:我們處在什麼狀態,我們有什麼,如何做下個狀態會比現在的好……

相比於拿過來方法直接使用,理解好上面的觀點再根據實際情況選擇方法是更有效的思路。

 

作者:齊齊獸,公眾號:齊齊獸,從技術轉型到產品經理,北郵MBA,千萬DAU平台型產品負責人,擅長社交和棋牌。

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《軟件開發:敏捷開發模式,無論是產品還是運營都要懂》
文章链接:https://www.pmbear.com/%e8%bb%9f%e4%bb%b6%e9%96%8b%e7%99%bc%ef%bc%9a%e6%95%8f%e6%8d%b7%e9%96%8b%e7%99%bc%e6%a8%a1%e5%bc%8f%ef%bc%8c%e7%84%a1%e8%ab%96%e6%98%af%e7%94%a2%e5%93%81%e9%82%84%e6%98%af%e9%81%8b%e7%87%9f%e9%83%bd/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们