敏捷與DevOps

這次訪談的對象是在中國設了研發單位的香港公司，由於 Covid-19 的影響使得這個年紀尚輕但又稍具規模的研發單位飽受困擾。該公司原先並未有明確的協作工具。成員之間的溝通靠的是線上會議和電子郵件的往來，但由於並沒有具體存放討論內容或思考內容的工具，彼此之間的知識交流也就靠著有有一搭沒一搭的零星紀錄來達成，而誤會和麻煩也就因此而起，比方說： 工作換手困難； 權責難清； 理解時間長； 資訊遺失。 即便這個新單位一開始就以敏捷的方式配置一切，最終迎接他們的就只剩下爭吵和無法達成目標。為此，他們採用了一個需求追蹤系統，其實就是自建了一個開源的知識管理工具，讓所有的人將各自的想法和平時的討論紀錄下來。這樣簡單的做法改善了他們的討論方式和協作的效率。 關鍵的改善往往勝過千萬個煙火式的實務做法，基於需求的單純解決方案，反而更有力量。當我們面對遠距協作需求時，有兩個很大的要點： 資訊共享； 體諒他人。 資訊驅動著人之間的討論。如果沒有一個共有而且即時的管道，人和人之間的討論將單純的基於假設和主觀認為。這樣的情境就算有爭吵也不會是太意外的狀況。不過，當回到了遠距，直覺上可能覺得大家會偷懶，但實際上大家更可能不知不覺地模糊了工作和生活的邊線，進而導致過勞。 因此，當團隊需要進行遠距協作，務必記得下列幾點： 提供便捷取得必要資訊的方式； 建立彼此之間的即時溝通平台； 尊重隱私並且建立溝通和協作原則； 在限制下，提供最多的團隊實體交流機會； 為他人設想。 當工作自由和生活自由重疊時，有時會造就出的不是更自由，而是更不自由且透支的狀態，而且遠距所造成的資訊不連續更是讓效率低落的元兇。此次的訪談對象透過簡單的工具（基本上沒做任何客製或特別技巧）解決了團隊工作推進的問題，並且降低了爭吵的狀況。這便是專注瓶頸解決問題的重要之處。不過，在訪談過程中，可以觀察到由於長時間遠距而加劇穀倉問題。因為他們原先透過明確職責分配和透過工具指派工作的做法，使得跨域成員之間的交流低落。或許他們接下來應該專注的是讓成員意識到跨域交流和技能學習，以及透過建立通用詞語交流需求的技巧！為此，我們還在與對方積極地保持聯絡，也期待能夠協助他們解決跨職能團隊建立和協作的問題。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.

今年有許多機會遇到外包許多 IT 研發人力的組織，組織規模不能說不大，但就是大到人不夠用。當內部開發人力不足時，很容易就遭遇到對技術缺乏良好掌控權和外包的系統理解不夠，甚至是對於其中程式碼的管理有些薄弱。當組織高速成長時，新系統和接連不斷的大功能滿足了組織實力展現需求和市場競爭力的需求，但當外部環境有些動搖時，組織開始希望有更好的成本效率，就不得不回頭檢討昔日的大量外包作為。不過，首要問題便會出在甲乙方交付模式與產出的管理方式了！此時，主事者會很直覺地想到需要開始收回對於產出的管理能力，而開始放大對於「工具」的渴求，彷彿有種工具能夠像神兵利器般解決一切的問題，重點是還很有成效，但事情真能這麼簡單嗎？ 此次的訪談剛好背景也是如此。受訪的組織為了更有效地管理產出，內部研發單位基於開源工具構建了一個管理平台，並且希望組織內的成員和外包商能夠全面運用，以便更好地管理產出和提升效率，但結果是自動化流水線成了上線前的最後一站測試，而整個管理平台最終也只是一個程式碼存放地，持續整合的概念說實在也談不上。受訪者委婉著說道「程式碼的確重回管控，但平台使用率不高，有沒有平台似乎也沒未工程師帶來太多誘因。」訪談過程中既能感受到他對於平台的用心和自信，但同時也感受到他的無奈。 工具對於日常操作的影響 「工具」有著較為具體的形象，既容易想像也能摸得著，但回到軟體開發或者是日常操作，終究得回到人而非單純的工具。在組織中，工具的確為每個成員帶來方便，但這些工具都會成為日常操作與營運的一部分，進而成為習慣。當引進任何工具或者平台時，除了工具的功能外，更應該考量的是工具對於日常操作的影響，比方說： 工具對於原來作法的衝擊； 工具是否對於原來流程產生影響； 組織成員對於工具的陌生感； 工具是否能夠進行客製，以便合於當下所需。 導入新工具前組織應先考量的事 上述都會是工具重要的考量，而非有了工具就能夠改善一切。有時強硬的導入工具反而會造成雙軌做法，徒增組織成員的痛苦。對於外包廠商就更是如此了，畢竟對於他們來說，更重要的是恰如其分的節約工時和不要做出越矩的事情。因此，對於正苦於如何導入新工具的組織來說，有以下的建議： 除了工具，請在意目前的做法； 提供人員足夠的培訓； 透明化目的與工具選擇的原因； 挑選正確的導入時間； 注意工具的必要性。切入重點，而非只為形式美。 與外包商的協作模式 當然對於有眾多外包商的組織來說，如果想要進一步推動外包商，更需要在意： 權限管理； 必要資訊的透明化； 增進外包人員的心理安全，並且引導他們提出改善措施 逐步增加外包人員的認同感和統一化組織價值觀。 訪談的最後，受訪者表示他們的平台在今年已經完備，目前重心就是推廣該平台。期盼他們能有好的結果，CPHT 也會繼續跟蹤後續的狀況，並且提供必要的協助，以便讓一切好事真的都會發生。

