【51CTO.com原創(chuàng)稿件】隨著互聯(lián)網(wǎng)產(chǎn)業(yè)的飛速發(fā)展，IT 研發(fā)的工作方式也越發(fā)的靈活多變。從應(yīng)用的角度來說，由原來的單服務(wù)應(yīng)用，到現(xiàn)在的微服務(wù)應(yīng)用，處理的數(shù)據(jù)量和類型也在不斷增長。

[[281102]] 

圖片來自 Pexels

從團隊的角度來說，不僅包括開發(fā)，測試人員，還引入了運維，安全，系統(tǒng)，網(wǎng)絡(luò)等各個專業(yè)的人員。

那么在新的時代下，我們?nèi)绾卫?DevOps(開發(fā)運維)的方法論指導(dǎo)交付過程，就顯得尤為重要了。

我們將從 DevOps 的兩個要點三個原則切入，來看看組織，團隊，流程的優(yōu)秀實踐。

DevOps 的兩個要點和三原則

做任何一件事情都有其價值，做事的過程就是“把業(yè)務(wù)構(gòu)想轉(zhuǎn)化為客戶價值的過程”，我們稱之為價值流。

對于研發(fā)團隊來說，也存在技術(shù)價值流。它就是通過“開發(fā)+運維”的敏捷迭代的方式為用戶提供價值。技術(shù)價值流就是第一個要點。

 

通過開發(fā)運維的方式，幫助業(yè)務(wù)想法觸達(dá)到客戶需求

如果把我們創(chuàng)造價值流的工作分成兩個階段：

• 第一個階段是設(shè)計和開發(fā)
• 第二個階段是測試和運維

 

技術(shù)價值流創(chuàng)造的兩個階段

那么前置時間是客戶提出需求，我們創(chuàng)建一個工單解決這個需求，然后處理工單，直到工作完成的時間的總和。前置時間作為第二個要點是我們值得關(guān)注的。

 

部署工作的前置時間和處理時間

通常情況下從設(shè)計，開發(fā)，測試，運維中間需要經(jīng)歷很多復(fù)雜漫長的過程。

 

交付的過程復(fù)雜且漫長

我們想要達(dá)到的目標(biāo)是，在代碼版本控制中不斷提交小批量的代碼，每次提交都會做自動化的編譯，自動化測試，手動測試(探索測試)，然后再部署到生產(chǎn)環(huán)境中。

為了實現(xiàn)這個目標(biāo)，需要盡量讓設(shè)計，開發(fā)，測試，發(fā)布的時間縮短，給客戶提供最大程度的技術(shù)價值流。

基于上面提到的兩個要點，下面三個 DevOps 原則就是最好的選擇。

流動原則

為了縮短從開發(fā)到上線之間的時間，提高服務(wù)質(zhì)量和可靠性，我們會加快開發(fā)(Dev)和運維(Ops)之間的流動。我們一起來看看需要注意哪些方面。

①使工作可見

和傳統(tǒng)行業(yè)相比軟件開發(fā)行業(yè)的工作可見度不高。通常只有完全做完才能看到可以使用的用戶界面，有的后臺服務(wù)甚至完成以后都看不到長什么樣子。

但是對于不可見的東西，人們對其又難以掌控，所以我們需要對工作進行可視化。

在敏捷開發(fā)中我們會對每個階段的任務(wù)進行切割，協(xié)助項目推薦和軟件開發(fā)的完成。

 

開發(fā)，運維，UAT，交付全流程

同時我們要告訴團隊，只有軟件交付到用戶手中并且給用戶帶來價值了，我們的工作才算完成。

②限制每人同時持有的任務(wù)數(shù)

這種場景大家是不是經(jīng)常遇到，你在開發(fā)某一個功能的時候，測試同學(xué)向你報了一個急需解決的 Bug，同時產(chǎn)品經(jīng)理又跑過來說這個需求可能需要再改改，架構(gòu)師也找你談重構(gòu)的事情。

這導(dǎo)致一個人同時要處理很多事情，每件事情都很重要，都需要馬上完成。就好像攤大餅一樣，每個事情都做，每件事都做不好。你會不斷地被打擾，在任務(wù)之間切換，使得效率變低。

因此，需要借助看板控制每人的任務(wù)量，讓任務(wù)保持合理的數(shù)量，從而保證質(zhì)量和效率。

 

一人持有多個任務(wù)

③減少批量大小

