敏捷史話(十五):我發明了敏捷估算 Poker —— James Greening
雪鳥會議
雪鳥會議前夕,James Grenning 在 Object Mentor 與 Robert C. Martin 一同工作,彼時組織雪鳥會議的 Bob 大叔盛情邀請 James,告知他會議的地點。James 聽到地點後毫不猶豫地答應,並在腦海中踴躍歡呼“我要去滑雪!”畢竟,“雪鳥是世界上最好的滑雪場之一”,沒有人會拒絕雪鳥的誘惑。當然,除了滑雪這個最直觀的念頭,James 也曾與 Kent Beck、Ron Jeffries、Martin Fowler、Ward Cunningham 共事、合作,有這樣的機會同這些人一起聊聊關於軟體開發的事,這也是另一個非常吸引他的原因。
不過他對參加雪鳥會議是否會對自己的工作產生有利影響沒有絲毫期待,在會議現場也只是進行些小組交流,他從未預料到這會對軟體開發行業產生如此巨大而深遠的影響。“我們很確定沒有人會在乎,但至少我們做了一些事情:
找出我們有什麼共同點,以及共同點在哪裡
。”
估算Poker
在一定程度上,
《敏捷宣言》是在大家聚在一起找出分歧,再找到共同點的過程中產生的。James 認為,這與估算
Poker
相似,二者的共同點是:
一個團隊需要在哪一部分達成共識
。
估算
Poker 的靈感來源於 James 作為敏捷教練參加的一次失敗的計劃會議。那一次,團隊八個人圍坐在桌子旁,兩位高階工程師主持此次會議,在會議中,二人不斷反覆討論如何構建使用者故事。當時在場的 James 極為混亂,他用了半小時甚至一小時的時間才意識到,他們在會議開始時談論的工時數與在會議結束時談論的工時數完全一致,整個會議所做的事情只是在爭論用什麼方法去做。而此時其他參會的六個人都已經昏昏欲睡,這是因為爭論的這二人“壟斷”了整場會議談話,而沒有參與討論、估算的人已經近乎脫離會議了。當時的 James 手上正好有索引卡片,於是在這場會議中場休息結束後,他給每個人都發了卡片,並要求提出某項工作後,所有人只能出牌,不能講話,來達成一致同意。
James 在 Object Mentor 網站上寫下了這個故事,提出估算 Poker。隨後,Mike Cohn 發現了這一方法,並根據自己的經驗對估算 Poker 的設計 進行了完善和增強,同時決定將估算 Poker 在大範圍內推廣使用。釋出後,這副特殊的 Poker 在程式設計師中廣受歡迎。
當然,估算並不只依賴於這一副
Poker,James 自己在被 Lowell Lindstrom 展示過親和圖優先順序估算的想法後,已經多年未使用估算
Poker。但估算
Poker 確實能透過以牌面朝下的方式隱藏數字,讓團隊避免“錨定”的認知偏差,提高估算效率。這是一種既能起到群策群力效果又有效避免眾口難調造成混亂的好方法,所以 James 的客戶們應用推廣,由此產生了
風險
Poker
、
價值
Poker
等型別。雖然這兩種
Poker 並未推向市場,但團隊想要借鑑的話,實現起來並不困難。
測試驅動開發
1999年,James 開始學習極限程式設計,從事嵌入式諮詢工作。當時一直在為客戶編寫用例並搭建體系架構的 James 在 Object Mentor 進行了第一次極限程式設計沉浸式學習,也開始接觸一些此前未了解過的事。當他看到當時名為“測試優先於開發”(現在的測試驅動開發)的演示時,他發出驚歎:“哇!我們可以打破對我們沒有的東西的依賴。”因此,如果需要構建某個系統,並且處於無法與硬體互動的情況下,仍然可以建立軟體,並
透過存根和模擬物件等來開發尚不存在的事物
。
激動興奮之餘,受到啟發的他產生了為做嵌入式開發的程式設計師介紹測試驅動開發的念頭,也將敏捷介紹給嵌入式開發的群體。他開始在嵌入式系統會議上做關於將敏捷應用於嵌入式軟體的演講。也有了專門寫作測試驅動開發的主題的書的念頭,這個念頭後來成型,就是《測試驅動的嵌入式 C 語言開發》。
從這顆被點燃的火花開始,再到他把敏捷、測試驅動開發的火花帶給更多的嵌入式開發工程師,他意識到語言通常是不同的,不僅僅是程式語言,人們相互交流的方式本質上是不同的,因為他們談論的是不同的東西。不同的整體擁有不同的世界,所以遊走於不同的群體間就可以學到不同群體的知識,比如他透過與 Bob 的合作瞭解到了許多非嵌入式的知識。從物件導向、極限程式設計到測試驅動開發,他願意把這些不同世界的知識帶給其他世界的程式設計師。
敏捷本身不是目標,而是尋找誠實而高效的方法來交付有價值的產品
,這是 James 一直強調的觀點。在2011年敏捷宣言十週年的訪談中,他認為自己與十年前在雪鳥會議的自己相比並沒有變化,但他一直擁有自我學習和進步的主人翁意識,在嘗試不同的想法並不斷完善。所以,敏捷更多是一種前進的方式,而不是可以在此停滯的目的地。回首往事,他不會從《敏捷宣言》中刪除任何東西,但會補充一些關於持續改進、適應和學習的內容。如今又是新的十年走過,透過他不斷更新的網站和活躍的動態,我們相信他一直在前進,從未停滯。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69982050/viewspace-2769566/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 敏捷史話(五):敏捷已逝 —— Dave Thomas敏捷
- 敏捷史話(十一):敏捷宣言“間諜”——Steve Mellor敏捷
- 敏捷史話(十六):我對《敏捷宣言》沒有半點貢獻—— Brian Marick敏捷
- 敏捷史話(八):敏捷的破局之道——Martin Fowler敏捷
- 敏捷史話(四):敏捷是人的天性 —— Arie van Bennekum敏捷
- 敏捷史話(十三):我被 Facebook 解僱了——Kent Beck敏捷
- 敏捷史話(十四):敏捷之峰的攀登者 —— Jim Highsmith敏捷MIT
- 敏捷史話(九):用做麵包的方式做敏捷——Alistair Cockburn敏捷AI
- 敏捷史話(十二):你現在接觸的敏捷也許是“黑暗敏捷”——Ron Jeffries敏捷
- 敏捷開發:使用者故事估算方法介紹敏捷
- 敏捷史話(三):篤定前行的勇者——Ken Schwaber敏捷
- 【DevCloud·敏捷智庫】如何利用故事點做估算devCloud敏捷
- 敏捷實施中的估算與實際效果 - Ottinger敏捷
- 敏捷史話(十):我犧牲了滑雪時間,參加了一場軟體革命——Jon Kern敏捷
- 敏捷開發敏捷
- 敏捷史話(十七):維基(Wiki)背後的靈感來源—— Ward Cunningham敏捷
- 敏捷開發框架敏捷框架
- 敏捷開發大家談(五)--敏捷開發的設計原則敏捷
- 敏捷開發相關敏捷
- 敏捷開發簡介敏捷
- 敏捷開發入門敏捷
- 初識敏捷開發敏捷
- 敏捷式開發管理敏捷
- 敏捷開發思維和免費敏捷管理工具敏捷
- 騰訊敏捷之道,實施敏捷開發,看我就夠了敏捷
- 敏捷專家認為敏捷框架SAFe實際最不敏捷敏捷框架
- 軟體開發流變史:從瀑布開發到敏捷開發再到DevOps敏捷dev
- 說說我們的用的Scrum敏捷開發工具Scrum敏捷
- 敏捷實戰分享:Runtastic停止了估算故事並改善衝刺,效率提高30%敏捷AST
- 敏捷史話(六):也許這個人能拯救你的程式碼 —— Robert C. Martin敏捷
- SAFe敏捷框架下的工具,實現規模化敏捷開發敏捷框架
- 敏捷開發|私藏的3個敏捷專案管理工具!敏捷專案管理
- 敏捷開發--Scrum開發模型敏捷Scrum模型
- CORNERSTONE對話騰訊&華為敏捷專家敏捷
- 敏捷開發大家談(二)敏捷
- 敏捷開發入門教程敏捷
- 敏捷開發的那些事敏捷
- 敏捷開發大家談(三)敏捷