VIVOTEK Digest

經濟部統計處: 飲料店營業額在台灣逐年攀升

第一個常見現象：開週會
Why are meetings so ineffective?

Great movies tell stories that have deep emotional resonance

第二個常見現象：同事間的工作互換困難
Why is collective work difficult?

Machine learning or human learning?

第三個常見現象: 加班

Why work overtime?

不同角度的生命科學系

又下班了?! 我還想工作

Schrödinger’s Cat 薛丁格的貓

敏捷開發
Why OverCooked can teach you agile?

一款具備敏捷精神的遊戲

Get back in sync

Realtime review

The programmer as navigator

How to avoid boring meetings?

How to develop a cohesive team?

合作或協作（英語：Collaboration）

是指一種由兩個或兩個以上的個人或團體作為一個共同的目標而交集或在一起共同工作，舉例說明：

一個知識分子可以透過合作的關係而去分享知識，再而經過學習和共識達到創作的目標

一個人走得快

一群人走得遠

 Why collective intelligence matters?

Pacific Rim: Uprising (2018)

True collaboration yields better results

Iteration based method

Jeff Patton did an Iterative Mona Lisa.

敏捷帶來的影響
How does agile affect my work and daily life?

從同事電腦辦公桌

變家人散步吹吹風

關門 SOP

前是把家當旅館

現在是家事盡量管

在 Scrum Team 中很強調 透明(transparency)，這次跟大家分享的是 Developer Resource 透明化帶來的好處。

傳統團隊

在傳統的開發方法上，常常都是以”月”、”季”為時間單位，因此常會聽到 PM 說：可不可以再加這個 X 功能、這個 Y 功能，還有那個 Z 也順便加進來好了，這一季完成這些，應該沒問題吧？
身為 developer 能拒絕他嗎？有點難，因為感覺一季的時間應該可以做蠻多事情的，就算你覺得不可以，PM也很容易這樣感覺：一季耶，三個月你竟然沒辦法幫我多做 X+Y+Z?
在 Developer Resource 不透明的的狀況下，還真的很難回答。而不透明的原因，其實是因為週期太長、功能多且不明確，倒不是因為什麼溝通或互信的關係。

敏捷團隊

但在敏捷團隊中，我們在每個 Sprint Planning Meeting 時，便會先算出這個 sprint 有多少資源可以用：6(hours) * 6(developer) * 8(days) = 288 points

接著在 Story 介紹、Story Point 估算、決定 priority 等等活動之後，便開始討論 PO 這次最後決定的 stories：A,B,C,D,E,F，把這 6 個 stories 再細拆分成各個 tasks，例如 Story A 可能會被拆分成下列 tasks：

1. QML：這個功能有 UI 介面，需要實作 QML
2. C++：實際功能由 C++ 完成
3. Unit Test：要對 C++ 實作單元測試
4. UAT：要完成自動化驗收測試
5. Code Review：這次的 C++ 還蠻難的，雖然有 Unit Test，但還是要進行 Code Review

然後，接下來團隊成員根據每一項 tasks 開始打牌，決定每一項的 tasks 所需的時間。這裡是關鍵，因為要由這過程去弄清楚 PO 真正想要的東西，也讓 PO 了解這個 task 為什麼需要這些時間來開發。

以 C++ 這項 task 來看，如果一開始大家出的點數差異有點大，例如：3,3,3,5,20,3,5，便要請出3及20的成員們分別說明一下他認為是3及20的原因。
張飛(RD)：我覺得這個 雙向語音 很簡單，用原本單向語音模組來改就可以了！
關羽(RD)：可是他不是全雙工嗎？這樣我們要改很多地方才能做全雙工..
劉備(PO)：耶，不用考慮全雙工，我們這個應用基本上只要雙工就可以了！
關羽(RD)：原來如此，是我想太多了..