我們在開發(fā)過程中經(jīng)常會遇到這種情況，一個事情有四個步驟組成，我們需要完成 100 件這樣的事情。

于是，根據(jù)抽象和分工合作的原則，我們把這個事情分成 4 步，每個步驟分配給一個人來完成，這樣每個人完成每個步驟 100 次這個事情就完成了。

這個方法沒有錯，但是在做這個事情的初期，最好是把這個事情的四個步驟由一個人先完成一次，看看是否存在潛在的問題，在看看在完成過程中是否有可以總結(jié)的經(jīng)驗和需要踩的坑。

這樣往復(fù)幾次，把一些問題解決以后再找其他幾個人來分步驟幫忙。這種方式在快速試錯的互聯(lián)網(wǎng)企業(yè)用的非常的多。

 

先完成閉環(huán)流程，再復(fù)制經(jīng)驗

④減少交接次數(shù)

我們在完成一個事情的時候往往會和其他的團隊和人員進行大量的溝通，請求，委派，通知，協(xié)調(diào)等工作。

例如：軟件發(fā)布過程中就需要面臨功能測試，集成測試，環(huán)境搭建，配置服務(wù)器，存儲管理，網(wǎng)絡(luò)等工作。如果任何事情都需要審核，協(xié)調(diào)勢必會降低工作的效率。

這里互聯(lián)網(wǎng)企業(yè)的扁平化管理就可以借鑒，每個小隊包括技術(shù)，業(yè)務(wù)，管理和不同領(lǐng)域的人員，這樣減少了跨部門的溝通，工作效率更高。

 

減少交接

⑤識別和改善約束點

在軟件開發(fā)交付的過程中有很多約束，包括：人員，時間，軟件，服務(wù)器，網(wǎng)絡(luò)等等。

在 DevOps 中也一樣，我們需要不斷的識別這個約束，并且不斷改善這些限制條件才能推進整個開發(fā)的進度。

 

讓約束點之間能夠平滑過度

環(huán)境搭建：建議使用自動的環(huán)境部署，利用現(xiàn)在容器技術(shù)(Docker)提高整個環(huán)境的搭建速度。

代碼部署：建議讓代碼上傳，編譯，部署自動化起來。這些動作在一個軟件交付團隊每天都在不斷的上演，開發(fā)團隊的人越多這個工作更是需要做。

測試執(zhí)行：這個是承接上一點的，一旦一個軟件發(fā)布以后就需要跟進自動化的測試。

至少用自動化腳本針對核心 20% 的功能進行測試，然后再由測試人員對具體功能進行冒煙測試。

軟件隨著功能擴展，測試工作量也會隨之增大。如果不用自動化測試，依靠手動測試工作量是很大的。

解耦架構(gòu)：隨著微服務(wù)的風(fēng)行，現(xiàn)在基本都是組件式的設(shè)計，組件出現(xiàn)問題都做故障隔離和熔斷機制，那么也需要針對組件進行發(fā)布。

反饋原則

如果說流動原則說的是，從開發(fā)到運維的快速流動，那么反饋原則就是從運維到開發(fā)快速的反饋。這兩個原則周而復(fù)始運轉(zhuǎn)，才能為客戶交付最好最快的軟件服務(wù)。

①及時發(fā)現(xiàn)問題

一個服務(wù)/產(chǎn)品的交付歷經(jīng)了很多個過程，從需求分析，原型設(shè)計，架構(gòu)設(shè)計，編碼，測試，發(fā)布，集成測試，驗收測試，一直到上線。

每個階段都有工作者參與其中。任何一個問題的產(chǎn)生都是有原因的，即使不能阻止問題的產(chǎn)生，但可以第一時間發(fā)現(xiàn)問題，讓問題暴露出來。

例如：產(chǎn)品經(jīng)理沒有分析透徹，到了開發(fā)的時候就會遇到需求不清的問題，這時程序員就可以提出問題，產(chǎn)品經(jīng)理就需要對需求進行澄清。

 

發(fā)現(xiàn)問題，反饋問題，解決問題流程圖

②解決分析問題

有這樣一種情況，在開發(fā)的時候發(fā)現(xiàn)的問題，在需求和設(shè)計上都沒有提到。如果放任錯誤不管顯然會影響系統(tǒng)運行。

如果采取事不關(guān)己高高掛起的態(tài)度，那么問題永遠(yuǎn)無法發(fā)現(xiàn)，那么出現(xiàn)問題我們應(yīng)該如何處理。

