星標(biāo)關(guān)注，第一時間獲取IDCF社區(qū)資訊，了解活動動態(tài)，福利多多不容錯過！

作者：

楊凌宇（現(xiàn)就職中國電信研究院）

(資料圖片)

研發(fā)效能（DevOps）工程師認(rèn)證學(xué)員

前言

在如今軟件開發(fā)流程和工具愈發(fā)成熟的現(xiàn)狀下，敏捷似乎是所有軟件產(chǎn)品團(tuán)隊(duì)前進(jìn)的目標(biāo)。很多團(tuán)隊(duì)都宣稱自己是敏捷團(tuán)隊(duì)，但實(shí)際上，他們更多是在一定程度上達(dá)到了敏捷。我們在敏捷實(shí)踐的過程中，總會與理想中的情況存在差距，所以我們更多要思考的不是怎樣徹底的達(dá)到敏捷，而是在當(dāng)前的實(shí)際情況下，怎樣更好的運(yùn)用敏捷的思想去改進(jìn)。敏捷涵蓋的范圍非常廣，從需求收集，到產(chǎn)品設(shè)計(jì)、開發(fā)交付、測試安全、運(yùn)維保障等一系列流程，都可以運(yùn)用敏捷的思想。其中開發(fā)交付的過程，是真正建設(shè)出一個產(chǎn)品的過程，我作為一名一線的開發(fā)人員，也更想談一談在開發(fā)過程中，以及對于開發(fā)團(tuán)隊(duì)來說，如何進(jìn)行敏捷的轉(zhuǎn)型。

何為敏捷開發(fā)

敏捷開發(fā)是以用戶的需求為核心，把大的需求進(jìn)行拆分，采用迭代式的方法進(jìn)行開發(fā)，使軟件一直處于可發(fā)布狀態(tài)。敏捷開發(fā)離不開團(tuán)隊(duì)合作。在任何形式的團(tuán)隊(duì)中，大家都會強(qiáng)調(diào)“teamwork”這個詞，敏捷開發(fā)團(tuán)隊(duì)的一個重要思想其實(shí)也是“teamwork”，我們稱為“協(xié)同”。

在一個Scrum團(tuán)隊(duì)中，有產(chǎn)品設(shè)計(jì)人員、開發(fā)人員、測試人員等，大家協(xié)同工作，以此構(gòu)成了產(chǎn)品的完整生命周期。在大團(tuán)隊(duì)內(nèi)有大團(tuán)隊(duì)的協(xié)同，在小團(tuán)隊(duì)也要有小團(tuán)隊(duì)的協(xié)同。對于開發(fā)團(tuán)隊(duì)來說，當(dāng)其內(nèi)的開發(fā)成員能夠在敏捷上達(dá)成共識，勁往一處使，這樣形成的合力才是最大的，這個團(tuán)隊(duì)才算是開始走向敏捷。在這之后，團(tuán)隊(duì)共同選擇合適的敏捷開發(fā)工具，定義敏捷開發(fā)的流程和規(guī)范，使得敏捷思想能夠真正落入到敏捷實(shí)踐中，從而實(shí)現(xiàn)團(tuán)隊(duì)的敏捷轉(zhuǎn)型，并能夠持續(xù)低成本高效的交付價值。

敏捷開發(fā)團(tuán)隊(duì)的核心思想

早在2009年，F(xiàn)lickr在演講中提出了一個非常重要的理念：“一個中心，兩個基本點(diǎn)”。其中兩個基本點(diǎn)一個是堅(jiān)持協(xié)作化，一個是堅(jiān)持自動化，那么在敏捷開發(fā)中，這兩個理念也同樣適用。協(xié)作化是提高生產(chǎn)力，自動化是提高生產(chǎn)效率，其目標(biāo)都是為了持續(xù)低成本高效交付價值。那么一個開發(fā)團(tuán)隊(duì)在向敏捷轉(zhuǎn)型的時候，重點(diǎn)考慮的就是這兩個點(diǎn)：提高協(xié)作化、提高自動化。

提高協(xié)作化

提高協(xié)作化，需要團(tuán)隊(duì)成員形成協(xié)同的理念，達(dá)成協(xié)同的共識。在傳統(tǒng)DevOps（開發(fā)運(yùn)維一體化）中，把開發(fā)和運(yùn)維的各個階段串通了起來，強(qiáng)調(diào)的是開發(fā)人員和運(yùn)維人員的協(xié)同。在開發(fā)團(tuán)隊(duì)內(nèi)部，需要各個開發(fā)成員之間的協(xié)同。直接給團(tuán)隊(duì)灌輸協(xié)作化的思想是難以改變的，但可以采取以下的一些實(shí)際的措施，去促進(jìn)團(tuán)隊(duì)的協(xié)作化行動。