在一番討論後，大家才能真正清楚 PO 想要的東西，而不會多做或少做，或著方向不對。此時再出一次牌，通常就能取得共識了。
在經過撲克牌大賽後，可以得到每個 tasks 需要的時間：QML 5, C++ 20, Unit Test 20, UAT 20, Code Review 8，合計73小時。
剩餘的 Story B ~ Story F 也是照一樣的方式去得到需要的時間，可能是 B:80, C:100, D:64, E:38, F:48，這樣 PO 就很清楚，在這個 sprint 有限的資源內(288)，可以去完成那幾個 stories(D應該做不完，E跟F就不要想了...除非運氣很好。

在 PO 很清楚知道資源有限的狀況下，他就必需去做抉擇。如果現在只有 1 個 sprint 的時間，你沒辦法 A~F 全做，你要考慮清楚最重要、對客戶最有價值的到底是那幾個!全做當然最好，但資源攤在你眼前，很清楚的告訴你：不可能！

所以我覺得透明性的帶來的好處，除了明確了解需求外，也可以讓 PO 理解資源有限，他必需非常認真的選擇他要的功能!


註1:我們認為每位 developer 一天當中完全專注在工作上的時間是六小時左右，扣掉上廁所、休息、上網，工作轉換的overhead等）。
註2:一個 sprint 為二週，扣掉第一天的 Planning Meeting 及最後一天的 Review ＆ Retrospective meeting，剩下8天。
註3:估算的過程重點在”溝通”，實際上的時間可能還是會不一樣。

                                

很多書都在強調 code review 的重要性。在我們的軟體部門剛開始成立，並沒有 code review。這個狀況持續了幾年，一直到前年，我才開始認真思考，不做 code review 真的對嗎? 於是我們從那個時候開始逐步推動 code review。

在沒有 code review 的時代，有兩件事情讓我印象深刻。第一件事情已經七、八年了，有一個週末，我們因為程式在下一週初要 release，想當然爾，工作是做不完地。所以我決定週末來加班。那時候我自詡應該當規劃者，所以平常是不寫程式碼地。可是真的來不及了，所以我得跳下來自己幹。沒想到那個週末，當我打開 project 的程式碼一看，我快嚇傻了。一個函式長達一千多行，眼睛東瞄西瞄看到的是許許多多重複的程式碼。這個該怎麼改呢? 到最後就是能頭痛醫頭腳痛醫腳，可想而知，那一個週末沒有什麼好下場了。第二件事發生在三年前左右，我們一個產品內的某一個 service，在屢次的進測，總是領到最多的紅牌。最後在產品被追殺的階段，我們發現那一個 service 無法收斂了。這時候我們開始投人進去那一個 service 進行 code review。不看不會怕，看了之後才知道多可怕。那一個 service 竟然高達一萬四千多行。可怕的是，這一萬四千多行在同一個檔案。是地! 一個 service 就一個檔案。最厲害的地方是，這個 service 破了之前的一千多行記錄，有一個函式高達三千多行。最後那一個 service 只能靠硬測的方式讓他自然地收斂。然後在後面安排 refactor。Refactor 後剩下八九千行，當然也拆了不少的檔案。可以看出來原來的作品中重複的程式碼有多嚴重。我們稱這種大函式叫："吾碼一以貫之"，這種一個函式殺到底的寫作方式，對於寫的人來說當然過癮，不用想太多次該怎麼擺變數，想一次就可以用 "很久"。但是對於看的人來說，實在是痛苦至極，看到第三頁的時候，已經不記得這個變數什麼時後宣告、什麼時候改值。諷刺的是一個函式不能太長這件事，在公司的 coding rule 當中是有提到地，為什麼還會看到這樣的事情出現？問題就在於事情沒有人去看，就容易歪掉。

這種事情就是這樣，開始總是最難地。前年開始推 code review 的時候，第一個遇到的難題就是人力的問題。這其實是一個弔詭的問題，本來寫 code 寫得很用力的團隊，突然要 "插" 一件 "本該做的事"，卻變成當時團隊多出來的事情。於是我只能動用手上所有的資源幫忙 review。然後因為遇到大家的時間不容易湊在一起，所以也請成員架上 Reviewboard 來協助分散式 code review。然後先是一個團隊持續地看到 review 活動，然後是另一個團隊的重要修改也開始 review。最讓人驚艷的是去今年初，已經有一個團隊將 Pre-commit review 自動化架好了 (用 Git + Gerrit + Jenkins)。只要 commit code，系統會自動驗證可否 build，然後會寄出 review request 給設定好的人。所以現在信箱一天會收到將近十封的 review request (說實在，加上 build 成功的訊息，一天信箱會被灌入 3, 40 封信，很快就會爆了 XD)。這樣的自動化，最有趣的地方在於讓你的 code 沒有被 review 過就不能夠 commit。因此現在對那個團隊而言，已經不是 optional, 而是 must。所以 review 活動就會被持續執行。而現在也會發現，因為 code review 的工作被拉出來，組長的工作裡頭自然會加入此項 task，所以比較不會像剛開始一樣覺得根本排不進去。

那麼到底這樣強推 review 有沒有什麼效果呢? 說句老實話，如果你期待 code review 可以大量減少 bug 數量，是比較不切實際地。但是他對於防範 non-trivial 的 bug，尤其是架構性問題、易維護問題、後續加新功能的 side effect 的防範，是有比較大的效果。另一個重點是，因為強制 code review，你可以在無形中強迫 member 去看到其他人被要求了哪些東西，下次他自己寫的時候就不容易重複同樣的錯誤。另外，自己寫的東西有人在看的時候就會比較小心一點，這些都是無形的效果。

現在開始有團隊在導入 scrum 了，在該團隊中更增加了 peer 的 code review。不再單純是上對下的 review。我覺得這樣做又有更進一步的效果，那就是懂 code 的人更多了，對於未來 task 的相互支援，也會變得比較有可能性了。這是我們在 code review 開始前享受不到地。

所以 code review 重要嗎? 非常重要。你們開始做了嗎?

討論是很重要的一件事，而且有時侯一圖勝萬言，因此如果有白板可以讓大家討論是很重要的一件事。在我們團隊的辦公室中，我們便規劃了三面白板，其中一面是當做sprint wall & burndown chart，另外二面就是 member 可以自由討論的地方，以目前團隊人數(10)來說是還蠻夠用的。這個sprint有一個功能是3位成員一起合作完成的，因此我們在白板上畫出了架構與流程來溝通討論介面該如何設計，溝通清楚後，大家在座位上一抬頭就可以看到當初討論的結論了，真是個好白板 XD。

此外，我們這間還有一台投影機及一台電視，電視最近加上了chromecast，讓團隊成員要分享畫面更加容易，有時侯要分享或討論的東西在電腦上，只要按個鈕就可以顯示在電視上跟大家討論，還挺方便的（不過FPS不高，要做影片的分享較不適合，可能還是要裝個 Apple TV 比較好）。

敏捷團隊很重視團隊成員的互相討論與分享，但如果環境因素讓成員不易分享與討論，就很難讓大家願意去分享與討論了。

你的工作環境會讓成員願意討論嗎？

「從A到A+」這本書已經上市十餘年了，裡頭一個很重要的觀念就是－先找對人，再決定要做什麼。最近 「Google 模式」 一書也很夯，在 Livehouse.in Sega 的加持下，在網路上更是瘋狂的洗板 XD，而裡頭一個很重要的觀念，一樣是 先找對人，再來做事情（找到好的人才、塑造對的文化，創新自然會浮現）。
為什麼人才是最重要的？因為我們需要的是群體智慧！在 敏捷開發 中，強調了群體智慧的重要性。在 點子就要秀出來 一書中，也提到了人類歷史上能夠閉門造車而成功的藝術家，幾乎沒有，大部份的人都是透過交流、互相學習而得到新的創意與作品。
從「從A到A+」到「Google 模式」，從「點子就要秀出來」到 「敏捷開發」，不論時間新舊、領域的差異，大家強調的精神都是一樣的－對的人 + 集體智慧。

你是先決定要做什麼，再找人才，還是先找人才，再由人才幫你決定要做什麼？
 

你是先決定怎麼作菜再找廚師，還是先請廚師再來決定怎麼作菜？

家裡附近有幾家早餐店，其中一家大部份只有老闆娘一個人獨撐大局，另外二家則是有好幾個員工。每家早餐店的客人數量感覺都差不多，不過員工多的反而常常出餐慢、上錯餐點，而一人早餐店卻可以做的非常有條理，速度也不錯。根據我長久以來的觀察，我發現了其中的奧秘...

一人早餐店：老闆娘具備了明星早餐店員工該有的特質：

1. 記憶力超強、超級會認人：她可以一邊接電話收預訂早餐的訂單，一邊聽在現場的客人跟她點餐，而且不會搞混。當你點過一次鐵板麵加半熟蛋後，以後你再來點鐵板麵加蛋時，她就會直接跟你確認：「蛋半熟厚？」，點過漢堡不加生洋蔥，以後她就會直接跟你確認：「洋蔥不要厚」。
2. 手腳快：是的，他一個人可以顧好四台烤箱、一排烤麵包機、正在煮的義大利麵跟那檯永不停息的鐵板爐，而且每當有一些新訂單進來時，他總能瞬間將生產排程最佳化
3. 心算快：要結帳時，他瞄一眼你的桌子，就知道你總共吃了那些，總共多少錢～

---

人海早餐店：這裡的員工通常不具備明星架勢

1. 記憶力普普：你講過一次的東西他可能在覆誦時就漏了，還有打電話來訂結果做錯餐的，當然，這裡的員工也不大會記得你愛吃什麼，什麼要加什麼不加，蛋是全熟還半熟，所以你每次都必需交待一遍（不過更慘的是，現在交待的也不見的記得清楚就是了..）
2. 手腳快不起來：每個人速度還好，但是做一個漢堡要三個人做－＞A對甲說：幫我烤一份漢堡，再對乙說：幫我煎一個豬排，最後再由A統一加工，每當A說：再幫我烤一份漢堡時，甲就開始想到底是剛才要烤的那份還是要再加一份，然後就需要進行「溝通」，每當有新的訂單進來時，也無法將生產排程最佳化，因為每個人都只能看到 local 的東西，沒有辦法綜觀全局。甲還不時要同步一下，問說：「所以現在總共烤二個嗎？」
3. 心算普普：當你結帳時，櫃台那位還很有可能要轉頭問另一位店員說：「他的多少錢？」，天啊，這樣不是很像冗員嗎.........而且被問的那位還要看看單子慢慢算，真的是很慢啊 =.="

當踏出人海早餐店，看著店門口寫著的：「徵工作夥伴」，我心都涼了.......下次應該帶幾本軟體專案管理的書給老闆看看，不然以我後早餐的選擇可能會變很少了。
不過我的心得是，軟體開發跟開早餐店有許多相同之處，軟體開發應該要找明星級人才來，而不是找一堆普通的人才，明星級人才可以一個人獨立完成相當規模的程式（C++ 5,000~100,00行），他不需要花時間在與其它人溝通，但如果你雇了三個普通的人才，他們花在溝通協調的時間（甲：喂，我這個不是thread-safe哦！乙：為什麼呼叫進去會block住這麼久？丙：你的介面很難用耶），可能明星級人才都已經把事情做完了（一個人做，他很清楚怎麼設計最好，別人還在 Multi-Thread 打滾時，他已經想出了一個高效的 Single-Thread 解法）。
你還認為三個臭皮匠勝過一個諸葛亮嗎，我不認為，因為扣除溝通這一點外，還有一句人月神話裡的名言：「在接受相同的訓練、同樣都是兩年資歷的情況下，優秀專業程式設計師的生產力要比差勁的程式設計師好上十倍」。如果要打造一個大型的軟體，你需要的會是幾個諸葛亮，而不是一堆臭皮匠。
後記：
今天早上又去了人海早餐店，點完餐，報紙翻沒幾頁時，店員竟然已經拎著我的早餐給我，對我說：「先生，你的餐好了，一共NT$135」，我眼淚都快流出來了，你們真的進步了，出餐的速度變快了。回到家，我真的流下淚來，我點了蘿蔔糕、漢堡、鐵板麵加一杯豆漿及薏仁漿，但是袋子裡面只有漢堡、鐵板麵跟薏仁漿，也就是有40%的餐點是沒有給我的（不過錢倒是100%都有算到）..............我無言了。只能說加油了....

大教堂和市集(The Cathedral and the Bazaar) 是一篇相當有名的文章，不過之前一直沒有看，直到後來讀了Dreaming in Code 一書後，才把這篇文章仔細讀完。這篇文章是由 Eric Steven Raymond 所寫，內容在描述 Linux 的開發模式（市集）及Raymond 自己仿照這個模式開發 fetchmail 的過程，並探討其為什麼成功，其中列了十幾項格言，有幾項個人還蠻有感覺的，如果你覺得你的團隊現在碰到了一些瓶頸，推薦你可以讀讀這篇文章。
http://www.linux.org.tw/CLDP/OLD/doc/Cathedral-Bazaar.html 這篇文章的翻譯翻的蠻好的，推薦!
[格言 1] 好軟體都是起源於程式發展者要解決切身之痛. [格言 14] 任何的工具以我們所知道的方法來使用都會有用, 但一個真正了不起的工具會以你從未想過的使用方法來發揮它的功能. [格言 19] 假如專案發展協調者擁有至少跟網際網路一樣好的媒體, 而他也不靠強制力來領導, 那麼一群人必定勝過一個人.
其中我認為最要的，仍舊是格言 1，因為它背後的含意是"熱忱"，有熱忱才能開發出好的軟體，如果你的團隊不知他為何要打造這個軟體？這個軟體到底有什麼用處？那麼，這個軟體註定不會成為一個優秀的軟體。