關於敏捷開發 - 天下武功，唯快不破?
在科技越來越便捷的時代裡，「速度」似乎晉升成為了絕大多數工作裡最重要的指標項目，「我們講求快速開發快速修正」「東西先作出來比較重要，不好我們再繼續調整」「我們平均每三天修正一次版本」諸如此類的對話在生活中越來越常出現，好像比起一切其他事情，只要不夠「快」就成了罪大惡極的事情。
但，真的是如此嗎?
對於這樣的觀念仍然抱持著強大的疑慮，原因在從小到大的自身經驗裡，對於太快把事情完成而經常造成不太好的結果總有著相當深刻的記憶，而通常在面對那些不好的產出後，我們會將原因回頭歸咎於過程裡所有的太不小心，甚至創造出「太倉促」等應該可以歸類到負面形容詞的辭彙作為事件進程的敘述。
所以大量拋棄標準作業規範只為了把速度提升到極致的這種做法到底好不好？
其實在問這個問題之前應該先想想，
自己的題目到底是什麼？
面對的使用者種類為哪些？
可能面臨的風險在哪裡？
很久很久以前中國有個蠻有名的人，姓孫，寫了中國史上最著名的一本交戰懶人包，叫作孫子兵法。這本書有多神相信已經不用多加贅述，其中一篇非常有意思，甚至在2012年被西方好萊塢科幻大片《超級戰艦》裡取了部分作台詞之用－『不知戰之地』。
其原文來自孫子兵法第六篇《虛實篇》裡其中一段，整節段落為
「故知戰之地，知戰之日，則可千里而會戰。不知戰之地，不知戰之日，則左不能救右，右不能救左，前不能救後，後不能救前，而況遠者數十里，近者數里乎？」
整段由現代人嘗試揣摩孫老先生用字後大致上可以翻譯成
「既預知與敵人交戰的地點，又預知交戰的時間，即使行軍千里也可以與敵人交戰。不能預知與敵人交戰的地點，又不能預知交戰的時間，倉促遇敵，就會左軍不能救右軍，右軍不能救左軍，前軍不能救後軍，後軍不能救前軍，何況遠的相距十里，近的也有好幾里呢。」
由此大概可以了解如果現在把「敏捷開發」一詞拿去對孫先生宣傳，大概可以想像岀他老人家搖頭的模樣，畢竟他崇尚的是「只要知道時間地點，要我走多遠都沒問題阿」這麼hardcore的理念。
所以回到前面提出的三個問題，
為什麼需要先問問自己的題目是什麼？面對的使用者種類為哪些？可能面臨的風險在哪裡？
其實與上述孫子兵法該篇道理相同，目的是需要先確認自己即將投入的戰場(市場、使用者)在哪，因為只有在確定戰場後才有決定怎麼前往的道理。只期望透過追求不斷快速調整的方式進軍，事實上也的確會前進，但綜觀來看就如同走到哪打到哪，遇見打不過的城池就轉彎打旁邊另外一座，到頭來也許的確能攻下不少城池，但如果那不是一開始最中意的領地，攻下了又能代表什麼？同時，適用於不斷更換方向的方式應僅只適用打前鋒的行軍部隊，對後勤補給部隊來說，如果無法明確知道接下來的幾週甚至幾天內會有怎樣的戰役，就無法將資源作最有效率的供應補充，也就是孫老所謂的「左軍不能救右軍，右軍不能救左軍，前軍不能救後軍，後軍不能救前軍」，而我們都知道，無論前方猛將再怎麼勇猛，少了珍奶跟雞排的及時能量補充，終究還是有非常大的可能因斷糧而敗陣。所以，常常有人說敏捷開發是最適合新創團隊的方式，其實或許正好相反，在使用敏捷開發這樣可能造成後勤補給無效率的狀況下，適用對象應該是有雄厚資源可以消耗的部隊，而不是初期可能兩個麵包要分三人吃或者一人就要身兼前鋒與後勤的迷你部隊，因此下次如果再有團隊成員提出「我們應該要採用敏捷開發的方式」時，記得先靜下心來好好討論一下團隊狀況是否適用這樣的方式，以及記得那樣只是行軍的方式，而不該是決定最終戰場的方式。
延伸推薦閱讀：
嫁給RD的UI Designer : 為什麼我不推薦敏捷開發