讀《使用者故事對照》與生活閒聊

其實我要講的有一半是來自於使用者故事對照這本書的讀書心得。上週，有次小主管帶我去聽演講 (Epoch-MIT ILP 專題演講)，其中一場是 PicCollage founder John Fan 為主講人，他就問台下觀眾，什麼是 MVP，當時還聽的不是很清楚，回家也有忘了。接著週末，我就拿起這本書開始讀，結果我發現 User Story Mapping 提到 MVP 還有一些 Lean Startup，與我那天聽到演講的內容很有相關性。

MVP 也就是 "Minimum Viable Product" 最小可行產品。

為什麼需要 MVP 呢?! 我在猜想某部分原因是因為當我們在策劃一個解決問題的產品的時候，大部分情況是我們在“猜想”使用者會遇到什麼問題，所以當我們想出了一個 solution 時，(也許我們要想非常多個 solution)，我們要做出一個 MVP 跟使用者互動，驗證我們是不是在對的方向，也用來驗證我們的猜測是不是越來越接近需求。所以會一直維持一種循環『build->measure->learn』 (看圖片)  不斷的試驗，不斷的學習，這樣的 iteration (循環)，能夠越快越好，能夠越接近使用者的想要的產品，iteration 也不要太久，差不多一次的 sprint 衝刺時間約兩周，這樣一個月可以 iteration 兩次（sprint 的週期主要還是看公司的步調是什麼狀況...）。

實現想法不急著產出設計稿
其實 wireframe 我研究不多，但那天聽演講覺得要點就幾個:

• 討論快速
• 修改也快速
• 去除任何顏色，單純線稿，單色色塊表現 (因為顏色會影響判斷能力，也會增加很多考慮易用性的變因)

User Story Mapping
這些列的是我看書的學習心得 :P, 也許對看文章的你沒什麼很直接的幫助，我建議你可以直接買書，會比較好理解，因為有些細節要搭配照片看比較了解。或是看 YouTube，這裡有這本書的作者的演講: User Story Mapping with Jeff Patton

• Story Mapping 幫助開發時聚焦在 user 跟使用經驗上，促成更好的流程(討論出來的)。
• 故事對照 Mapping 是很容易的一件事情，基本上我們只需要準備便利貼(如果你不嫌貴的話，公司又願意花錢買便利貼...)，由左而右的排序，寫下整個使用者在使用產品的故事。而細節是沿著每個步驟的下面，往下貼，也就是水平排序為故事的流程，而垂直的便利貼，表示該流程的一些細節。(看 slides) ，一個人也可以練習如何 User Story  Mapping，基本上你可以把你某一天的早上所做的所有的事情透過便利貼描述出來，這是一種練習方式，書本某一章節有提到如何練習~
• 『分享文件不是分享共識. p.XXX』 這句話還慢令人有所感觸的 XD，為什麼呢？！因為寫 spec 的人跟看 spec 的人可能認知不同，如果沒有確認大家對於這份文件所講的某件事情有相同的認知，那麼 spec 跟實際做出的東西可能會有很大的落差。即便大家都在 spec 上面簽了名... 也不代表大家想的是同一種預期的結果。
• 呈上點，個人結論是: spec 別寫得太完美... XD (其實我以前是開發完才補文件.... )
• 當在敘述故事的時候，所有的對話記錄，寫在白板上，貼在牆壁上的便利貼所有討論，過程照片，都可以任何形式記錄下來，如拍照等等，因為重要的不是被寫下來的文字，而是你看這些記錄可以讓你想起什麼討論的細節。
• 千萬要記住，User Story 絕對不能代表需求，而是利用文字, 圖像，透過大家共同討論, 述說故事，建立大家對 User Story 的共識。
• 大故事可拆解成好幾個小故事。(我覺得這樣做的好處也適合拿來拆成要製作的功能，但感覺又不能這麼工程師一面的想法... )
• 『在探索深度之前，先聚焦於使用者故事的寬度』 p.12，這句話的意思是，討論得很 high 的時候不要一直往細節討論，要拉回來照顧一下整體的 story 以及繼續往後面的 story 前進，書上的說法叫做"整體圖像"，討論細節之前請先以達到故事尾端為重，『思考寬度一英里，思考深度一英寸』 (我好喜歡這句話 :P)
• Ron Jeffries 的三個 C: Card, Conversation, Confirmation
  http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
