l

2012年8月30日 星期四

怎樣才算敏捷?

August 29 20:40~21:50

image

 

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

先思考一下這幾個問題:

  • 聽說敏捷方法都沒有在寫文件的耶,這樣怎麼行?
  • 我最近用到前人寫的元件,都沒有說明文件可以看耶。所以我打算在下個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:活動報名不到會發生很恐怖的事…不要問…真的很恐怖啊。

5 則留言:

  1. pair programming和code review不能算是等價的。pair programming時,2位programmer的心態(主要還是開發功能)和執行code review的心態(找出問題)不同,而且formal code review通常會有嚴格的check list和多位reviewer,並不是說有pair programming就不需要code review了。

    回覆刪除
  2. To Spirit Du:

    我可以回應說...『這樣就不敏捷了啊』...XD。

    我知道 pair programming 和 code review 不一樣。我的重點是,有些人想要做『很多事』,所以要求開發人員要做一些『預備工作』,這樣才能讓整個開發活動『看起來』很有『制度』。結果卻是把大部分的精神都花在『規劃制度』,之後發現沒有時間去落實制度所規範的每一個步驟。

    回覆刪除
  3. 我想表達的是即便是敏捷開發,code review和pair programming都是可並存的,而且都很重要。

    回覆刪除
  4. To Spirit Du:

    同意。不過我常常做了 pair programming 之後就沒有安排 code review ...Orz...(偷懶)

    回覆刪除
  5. 的確是「真的有所提升」最重要,無論是對客戶、團隊的戰力、還是程式碼的品質。至於是得用Code Review、Pair Programming、還是兩者並用才能達到,這就得靠各自的「敏捷力」來判斷了。

    回覆刪除