Search
#純靠北工程師52t
----------
花一大堆時間討論極少數會發生的狀況，不斷challenge原本在報告的人、不斷將狀況複雜化，然後這個不斷增長開會時間的人，突然之間意識到開會時間嚴重超時。
This is what we called "scrum standup meeting"
----------
💖 純靠北官方 Discord 歡迎在這找到你的同溫層！
👉 https://discord.gg/tPhnrs2
----------
💖 全平台留言、文章詳細內容
👉 https://init.engineer/cards/show/6581
[Product Backlog Refinement 進行時機]
(1) 在 Scrum Planning 會議時進行 PBR
Scrum 在一開始時, 並沒有 PBR 這個東西, 所以便在 planning meeting 中去梳理需求. 但是這個會造成 planning meeting 開會開很久, 或許比較適合需求不太複雜的狀況
(2) 在 Scrum Review 會議時進行 PBR
Scrum Review 會議會展示這個迭代完成的需求, 所以也是一個合適的時機點, 來討論接下來下個迭代中的需求. 可是同樣會有的問題: review meeting 也會開很久.
(3) 在 Scrum Planning 會議之前, 另安排一個會議進行 PBR
專門有個會議在進行 PBR, 這樣可以讓 planning meeting 比較專注, 時間也比較可控. 但是不可控的還是需求要梳理多久.
(4) 在 迭代過程中, 依狀況召開 PBR
因為需求可能很複雜, 或者某些關係厲害人的時程, 需要在迭代中, 分成多次來進行. 通常是有需要時, 就召開 PBR 會議, 來梳理下個迭代中的某些需求
不知你們都是哪一種?
敏捷宣言明年就 20 年了，從敏捷宣言簽署者之一 Ron Jeffries 在 2 年前講出這樣的話，自然是很夠份量的。
敏捷宣言其實是站在「軟體產品」的角度，解決人、協作、組織、文化上的根本問題。
然而，軟體產品中最核心的本質「開發與交付」其實是在更前面的 extreme programming （極限編程，簡稱 XP）就被帶出來了，而且這件事並沒有因為敏捷宣言而改變。
為什麼這個世界上大部分的「人」（也就是不只開發人員）大部分搞 scrum 類型的框架弄不太起來，而真的弄得起來的人，你可以說他們不用 scrum 可能軟體的交付速度、品質也不會差到哪去。
那是因為核心還是 XP 啊。他們用 scrum 類的協作方式，可以改善他們需求、溝通、協作上的浪費，用 LeSS 可以帶著全局思考的角度，避免局部優化的浪費。
但大部份畫虎不成反類犬的公司在敏捷轉型過程，這些軟體產品開發的本質才是他們的核心問題，他們用 scrum 初期好處就是透明，然後發現組織存在更多這樣的問題，但大部份的角色（包含開發人員）對極限編程的實踐、精神都是迴避跟鴕鳥的，他們寧可喜歡兩週裡面開開 daily meeting, retrospective, planning, review (然後也沒有比較扎實的 refinement)，至少他們覺得自己「在 scrum」，失敗了在賴給它就好了。
如果你是個開發人員，至少你可以跟其他開發人員先從 #極限編程 的實踐做起，至少你會開心一點，而且累積在自己身上的，誰也帶不走。
等到你有這樣的能力，你能選擇跟這樣的團隊在一起工作，屆時你們要解決的，就只剩下協作的問題了，那時你們自然就會去搞 scrum 類型的方式來解決你們瓶頸的問題。
看到了嗎？這就是 20 年前，一群技術大神聚在一起寫敏捷宣言的背景啊...他們都是技術大神，技術問題基本上對他們來說是不存在的，他們弄敏捷宣言就是因為技術對他們來說不是問題了，自然要扭轉一下世人過去瀑布類型方式的問題瓶頸。
來源：https://ronjeffries.com/articles/018-01ff/abandon-1/
簡體譯文：https://mp.weixin.qq.com/s/UbG5XNXrSWdMBdao0RXIwg
講那麼多，持續整合、pair programming、單元測試、重構、測試驅動開發、讓需求單位早點提供 feedback 或參與，大家做了多少呢？