• 魚缸協同合作模式 (人多未必好辦事)，這模式挺有趣的，意思就是，有興趣的人就加入對話，沒興趣的就離開魚缸的範圍 (其實是類似在一個房間界定魚缸的範圍)，如果你的團隊有人開會時表現的興趣缺缺，滑手機之類的症頭....==。類似的文章: https://blog.itcilo.org/2009/02/16/facilitate-a-fishbowl-discussion/
• 基本上想做的事情，跟擁有的時間，有很大的落差。但 User Story 會談到很多細節，可以拉出一條線，在線以上叫做 in，線下叫做 out，in 表示在某個階段之內可以先完成的，也許是一些必要的功能，out 則是暫時先不做，不代表捨棄那個流程的 detail. 可能在這個流程上會有一些便利貼會被移動 XD (感覺很像在走 scrum)
• 我也好想玩玩看但我公司應該沒有這種 project 可以玩這種流程 QQ

有興趣的話建議買書來看看吧! 要不是這本書，我真的沒聽過 User Story Mapping.


關於 User Story Mapping 你也可以參考:

• gotop 使用者故事對照｜User Story Mapping
• (博客來) 使用者故事對照：User Story Mapping
• http://jpattonassociates.com/user-story-mapping/
• http://jpattonassociates.com/storymappingslides/ 書籍作者的投影片
• Ruddy 老師的 slide http://www.slideshare.net/ruddylee/user-story-mapping-43373448
• User Story Mapping 使用者故事對照
• vividadada的技術筆記 使用者故事對照/地圖演講摘要 (User Story Mapping)

如果有寫錯什麼內容，還麻煩留言指正指正，謝謝!
若有問題，或是有任何不妥的文字，歡迎來信 yiyingwu.1990小老鼠gmail[.]com

元旦三天連假讀的三本書

1. 從0到1：打開世界運作的未知祕密，在意想不到之處發現價值
2. Melody的幸福3元素：閉嘴、放空、微笑
3. 喬志先生愛情處方箋

[讀書心得] SCM 軟體配置管理

書名: SCM 軟體配置管理  作者: 董越

這三天把這本書看完了，我大概 brief 一下每章的一點筆記就好，其實主要是書已經在身上，寫太多出來也沒有太大的必要 XD 大家有興趣再去看看書吧 :D (新年新希望難道沒有一年要看幾本書的目標嗎?! :P)

SCM 是 Software Configuration Management 的縮寫，書中翻為軟體設定管理，簡單的說就是對一個不斷演化的軟體資產做管理，主要有兩個方向，一是針對資產做管理以及儲存，二是適當的控制軟體的品質，像是關注於軟體的整合。

比較精確的定義要參考 IEEE-STD-610，或是你可以參考本書本書的ch01。

Ch02 基本的版本控制
* 即使只有一個人，也要做 SCM
* 防止版本覆蓋: 如果你仔細去細想，在多人開發軟體的時候，同一隻檔案被同時修改的機率非常高，因此防止檔案被別人覆蓋，是很重要的議題。
當然，不同的版本控制工具各有不同的處理方式，第一種是串列的方法，類似我們寫程式處理的 quene 啦，就是當有人要拿檔案去修改，該檔案就會被 lock 住，但是這雖然是一種方法，可是對開發效率來說是偏低的，因為如果檔案一直 lock 住，表示其它的開發人員只能乾等。這種防止覆蓋的方法的版本控制工具的一個例子是 Visual SourceSafe (縮寫 VSS，微軟出的古老版版本控制工具)。

第二種方法是平行，平行的處理手法解決了串列的問題，就是允許多人同時修改同一個地方，在做合併時，工具會判斷什麼時候需要合併，合併哪些東西，大部份情況是可以自動合併的 (像 git 的 auto-merge)，不能的時候就會叫你人工合併 (類似 conflict)。這類的版控工具，像是耳熟的 Subversion(SVN), GIT, ClearCase(CC, 同時支援串列跟平行的方法，是 IBM Rational 出品的商用軟體設定管理工具)。