第一，上游環(huán)節(jié)出現(xiàn)問題，一定不要把問題帶到下游環(huán)節(jié)。在上游環(huán)節(jié)就把問題解決掉。

 

上游環(huán)節(jié)出現(xiàn)問題

第二，暫停上游環(huán)節(jié)的工作，避免新的問題繼續(xù)產(chǎn)生。

 

發(fā)現(xiàn)問題及時處理

第三，建立 PDCA 環(huán)，計劃(Plan)，實施(Do)，檢查(Check)，改進(Action)避免此類問題不再發(fā)生。

 

建立 PDCA 機制

③源頭保證質(zhì)量

什么是源頭，相對下游來說上游就是源頭。產(chǎn)品經(jīng)理是開發(fā)的源頭，需求質(zhì)量不過關(guān)代碼就受影響。

程序員是測試人員的源頭，程序質(zhì)量有問題測試就會受影響;測試人員是客戶的源頭，如果問題都被放過了，那么就不能給客戶帶來價值。

所以，保證源頭就是保證交付的質(zhì)量。對每個過程和階段做監(jiān)控是我們要關(guān)注的：

• 需求階段：需求評審，需求確認(rèn)，需求宣講。
• 開發(fā)階段：代碼審核，結(jié)對編程，單元測試。
• 測試階段：冒煙測試，回歸測試，驗收測試。
• 發(fā)布階段：自動配置，自動部署，自動檢測。

 

追根溯源圖

④客戶同理心

客戶分為兩種，內(nèi)部客戶和外部客戶。外部客戶是通常意義的客戶，我們?yōu)榭蛻籼峁┸浖桓?，滿足客戶的需求，為客戶創(chuàng)造價值。

內(nèi)部客戶就是我們的下游。產(chǎn)品經(jīng)理把開發(fā)人員作為客戶，開發(fā)人員把測試人員作為客戶。

我們在做任何動作，發(fā)現(xiàn)任何問題，做任何決定的時候都要想想我們的“客戶”，是否對他們有利。我們要把自己放在客戶的角度來看問題，好多問題在當(dāng)下就會被解決。

 

客戶在哪里，站在客戶的角度

學(xué)習(xí)原則

學(xué)習(xí)原則是對前面兩個原則的支持，是基礎(chǔ)原則。不管你在工作中踩了多少坑，不管你在編碼過程中遭受多少失敗都不要忘記學(xué)習(xí)，持續(xù)的學(xué)習(xí)讓一個人變得更加強大，讓一個團隊逐漸成熟。

①建立學(xué)習(xí)型的組織結(jié)構(gòu)

在服務(wù)交付的過程中，無論我們?nèi)绾蔚男⌒亩紵o法避免犯錯。大家都有背鍋的經(jīng)歷。

比如某某需求，本來產(chǎn)品經(jīng)理就沒有說清楚，程序員在實現(xiàn)的時候忽略了，到了交付的時候就是程序員的鍋，之后項目經(jīng)理就會信誓旦旦地把開發(fā)人員批評一通。

這種場景在我早期工作的時候經(jīng)常遇到。后來隨著帶的項目越來越多，發(fā)現(xiàn)這樣“責(zé)備”式的解決問題方式是不對的。

我們應(yīng)該多從問題本身出發(fā)，找出問題的原因?？偨Y(jié)歸納，定義好的流程和機制讓兄弟們不再犯類似的錯誤。

如果我們把組織分為三類的話，我希望我們應(yīng)該是生機型(學(xué)習(xí)型)的組織。

 

組織類型分類

病態(tài)型：組織中的成員感到大量的恐懼和威脅(生怕做錯事情)。大家為了保全自己都不愿承擔(dān)責(zé)任，甚至隱瞞真相和事實。

官僚型：規(guī)則多，流程僵化，大家自掃門前雪。

生機型(學(xué)習(xí)型)：在錯誤中不斷總結(jié)，不斷學(xué)習(xí)，不斷進步。大家積極探索，勇于承擔(dān)，樂于共享。

 

生機型組織是我們的目標(biāo)

②日常工作制度化

這里的制度化并不是為了官僚而給大家加入的繁文縟節(jié)，正好相反這些制度的產(chǎn)生都是兄弟們在工作中總結(jié)出來的經(jīng)驗教訓(xùn)，轉(zhuǎn)換成制度的原因是希望不要有其他的兄弟再踩這些坑。

