chakming w

Economical Agile Tools

2014-08-17T01:33:11-07:00

有人問，網上的Agile Tools，有貴、有勁貴，其實有沒有比較便宜的選項。Any Cheap Agile Tools?

其實 Post-it 就係最強Agile Tools!

網上的Agile Tools往往都要大家「主動」去看，要形成這種「動力」其實需要一段時間。而且Online Tools很早就定下一個框架，這種框架又不一定切合你的需要。

反而Post-it加一塊白版，帶來無限靈活性和可能。將它變成Kanban，將它變成Business Model Canvas，將它變成Lean Canvas，將它變成Dot Voting戰場，將它變成Retrospective工具，很多很多的可能。

每天「村民」回到這個「部族」，大家都對著這些Post-it，大家Share著同一「語言」，大家溝通會更為方便，亦清楚知道部族的短期長期目標。

連八次連續創業家Steve Blank，都叫大家買Yellow Stickers，就知Post-it簡單易用哈哈。

當然網上的Agile Tools有History Record，可以觀察下公司實作的經歷和改變，也是件好事哈哈。如果真的不想用白板，我想，用Trello + Projector也是可行的。不過我想這就沒了一種回顧和成功感（當你看著你完成的每個慢慢變少要很有趣的）。

Trying ScreenEdgePanGestureRecognizer

2014-08-13T03:29:26-07:00

學習iOS不夠半年，慢慢試慢慢玩別人的 Library。

ScreenEdgePanGestureRecognizer 還是第一次接觸。在Xcode的xib edit中看不到他的存在，向朋友解釋我在做甚麼後，他提一提才知原來有這樣的Gesture。

找到了一個與我在做的東西非常接近的東西，以Swipe轉換View Controllers。但我需要的是只能在Edge Swipe/Pan才trigger animation。改了一下別人的Source Code，用上ScreenEdgePanGestureRecognizer，順道contribute open source 的世界。

這樣便大半天了哈哈。

Applying new ideas to the team 推動團隊改變

2014-08-09T19:20:13-07:00

If you’ve learned a lot about leadership and making a movement, then let’s watch a movement happen, start to finish, in under 3 minutes, and dissect some lessons:

A leader needs the guts to stand alone and look ridiculous. But what he’s doing is so simple, it’s almost instructional. This is key. You must be easy to follow!

Now comes the first follower with a crucial role: he publicly shows everyone how to follow. Notice the leader embraces him as an equal, so it’s not about the leader anymore - it’s about them, plural. Notice he’s calling to his friends to join in. It takes guts to be a first follower! You stand out and brave ridicule, yourself. Being a first follower is an under-appreciated form of leadership. The first follower transforms a lone nut into a leader. If the leader is the flint, the first follower is the spark that makes the fire.

The 2nd follower is a turning point: it’s proof the first has done well. Now it’s not a lone nut, and it’s not two nuts. Three is a crowd and a crowd is news.

A movement must be public. Make sure outsiders see more than just the leader. Everyone needs to see the followers, because new followers emulate followers - not the leader.

Now here come 2 more, then 3 more. Now we’ve got momentum. This is the tipping point! Now we’ve got a movement!

As more people jump in, it’s no longer risky. If they were on the fence before, there’s no reason not to join now. They won’t be ridiculed, they won’t stand out, and they will be part of the in-crowd, if they hurry. Over the next minute you’ll see the rest who prefer to be part of the crowd, because eventually they’d be ridiculed for not joining.

And ladies and gentlemen that is how a movement is made! Let’s recap what we learned:

If you are a version of the shirtless dancing guy, all alone, remember the importance of nurturing your first few followers as equals, making everything clearly about the movement, not you.

Be public. Be easy to follow!

But the biggest lesson here - did you catch it?

Leadership is over-glorified.

Yes it started with the shirtless guy, and he’ll get all the credit, but you saw what really happened:

It was the first follower that transformed a lone nut into a leader.

There is no movement without the first follower.

We’re told we all need to be leaders, but that would be really ineffective.

