almost 2 years ago

IMG_3050.JPG

Odd-e 每一次的課程總是對我造成一次又一次的衝擊
我不求學習很多,但只要每一次都有我從未接觸過的,讓我印象難忘的新知識
那麼這趟課程我就不沒有白白浪費了。

先來回顧一下這3天課程讓我最印象深刻的主題:

  • 實例化需求
  • Acceptance test solution - Cucumber
  • Mob programming
  • 極緻的 Code review
  • Code smell and Refactor
  • TDD (Test-driven developing)

之後再來一一回憶一下,
先來談談:

實例化需求

透過使用具體的資料來刻畫需求的輪廓,以便團隊針對具體的example來進行需求的確認與討論,因為實際例子更能體現實作的細節,團隊也就能更快地達成共識。

我需要一個「可以針對某一個月份來增加預算」的功能,
看似知道這個功能是要做甚麼,就是要可以選一個月份,然後輸入一個金額
這時候team裡面的engineer 可能就會很直接地開始想怎麼實作:
要用 year + month 來當 primary key?
ui 用哪個 date picker library?
有要紀錄更多的資訊嗎?例如留audit log, 哪個user 新增的?

顯然大家對需求確認有著不同的進行方式,
這時,課程老師 Joseph 請其中一組同學,
每人針對這個功能可否輸入「小數」金額給出答案
結果,這個6人的小組,有4個人的答案是可以輸入小數,2個人的答案是不能。

可以預見問題了嗎?

如果此時已經進入實作階段,
假設 a同學被assign開發backend的 API,而他認為是不能輸入小數的
另一位 b同學則負責前端ui開發,而他則是認為可以輸入小數
那麼這樣的串接過程,最後就會發現因為 b 傳呼叫 a 的 API,而增新金額是小數
最後 API 則會回傳unsupport format 的exception 回前端,
如此 a、b 同學又要針對這問題重新跟 PO/BA確認,再次修改實作方式

這個例子或許最後要重新修改並不難,但如果團隊中的認知落差體現於更大的問題上呢?

因為大家的經歷都不一樣,所以認知才會有落差,
這被稱為「知識的詛咒」(Curse of knowledge)- 當你知道的事情越多時,你的認知世界觀中就會發展出越多「個人認為的common sense」,就越容易會誤以為別人應該跟你一樣知道,
所以在溝通過程中,自以為是大家都孰知的事,故然不會特別拿出來討論或說明
誤會往往因此發生

有更好的方式來提早解決這溝通上的不足所引起的問題嗎?

這裡提出來的「實例化需求」,就是透過把需求透過用實際例子來說明,以「新增某一個月的預算」為例,舉列一個例子:

「透過界面,我可以輸入月份資料 "2016-09",並輸入金額 "1000.00"

仔細來看一下這個例子對於程式的實作上提供了甚麼有用訊息?
需要由 ui 介面操作;
月份資料的格式為 yyyy-mm
系統應該要支援小數金額的輸入, 並且數值只保留到小數點後2位
....

如此透過實際的例子來降低隊團成員的認知差異。
因此其實使用的例子也是需要有所巧思,盡量表達出意圖
例如 "2016-09" 會比 "2016-10" 更有含意一點,表達了月份的確切格式,
如果使用 "2010-10" 就不能確定個位數時的格式了。

再次強調,實例化的最終目的,是在於讓團隊對需求有更明確的共識,
所以實例需要經過思考設計,卻不必窮舉。

第一部份先寫到這邊,下一篇會來談談 acceptance test

[引導型敏捷領導力]#1 - 先說個人收獲 →