舉個例子，早先我們做發(fā)布的時候總是忘記發(fā)布數(shù)據(jù)庫的腳本，導(dǎo)致生產(chǎn)環(huán)境的程序 Run 不起來。后來，我們把更新數(shù)據(jù)庫腳本作為發(fā)布前必須做的事情寫入到發(fā)布制度中。

再后來，作為自動化腳本寫到自動化發(fā)布中。實際上在工作中有很多好的經(jīng)驗，如果我們留心都可以建立這樣持續(xù)改進的機制，成為心照不宣的制度。實際上我們在平時編碼中有很多事情都可以好好總結(jié)。

比如：編碼規(guī)范，命名規(guī)范，標(biāo)準(zhǔn)的 MVP/MVC/MVVM 寫法，發(fā)布流程，測試用例，測試腳本。

 

制度服務(wù)于流程

③局部經(jīng)驗全局化

在開發(fā)/運維過程中我們經(jīng)常會遇到各種各樣的事件(坑)，這些事件或是迎刃而解或者困擾我們許久。

但最終解決以后，我們希望把這些經(jīng)驗放到知識庫中保存起來，這是我們共同經(jīng)歷的一筆財富。

實際上一個項目做完以后，問問自己你在這個項目里面學(xué)到了什么，就是這些經(jīng)驗的積累。

當(dāng)你找下一份工作的時候，面試官問你遇到最困難的問題是什么的時候，你就可以自豪的分享這些經(jīng)歷了。

就算是再小的經(jīng)驗，在放到全局的時候?qū)ζ渌募夹g(shù)人員甚至是跨部門的技術(shù)人員都是有啟發(fā)和幫助的。

 

用知識庫管理經(jīng)驗

④注入彈性模式

這里說的彈性有兩個方面的意思，一個是指人員的彈性，一個是指我們維護系統(tǒng)的彈性。

人員的彈性，在沖刺項目的時候要有長征的韌性和搶渡大渡河的勇氣。在項目不忙的時候，也需要不斷總結(jié)，學(xué)習(xí)新知識，每個人的成長才能帶動整個團隊的成長。

項目的彈性，用壓力測試的方法，對維護的系統(tǒng)進行正壓力測試和負(fù)壓力測試，探查我們系統(tǒng)的承受極點，從而完善他。

 

團隊彈性和系統(tǒng)彈性

DevOps 組織結(jié)構(gòu)

根據(jù)康威定律，軟件的架構(gòu)和軟件團隊的結(jié)構(gòu)是一致的，這個是康威定律對團隊和架構(gòu)的解讀。

我經(jīng)歷過團隊從小到大的發(fā)展，在初期人較少時，工作流程概念不強，一個人做多個角色的事情，基本沒有溝通成本，軟件的架構(gòu)基本是單應(yīng)用。

后來隨著開發(fā)，測試，運維人員的增加，總體需要處理的工作量也大了。為了方便管理和項目推進效率，會對人和事情進行切割，規(guī)定流程以及團隊之間的溝通方式。

架構(gòu)也從原來的單應(yīng)用轉(zhuǎn)變成了后來的微服務(wù)，數(shù)據(jù)庫從原來的單庫轉(zhuǎn)化為分表分庫的模式。

 

組織結(jié)構(gòu)決定軟件架構(gòu)

開發(fā)，測試，運維相互融合

在開發(fā)過程中，開發(fā)，測試，運維所屬不同的專業(yè)，在項目推進過程中各司其職。在 DevOps 的組織結(jié)構(gòu)中，需要他們?nèi)呋ハ嗳诤稀?/p>

開發(fā)完成以后需要通過單元測試，結(jié)對編程的方式保證代碼的質(zhì)量。測試需要發(fā)現(xiàn)/驗證 Bug，并且與運維合作完成壓力測試/性能測試。

大家會發(fā)現(xiàn)，現(xiàn)在很多大廠的一線運維人員都是來自開發(fā)團隊，甚至有很多公司都鼓勵，開發(fā)，測試人員參與運維工作。讓他們感受一下自己的工作對下游工作的影響。

 

開發(fā)，運維，測試相互融合

DevOps 團隊搭建

 

團隊成員互為依托

既然了解了 DevOps 的組織結(jié)構(gòu)，那么團隊需要哪些成員參與呢?