The best way to make a movement, if you really care, is to courageously follow and show others how to follow.

When you find a lone nut doing something great, have the guts to be the first person to stand up and join in.

頗感動的一段片。

推動團隊的改變，從來都不是單方面推動。其實是整個團隊合作慢慢建立信任，投入感，一開始一個兩個三個人，慢慢將整個運動帶給不同人，最後建立了那股推動力，自自然然就改變了大家。

有時都不太明白我為何總是想推動大家，向Clean Code 進發。看到了Agile和Lean後，更相信這一套看法，但我實力還未追不上，又不太敢輕言叫大家嘗試。

結果就與另一位朋友「互相發功」大家推動學習為先。學習的成果，這一兩年來有目共睹：因為習慣了Dependency Injection的關係，很多Classes都不會做太多的事 (Single Responsibility?)。因為嘗試更多Clean Code，開始對拆解的觀念變得純熟，慢慢地Pattern就自然走出來了。又因為嘗試了更多的Pattern，開始在不同的範疇靈活運用。又因為嘗試了太多，都不再對嘗試新事物產生太多恐懼，不同的新事物不斷將開發時間加速與改進，非常有趣。

那時在「一間工作了最久的startup」工作，算是帶動到了學習氣氛？前前後後，說服大家一起分享、一起學習，花了近三四個月的時間。

朋友兼同事與我，在開始想推動的時候，可能太過進取，將太多新詞滙貫進大家腦中；可能因為大家對不少東西已有第一印象，當大家聽到它們的時候，容易有「我很忙，沒時間理會這些東西」的錯覺，造成不少反效果。

及後，由自身出發，在lunch free time看Uncle bob的片(很貴!)，又買又看Engineering書，在開發過程中滲入Clean Code的concept。

或許是大家看到兩個傻人為何不斷學習之下，大家開始感到有興趣？終於有機會開始向大家分享不同的 Software Engineering，嘗試更多有趣的東西。

雖然我離開了這團隊，怕他們不會繼續分享，但某日回去，竟然看到他們繼續分享和學習的心態，甚至建立了一套Code Review的方法，感覺很不錯哈哈。

大家繼續努力！我相信學習從不停止。

因為它們實在有趣。

以慢打快

2014-07-26T20:28:31-07:00

「天下武功，唯快不破。」

最近有另一種體驗。

最近在學素描。模特兒通常只來兩堂，每堂都只有約兩小時，中間還有約半小時的休息時間，所以畫的時間都很倉猝。頭幾堂，不懂畫。大多時間亂畫，又問老師很多問題。或許是因為心急完成畫作，開始在最後的時間亂來，結果，需要老師出手哈哈。

看著老師一學始畫得很慢，但後段加速竟然可以快到一個難以置信的地步。加上他本來就需要指導油畫堂的同學，可以想像他根本就沒有太多時間素描，但畫作卻沒有絲毫亂來之感。畫有神韻，畫的時候又冷靜坦然，簡單幾筆﹐同學們都非常佩服。

老師總是提醒著：「要快不難，但 快是由很多很多的『慢』組成 。」當基本功練得好，例如觀察，比例控制，定位，分面，往後做明暗分界線，選擇重點，很快就能加速。

慢慢開始了解到一開始要慢，要多些思考和觀察，那個「亂」的上升速度會比沒有計劃的慢。每節休息時間又可以抽身，走遠一點看看自己的畫，用另一種角度看。

素描真的很有趣哈哈。

最近比較滿意的畫，因為告訴了老師自己太想以完成為目標，他提出了畫三堂的做法哈哈。

其實不只是素描，很多東西也是。

「天下武功，唯快不破。」

但快的功力，正是由慢以來啊。

客戶「口是心非」Your Customers Do not Mean What They Say

2014-04-27T06:28:47-07:00

歡迎來到 Engineer讀書會 - Round 2，這次繼續97 Things Every Programmer Should Know中，Your Customers Do not Mean What They Say，筆者譯作「口是心非」。

