改變/改革:流程與衡量指標

改革,很不容易;摧毀改革,卻很簡單。知名的改革框架,莫不注重改革的整合與固化。 敏捷亦然。 敏捷三叔公 David Ko 在 Scrum 社群裡轉貼了一篇文章,一則可悲的故

Scrum 沒有明說的事:休耕期

Scrum 的官方白皮書 The Scrum Guide 非常輕薄短小(像 Nov 2017 版只有 19 頁),它的理念是:只制定最核心的原則、價值、角色、活動、產出物,其餘的則交給團隊根據經驗主義 1 去調適出最適合自己的細節。

想當然爾,有很多事,Scrum 並沒有明說。

那麼,沒有明說的事,就不需要做、就不能做了嗎?做了,就違反 Scrum 嗎?

這是許多奉 The Scrum Guide 為圭臬的人,常有的盲點。

「從 Ops 角度看 DevOps」的感想

在台灣(或許在其他地方也是),DevOps 的話語權,很大幅度都被 Dev 一方把持。我們很少聽到 Ops 一方的說法。

成功的改革,需要兼顧各方利益者的需求及痛點。隨著 DevOps 守備範圍日益擴大,這種失衡狀態必須改變。

今晚參加 DevOps Taiwan 社群舉辦的講座:【從 Ops 角度看 DevOps】,聽聽胡士亮 (Robert Hu) 從正統 Ops 角度來詮釋 DevOps,甚至 OpsDev,收穫頗大。

聽知識,聽心得,也聽熱情與願景。

DevOps 的價值與指標

看完〈敏捷的價值與指標〉之後,很自然的會進一步追問:「那麼,什麼才是 DevOps 圈子所認定的價值,以及對應的指標,尤其是領先指標?」 這問題其實比較容易