為了精準估算,你必須付出什麼代價?

開場對話

開場對話

研發團隊,常會被問到一個問題:

「請問一下,這個A功能,大概要多久才能完成?」

這個問題,不會因為你跑的是敏捷,就自動免疫。那麼,身為經過敏捷思維洗禮的人,該如何做出合宜的應對?

我在 Agile Tour Kaohsiung 2018 開辦一場 2.5 小時的工作坊,帶領大家親自體驗這個議題。

不過,這個題材的背後,其實還有三段故事。

故事,要從一年半前講起。

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

改革,很不容易;摧毀改革,卻很簡單。知名的改革框架,莫不注重改革的整合與固化。 敏捷亦然。 敏捷三叔公 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,收穫頗大。

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