原文翻譯。

我遇到的顧客，開會討論他們想要甚麼的時候，通常不太愉快－特別在討論「細節」的時候。他們多數會隱藏心中的想法。他們不是騙子，但他們經常以「客戶」的口吻討論，卻沒嘗試用開發者的角度來說明。他們有自己一套「專有名詞」，自己的「世界觀」。他們忽略某些重要細節。他們覺得你在他們的行業打滾了20多年。他們不知道自己最想要甚麼！有些客戶能看透大局，但很少利用圖像有效解釋。又有一些客戶只知道自己「不想要」甚麼東西。

這麼多的問題，怎樣才能知道客戶心中所想？簡單。和他們交流更多吧。

嘗試問些刁鑽的問題。 越早越好。越多越好。 不要被他們帶領整個會議的流程。記著：

客戶們都「口是心非」。

我經常抱著懷疑態度，改變某些字眼，再質問他們，「挑戰」他們的想法。你往往發現「客戶」和「產品用戶」的想法相差甚遠。那位客戶還期望你好好跟上他對產品的想法，而不是「用戶」的想法。你會非常混亂，大大影響系統開發。

直至你覺得你明白客戶的想法前，鍥而不捨地討論吧。兩次、三次，提出相的同題。 試試將你先前所了解的與討論後所知道的，重申一次給他們聽。 如果可能的話，與客戶們每個人進行「一對一」的交流。你會發現每一個人都會有自己獨特的想法，甚至客戶內部每個人的想法，都會有矛盾的情況。如果你不想接下一個爛工作的話，在開始寫程式前，好好拆解每個人的想法，明瞭不同想法的差異之處。

好好善用圖像工具。白板，是很不錯的選擇，特別是早期階段，設計雛型的時候。這些做法早就經過科學證實，能大大幫助討論。圖像可以延長開會集中力，長遠而言，整個圖像框架可以保留下來，下次討論的時候，不容易忽略上以開會討論過的細節。

我以前是一個「多媒體開發者」。有一次，客戶告訴我們很多細節。在早期設計的會議上，主動提出她想要的色調搭配，要以黑色背景為主。我們跟著黑色色調進行設計。團隊們設計了很多東西，花了很多人力物力去塑造、完成產品。當我們將完成品交予客戶的時候，卻收到了極震撼的消息：「我說要『黑』，其實是『白』」。

看吧，黑與白，其實很難分辨。

By Nate Jackson

Agile Manifesto 敏捷宣言有四點，其中一點是：

Customer collaboration over contract negotiation (「與客戶合作」重要過合約、談判)

［注：這裏不否定合約的重要性（作為協同，訂下合作範圍），但互相合作才是重點。］

我們為何要在早期時候花時間，拼命地明白客戶想法？筆者想到的答案有很多，但百變不離其中：越早知道問題，越早找出辦法，對往後有好處。

商業角度一點看，好處在那？重點是軟體 「改變的成本」 。來幅圖像說明一下。

當我們越早找出問題根本，便越能有 低耗資源 的對應方法，去應付每次改變。而將問題留待越後，要改，要變，成本越重。上圖不少都是Extreme Programming的做法，好讓開發過程提早發現問題，將「改變成本曲線」降低。

假設你每次的專案都只能開一次會，你能夠想像完成品有多大機會「打回頭」重新做過？你覺得客戶願意接受一個製成品，及後改變的資源時間異常多嗎？如果缺乏客戶交流，你能想像最後受罪的，會是你的團隊嗎？

這些內部的損耗，會對團隊影響可以有多大？以為OT OT OT便能解決一切問題，其實背後 根本的問題 解決了嗎？

制訂完合約後並不是指不用再溝通。雙方也應定期溝通定期檢討，提前了解錯誤的地方，好讓改變成本減低，對雙方均有好處。記著不要盲目做，忽略 定期檢討的好處 。

有趣的是，如果採取「相反做法」，事前太詳盡計劃又會怎樣？