1、多溝通和交流。在很多公司中，一個開發(fā)團(tuán)隊(duì)往往是坐在一起的，甚至是在一個相對獨(dú)立的會議室中圍成一圈辦公，這個就是一個最佳實(shí)踐。在很多人的傳統(tǒng)印象中，開發(fā)人員比較少言寡語，他們喜歡專注在自己的世界里默默開發(fā)，不太愿意與人交流，而這可能就是阻礙敏捷的一個重要原因。在敏捷中強(qiáng)調(diào)個體與互動，當(dāng)大家能夠坐在一起開發(fā)，能夠face to face的去溝通，就能快速解決很多問題。例如對當(dāng)前的開發(fā)需求理解是否到位？當(dāng)前開發(fā)遇到的Bug如何解決？當(dāng)前的功能是否已經(jīng)有相關(guān)的實(shí)現(xiàn)可以復(fù)用？當(dāng)前自己手頭上的任務(wù)完成是否可以給予其他成員幫助？如果大家都愿意這樣，就能發(fā)揮出一個團(tuán)隊(duì)最大的價值，補(bǔ)齊了可能因木桶效應(yīng)存在的短板，所有開發(fā)人員作為一個整體來交付代碼，大家的知識和能力也得到了共享、提升。在Scrum5個會議中的每日站會，也是為了加強(qiáng)溝通交流，拉齊信息，提出問題，尋求幫助，其本質(zhì)思想是一樣的。而缺乏溝通和交流的團(tuán)隊(duì)，會造成極大的浪費(fèi)，如等待的浪費(fèi)、尋找信息的浪費(fèi)、移交的浪費(fèi)、尤其是對人才的浪費(fèi)（人的價值沒有得到最大的展現(xiàn)和發(fā)揮），對團(tuán)隊(duì)的效率影響是巨大的。

2、多幫助，少抱怨。一個開發(fā)團(tuán)隊(duì)中成員的技術(shù)水平難免參差不齊，作為資深的前輩，要能夠在各個方面給予后輩幫助和支持，而不是對其進(jìn)行責(zé)備或抱怨。只有在團(tuán)隊(duì)中營造了一個互幫互助的積極的氛圍，團(tuán)隊(duì)才能更快進(jìn)步和成長，從而帶來效率的提升。

3、一起討論選出合適的工作軟件，制定合適的規(guī)范。開發(fā)團(tuán)隊(duì)中的每個成員在過往的經(jīng)歷中可能都有自己擅長的軟件和熟悉的規(guī)范。但是在新的團(tuán)隊(duì)中，為了團(tuán)隊(duì)的整體協(xié)作，成員需要放下自己的偏好，共同討論出最適合整個團(tuán)隊(duì)的軟件和規(guī)范，包括IDE、編碼規(guī)范、Git提交規(guī)范、CICD工具、發(fā)布流程規(guī)范等。通過一致的工作軟件和規(guī)范，加強(qiáng)團(tuán)隊(duì)的協(xié)作水平。

4、根據(jù)情況靈活調(diào)整計(jì)劃。在敏捷宣言中有這樣一句話：響應(yīng)變化高于遵循計(jì)劃。在一個開發(fā)團(tuán)隊(duì)中，不可能百分百的按照計(jì)劃進(jìn)行開發(fā)，并且每個開發(fā)人員都有自己擅長的技術(shù)部分和不擅長的技術(shù)部分，這就導(dǎo)致每個開發(fā)人員的開發(fā)效率都是變化的。如果嚴(yán)格百分百按照計(jì)劃排期開發(fā)任務(wù)，那么勢必會導(dǎo)致閑忙不均勻的狀況。而如果要把計(jì)劃先做到完美，那更是一件不太實(shí)際的事并且還要為此付出巨大的精力。所以更好的情況是，開發(fā)人員對PBL有一個初步的任務(wù)排期后，便可進(jìn)行實(shí)際的開發(fā)，也就是“stop starting, start finishing”。在實(shí)際的開發(fā)過程中，根據(jù)任務(wù)的難易程度和自身的情況，靈活應(yīng)對，并且團(tuán)隊(duì)成員之間互相交流幫助，這樣才能最大化團(tuán)隊(duì)的開發(fā)效率。

所以協(xié)作化實(shí)踐起來并不難，關(guān)鍵還是團(tuán)隊(duì)成員能否在協(xié)同上達(dá)成共識，把團(tuán)隊(duì)放在個人之上，有榮辱與共的價值觀和使命感。

提高自動化

如果說協(xié)作化是思想上的轉(zhuǎn)變，那么自動化就是行動上的轉(zhuǎn)變。通常來說軟件開發(fā)過程也是整個產(chǎn)品的交付周期中最漫長的過程，所以其中能用到哪些自動化工具和手段進(jìn)行輔助，如何提高自動化水平尤為關(guān)鍵。從一百天交付一個版本，到一天交付一百個版本，這是一個質(zhì)的飛躍。