書本有列一些市面上的版控系統，很多我也沒聽過 XD，但是後面幾個章節主要都是拿 svn, git, ClearCase 來比較，有 ClearCase 的原因我想大概是因為書中有提到他的市佔率蠻高的，老實說我不知道台灣有哪些公司有用到..?! 知道的朋友可以幫忙舉例一下 XD

不同的工具做類似事情的行話不太相同，像是:
* SVN 用 check out, commit, update...etc
* git 用 pull, fetch, merge, add, commit, push..etc
* ClearCase 用 check out, check in... 恩..ClearCase 我覺得比較複雜一點，但是我沒機會接觸到所以沒有特別去記，看看就過去了... 。

假設企業要導入 SCM，也要有人出來處理工具的選擇, 教育訓練, 制定開發流程等等。這也是 SCM Engineer 的工作之一~ 類似的職稱有 CM (簡稱配管), 或是設定經理 (Configuration Manager)。 一樣.. 我也不知道台灣有沒有這樣的缺 ?!  SCM Engineer 我是沒聽過耶 =="(我果然是井底的青蛙)...


Ch03 當代的版本控制方法
* 變更集合的概念 (或是變更套件  change set, change package)
* 小單位的修改就可以交付程式碼，盡量不累積
* 修改前先以拿到最新版的程式碼開始，或是反方向處理，在自己的工作區域修改後常常去更新 Repo 最新程式碼回來，在 git 是指 pull,  在 ClearCase 是指 Rebase。


Ch04 關注整體品質
* 這章主要在提整合。Intergration 主要的使命就是把產品的各部分合在一起，並且保障產品還是可以運作的情況，而不是每個模組, 單元都各自在特定的環境下可以運轉。因為每個地方都是正確的情況下，並不能確保整合在一起後就是正確的。

* 4.2 保障交付的品質: 關於這點，有幾個方向可以努力，一就是寫測試，單元測試與 TDD 是個很好的方法，再來是 Peer Review，或是 Code Inspection (現在很多 Peer Review 工具都有跟版本控制整合，像是 github 上就有幾套，只是大部份都要付費。在我任職過的公司 urAD 曾經對某專案做過 Code Review，還蠻有趣的，每個人都要針對同事發的 pull request 做 review)。還有 Pair Programming，目的也是加強程式品質。

上述的幾個方法，都是靠人來完成，當然也有方法，不是靠人來幫忙達到品質的把關，像是靜態程式分析 (Statis Program Analytics)，利用類似的工具發現程式碼的錯誤等等。畢竟有人就有可能有疏漏, 也有可能有犯錯的機會，所以利用一些工具來相輔相成幫助軟體的品質更好。


Ch05 從原始程式碼到執行中的程式碼
* 軟體的建構有兩種，全量建構 Full Build 以及增量建構 Incremental Build，主要指的是編譯連結的過程。 全量是從頭開始，重新編譯每隻檔案，比較耗時。增量主要是找有差異的重新建構，較快但有風險，相較之下比較沒這麼可靠。不過這個我體會不深，我寫的語言幾乎是不太需要編譯的 XDDD

Ch06 邁向持續整合
* 持續整合: 整合可以更頻繁，也就應該要更頻繁。如果能夠收到工程師的 commit 就開始進行整合是最好，通常也是會寫個 hook，當有人 commit 的時候就去跑 ci。
* 越大的專案，越能夠從持續整合中看到明顯的成效。 (但越大的專案要做持續整合也越難...)。
* CI 的工具有，像是有名的 Jenkins, 或是 CruiseControl (這個我就沒聽過了... )


Ch08 管理文件
* 軟體設定管理當然不只管軟體，也管文件。
* 軟體寫給機器看，文件寫給人看。
* 檔案的命名應該要加上版本號，另外也建議使用具有版本控制功能的文件管理工具。
* 不同文件可能會有保密的不同層級，應該要在文件附註這些資訊。


Ch09 
* 第九章都在講跟 bug 有關的，主要是也提到幾個 Defect Tracking System 缺陷追蹤系統，(Bug 的學名就叫做缺陷)。工具很多像是 Bugzilla, Redmine, Mantis, Trac, BugFree, ClearQuest (IBM Rational 出品的), JIRA。
JIRA, Redmine 我都用過，還蠻喜歡 JIRA，但是商用都是要付費的。
* 對於 bug 的描述一定要做到可以讓開發人員及 QA 可以做到複現，包含遇到的情況, 當時的作業環境。