有些人也許覺得在前頭「寫好計劃」，有多少細節都記錄在案，交予團隊便不用將「浪費時間」討論。但我們往往 隨著時間越多才會對專案認識越多 ，而不是專案初期就能瞭如指掌。不少 事前假設 讓他們以為一切會跟著計劃走，卻引致過早開發多餘功能，增加「改變成本」。

這亦正正代表「詳盡計劃」其實不是甚麼相反做法，同樣地忽略 定期溝通 的重要性。

要花時間定期溝通、互相合作，很難嗎？太理想化？我想，客戶投入的程度往往說明，它對專案有多認真吧。

總有些改變，不是討論過後就能提早發現對吧？那些問題「到時候」才變的話，系統設計能容易導入新功能嗎？開發者有方法減低改變成本嗎？那，又是另一個故事了。

童軍守則 The Boy Scout Rule

2014-04-20T22:56:57-07:00

歡迎來到 Engineer讀書會 - Round 1，這次推介的是97 Things Every Programmer Should Know中，所提及的Boy Scout Rule - 童軍守則。

筆者嘗試翻譯原文。

童軍有一條規則：

每次你到過的營地，離開後要比之前更乾淨。

如果我們將這個習慣套用在程序員身上：即使是小問題，即使那些程式的原作者不是你，我們都一一清理。最後會變成怎樣？

只要維持這個簡單的習慣，我們不會再見到那些「無止境式墮落」的軟件。系統每次都會因為我們的每次的改變，而變得更好。我們不再是依賴一兩個人的付出，而是整個團隊都會感受到大家對系統的珍惜呵護。

Boy Scout Rule不是指 「凡事完美」 。只要你每次改動都比之前更好，就非常足夠。這意味著你每次加一個新組件新功能，都一定要比之前乾淨。你可以改變某些 variables 的名稱(讓其他人更快更易明白程式的上文下理)，可以將一些寫得太長的functions/methods 一分為二(extract methods)。你可以拆解Circular Dependency，又或者加入新的Interface 來隔離兩者的依賴(Interface Segregation Principle)。

這個習慣就像將垃圾掉入垃圾埇一樣。亂拋垃圾是不應該的行為，就正如你每次對系統作出的修改／加減一樣，都不應該雜亂無章。

Boy Scout Rule 還有更多。我們不只是關心自己的Code Quality，而是連團隊的問題都一同關心。好團隊應該互相幫助，將其他人忽略的東西都整理好。好團隊維持清潔的好習慣，不只是對自己有利，而是對往後每一個人都有好處。

Uncle Bob的書很好看，特別是Clean Coder。Programmer每一個人都應該抱有尊業精神，去看待你所接觸的每一個軟件/系統。

筆者非常認同，Clean Code其實是「潔癖」的一種。但它是一種非常良性的強迫症。從Programmer的角度，Clean Code方便我們維護系統，對Refactor，對新同事上手，對重用或加減新功能有很大影響。但 Clean Code的商業價值在那兒？

Clean Code的商業價值其實正正在於它的品質，會影響發展速度。

我非常建議大家每天紀錄Debug與開發的比例，將這個比例告訴上司或是其他人。這個比例往往說明，從前所留下來的所謂「Technical Debt」，對今時今日，甚至往後所帶來的，根深蒂固的問題。Software Engineer 亦應該好好裝備自己，不要再將沒有時間學習成為你的借口。

接下來仍會為大家送上97 Things Every Programmer Should Know其他好篇章。

何謂快？

2014-04-04T12:28:27-07:00

回應《Startup就是一窩老鼠》。

我很認同Startup是追求速度的民族。再沒有比Startup願意為速度犠牲一切。例如不用寫Test可以提高開發速度，覺得OT是犠牲私人時間換取公司發展，或者沒有停下來的時間思考，再前衝便是云云。而這些犠牲造成的等價交換，或會是客戶的喜愛、忠誠。

據筆者了解，這個民族往往容易忽略「速度」的意思。

二分法的世界

