貫策目標
其實在運作的過程中，我們會以責任共擔、質量導向來當作我們要建立文化的價值觀，所有的行動與動作都會圍繞著這兩個觀念進行與展開，甚至也可以提升為企業的使命。

從 0 到 0.1 ( 2-3人or 都沒碰過敏捷)

在這個階段中，你可能是團隊中技術最資深的，很多問題可能都需要你解決，所以用雲服務是當務之急，你絕對沒有時間再去管理自建工具。

以傳統方式來說，通常都會先出 SA、SD，文件，但效果來說並不好，這種文件難以根據需求與進度來調整與變動，尤其在現今軟體設計架構下，並不好去配合敏捷開發，但並不是說他不重要，這些文件應該參與在 UX 設計下的需求訪談、Flow、wireframe、prototype，這邊後續會以其他文章的形式出現，今天會先專注在開發面的 DevOps、SRE。

GitOps

這個項目中，我們在乎的是先讓團隊成員熟悉這種開發流程，透過版本管理工具Git 來解決持續集成(CI)的問題。我們選用的服務是 [Bitbucket]。在第一個小階段我們使用的卡片服務是 Trello 對於剛有敏捷觀念的開發這來說，先上手這兩個東西應該是很好的切入點。

卡片中的內容除了需要描述用戶故事之外，可能也還需要提供他可能的撰寫邏輯，否則很可能會有看著卡片發呆的情況發生。

持續集成的部分一定要告訴開發者，他要切分支出來開發。這階段可以不強制開功能分支來開發（時程、交付速度都要考慮），但一定要養成 PR、Code Review 之後，並入主分支的習慣，即使是主推人也要執行。

注意，你在執行任何過程時，所認為的這次算了沒差，下次記得就好，都會降低一點你的成功率。

ChatOps

我們希望團隊中所有人的變動與更改，都被其他團隊成員所關心，個人認為這是 DevOps 有成果很重要的因素，當團隊成為互相關心彼此做的事情、了解彼此做的事情，這時候效益就會慢慢發酵，大家的多點連線漸漸成為了一個結構體，對於專案會顯得更扎實。這個項目中我們引入了Slack，並且將上面的 [Bitbucket] 與 Trello 綁定其中，當有更新時，自動發消息在 Slack中。

挑戰

剛引入這些所謂敏捷開發的工具時，沒有經驗或者被舊經驗所困住的開發夥伴們，一定都會有點茫然，而且主推者有可能很難去推行這流程，因為大家不習慣。這個階段要培養的一定是團隊成員彼此的關心與想要利用這套工具的誘因。這邊可以分享幾個經驗給大家。

• 不厭其煩的提醒需使用
  • 比方說團隊成員完成了某張卡片，但卻沒有更新狀態時，一定要很明確的說「那記得在拖曳一下卡片讓大家知道」。
• 遊戲化
  • 在卡片上分配點數，當一周衝刺完了之後，大家可以看到自己得到多少點數
  • 這個點數可以設計在企業內部可以提供兌換，或者獎勵，目前打算配合企業內部系統來達成（這個我們也尚未達到，關於遊戲化設計工作，可以參考[遊戲化實戰全書]）
• 密集的短暫開會
  • 注意是密集的短暫，比如說先施行站立會議，因為這有助於團隊成員彼此縮短距離。有時候一個成員描述完之後，也可以問一下其他成員，他說了說了什麼，理解嗎，有什麼建議，一開始會很扭捏，但是習慣了就好，現階段最重要的是習慣。
• 提供安全的心理支持
  • 這個過程中需要大量的向團隊成員提供安全的心理支持，可以讓他們覺得天塌下來有你扛等等，這個初期的階段需要安全感
• 剛學會開發的新手
  • 如果是剛會開發的新手，這邊絕對要再更謹慎，這個階段的新手比較適合指令式的工作，可以觀察三個月，若三個月後他還是無法自行解決問題、無法自學、無法上手新概念，這時候要考慮轉崗或放棄。
• 概念演說、技術指導不能少
  • 在這過程中一定要常常讓大家了解敏捷是什麼、多實作與練習
  • 定期的宣導新的概念與學習目標，可以用每週一概念循序漸進地讓團隊成員了解。

現階段架構展覽

(img)
(img)
這個部分可以先不花心力處理單元測試問題，我們都知道需要寫單元測試，但實際上他需要更長時間的習慣養成。

這個階段的金錢上成本可以說幾乎為零，最大的成本是要讓團隊成員熟悉與了解這個過程與項目（這成本很巨大），這個期間應該會持續 3-6個月，根據成員的熟悉度而不同，在這期間如果能發現團隊成員對於敏捷的概念熟悉或學習很快，對於下一階對是很有幫助的。你可能會在這階段灰心喪志，這個過程是最艱苦與困難的，但千萬不要放棄。（以我們的經驗來說大約持續了 4 個月才免強進入下個階段）

總結

今天跟大家分析與分享了 0 到 0.1 的 DevOps 之路，希望對你有幫助！