Ch10
第十章在講遇到 Feature 時的處理方式，另外也提到 Scrum, FDD 等。

* Scrum 是敏捷開發的一種方法，用一種反覆運算, 增量為主的特點來開發軟體。 這裏的增量指的是 Enhancement 代表一些小小的功能請求，想在原有的程式加上一些功能。 (我也打算看一下 Scrum 的書，如果有推薦的書目也歡迎留言推薦給我，謝謝 ! :D )

* 除了可以用 Scrum 來管理這種一個一個的 Feature 之外，也可以用 FDD 也就是特性驅動開發 (Feature Drive Development) (wiki)，FDD 也是一種敏捷開發方法，我有找到一篇文章有興趣可以看看: David Ko的學習之旅 - Feature Driven Development 簡介。
(不過...  FDD 我比較少聽到 XD，大部份聽到 Scrum 比較多)

FDD 對於 Feature 的週期是兩週內完成，Scrum 的週期單位是用一個 Sprint (衝刺) 來算的，通常是 15-30 天，長度由開發團隊決定。

* 在瀑布模型下管理 Feature，要注意一旦決定要執行的計畫就不要去更改他了。(瀑布下要減少變更, 變更是不能夠隨意的發生，但不是指完全不行)

其實我覺得增加 Feature 在大型專案上比較麻煩，因為要往上通報，由主要 Leader 決定開發這個 Feature 的成本是否有意義，因為會影響時程, 開發人力，實際對 user 的方便性跟效益是否是值得的? 會不會引發後續的其他 issue 跟 maintain 時程, 以及相對應的測試 code 都要修改。

* 書中有提到可以成立變更控制委員會 (Change Control Board, CCB)，由一群人來決定是否要執行某個 Feature(我個人覺得有這種會議如果遇到很麻煩的 Feature 應該很容易開的沒完沒了 XDD )。

* Feature 的處理流程，應該要依照 Feature 的程度而有所劃分，並不是所有的 Feature 都要經過嚴格的管理。


CH11
11章在講學院派對 SCM 的理論。讀起來比較悶，感覺很像在唸考試的東西 XD 其實主要在講 CMMI 啦

* SCM 主要由四大部分組成:
1. 設定識別 (Configuration Identification, CI)
2. 設定控制 (Configuration Control)
3. 設定報告狀態 (C... Status Report)
4. 設定稽核 (C.... Audit)


後面章節的我就先不寫了，但都是在講 SCM 在實際場景的舉例，嘻! 有興趣知道可以買回家看看 :) 總之我是覺得，看這種書很快樂 XD 雖然實際上在工作不一定都能用到或是親生經歷，但是知道有什麼方法就夠了(工作與團隊之間，不同階段有不同挑戰)。

[讀書心得] 第三方支付的真相

完整書名: 第三方支付的真相：如何從網路收到錢？線上開店和個人賣家都要懂的行動金流攻略 - 作者： 陳柏江

這本書還蠻適合給正在研究要不要做電商的人，而且書不厚，在咖啡廳待個兩小時就可以看完了。

[讀書心得] 巨型網站成長從無到無限大，技術架構大揭祕

在去年年底，我從天瓏書局扛了一堆書回家，其中一本就是 從車庫的舊PC到百萬台伺服器：巨型網站成長從無到無限大，技術架構大揭祕，作者是 李智慧。

後來因為忙碌，一直沒有去看，直到我做網站遇到了一些瓶頸，從上個月看到今天，大約六週的時間，總算看完了。

這本書寫的是經驗跟方法，並不適用於所有的網站，而是依照業務上的需求，而有不同的規劃。有業務，才有技術上的考量。

『程式設計人應該知道的 97 件事』讀後感

這本書非常適合在寫程式寫到腦袋有點鈍掉，又不想停下來好好休息的人拿去咖啡廳坐著看一看。

我不知道大家 coding 到有點 co 不下去的時候會做些什麼事情，如果是我，就是在臺北東區亂走路，但又不至於走9遍忠孝東路，或是焦慮的喝著有咖啡因的液體...，沒有要幹嘛，但就是也不想睡覺休息 XD。常常我是邊走路邊想事情。

