閒聊Scrum敏捷式開發
寫在前面
從我的自我介紹中，或許很難想像我會和敏捷管理、Scrum開發等聯想起來，最多最多可能就是參與研發時沾上一點邊；實際上，Agile的概念在台灣出現的算早，我也在2009年左右就接觸到此一概念，還記得第一次聽到時，我還打趣地跟同事說，要敏捷開發，那我是不是可以跳著寫?
想必我會這麼說，一方面是因為年輕氣盛，一方面是因為對團隊運作沒有相當足夠的經驗和歷練，所以沒有很深刻的了解這能幫我們解決甚麼問題，在歷經研發系統、管理部門後，再加上一些應用經驗，才能更具體地描述Scrum可以解決甚麼問題，不能解決甚麼問題，故後面我會加入以往運用Scrum的經驗和心得，來述說我對此一方法的看法。
迷思
不管在上海、北京或是台灣，我都曾和當地客戶或IT主管交流過Scrum開發，在這些閒聊過程中，我發現一些很有趣的共性，對於Scrum開發，許多人在還沒真正進入時，總有一些迷思和困惑，甚至在導入一段時間後，仍覺得事實與想像不符，以下說說我遇到的趣事。
我團隊的研發速度相當慢，是不是應該導入Scrum ?
是，但你一開始可能會失望，因為導入後未必速度就會快了起來，事實上，敏捷雖然從字面上看來會讓人聯想到動如脫兔之類的意象，但實則他和「快」這件事情毫無相關，但或許你可以透過Scrum找出你團隊潛在的問題，並進而改善後得到效益。
我們每天都在做例行性的工作，這樣有需要導入Scrum嗎 ?
這沒有標準答案，過往很多人運用Scrum時，強調的是開發，但若是以筆者經驗來看，運用Scrum時應該思考的方向是「解決問題」，若是以解決問題的方向來思考，面對的是不是例行性工作相對就不是那麼重要了。
我們已經有固定的工作模式，Scrum未必適合我們公司的型態。
若你滿意的話，這麼說是也沒錯，但如果閣下總覺得現有工作模式好像有點說不出的點，或是想要再得到更多的效益，那或許你可以嘗試一下Scrum。
導入Scrum後，是否一個團隊就可以滿足多面向的開發工作 ?
這是我們都想要的結果，但不幸的是，就以往經驗看來，在Scrum運作越臻成熟下，該團隊的工作內容應該越趨向單純，耦合度高。
舉個例子來說，一個團隊的工作內容都在撰寫程式、發展邏輯，隨著成員對這些工作內容越趨熟練，你會發現研發效率和品質都相當好，但若團隊工作內容開始參雜了美工設計、介面討論，則慢慢地你會發現成果的品質和效率都會略為受到影響，我曾思考過這問題，在時程固定的情況下，應是或多或少受到學習成本的影響，才會體現這結果，
導入Scrum後，我們是否還要像傳統開發一樣，需關心各階段的狀況。
如果你有一組成熟的團員，那我會說太好了，但我們依舊免不了計畫、執行、驗證和回歸這幾大階段，但這並不是意味著我們要讓成員全部做完計畫，再全部下去執行，最後作全部的驗證和回歸這樣，若是這樣，那你只是把這些人分次使用而已，並沒有對現有流程做多少改變。
如果上述幾個迷思，在閣下心中都有良好答案，那我得說，我們有了一個好的開始。
畫虎不成反類犬的模仿
我也曾看過一個部門的管理者，從網路上看了些文章後，就將所有人叫來後，接著要每個人把手邊工作一五一十交代清楚，接著在牆上或看板畫標出幾個區塊分別代表待進行(To do)、進行中(Processing)、已完成(Completed)。
這是一個常見的雛形，如此一來，所有事情進行到甚麼地步，我們都可以一目瞭然，但是在缺乏良性互動和管理的狀況下，這個看板的生命僅維持了2周。
 |
因為在只做Task進度更新的情況下，執行這件事反而對成員是負擔，對大多數成員來說，在無人打擾的情況下，大夥總是沉浸在自己的工作進度中，在普遍情況下，他們的工作進度和思緒是沒有斷點的。
在照著自己步調走的情況下，每人更新進度的時間不一，也無法協同工作，更不用說許多成員根本就忘了更新進度這件事情，然而當管理者拿起鞭子要大家更新進度時，又會打亂成員思緒，造成思路中斷，無法有好的連貫，相對也拖累了進度。
來例會吧，還是…來野餐吧？
相同狀況也發生在每日例行會議中，有些管理者會透過每日會議來更新自己對進度的掌握，這是一種常見手法，沒有好也沒有不好。
但若沒有良好的管控會議進度、每位成員發出的資訊量，往往容易導致會議方向偏題，甚至過度琢磨在某個成員的某個問題中，這現象很恐怖的是，你會發現一開始只有一兩個人講得特別久，後面則越來越多成員講得很久，大家忙著噴口水，最後開一場會議的時間，從5分鐘暴增到1小時都不算罕見。
也許管理者會沾沾自喜，覺得大家都參與討論，最後問題也得到解答，但需要注意的是，有些問題往往是1~2個成員之間的困擾，為什麼需要大家一起來陪聽呢 ？即便需要大家一起參與討論和找到解答，著實浪費大家的時間，而會議沒有完整主軸，變成一場各聊各的野餐會議。
.jpeg)
說了那麼多迷思和常見的錯誤，其實筆者真正想表達的是關於敏捷的四大價值，或許各位在開始之前，可以細想這幾句話的意思，若牢記於心的話，那麼我們就可以開始冒險了 !
「個人與互動」重於「流程與工具」
「可用的軟體」重於「詳盡的文件」
「客戶的合作」重於「合約協商」
「回應變化」重於「遵循計畫」
敏捷的四大價值
再琢磨琢磨以上四大價值，或許你就不難發現，在敏捷開發的思維中，我們更在乎人與人之間的互動，不管是成員和成員，或是成員和客戶，在長久的軟體工作/一般工作發展看來，大家或多或少都會對上述的價值有所體悟。
不過，SOP、計畫、合約和文件都是必要的，我們不能捨棄掉工作上的嚴謹性，更重要的是我們能不能避免工作過於僵化，流於形式，讓專案中每個成員對工作內容有一定的認知和熟悉感，如此才能發揮真正的敏捷彈性。
留言
張貼留言