又提一次The 7 Habits of Highly Effective People。我們不知何時習慣將世界的真理用「二分法」來看。大與小、對與錯、快與慢、輸與贏。

我們的教育制度，一直以高分來定義學生的好，各式各樣的比賽來定奪參加者的能力優次。我們世界定律不是如此？

犧牲品質可以增加開發速度？

Engineering的速度，原來在多年前己有「定案」。只從敏捷宣言開始，Engineering界各種形式的討論走了出來。Kent Beck提倡的Extreme Programming，非常具體地提出各種好觀念，指出不少。而其中，品質， Quality ，非常關鍵。（談談XP Principle有中文解釋，值得一看。）

公司內部的情況亦不能忽略。

我們都明白「客戶」是公司的大關鍵。解決他們的問題，完成客戶的要求，非常合理。可是，經常濫用「技術債」一字，覺得有借，可以以後再還，那是不切實際的想法。而背後理由，是內部發展的問題。

在商言商，你願意見到公司成立初期便要經常花時間處理Bugs嗎？（系統「墮落」的速度，不少人早已指出，是非常快的。）你能否想像每天都在救火而沒有開發新功能的日子嗎？（系統很有可能根本應付不了客戶將來的要求。）你能否想像員工士氣低落嗎？你能否想像同事每晚都要三更半夜被告知系統有問題，而明天仍要返工的日子嗎？

而最難以想像的，是那些同事根本不打算告訴你系統「早而沒救」的消息，到你發現公司人事變動很快的時候，才發覺原來「系統設計」的影響力如此大？

很多很多的因素都會導致公司內部的齒輪運轉速度減慢。但你你你，有沒有停下來想過以上問題？

我非常建議Startup嘗試一下：

記錄公司開發時間與處理Bugs的時間。如果這兩者的比例是一比一，不用說，背後問題一羅羅。

品質優先是Startup定律？

不，只是我相信這個世界很大，很多東西沒有既定答案。筆者比較傾向以Engineer based Startup作為討論的方向，以上想法，不一定能套用其他地方。

不過，品質對長遠開發而言影響力深遠。

如果你問，香港人才的技術有限，講求品質談何容易。筆者只能說，是你未遇上好的Engineer而已。或是你太集中在香港找人才，缺乏全球化的世界觀。筆者早就覺得大陸的Engineer技術與溝通都非常成熟，甚至Startup風氣比香港更甚。

那怎樣才可以讓系統更易開發? 那，又是另一個故事了。

有甚麼比在Startup工作更能學到如何營運一間Startup？

2014-04-04T12:27:20-07:00

沒有。所以我已經在三間Startup工作過了。

Recommend: 從前有一個港口小城市

回應《用大過整》

2014-03-30T12:28:09-07:00

看到了《用大過整》後，總是想著要回應一下。

「決定整甚麼」與「如何落手做」都是 Lean 一直想解決的問題之一。「這麼多的Code，大部份，最後會無人用」，和「知難過整」，這兩個想法都是不太了解Lean才會出現的問題。

決定整甚麼

「決定整甚麼」其實可以落手落腳從詢問用戶開始。筆者推薦Running Lean一書。內容提及可以利用 Lean Canvas(Revised Business Canvas)，在九格Business Model一一填上，然後開始 Problem Interview 。

Problem Interview 主要是透過訪問調查的形式，嘗試證實以下三個假設成立：

Target Customer Segment 主要客戶群

Existing Problems 客戶遇到的問題

Existing Solution 客戶現在有沒有在用任何東西解決以上問題

這個做法就是以不開始尋找或實作任何解決辦法，全力尋找大方向的路。

要怎樣做，不難。難在你需要有失敗的決心。因為你必需要知道自己一直在以大量「假設」為業務基礎，現在你大有可能需要面對自己一直以來 錯估形勢 ，一直提出大量假設，說服自己所做的事會有用戶，會有價值，卻和你所想的大相逕庭。