這本書，整體來說，並沒有什麼總結，只是很多人對於工程師的一些想法，不論思考, 做事的方式, coding 跟重構等等。

有些人的想法，看了會很有共鳴，你會覺得，好像我也是這樣做, 好像...我也是這樣想。有些人的想法，可能跟你互斥，不過都是別人的經驗，你可以汲取你認為好的，或是思考一下，不想做 plan A，那如果是你，你會有什麼樣的 Plan B，因為方法沒有一定，端看你的工作環境,  coding 方式, 同事, 客戶等等。


蠻意外的共同點

• 有幾位專家認為增進 coding 的能力之一是共同參與別人的 open project，或是去看那些開源的專案的程式碼。
• 這點我自己承認我沒做好，因為我沒什麼耐心看別人的 code，除非是我很有興趣的專案，像是一些用 JavaScript 寫出來的效果等等... :P (還需要多培養....)

註解不是邪惡

• P.32 那篇是個很好的故事，簡單來說就是，作者在念大學的時候，老師出了一題算出平均值的程式，題目不難，作者得到了一個勉強的分數，但是老師在評分卷上寫著: 『沒有註解 ?』 。老師會這樣問的原因是，老師跟作者都知道這段程式碼目的是要做什麼 (因為已經知道題目了)，但是這樣還不夠，『程式碼必須可以對下一個的程式設計師解釋他自己』。
• 但是也不該過度註解，註解最好可以用來解釋程式無法解釋地清楚的地方 (可以跟『在程式碼無法表達之處註解』, P.34  做比較)
• 總是有機會會寫到很複雜的功能
• 『如果這東西很難寫，那麼也應該很難讀』，這句的意思為反意，要注意程式碼的可讀性 (update 2015-01-15，謝謝 洪象成)。

學習程式以外的語言

• 是的，這篇我很有體悟，尤其剛參加完英文講者蠻多的 JSDC 之後，要好好學英文...

程式碼的審查. P.28

• 這篇建議可以給會被 code review 的新人看看，我曾經有犯過這種錯，就是被別人 code review，但是我覺得那是對方的偏見，改了我的 code 有時候心情蠻差的。但我後來是蠻喜歡被 code review 的...，有時候就是這樣，當你很討厭被 code review 時，就一直有人會來 code review 你，當你想要有人幫你 review 時，卻很難有這樣的人 XDD 這機會很棒啊，如果有人要 code review，要心存感激啊 !
  
  程式碼的審查不是用來指正新人的錯誤，而是分享知識，這個很重要。不要讓 code review 變得很嚴肅，如果公司能把 code review 變成一個快樂的點心跟下午茶時間，那會很不錯。

別在你的測試資料裝可愛. P.50

• 這篇非常有趣，因為真的很容易發生這樣的事情，簡單來說就是，多為你的客人著想 XDD，情境有點類似假如客戶提出了很奇怪的要求，然後你在 log 或是 alert 寫下一些情趣化的 log (ex: 別再按這個鈕了，沒有功能，你這白癡) 之類的話，或許工程師覺得好玩或是無心寫下，當做 debug 用的訊息而已，但是如果忘記拿掉，在客戶面前 demo 時，會給客戶留下很不好的印象，也會很尷尬 XDD 
• 要這樣寫測試的 log 也要記得拿掉呀 XDDD

學會評估時程

• 這個是我覺得很難學的部分，因為一個需求，怎樣算完整，我又該怎麼估時間呢 ><，建議以後做一個功能自己記錄一下所花費的時間跟工作內容的細節。
• 不過這篇的重點不是要工程師給上級一個明確的時程，重要的是釐清需求是什麼, 評估目標跟如何達到自己的承諾。

有幾篇是在講重構跟 pattern，這個可能給有寫過比較大型或是 C++/Java 專案的人看的，我就比較難融入在其中。


P.45。最後，做大量審慎的練習，『達成專門技術最重要的元素，就是你花在進行審慎練習的時間，先天的資質不是主要的原因』。審慎地練習是一種學習，這學習會改變你，也會改變你的行為。這篇是很好的分享啊~ 我很喜歡 :)


我只有記錄幾篇我認為很印象深刻的，
再多說就破太多梗了，要給書商賺點 $$，
有興趣的捧油可以去書店翻翻這本書 :)