軟體架構・絮語

Automate everything, make life easier!

引導活動,請注意「不注意視盲」

越來越慶幸,當初選擇深化引導技能的第一步,是從心理學著手。從此,走上一條自己也料想不到的蹊徑。(這段往事,詳見 1 及 2...

READ MORE

User story 的 "user" 是什麼?"story" 又是什麼?

同事面對看板上面的 user story 卡片,提出一個疑問: 現在愈來愈像是把 spec 或要做的事硬寫成 story。但 story 失去本意的話,好像也不用寫 story~~直接寫成待辨事項,是不是對大家來說更清楚?現在有點是要寫成待辨事項的 story 吶~~我覺得怪怪的 這問題,其實還可再細分成三件事: User story 的 "user" 是什麼? User story 的敘事句,需要有固定格式嗎? User story 的 "story" 是什麼? 以下就來一一探討。 User story 的 "user"...

READ MORE

以 impact mapping 進行參與式決策

我在半年前〈以談判角度看 Sprint Planning〉一文曾提過: 只要是我有權主導的 Sprint Planning,都會先花些時間請 PO 重新展開 Impact Mapping 及 Scaling Lean 的內容,尤其是還沒有穩定扎實 Product Backlog Refinement 的團隊。 欲達我心目中的理想境界,需要先讓團隊成員練習一兩次 impact mapping,才能在正式上戰場時,更有效產出高品質的 impact map。 就連 PO 本身亦然。畢竟,許多沒有「參與式決策」習慣的 PO,對於這類方法,常以自身專業角度提出質疑: --- Quote:...

READ MORE

咬文嚼字的必要性

前同事 Peter Su 提出他在荷蘭工作的觀察: 貼文短短,卻已提到幾則重點: 準則 思考框架 句型 參考範例 儘管自己沒有在國外工作過,但成天浸潤在外文書籍中,也感同身受。 關於「思考框架」這一點,我在〈思考框架的刻意練習〉一文提過自己的看法。現在這篇文章,我想繼續談談「句型」這一點。 ◉ 用句型輔助思考 歐美系的「思考框架」或「準則」,很喜歡用句型式的步驟來引導思考。 譬如說,在軟體研發領域常用的 user story,本身就有一個經典句型: As a <type of user>, I want <some goal>...

READ MORE

2017 個人回顧

又到了年終,又開始要做個總回顧,再對來年許願。 2017 年,大體上仍然是個華麗的冒險,而且,比 2016 更刺激。 去除一些不便揭露的事情,以下是簡單的回顧。 ◉ 補血課程 這一年,參加的補血課程及講座比較節制,但也更聚焦。 敏捷開發系列: CSPO by 呂毅 (心得) LeSS by 呂毅 (部分心得) SBE by 姚若舟 & 柴锋 (部分心得) Agile Coaching by 李國彪 薩提爾系列: 基礎篇、應用篇 (心得) 助人篇 (部分心得) 職場系列: 302 專案的談判與協商...

READ MORE

估時砍半的邏輯

估時,一直是敏感問題。我甚至懷疑:它是必要之惡嗎? 儘管敏捷陣營發展出一些方法,像故意不給絕對數字,而是相對數字的 Planning Poker,但實際運作下去,仍然可能遇到〈專案的一般症狀〉點出的根本問題。 人性問題,不是 Delphi 法、PERT 法、Planning Poker 法就能完全解決的。 針對此問題,高德拉特博士的 CCPM 關鍵鏈,有一招很駭人的「對半腰斬」法: Therefore, ask for task durations within the context of what the workers understand --- the way...

READ MORE

Product backlog refinement 文章小蒐集

由〈Product backlog refinement 的必要性〉及〈從 Ready 角度看 Product Backlog Refinement〉兩篇文章可看出,Product Backlog Refinement (PBR) 並沒有固定的時間及形式,完全看團隊自己,秉持 Scrum 的 empirical process control 精神,自己調整出適合自己的細節步驟。 話雖如此,我還是希望給團隊觀摩一下,其他人是怎麼運作 PBR...

READ MORE

從 Ready 角度看 Product Backlog Refinement

上個月〈Product backlog refinement 的必要性〉那篇文章,自認有點匆促,沒有把腦袋裝的都寫出來。正好最近敝公司某幾個團隊,已經走到可以正式探討是否該引進 refinement meeting 的階段,我就來補充一些論述吧。 尤其是針對文末「Sprint Planning 是一整個 Sprint 士氣的火車頭,不宜消耗在梳理瑣事上」這段論述。 先以傳統的專案管理角度來類比(Scrum 純粹論者,請先不要挑剔這類比是否允當)。 我一直認為,某方面來說,Scrum 的 Sprint,其實可以類比成傳統的...

READ MORE

SBE 角度的「最成功的團隊」

今年四月,我曾經在公司內舉行兩次 DDD (domain-driven design) 讀書會(1 & 2),試圖推動 DDD 觀念與實踐,以解決日積月累的技術債及文件債。不過,我高估了一般工程師的 modeling 能力,尤其是「透過對話進行 modeling」的能力。 畢竟,「透過對話進行 modeling」其實已經有點偏向商業分析師或系統分析師的工具箱了,若想成為整個團隊成員的共同技能共通語言,可能得培訓好一陣子。 隨後,個人重心暫時轉移到公司的敏捷轉型議題上,就沒繼續強求 DDD 了。 我也思考另一個導入途徑的可能性:SBE (specification by...

READ MORE

從系統思考看 DevOps

自從去年在〈有了 Agile,為什麼還要有 DevOps?〉及〈從限制理論看 DevOps〉兩場演講中,分別以 lean thinking 及 theory of constraints (TOC) 兩個角度探討 DevOps 之後,心中一直有個願望:想再從「系統思考」角度探討 DevOps。 畢竟,「系統思考」算是名門正派,「學習型組織」更是我從研究所時代就心嚮往之的目標呀。 翻開書架上那本,從研究所時代就買的《第五項修練》(第一版),讀著讀著,還是不甚有把握直接應用到 DevOps 場域上。畢竟系統思考的重要思維工具 CLD (causal loop...

READ MORE