The series of “Essence of Scrum” articles tries to identify the essence of Scrum elements (e.g., events and artifacts) so that:
the core can be understood without much effort.
the feeling overwhelmed can be reduced.
the gradual adoption is more possible.
My selection and elaboration of “essence” is very subjective. Follow the advice at your own risk.
今年一月，換到一家以 Go 為主力語言的公司。
習慣了 Java 紀律，一碰到 Go 的自由奔放，不禁想尋求一些 best practices 與 patterns。
以前我曾蒐集過一份 Go Best Practices 清單。浸潤 Go 半年後，再回頭看這些內容，當初不甚明瞭之處，竟然也懂了許多。便想重新整理一次，並加上個人的短評。
我算是 Travis CI 的老用戶了。
以前 Travis CI 很慢，對 Docker 不友善，又很難 debug，讓我一度將重心轉移到後起之秀 CircleCI。後來 Travis CI 向 CircleCI 看齊，讓我們能夠 ssh 進去虛擬機 debug，兩者的差距已經逐漸縮小。所以，我自己的重要專案，總是盡量同時掛上 Travis CI 及 CircleCI，讓 CI pipeline 的核心在某種程度上也能盡量 reproducible 不被 lock in。
Travis CI 也提供許多常見的程式語言及伺服器軟體，以方便做 CI 測試。我個人的習慣是，盡量不去使用這些功能，而是直接用 Docker 或 Docker Compose 來組裝，以降低對於 Travis CI 的依賴（尤其我還要兼顧 CircleCI）。
不過，如果是與人合作的專案，就得顧及其他人的習慣。我在使用 Travis CI 提供的伺服器軟體 Postgres、Cassandra、RabbitMQ 時，遇到一些雷，特地記錄下來，供有類似困擾的人參考。
在導入 Scrum 時，我偏好實體看板。
實體看板容易 zoom in/out，利於適時切換俯瞰與細節視角，不需過度的數字管理。
實體看板的空間共時性，容易塑造團隊的一體感。
實體看板彈性大，能以最小成本，讓團隊在敏捷路上不斷嘗試與調整。