• 產(chǎn)品負(fù)責(zé)人：業(yè)務(wù)方面的代表，可以把他想象成客戶。
• 開發(fā)團隊：負(fù)責(zé)具體功能開發(fā)。
• QA 團隊：負(fù)責(zé)質(zhì)量保障。
• 運維團隊：維護生產(chǎn)環(huán)境，配置，發(fā)布。
• 信息安全團隊：負(fù)責(zé)系統(tǒng)和信息的安全。

當(dāng)然，大家可以根據(jù)自己公司的需要在這個基礎(chǔ)上增加一些管理和支持職責(zé)的團隊。

對初創(chuàng)企業(yè)來說，如果沒有運維和信息安全的團隊，建議找開發(fā)團隊的兄弟兼任。

團隊價值流

多個團隊合作工作，存在溝通，統(tǒng)一認(rèn)知等方面的問題。價值流圖就是為了統(tǒng)一大家的思想，讓每個團隊的成員都知道，在什么階段需要做什么事情。實際這些圖在之前的文章中也有介紹，無非是把團隊和階段對應(yīng)上。

 

團隊價值流圖

工作在線

如果說要讓團隊站在同一個平面上面，使用高效的工具是必不可少的。例如：Confluence，石墨文檔，Jira，禪道，ProcessOn，Jenkins，Bamboo，Git，JMeter，LoadRunner。

它們可以幫助我們從設(shè)計，開發(fā)，測試，發(fā)布各個階段提升工作效率。讓團隊保持高度統(tǒng)一，讓所有的工作都在線。

 

讓工具為團隊服務(wù)，讓工作在線

DevOps 流水線部署

團隊存在的目的是，為了客戶創(chuàng)造價值。那么將軟件交付到用戶手中的過程，就好像工廠的流水線一樣，流水線的上游是原料，經(jīng)過加工以后，輸出的是商品。作為 DevOps 的流水線部署，需要使這個過程自動化。

作為交付團隊每次完成代碼編寫完成，都需要提交版本庫。提交以后，版本庫會對整體的代碼進行編譯(構(gòu)建/Build)，并且執(zhí)行單元測試的代碼。

如果失敗，會把錯誤信息打回交付團隊，程序員在修正錯誤以后再次提交代碼。只有通過后，才發(fā)布到測試環(huán)境，進行自動化腳本的測試。

同樣沒有通過自動化測試，依舊會打回到開發(fā)團隊，再次進行修改。這個過程周而復(fù)始，直到通過用戶驗收測試，并且發(fā)布。

 

DevOps 流水線

提交階段：是從技術(shù)角度上判斷系統(tǒng)是可以工作的。這個階段會進行編譯，運行單元測試腳本，通常這些腳本都是程序員自己編寫的。

另外，會針對具體代碼，由經(jīng)驗豐富的程序員做代碼走查，或者代碼互查。這里可以使用 Junit 單元測試工具。

自動化驗收測試階段：是從功能和非功能角度上斷言整個系統(tǒng)是可以工作的，即從系統(tǒng)行為上看，它滿足用戶的需要并且符合客戶的需求規(guī)范。

手工測試階段：用于判斷系統(tǒng)是可用的，滿足了它的系統(tǒng)要求，試圖發(fā)現(xiàn)那些自動化測試未能捕獲的缺陷，這部分測試內(nèi)容較為復(fù)雜，步驟較多，甚至存在多系統(tǒng)切換的情況。

這一階段通常包括探索性測試、集成環(huán)境上的測試以及 UAT(User Acceptance Testing，用戶驗收測試)。測試人員會根據(jù) UAT 的用例對系統(tǒng)進行測試。

發(fā)布階段：旨在將軟件交付給用戶，是直接將其應(yīng)用部署到生產(chǎn)環(huán)境，部署之后就進入運維階段。

按照流水線部署的好處就是，控制每個階段的交付質(zhì)量，逐步建立交付者的信心，通過層層篩選將問題擋在外面。

同時對于開發(fā)，測試，運維人員也是考驗。他們需要大量的協(xié)同工作，不斷地讓應(yīng)用在流水線上流動，并且及時反饋給不同位置上的隊員。

在熟悉了流水線上的幾個階段以后，再來看看每個階段產(chǎn)生了哪些數(shù)據(jù)，以及這些數(shù)據(jù)是如何流動的。