前言 GitLab CI/CD 的 job 如何獲取程式碼庫時提供三種策略，分別為： clone fetch none 在比較這三個策略的差異之前，我們需要先了解 Executor 主要的初始作業與結束作業是怎麼運作的。 Executor 初始作業 我們先以一個基礎的 GitLab CI/CD 範例來看，該範例將會運行一個 build job： stages: - build build: stage: build script: - echo "building.

這次訪談對象是來自一間提供金融交易數位服務公司 PMO 的一位資深管理人員。從訪談間可以了解到該組織的管理者對於時間調配和公司規則都是帶頭施行，以身作則，因此公司在相關營運流程上的管理不僅嚴謹也有效率，更重要的是員工對於這樣的文化充滿了自信。「我相信能做到如此的業界同行也是相當少數。」受訪者如此地跟我說道。 由於此次的訪談仍然是和敏捷有關，因此在圍繞背景資訊閒聊一陣後，便提到敏捷。讓我意外的是對方表示「所採用的實務做法是否為敏捷，並非他們所在意的。他們只是因為需要解決實際問題，而採用了一些實務做法，重要的是解決問題，而非是否採用了哪個框架或做法。若採用的實務做法恰為敏捷裡的實務做法，那也只是剛好而已。」這樣的說法相較於敏捷到只剩下做法的狀況來說，顯然還算不錯。 敏捷性的追求沒有絕對的套路 敏捷性的追求，不會有絕對要如何遵從的套路，準則抓的對，持續改善漸進改變也是很好的過程，甚至能夠讓敏捷變得更加有效。只不過應該要注意的是實務做法之間往往彼此有相關聯性。單獨採用某個實務做法，有時並不能最大化實務做法帶來的好處，還是要回到目的、資源和風險三方面來了解自己最適合的方式是什麼。 接近訪談的尾聲時，意外地聽到了受訪者的另一個焦慮，那就是該如何進行規模化的敏捷。對於一個並不矜持於敏捷，只追求務實解決問題的組織來說，到底他們正面對怎樣的狀況，而使得所提的疑問有種越級打怪的感覺，或許是因為受訪者正在面對一個更加緊迫的市場環境，使得他們不得不思考如何讓專案和產品能夠更好的面對市場變化，從而達到降本增效的效果。 關注實務做法間的連動關係 面對此次的訪談，不得不說面對危機和競爭，敏捷是企業會想到的好解方，但敏捷的落地需要更為系統性的規劃才能夠獲得明確的效益。受訪者應該思考的是： 此次對於規模化敏捷的企求想達成的目的是什麼？ 過往較為嚴格且緊迫的時間管理方式，是否會讓面對改變的組織成員難以消化“規模化敏捷”的好處？ 盤點當前的作法和敏捷之間的關聯性來了解自己的情境和落差，以便知道“規模化敏捷”的內容與方向。 工程所體現的系統性，並非單純地展現在單一實務做法上。相同目標而在不同面相上的實務做法往往會有互相連動的關係，進而成為一種解決目標的系統性作法。當期望將此類做法導入企業，尤其是全面導入時，更應該關注既有做法、想解決的問題和想導入的做法彼此之間的關係，並且階段性的導入，畢竟羅馬不是一天造成的。 – 如果你也正在思考如何規模化敏捷並且為組織帶來改變，CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro