從想要到需要

April 22 22:10~23:59

 

《User Story Mapping》書中對於軟體開發有一段很有趣的描述，有一首歌的歌詞提到：

You can't always get what you want. But, if you try sometime, you just might find, you get what you need（你不可能永遠得到你想要的。但是，如果你嘗試一段時間，你也許會發現，你會得到你所需要的東西）。

軟體開發和上面這段歌詞剛好相反，如果你（product onwer）和一個有能力的團隊一起合作，在sprint review的時候你總是可以獲得what you want（你和團隊在sprint planning時所同意的user story內容），但只有在看到結果之後，你才能夠更進一步評估什麼才是what you need。請不要責怪你自己，軟體開發的本質就是如此。

***

用戶真正的需求（need）通常要等到看到產品之後才會慢慢變得具體，這個道理雖然簡單，但當自己成為開發團隊的一員的時候，常常陷入當局者迷的陷阱：

• 什麼，又要修改功能？你能不能一次說清楚啊。
• 什麼，你還沒想清楚？你負責定義需求的人都不知道，那我要怎麼寫程式？
• 我不知道啊，user story（或需求分析書）就是這樣子寫的，我只是照著規格做，不關我的事啊。

雖然搞敏捷的人都說要「擁抱改變」。是啊，出一張嘴叫別人擁抱改變很簡單，輪到自己的時候，改變距離你還有100公里你就已經覺得「溫度太熱」，想辦法找個涼一點的地方躲起來先。

***

《User Story Mapping》的作者在書中提到Alistair Cockburn曾經告訴過他：「每一個user story在product backlog裡面都應該有三個項目來代表它。哪三個？第一個項目是原本要做的那個user story，第二個項目是修改第一個項目，第三個項目是修改第二個項目。如果你的product backlog不是這樣，你就沒有在學習。」

每個功能做好之後還要再修改兩次，只是剛剛好而已啊。

***

友藏內心獨白：可以有不改程式又擁抱改變的方法嗎？