其實(shí)，軟件自動化的發(fā)展經(jīng)過了非常久的時間和技術(shù)沉淀。在以前，開發(fā)人員在本地編寫好代碼后，需要手動編譯構(gòu)建，打包成軟件制品，然后通過腳本或者命令的方式部署到測試服務(wù)器上，有時還會因?yàn)榉?wù)器環(huán)境的問題造成部署過程中的各種異常。盡千辛萬苦部署成功后，交給測試人員進(jìn)行專業(yè)化測試。期間測試人員測試出的問題，開發(fā)人員修復(fù)后都要再重復(fù)一次上述的流程，耗時耗力，最后發(fā)現(xiàn)開發(fā)人員只有小部分時間在真正寫代碼，更多時間是在干一些重復(fù)性和繁瑣性的工作。后來Jenkins工具的出現(xiàn)，將持續(xù)集成（CI）和持續(xù)部署（CD）都做成了可自動化執(zhí)行。開發(fā)人員在Jenkins上配置好后，只需要編寫并提交代碼即可，其余的步驟Jenkins都能幫忙處理。在部署環(huán)境上，由于開發(fā)人員是在自己的電腦上編寫程序并調(diào)試運(yùn)行，然后需要發(fā)布到服務(wù)器上，由于環(huán)境不一致導(dǎo)致的問題也總是讓人頭疼，后來出現(xiàn)了Docker和K8S這些技術(shù)，解決了部署運(yùn)維層面的統(tǒng)一和自動化管理問題。而把這些自動化的工具和技術(shù)結(jié)合起來，開發(fā)人員只需要把精力集中在代碼處理上即可，后面的流程都能自動執(zhí)行。

上述自動化技術(shù)更多聚焦于集成和部署層面，但其實(shí)，軟件的自動化不止如此，在開發(fā)層面，其實(shí)也有著很多自動化技術(shù)。B/S架構(gòu)興起后，更多開發(fā)人員開始做Web開發(fā)，但是大家可能要手寫很多Web底層的代碼，這些都是重復(fù)性的并且和業(yè)務(wù)沒有關(guān)系，所以之后便出現(xiàn)了許多Web框架，如Java中的Spring框架、C#中的ASP.Net框架。這些框架把Web底層的技術(shù)進(jìn)行了封裝，通過一些簡單的配置即可實(shí)現(xiàn)很多底層邏輯的自動實(shí)現(xiàn)。此外，現(xiàn)在的IDE越來越先進(jìn)和智能，我們通過很多插件，在開發(fā)的過程中能夠自動幫我們生成代碼，自動幫我們檢查代碼和糾錯等等。

所以這些自動化技術(shù)、工具、框架的出現(xiàn)，讓開發(fā)人員能夠更聚焦于業(yè)務(wù)的實(shí)現(xiàn)，減輕各種復(fù)雜繁瑣的工作，從而提升了交付價值的效率。而且隨著大數(shù)據(jù)、AI技術(shù)的愈發(fā)成熟，人們不再滿足于自動化，而會向著更高層次的智能化前進(jìn)。對于開發(fā)人員來說，如果能夠把一些非核心功能的代碼交給AI來實(shí)現(xiàn)，那無疑是生產(chǎn)效率的進(jìn)一步飛躍。

協(xié)作化和自動化的結(jié)合

協(xié)作化和自動化是敏捷開發(fā)團(tuán)隊(duì)轉(zhuǎn)型的兩大重點(diǎn)，并且不能只看其一，而要將其有機(jī)的融合。

我曾有過一段項(xiàng)目經(jīng)歷，雖然項(xiàng)目團(tuán)隊(duì)也是按照Scrum的方式進(jìn)行組建的，每天都會開每日站會來拉齊信息、同步工作進(jìn)度，開發(fā)過程中的各種CICD自動化工具也都有使用上，但是整個研發(fā)效能還是上不去，其實(shí)就是協(xié)作化和自動化沒有很好的結(jié)合起來。每個人都盯著分配給自己的那些任務(wù)，遇到困難時不會主動去進(jìn)行溝通，而是自己悶著解決，這樣就拉低了整個團(tuán)隊(duì)的進(jìn)度。代碼提交的時候缺乏評審機(jī)制，所有人都想著趕緊把自己的代碼先提上去，因?yàn)橥硖岽a的人要解決沖突這種煩心事，誰負(fù)責(zé)的功能模塊出問題就誰解決，沒有一種互相協(xié)作的氛圍。表面上看這種好像是有規(guī)章有制度的形式，但其實(shí)卻背離了敏捷的思想。

所以當(dāng)我們基于敏捷的理念去做開發(fā)時，大家都會用自動化工具是一方面，更重要一方面是，大家都會用自動化工具進(jìn)行協(xié)作開發(fā)。

敏捷開發(fā)的展望

敏捷開發(fā)的演進(jìn)是一個過程，并且沒有終點(diǎn)，它會永遠(yuǎn)朝著一個目標(biāo)前進(jìn)：讓人的價值最大化。無論是團(tuán)隊(duì)協(xié)同，還是借助各種自動化工具輔助，本質(zhì)上都是在不斷地放大人的價值。隨著開發(fā)團(tuán)隊(duì)逐漸走向敏捷，也許他們每天產(chǎn)生的代碼會減少，但每天產(chǎn)生的價值一定會增加。

與其臨淵羨魚，不如退而結(jié)網(wǎng)，用力擁抱夢想，從《研發(fā)效能（DevOps)工程師》認(rèn)證開始！

7月20日開班，掃描下方海報二維碼，立即報名，考取職業(yè)技術(shù)證書，擴(kuò)展職業(yè)發(fā)展與晉升之路！

關(guān)鍵詞：