Problem Solving 的技巧 (3)：因事制宜
不知不覺，這類文章可以寫到第三篇，感到頗意外的。前兩篇是：
昨天看到 TonyQ 在 Soft_Job 寫的文章：《Re: [閒聊] 你在開發程式時，是重視績效還是品質。覺得深有同感，摘錄幾段如下：
在討論這個議題前，我想先強調，為了方便聚焦討論，我們往往會先偋除一些條件，或是先依自己的假設開始論述。而有爭論的地方，往往卻是這些隱藏的前提。好比說「寫測試碼重不重要？」單單這樣一個命題，只能討論出很模糊的概念，不論支持與否，看起來都有些道理。但加入一些條件後，像是「這是長期開發並有多人參與的專案」或是「後天要交的雛型」，相信大家對此會有不同的答案，也會少一些分歧。相關的想法，可以參考《黑天鵝效應》。 這篇有摘要讀書心得，其中敘事謬誤和戲局謬誤啟發我這個觀點。
我的想法是，在達到必要需求的前提下，依個人以及團隊的能力，看看能提昇多少品質。問題在於，何謂 must have、何謂 nice to have，每個人的見解不同。爭議點在於，每個人的能力不同，導致評估的實作成本不同。一樣是 nice to have，有些被認同可以做，有些則否。
( ps. 這篇文章不討論規格不明確的問題，這是另一個大議題。 )
舉例來說，A 認為現在重構只能提升一點品質，卻要花兩天；B 認同 A 評估的品質，但 B 覺得只要花半天。所以 A 覺得不划算，而 B 持相反意見。從這樣的評估結果很難說 A 或 B 誰對誰錯，也許 A 沒重構經驗不信任重構，也可能 A 有豐富的經驗，估得比 B 準。
在體認到個人能力不同、習慣不同的前提下，對自己的要求是盡量提高自己的能力，多付出時間提高品質，減少日後維護成本並能練功，形成正向循環；對其他人來說，看對方是那種人，是「過」或「不及」，再從另一個角度和對方討論。
舉例來說，若團隊成員不熟或不認同 unit test。當下就要出貨了，這時硬要大家學習並實作測試，並不適合 (不如當「負面教材」，待下次專案的開頭提出討論)。但若成員有過相關經驗，同樣時程下，就能針對核心程式補些測試，花最小成本減少最多風險。當成員嘗到測試甜頭，不小心寫過多測試碼時，和對方討論優先順序，減少寫 C/P 值低的測試碼。
回頭看品質的問題，能力愈強、經驗愈豐富，增加 nice to have 的成本愈低，自然能前期處理，減少技術債。反之，在時程的考量下 (ship or die)，能力和經驗不夠時，得選擇先放過一些潛在問題，日後仍有需求時，再花更多成本補救。先活下去，才有更多的本錢來還債。
因事制宜說來簡單，只有四個字而已。實務上卻需經年累月的經驗，不止要考量時程、未來需求變化等項目，也要留意每個人的能力和習性，才能在當下找到較為適當的平衡點。而增加經驗的方法，如同杜書伍在《打造將才基因》裡所言，除了比別人投入更多時間外，沒有其它的捷徑。
2011-09-25 更新
看到 Thinker 提了他的相關看法：《程式碼要清的多乾淨?》，裡面提了不錯的建議：
昨天看到 TonyQ 在 Soft_Job 寫的文章：《Re: [閒聊] 你在開發程式時，是重視績效還是品質。覺得深有同感，摘錄幾段如下：
對我們來講很多其實可以是 nice to have 的東西， 都會被我們當成 must have。在 Plurk 上貼了這篇文章後，Thinker 和 qrtt1 提出另一面看法，強調「早期發現，早期治療」的好處。於是決定借題寫一下自己的看法。
這個判斷是經驗跟 domain 累積下來的，沒有公式，沒有法則， 做久了你就是會知道什麼架構之後會一直噴 exception ，
而且你還會知道等他出事時你一定沒辦法好好處理， 所以你要在這個當下把它處理掉。
...
觀察他們影響到哪些地方，你有沒有能力測試他們， 還有你的環境允不允許這件事情帶來的不穩定性。
一般來講，如果是我個人自己的專案，我非常不介意大改， 只要我後續還有時間可以處理這些出來的問題。
對公司或者客戶的專案，我會採取相對保守的態度。
這是對風險管理的策略問題。
在討論這個議題前，我想先強調，為了方便聚焦討論，我們往往會先偋除一些條件，或是先依自己的假設開始論述。而有爭論的地方，往往卻是這些隱藏的前提。好比說「寫測試碼重不重要？」單單這樣一個命題，只能討論出很模糊的概念，不論支持與否，看起來都有些道理。但加入一些條件後，像是「這是長期開發並有多人參與的專案」或是「後天要交的雛型」，相信大家對此會有不同的答案，也會少一些分歧。相關的想法，可以參考《黑天鵝效應》。 這篇有摘要讀書心得，其中敘事謬誤和戲局謬誤啟發我這個觀點。
我的想法是，在達到必要需求的前提下，依個人以及團隊的能力，看看能提昇多少品質。問題在於，何謂 must have、何謂 nice to have，每個人的見解不同。爭議點在於，每個人的能力不同，導致評估的實作成本不同。一樣是 nice to have，有些被認同可以做，有些則否。
( ps. 這篇文章不討論規格不明確的問題，這是另一個大議題。 )
舉例來說，A 認為現在重構只能提升一點品質，卻要花兩天；B 認同 A 評估的品質，但 B 覺得只要花半天。所以 A 覺得不划算，而 B 持相反意見。從這樣的評估結果很難說 A 或 B 誰對誰錯，也許 A 沒重構經驗不信任重構，也可能 A 有豐富的經驗，估得比 B 準。
在體認到個人能力不同、習慣不同的前提下，對自己的要求是盡量提高自己的能力，多付出時間提高品質，減少日後維護成本並能練功，形成正向循環；對其他人來說，看對方是那種人，是「過」或「不及」，再從另一個角度和對方討論。
舉例來說，若團隊成員不熟或不認同 unit test。當下就要出貨了，這時硬要大家學習並實作測試，並不適合 (不如當「負面教材」，待下次專案的開頭提出討論)。但若成員有過相關經驗，同樣時程下，就能針對核心程式補些測試，花最小成本減少最多風險。當成員嘗到測試甜頭，不小心寫過多測試碼時，和對方討論優先順序，減少寫 C/P 值低的測試碼。
回頭看品質的問題，能力愈強、經驗愈豐富，增加 nice to have 的成本愈低，自然能前期處理，減少技術債。反之，在時程的考量下 (ship or die)，能力和經驗不夠時，得選擇先放過一些潛在問題，日後仍有需求時，再花更多成本補救。先活下去，才有更多的本錢來還債。
因事制宜說來簡單，只有四個字而已。實務上卻需經年累月的經驗，不止要考量時程、未來需求變化等項目，也要留意每個人的能力和習性，才能在當下找到較為適當的平衡點。而增加經驗的方法，如同杜書伍在《打造將才基因》裡所言，除了比別人投入更多時間外，沒有其它的捷徑。
2011-09-25 更新
看到 Thinker 提了他的相關看法：《程式碼要清的多乾淨?》，裡面提了不錯的建議：
除了能力不同之外，個人的膽量、積極態度和價值觀也同樣影嚮著評估的差異。 我強調的是，積極態度和個人的能力呈正相關。勇於嘗試、有控制性地犯錯，對於學習很有幫助。我覺得在我學習的前一大段生涯裡，過於謹慎而不敢犯錯，以致於學習速度較為緩慢。而我認識一些晚起步、卻成長相當快的朋友，都具有大膽嘗試、不斷犯錯的特質。他們快速地累積經驗，並培養出更多的膽識和更大的企圖心。
...
要評估自己的能力，並適度的承受犯錯的風險。
Reference:
http://fcamel-fc.blogspot.ca/2011/09/problem-solving-3.html
No comments:
Post a Comment