這做法，好處就是不用盲摸，省卻開發資源。在直接面向潛在客戶的狀態下，還可以開始建立客戶群和測試群，對將來測試產品，尋找接近客戶群，宣傳，都非常有利。你或會聽到他們會重覆某些關鍵字眼，日後可以成為你的宣傳口號。

如何落手做

在完成幾輪Problem Interview之後，找到一條有爆發力的一條路，就可進入 Solution Interview 。此時才進入「實作階段」，但也不是甚麼都做。大家可以開發你的Minimum Viable Product (MVP)。

Minimum一字實在有誤導成份。它並不是以最少錢最少資源為目標，而是剛足夠吸引客戶嘗試產品的情況下，適當地開發你的產品。

在上Certified Scrum Master的堂上，有一個簡單的堂上練習：

你們將要建立網上寄咭服務，請將不同的User Stories按推出市場的次序排列

堂上不乏銀行的PM。他們傾向以功能完整性出發，想先做好Card Design System，讓用戶可以設計咭片，不論大小，樣式，還可以上載自己的圖片，加上文字圖案。

但整個網上寄咭服務，最重要的寄咭服務，竟然擺在最後？如果將Customization的功能放到最後，先完成寄咭服務，再以兩三個Design Template開始，並慢慢增加其他功能，不是能夠減省推出市場時間麼？及早推出市場，收回反饋並尋找改善空間，不正是Lean的中心思想麼？

對Lean的慢慢了解，就完全想像不到為何「這麼多的Code，大部份，最後會無人用」的浪費情形。

但如何定義有市場、有價值的路？Solution Interview又怎樣做？在Engineering上如何配合Lean？那，又是另一個做事了。

I'm busy. I got no time at all.

2014-03-29T12:28:37-07:00

好多人都話自己忙。

最近睇左一本叫The 7 Habits of Highly Effective People的書。

書頭並未開始講及七個習慣之前，作者提到分享的力量。分享會幫到大家容易了解書本的內容，又可以影響下身邊朋友既睇法，有利無弊。

其中筆者比較喜歡的是第二個習慣，中文或者可以叫做 「長遠計」 。

長遠計

我想大部份人都會明白忙其實可以有好多意思。所謂「忙」其實可以看成「重要性」和「迫切性」兩個範疇，劃分為一個2x2 的方格:

先說說三個非重點方格。

又急又重要

圖中第一格，我們大部份的時間都花在這一個位置。（看來是理所當然的嗎？）

我想大部份公司基本上，都將所有工作所有任務都標籤做又急又忙。這一格很容易隨著時間越久，只會越來越大。原因？因為我們都 喜愛短時間內解決問題為基礎 。

不論工作或是學習環境，大家都喜歡以最少時間完成最多工作，覺得工作效率高便是好員工，有能力。

再來一幅圖改變大家想法。

書中並非否定這一種想法，可是這想法卻讓人難以停下思考，或檢討工作上一直以來的大問題。

某些惡性循環之下，這一格會罷佔你所有時間（或者是工作時間）。這個時候你的效率或會降到零。你或許不知道自己在忙甚麼，或者被很多突如其來的事阻礙你預先計劃的工作。

這個時間可能是「 ~~請人良機~~ 」（大誤！筆者相信這是窮忙的開始）。

急，但不重要！

圖中第三格，這明顯是技術錯誤。

這與上面提及的差不多，但連重要性都忽略了。時間放在不必要的地方，對Startup來說非常致命。

不急又不重要

圖中第四格，以下省略……

重要，但不急？

這是書中提及應該花時間的地方。

道理很簡單：長遠計，做那些東西可以省卻將來的時間？

我們可能一直在用一個方形車輪推著前進。但我們無人留意，無人提出方法，大家死命向前。原來你停下來，想一想那些重要的改變，並願意花些時間改變（用圓形車輪！）就能慳水慳力。

這就是在套用80/20理論的其中一個好例子。

書中一直提及 「有效 > 效率」 ，謹記著這個法則，很多道理也很易懂。

Engineering的慳水慳力要點做？這，又是另一個故事了。