Feature Driven Development (FDD) 也是一種敏捷開發方法, 它最先出現於 Java Modeling in Color with UML這本書中. 但是聽過的人比較少, 讓我們來簡單的介紹一下.
FDD 是一個 model driven, short iteration 的流程. 一開始要建立一個整體的 model, 然後再利用一連串兩周的 "design by feature, build by feature” 的 iteration, 來建立出整個系統.
上次在 InfoQ 中看到一篇文章討論測試自動化, 其中讓我印象最深刻的是有關測試工具.
在十年前, 測試工具大概由三家公司所佔據, 公司名稱已經不太清楚了, 目前大概只剩 QTP 活下來. 那時候第一名的市佔率, 大約是第二名的兩倍. 開源的測試工具那時候還不成氣候.
曾幾何時, 世界變了, 從 Google Trend 發現到, 當年市佔率約 30% 的 QTP, 衰敗到一整個不行, 開源的測試工具現在已經是席捲大地.
http://www.google.com.tw/trends/explore#q=qtp%2C%20%2Fm%2F025sf8g%2C%20Robot%20Framework&cmpt=q
公司有項任務, 是要培訓一些創新引導師, 來幫助產品創新工作的進行. 在這過程中, 雖然付出了很多時間, 但是其實收獲最大的, 反而是主持活動的自己, 因為可以有很多機會, 偷學到不少東西.
其中, 最常進行進行的活動, 就是進行腦力激盪. 經過了上百場腦力激盪, 我覺得以下事情是很重要的:
當我開始執行 scrum 後, 發現公司大多數回顧會議(retrospective)的進行, 都是從我們 team 抄出去, 雖然這是一件很驕傲的事情, 但是執行久了, 還是覺得會很無趣.
回顧會議是希望大家能夠講真話, 能夠有機會反思自己做的好不好. 立意雖然不錯, 但是執行久了會乏味. 就像一道美食天天吃, 日子一久也會咽不下去. 因此主持人要能改變實施方式, 帶動會議的氣氛, 讓大家能夠享受在其中.
