怎樣才算敏捷?

August 29 20:40~21:50

 

先說明一下，這個問題，沒有什麼正確答案，必須要自己用心體會。

先思考一下這幾個問題：

• 聽說敏捷方法都沒有在寫文件的耶，這樣怎麼行？
• 我最近用到前人寫的元件，都沒有說明文件可以看耶。所以我打算在下個sprint中，安排一些時間來補寫API的使用文件。
• 有了這個電子化看板（taskboard）之後，我就可以從電腦上看出來每個開發人員每天花了幾個小時、做了哪些事情、check-in那些程式碼。
• （承上）而且這樣我就可以透過這個系統來review開發人員的程式碼了。

以上所說，和敏捷不敏捷有何關係？

故事一

安辛啞的寫真集一本80塊，搖搖的寫真集一本60塊。鄉民們手上只有100塊，請問要買哪一本？

鄉民甲：安辛啞比較可愛，當然是買她的啊。

鄉民乙：搖搖比較大…方…又平易近人，而且一本只要60塊，當然是買她的啊。

鄉民丙：你們很笨耶，沒看過食神嗎？當然是兩本一起買啊。

阿兩：當然是買安辛啞啊，因為她會模仿搖搖 。

眾鄉民：誰是阿兩？

Teddy：不重要，來亂的。繼續看下去。

鄉親們，誰都想兩本一起買。問題是，別忘了你手上只有100塊，在有限的資源之下，要做出最合適的選擇。兩本都想買，最後很可能落得一本都沒買到。

敏捷方法要不要寫文件？有需要、有時間，那就去寫。有需要、沒時間，就安排合適的時間寫。沒需要，有時間，也不要寫。沒需要，沒時間，當然不寫。重點是，從對於「有沒有需要」這件事情的判斷，就可以看得出每個人的敏捷力（好玄啊 ）。

***

故事二

主管：團隊自從用了電子化看板之後，每天都有乖乖地填入工時，這樣每週每個人在那些專案上所投注的時間都一清二楚，這個系統真好用。

烏鴉嘴：有了這麼好的系統，怎麼案子還是都延遲、客戶還是不滿意、bug還是那麼多？

如果想要做code review，為什麼不鼓勵pair programming，而要事後再來做？啊，因為只有你有資格幫別人做code review，而你又是全團隊最忙（到處開會）但卻沒有時間做事的人。所以，「會議好多都沒時間去做code review」就成為專案的「現況」。

想知道團隊成員每天都在幹什麼，為什麼不實地觀察？「皇祖母有云：奏摺是天底下最不可信的東西」。要靠報表治理軟體開發團隊，有誰成功的請好心的分享一下相關經驗。

***

鄉民：以上講了這麼多廢話，該講的事情都沒講。

Teddy：對不起，我該講什麼？

鄉民：就「怎樣才算敏捷啊」！

Teddy：喔、喔，對耶。答案很簡答…如果這一次Teddy再搞什麼「一字曰之心」這種老艮，鄉民們就可以準備轉台了。各位觀眾，答案是：

在做決定的時候，思考這個決定是否對於對客戶價值真的有所提升，這就是敏捷精神（的一種體現）。

姥姥 鄉民：這哪招？

大家都想要提升客戶價值，也都以為「這樣」（自己正在做的事情）可以提升客戶的價值。難就難在，如何判斷某個措施或是制度，只是在做白工，還是在提升客戶價值。

這就要靠鄉民們的智慧去自行判斷啦。不然有機會多參加C. C. Agile每月一次聚會互相交流一下，也是一個不錯的提升功力的途徑。

***

友藏內心獨白：拜託，一個月才辦一次，然後名額才20個，要哪一天才搶得到啊…Orz。

PS：活動報名不到會發生很恐怖的事…不要問…真的很恐怖啊。