Agile Tour Taichung <從趨勢科技的agile之旅談改變的導入> 演講摘錄

今年 1/23 Agile Tour Taichung 我們請了志工幫忙做演講記錄，感謝Philip 的細心整理。

從趨勢科技的agile之旅談改變的導入

文/Philip Li

Joy 於趨勢科技研發總部的 Software Quality Assurance / Software Engineering Process Group 擔任 Senior Director。團隊的任務在於使公司持續成長，變得高敏捷、高品質、高生產力，且須時常注意世界的變化，並適時引進公司。簡言之，就是在幫公司做改變的團隊。

1980年代啟發Scrum的論文-The New New Product Development Game-重點摘要(part1)

(photo credit : www.foxsports.com.au)

2/23 參加 ASM(Advanced Scrum Master) 講義中提到這篇論文[註1]，而且Jeff Sutherland 在「SCRUM：用一半的時間做兩倍的事」這本書中也提到這篇論文啟發Scrum，因此就找來拜讀。

論文中提到 80年代許多公司愈來愈著重新產品的開發，新產品所佔公司的利潤跟70年代相比成長了將近20%。因此新產品開發過程的速度(speed)及彈性(flexibility) 便關乎公司的競爭力。

乎出意料地，文中提到的都是關於硬體新產品開發的案例，其中特別提出六個案例：

專案估算還是商業目標?

(photo credit : theatlantic.com)

通常在討論專案時程時，經理和工程師想得有點不一樣：

場景一：

麥總(業務主管)：這一個專案你需要多久才能完成？我們需要在三個月內讓系統上線以便參加明年1月的CES。而且我們没有多餘的資源，所以你必須用目前的RD團隊來完成，這邊是要參展時我們系統需要有的功能清單。

小斯(Team Lead)：讓我回去跟團隊估算一下再跟你報告。

RD會議…

小斯：我們預估這個專案必須用到5個月的時間。

麥總：５個月！？你有聽到我說的話嗎？我之前跟你說的是我們需要這個系統在３個月內完成，這樣才能去CES參展！

在二人互動後，小斯心中可能在想：「麥總的要求真是不合理，怎麼要求我們Team用三個月的時間做5個月才能做完的事，說得比做得容易！」

而麥總心中則是在想：「這小斯完全不懂商業現實！他不能了解在系統在三個月準備好去參展是一件悠關公司生存的大事嗎？」

在這個例子中，我想麥總並不是真得要小斯去做專案的時程預估(estimate)；他其實是希望小斯擬定如何完成系統並準時參展的計畫(plan for a biz target)。

大部份的業務主管並没有足夠的技術背可以區分估算(estimates)、目標(targets)、承諾(commitments)跟計畫(plans)的差別。 因此RD主管便有責任將業務主管需求轉譯成更特定的技術項目。

底下提供一個比較有效的互動方式

場景二：

麥總：這一個專案你需要多久才能完成？我們需要在三個月內讓系統上線以便參加明年1月的CES。而且我們没有多餘的資源，所以你必須用目前的RD團隊來完成，這邊是要參展時我們系統需要有的功能清單。

小斯：我想再跟您確認一下，是「所以需求都100%完成」還是「要有亮點可以參展比較重要」?

麥總：我們一定要去參展而且要有新的話題讓行銷部門可以做文章。當然如果可能，我也希望所列的需求能夠100%完成。

小斯：我們會依照您所定的優先順序全力以赴，但如果RD團隊估算之後沒有把握交付100%的需求功能，我們是否還是要將已完成的功能整合後交付，還是我們可以在CES在後再交付？

麥總：我們一定要有新功能新話題去參展，但若情況很緊急，即使不是100%完整，我們還是要將已完功能包裝好。

小斯：好的。我會擬出一個時程計畫讓RD Team在未來3個月儘可能地完成最多的功能。

—————
如果你是一個 Project Lead/Team Lead，下次當你被要求提出一個專案時程預估時，你可以注意以下幾件事

• 了解你是要做估算(estimate)還是要去達成商業目標(target)
• 儘可能跟業務主管討論需求項目的 priority
• 依照 priority 採用增量式(incremental)的開發模式，完成一個新功能之後儘量都有一個潛在可交付(potentially shippable)的產品