①流程的起點是，開發(fā)人員向代碼庫提交代碼。在 Checkin 代碼之前，開發(fā)人員需要把代碼庫中相關(guān)的代碼和組件下載到本地，保證修改后的代碼在本地是可以編譯通過的。

比較規(guī)范的公司，是需要申請 Code Review，讓其他的同事走查代碼。雖然在 Checkin 到代碼庫之后，平臺會自動運行單元測試。但是建議各位，先做單元測試。

因為，一旦進入驗收階段，編譯會花費大量的時間，如果出現(xiàn)問題，系統(tǒng)會生成錯誤報告并且發(fā)給 Team Leader 或者項目組。

如果那個時候再改代碼，恐怕所有人都知道 Bug 是從你這里出來的了。因此，還是先在本地跑一下單元測試。

其范圍包括你修改代碼的模塊，也包括其他模塊。實際上，任何對代碼的修改都有可能影響其他模塊，即使你并沒有修改其他模塊。

持續(xù)集成管理系統(tǒng)對這次代碼提交作出響應(yīng)，從指定的代碼庫拉取代碼，并且進行編譯，運行單元測試，執(zhí)行代碼分析，組裝打包。

如果單元測試都通過，并且代碼符合編碼標(biāo)準(zhǔn)，就可以打包成可執(zhí)行文件，并放到一個成品庫(artifact repository)中。

當(dāng)下的持續(xù)集成服務(wù)器，都提供這些功能，并讓用戶和流水線的后續(xù)階段能以簡便的方式進行。

另外，還有像 Nexus 和 Artifactory 這樣的工具可幫助管理過程產(chǎn)物。目前比較成熟的產(chǎn)品。例如 Bamboo，Jenkins 都可以通過配置代碼庫，成品庫，通過腳本命令的方式完成上述操作。

②第二個階段通常由運行時間較長的自動化驗收測試。這些測試的主要內(nèi)容，是針對一些 API 和模塊的測試。

也有的項目組用來做頁面的測試，但是個人不建議做頁面的自動化，特別是在頁面設(shè)計的初期，頁面元素經(jīng)常變動，自動化的腳本變化也很大，效果不是很好。

在此之后，部署流水線可能會有分支出現(xiàn)，這樣就可以將該構(gòu)建版本獨立部署到多個不同的環(huán)境中，比如部署到用戶驗收測試環(huán)境、容量測試環(huán)境和生產(chǎn)環(huán)境。

也有串行的例子，比如 DEV(開發(fā))環(huán)境，INT(集成測試)環(huán)境，MO(準(zhǔn)生成)環(huán)境，Prod(生產(chǎn))環(huán)境。

通常情況下，我們希望測試人員或運維人員可以做到自服務(wù)，即自己手工選擇需要的某個版本。

例如：可以通過 Bamboo 或者 Jenkins 工具選擇成品庫中的應(yīng)用版本，然后發(fā)布到指定的環(huán)境。

所謂的自動化部署腳本也就是一行能夠在服務(wù)器上運行的命令，執(zhí)行命令完成部署工作。

測試人員應(yīng)當(dāng)能夠看到需要手工測試的所有構(gòu)建版本，以及它們的狀態(tài)，之后單擊一個按鈕，運行相應(yīng)的部署腳本將選定的構(gòu)建版本部署到選定的環(huán)境上。

 

提交和驗收階段

總結(jié)

DevOps 模式需要遵循三個原則，快速流動，及時反饋，堅持學(xué)習(xí)。因此，DevOps 的組織結(jié)構(gòu)需要開發(fā)，測試，運維緊密合作。

按照這個標(biāo)準(zhǔn)去打造團隊，讓團隊產(chǎn)生價值流，通過工作在線的方式，給用戶提供價值。

DevOps 的價值體現(xiàn)在流水線的部署方式，這里需要合理配置提交，驗收，手工測試和發(fā)布階段。讓應(yīng)用快速流轉(zhuǎn)，讓團隊收獲及時反饋，從而穩(wěn)步推進軟件交付。

作者：崔皓

簡介：十六年開發(fā)和架構(gòu)經(jīng)驗，曾擔(dān)任過惠普武漢交付中心技術(shù)專家，需求分析師，項目經(jīng)理，后在創(chuàng)業(yè)公司擔(dān)任技術(shù)/產(chǎn)品經(jīng)理。善于學(xué)習(xí)，樂于分享。目前專注于技術(shù)架構(gòu)與研發(fā)管理。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】