在昨天的文章提到了關於Jira和GitHub的整合案例，那再拉回到整個評估解決方案的角度可以提出幾個問題(針對版本控制的部分)，例如為什麼要使用GitHub作為版本控制的工具、除了版本控制之外還有考慮到哪一些其他的因素(ex : 現有工具轉換上的考量、延伸服務使用的考量或者是工具市占率的考量)。

什麼是版本控制平台？

在進入評估前先複習一下版本控制是什麼，版本控制平台是一種讓開發者協作、管理、追蹤、審核和部署程式碼的工具(也可以稱之為服務)。這些平台可以提高開發效率、減少錯誤、保護智慧財產權和促進團隊合作。版本控制平台可以分為集中式和分散式：

• 集中式版本控制：這種類型的版本控制有一個伺服器來管理所有版本的檔案，而許多用戶端會連到這台伺服器取出檔案來使用。所有的檔案版本都儲存在中央伺服器上，且需要連接到中央伺服器才能提交更新或取得更新。例如：SVN。

• 分散式版本控制：用戶端不只取出最新的檔案快照，還把整個倉儲做個鏡像。每個用戶端都有完整的版本歷史，作為倉儲的鏡像，且可以與多個遠端倉儲互動，並支援多種工作流程。例如：Git、GitHub、GitLab、Bitbucket。

此外版本控制平台還可以分為雲端、本地、開源、商業等不同的類型和特性，接著從上述的兩種版本控制說明彙整成表格來做對照。

分散式與集中式版本控制的差異

資訊基於 Git 官方文件 的內容。

如何選擇一個適合的版本控制平台？

選擇和導入一個適合的版本控制平台並不是一件容易的事情，中間需要考慮多個因素像是成本、功能、安全性、可用性、相容性和學習曲線，為了更好地評估版本控制平台的導入，可以從一個更高的維度來看待這個問題，例如視版本控制平台視為一種組織文化的變革，而不僅僅是一種技術的選擇，接著從以下幾個方面來分析和評估版本控制平台的導入：

版本控制平台作為組織文化的變革

1. 目標
   明確界定導入版本控制平台的核心目的並且考慮以下問題：

• 希望提升哪些方面，如開發速度、品質或安全性？
• 是否期望增強團隊或跨部門的協作?
• 是否需要符合特定的行業或法規標準? (ex : iso27001)

這些目標可以引導選擇和評估合適的版本控制平台。

2. 現狀分析
   客觀評估當前的開發流程和公司文化思考以下幾個問題：

• 目前使用的版本控制工具是什麼？其優缺點為何？
• 開發團隊的規模和他們對版本控制的熟悉程度如何？
• 開發環境的複雜性有多高？

這將幫助我們識別導入版本控制平台時可能遇到的挑戰。

3. 策略制定
   制定一套實際且具體的導入計畫考慮以下要點：

• 選擇的版本控制平台有哪些特色和優勢？
• 如何配置、部署、測試和驗證該平台？
• 如何培訓開發者以確保他們能有效使用？
• 如何持續監控和評估其效果？

4. 執行計畫
   與各方利益相關者溝通，確保計畫的順利進行。注意以下階段：

• 準備：在導入前，確保有足夠的資源和權限與備份現有資料，並向相關人員解釋導入的好處和流程。
• 配置：安裝和設定平台，並確保其安全性、可用性和效能。
• 測試：驗證平台功能，評估其對開發流程的影響，並根據反饋進行調整。
• 培訓：提供教學資源鼓勵開發者參與培訓，並建立溝通的管道。

上述的各個面向的評估資訊接著透過心智圖呈現

結論

從剛剛的例子中可以看到在做決策或計劃過程中，需要考慮的因素和面向是非常多且複雜，但可以掌握幾個核心原則就能夠更有效地進行(個人的經驗)。

首先換位思考是一個非常有價值的技巧，因為從發起需求的使用者的角度去看待問題，可以更容易的理解他們的需求和期望，不僅僅只是幫助蒐集更有價值的資訊，還可以確保整體的解決方案更加貼近使用者的真實需求。

另外有效的溝通和交流是成功的關鍵，在與使用者或團隊成員訪談時，正確的引導方式可以幫助確保討論保持在正軌，並且可以獲得最有價值的資訊。

最後可以延伸思考一下，當接收到這個需求和計畫的時候你/妳會怎麼做?