軟體架構・絮語

Automate everything, make life easier!

估時砍半的邏輯

估時,一直是敏感問題。我甚至懷疑:它是必要之惡嗎? 儘管敏捷陣營發展出一些方法,像故意不給絕對數字,而是相對數字的 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

Product backlog refinement 的必要性

去年十一月在 Agile Tour Hsinchu 2016 演講〈瓶頸處理九大原則〉時,我曾引用 Essential Scrum 的圖: 後來被老司機提醒:「現在 Scrum 陣營,已經不太用 "grooming" 一詞了,建議改成 "refinement"。」我才第一次發覺,這可能是很重要的活動,才值得 Scrum 陣營特別予以正名。 Refinement? 這是一個在初等 Scrum 書籍中,極少被提及的會議。值得細究。 略做考古,最早的 Scrum Guide 2010 版是用 "grooming" 一詞: Scrum Teams often spend...

READ MORE

你曾經變成你自己最糟糕的一面嗎?

湯姆・漢克與梅格・萊恩主演的《電子情書》中,有一段台詞: Do you ever feel you've become the worst version of yourself? That a Pandora's box of all the secret, hateful parts - your arrogance, your spite, your condescension - has sprung open? Someone upsets you and instead of smiling and moving on, you zing them. "Hello,...

READ MORE

思考框架的刻意練習

我自認是個思考框架控。 學生時代,只是不自覺的這麼做。但後來,被勝間和代《新・知識生產術》洗腦,我就開始下意識蒐集並應用。 我知道《精準明確思考術》或《超神速全腦學習法》都一再警告依賴既定框架的陷阱,但是,看到連鼓吹思考框架甚力的勝間和代都曾有此疑問,且給出一份建議,我就放心了。她在《培養商業腦的7種組織力》書中是這麼說的: 後來,看到另一位我很崇拜的憲哥,在書籍中也一再重申: 養成持續且大量的閱讀習慣,是每個人成長,成為一個咖的必經過程。找到案例、找到一個比你更好的架構,來印證你觀點的重要時刻。--- Quote: 《人生準備 40%...

READ MORE

以談判角度看 Sprint Planning

自從去年 Q3 個人的 Scrum 首航開始,讓我壓力最大的,並不是主持 Retrospective,而是 Sprint Planning。上完 CSPO 課程後,更是對高品質的 Sprint Planning 有著不一樣的願景。 研發團隊需要再教育,PO 又何嘗不是呢? 只是,不同的 PO 有不同的團隊領導風格,大多數個性鮮明的 PO 也不是那麼容易被改變。這就有待 Scrum Master...

READ MORE

DDD 讀書會,進度 #2

歷時兩週的第一次【Domain-Driven Design 讀書會】,上週五正式檢討作業。 整個驗收討論的過程,我刻意親自示範何謂「大聲地建模」(Modeling Out Loud)。也順便以此過程,讓大家在現場親自體會作業第 3 題「為什麼作者主張,要透過對話來研究、改善模型?」 用肉身踩雷,比說破嘴更有說服力。折騰這一遭,其實也順便在灌輸敏捷開發的原則:individuals and interactions over processes and tools。 打鐵趁熱。第二輪開始了。 如此下去,我們的團隊會變成什麼樣子呢?真令人期待。 這次,仍然是...

READ MORE

DDD 讀書會,進度 #1

去年十月【API Design 讀書會】之後,原本要再接再厲,推出 microservices 及 domain-driven design 系列,以深耕團隊的技術實力。不過後來,主觀判斷,專案管理心態更是當務之急,因此,將讀書會主題暫時改設定成【工作分解講座】及【三年後,你的工作還在嗎】。 也已經好幾個月了。現在,要回頭盯技術了。 讀書會材料,當然就是這兩本書: 兩本都是經典,自然不宜囫圇吞棗。 接下來,為期兩季的 microservices + DDD 讀書會,乾脆也採用 1~2 weeks 迭代的方式進行吧,也比較容易出深入一點的 ORID...

READ MORE