註：本文是參考 "Software Estimation Demystifying The Black Art by Steve McConnell” 一書其中的內容而改編。 

視覺化的好處

今年春節和家人一起去走了鳴鳯古道，這條古道難度平易近人老少咸宜，非常適合我這種很久没運動的中年大叔。

自從我學習了「敏捷」這一把錘子，眼中則是看到跟敏捷有關的事物。今天要談的主題就是「視覺化」。

鳴鳯古道全程大約3.5公里，但路程中有30~40度的石板路，中年大叔走來還是給它有點喘。還有的是這條古道在整修時便將里程數作了醒目的石碑讓旅人可以知道走了多遠，離目標還有多久。有了這種視覺化的目標，沿途走來都可以當下的進度。

更厲害的是還有好心的鄉民每隔10公尺就在地上寫了里程數

這就像是 Sprint 中 burn down chart 的作用，在很短暫的間隔就可以知道又更靠近目標了，可以讓自己保持很高的戰鬥力啊！

倘若没有這些實體的標誌，還是可以拿出手機來看距離目的地還有多遠，但當你低頭喘氣時應該還是那些直入眼裡的標誌來得快速直接，這也是我比較喜歡在辦公室要放置實體看板的理由。

若是對鳳鳴古道有興趣，可以參考：苗栗文化觀光旅遊網- 鳴鳳古道

題化話：新春期間在古道上迎面相會時，大家都會說一句「新年快樂！」心情很好啊。下次去走步道時，也應該給對面而來的朋友一句問好。

Agile Tour Taichung 2015 回顧筆記

這次的 Agile Tour Taichung 能順利完成要感謝很多人，我在FB雖然已經先發文感謝了，但還是要再說一次：

感謝鈦坦科技(林昱承)、 微程式-夢種子(薛共和)、 光明頂創育智庫(賴銘堃)在經費,場地,座椅上的協助與支持。

Joy Chen, Aska Lee, Nor Chen, Erica Liu, Tony Chang 遠從台北、台南甚至抱病前來，不計較微薄講師費，為中台灣軟體圈注入敏捷開發的新力量，感謝各位慷慨無私的分享。

還有 Cash Wu, 莊家昇, King Jk 等朋友在寒流來襲，冷風大雨中幫忙載椅子、佈置會場。

這一次超精彩的 Agile Tour Taichung 感謝有您們的寒冬送暖，外面是凜冽的，會場卻是溫馨熱情的。

Max 給各位朋友深深一鞠躬。

Agile mindset 中最重要的就是"回顧(retrospective)" ，感謝的話說完了，接下來要自省一下。

做得不錯的項目：

• 我們事先先參加 Agile Tour Taipei, Agile Tour Taichung 的活動觀摩，也跟 David Ko 請教了許多細節。謝謝他在幕後的支援。
• 活動籌備討論主要利用  FB messenger 的群組討論、搭配 Google drive。活動前全體志工只有場勘一次，對一個60人的活動算是很有效率的方式。當然前提是志工平時在 Agile.Taichung 大家都很有默契了，而活動場地—夢種子也是大家熟悉的地點。
• 有一位參加的朋友私下跟我說：這次應該是賠錢的吧？若單單以報名費的收入來看是賠的，幸運的是有贊助商的支持能讓活動的預算能比較寬裕。

可再更好的項目：

• 早上演講結束到用餐、用餐結束到工作坊、工作坊結束到回顧會議，這三個 session 轉換過程因為要移動座位而讓流暢度有些受阻，也謝謝參加學員的主動幫忙，桌椅的擺設可以很快地調整好。下次辦活動應該會找有大小會議室的場地，如此可以分開辦演講及工作坊，可以讓活動進行更流暢。
• 因為每個工作坊結束的時間一定不一樣，之後的回顧會議讓比較早結束的參加者稍微等了一下。下次活動工作坊之後就可以直接結束，不用再排一個整體的session。
• 這次的主要志工連我只有4位，當天人手明顯不足，因此這類的大型活動當天需要 full time 的志工來協助場控、場地、攝影、拍照、文字記錄等工作。

若參加的朋友還有其它的建議，歡迎您再私下跟我說，讓 Agile Taichung 的活動品質可以更好。

再二天就是猴年了，也祝各位朋友未來的一年萬事如意、財猿廣進！