研發效能認證學員作品：談敏捷開發團隊轉型中的協作化與自動化丨IDCF
時間：2023-06-24 04:31:57
星標關注，第一時間獲取IDCF社區資訊，了解活動動態，福利多多不容錯過！
作者：
楊凌宇（現就職中國電信研究院）
(資料圖)
研發效能（DevOps）工程師認證學員
前言
在如今軟件開發流程和工具愈發成熟的現狀下，敏捷似乎是所有軟件產品團隊前進的目標。很多團隊都宣稱自己是敏捷團隊，但實際上，他們更多是在一定程度上達到了敏捷。我們在敏捷實踐的過程中，總會與理想中的情況存在差距，所以我們更多要思考的不是怎樣徹底的達到敏捷，而是在當前的實際情況下，怎樣更好的運用敏捷的思想去改進。敏捷涵蓋的范圍非常廣，從需求收集，到產品設計、開發交付、測試安全、運維保障等一系列流程，都可以運用敏捷的思想。其中開發交付的過程，是真正建設出一個產品的過程，我作為一名一線的開發人員，也更想談一談在開發過程中，以及對于開發團隊來說，如何進行敏捷的轉型。
何為敏捷開發
敏捷開發是以用戶的需求為核心，把大的需求進行拆分，采用迭代式的方法進行開發，使軟件一直處于可發布狀態。敏捷開發離不開團隊合作。在任何形式的團隊中，大家都會強調“teamwork”這個詞，敏捷開發團隊的一個重要思想其實也是“teamwork”，我們稱為“協同”。
在一個Scrum團隊中，有產品設計人員、開發人員、測試人員等，大家協同工作，以此構成了產品的完整生命周期。在大團隊內有大團隊的協同，在小團隊也要有小團隊的協同。對于開發團隊來說，當其內的開發成員能夠在敏捷上達成共識，勁往一處使，這樣形成的合力才是最大的，這個團隊才算是開始走向敏捷。在這之后，團隊共同選擇合適的敏捷開發工具，定義敏捷開發的流程和規范，使得敏捷思想能夠真正落入到敏捷實踐中，從而實現團隊的敏捷轉型，并能夠持續低成本高效的交付價值。
敏捷開發團隊的核心思想
早在2009年，Flickr在演講中提出了一個非常重要的理念：“一個中心，兩個基本點”。其中兩個基本點一個是堅持協作化，一個是堅持自動化，那么在敏捷開發中，這兩個理念也同樣適用。協作化是提高生產力，自動化是提高生產效率，其目標都是為了持續低成本高效交付價值。那么一個開發團隊在向敏捷轉型的時候，重點考慮的就是這兩個點：提高協作化、提高自動化。
提高協作化
提高協作化，需要團隊成員形成協同的理念，達成協同的共識。在傳統DevOps（開發運維一體化）中，把開發和運維的各個階段串通了起來，強調的是開發人員和運維人員的協同。在開發團隊內部，需要各個開發成員之間的協同。直接給團隊灌輸協作化的思想是難以改變的，但可以采取以下的一些實際的措施，去促進團隊的協作化行動。
1、多溝通和交流。在很多公司中，一個開發團隊往往是坐在一起的，甚至是在一個相對獨立的會議室中圍成一圈辦公，這個就是一個最佳實踐。在很多人的傳統印象中，開發人員比較少言寡語，他們喜歡專注在自己的世界里默默開發，不太愿意與人交流，而這可能就是阻礙敏捷的一個重要原因。在敏捷中強調個體與互動，當大家能夠坐在一起開發，能夠face to face的去溝通，就能快速解決很多問題。例如對當前的開發需求理解是否到位？當前開發遇到的Bug如何解決？當前的功能是否已經有相關的實現可以復用？當前自己手頭上的任務完成是否可以給予其他成員幫助？如果大家都愿意這樣，就能發揮出一個團隊最大的價值，補齊了可能因木桶效應存在的短板，所有開發人員作為一個整體來交付代碼，大家的知識和能力也得到了共享、提升。在Scrum5個會議中的每日站會，也是為了加強溝通交流，拉齊信息，提出問題，尋求幫助，其本質思想是一樣的。而缺乏溝通和交流的團隊，會造成極大的浪費，如等待的浪費、尋找信息的浪費、移交的浪費、尤其是對人才的浪費（人的價值沒有得到最大的展現和發揮），對團隊的效率影響是巨大的。
2、多幫助，少抱怨。一個開發團隊中成員的技術水平難免參差不齊，作為資深的前輩，要能夠在各個方面給予后輩幫助和支持，而不是對其進行責備或抱怨。只有在團隊中營造了一個互幫互助的積極的氛圍，團隊才能更快進步和成長，從而帶來效率的提升。
3、一起討論選出合適的工作軟件，制定合適的規范。開發團隊中的每個成員在過往的經歷中可能都有自己擅長的軟件和熟悉的規范。但是在新的團隊中，為了團隊的整體協作，成員需要放下自己的偏好，共同討論出最適合整個團隊的軟件和規范，包括IDE、編碼規范、Git提交規范、CICD工具、發布流程規范等。通過一致的工作軟件和規范，加強團隊的協作水平。
4、根據情況靈活調整計劃。在敏捷宣言中有這樣一句話：響應變化高于遵循計劃。在一個開發團隊中，不可能百分百的按照計劃進行開發，并且每個開發人員都有自己擅長的技術部分和不擅長的技術部分，這就導致每個開發人員的開發效率都是變化的。如果嚴格百分百按照計劃排期開發任務，那么勢必會導致閑忙不均勻的狀況。而如果要把計劃先做到完美，那更是一件不太實際的事并且還要為此付出巨大的精力。所以更好的情況是，開發人員對PBL有一個初步的任務排期后，便可進行實際的開發，也就是“stop starting, start finishing”。在實際的開發過程中，根據任務的難易程度和自身的情況，靈活應對，并且團隊成員之間互相交流幫助，這樣才能最大化團隊的開發效率。
所以協作化實踐起來并不難，關鍵還是團隊成員能否在協同上達成共識，把團隊放在個人之上，有榮辱與共的價值觀和使命感。
提高自動化
如果說協作化是思想上的轉變，那么自動化就是行動上的轉變。通常來說軟件開發過程也是整個產品的交付周期中最漫長的過程，所以其中能用到哪些自動化工具和手段進行輔助，如何提高自動化水平尤為關鍵。從一百天交付一個版本，到一天交付一百個版本，這是一個質的飛躍。
其實，軟件自動化的發展經過了非常久的時間和技術沉淀。在以前，開發人員在本地編寫好代碼后，需要手動編譯構建，打包成軟件制品，然后通過腳本或者命令的方式部署到測試服務器上，有時還會因為服務器環境的問題造成部署過程中的各種異常。盡千辛萬苦部署成功后，交給測試人員進行專業化測試。期間測試人員測試出的問題，開發人員修復后都要再重復一次上述的流程，耗時耗力，最后發現開發人員只有小部分時間在真正寫代碼，更多時間是在干一些重復性和繁瑣性的工作。后來Jenkins工具的出現，將持續集成（CI）和持續部署（CD）都做成了可自動化執行。開發人員在Jenkins上配置好后，只需要編寫并提交代碼即可，其余的步驟Jenkins都能幫忙處理。在部署環境上，由于開發人員是在自己的電腦上編寫程序并調試運行，然后需要發布到服務器上，由于環境不一致導致的問題也總是讓人頭疼，后來出現了Docker和K8S這些技術，解決了部署運維層面的統一和自動化管理問題。而把這些自動化的工具和技術結合起來，開發人員只需要把精力集中在代碼處理上即可，后面的流程都能自動執行。
上述自動化技術更多聚焦于集成和部署層面，但其實，軟件的自動化不止如此，在開發層面，其實也有著很多自動化技術。B/S架構興起后，更多開發人員開始做Web開發，但是大家可能要手寫很多Web底層的代碼，這些都是重復性的并且和業務沒有關系，所以之后便出現了許多Web框架，如Java中的Spring框架、C#中的ASP.Net框架。這些框架把Web底層的技術進行了封裝，通過一些簡單的配置即可實現很多底層邏輯的自動實現。此外，現在的IDE越來越先進和智能，我們通過很多插件，在開發的過程中能夠自動幫我們生成代碼，自動幫我們檢查代碼和糾錯等等。
所以這些自動化技術、工具、框架的出現，讓開發人員能夠更聚焦于業務的實現，減輕各種復雜繁瑣的工作，從而提升了交付價值的效率。而且隨著大數據、AI技術的愈發成熟，人們不再滿足于自動化，而會向著更高層次的智能化前進。對于開發人員來說，如果能夠把一些非核心功能的代碼交給AI來實現，那無疑是生產效率的進一步飛躍。
協作化和自動化的結合
協作化和自動化是敏捷開發團隊轉型的兩大重點，并且不能只看其一，而要將其有機的融合。
我曾有過一段項目經歷，雖然項目團隊也是按照Scrum的方式進行組建的，每天都會開每日站會來拉齊信息、同步工作進度，開發過程中的各種CICD自動化工具也都有使用上，但是整個研發效能還是上不去，其實就是協作化和自動化沒有很好的結合起來。每個人都盯著分配給自己的那些任務，遇到困難時不會主動去進行溝通，而是自己悶著解決，這樣就拉低了整個團隊的進度。代碼提交的時候缺乏評審機制，所有人都想著趕緊把自己的代碼先提上去，因為晚提代碼的人要解決沖突這種煩心事，誰負責的功能模塊出問題就誰解決，沒有一種互相協作的氛圍。表面上看這種好像是有規章有制度的形式，但其實卻背離了敏捷的思想。
所以當我們基于敏捷的理念去做開發時，大家都會用自動化工具是一方面，更重要一方面是，大家都會用自動化工具進行協作開發。
敏捷開發的展望
敏捷開發的演進是一個過程，并且沒有終點，它會永遠朝著一個目標前進：讓人的價值最大化。無論是團隊協同，還是借助各種自動化工具輔助，本質上都是在不斷地放大人的價值。隨著開發團隊逐漸走向敏捷，也許他們每天產生的代碼會減少，但每天產生的價值一定會增加。
與其臨淵羨魚，不如退而結網，用力擁抱夢想，從《研發效能（DevOps)工程師》認證開始！
7月20日開班，掃描下方海報二維碼，立即報名，考取職業技術證書，擴展職業發展與晉升之路！
