 |
||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
什麼是 SCRUM ？SCRUM一詞源於橄欖球賽的「並列爭球」，指的是全隊通力合作把球往後場傳的方式，必須結合細膩的團隊合作、一致的意念以及明確的目標才能做到，套用於完美團隊的運作，再貼切不過。 各界推薦 元智大學講座教授 許士軍 推特首席技術長 亞當 • 麥辛哲 《精實創業》作者 艾瑞克 • 萊斯 人氣部落格「專案管理生活思維」主筆 姚詩豪 |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||
為何要談SCRUM我在二十年前和肯 • 施瓦布（Ken Schwaber）一起開發SCRUM，當時的用意是要為科技業設想一套更快速、更可靠、更有效的軟體開發手法。從那時候直到至少2005年，大多數的軟體開發專案都還是採用瀑布法，專案分成多個階段完成，一個又一個階段發展出準備釋出給顧客或軟體使用者的終極版。那樣的流程很緩慢，也無法預知成果，而且往往會做出使用者並不想要或不願付費購買的產品。進度延遲幾個月或幾年是家常便飯。這種事前先把每一步都規劃好的計畫，會把所有細節都畫成甘特圖，也讓管理高層相信開發的過程完全在掌控中，但結果往往是進度很快就開始落後，而且預算嚴重超支。 為了免除這些缺失，我在1993年想出一種做事的新方法：SCRUM。 它徹底改變過去那種由上而下、規範式的專案管理手法。相較之下，SCRUM可說是一種具備進化能力、有彈性，還能自我修正的制度。自問世以來，SCRUM架構已經成為科技業發展新軟體與新產品的一種方式。不過，SCRUM固然在矽谷已經有管理軟硬體專案方面的口碑，但在一般商業應用上有何潛能仍是未知數。就是因為這樣，我才會撰寫這本書，為科技業以外的企業揭露並解說SCRUM這套管理系統。 |
||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||
每日立會在寶蘭，每日會議至少會召開一個小時。這樣的時間長得讓我留下深刻印象，因此我試圖找出集會時最核心的溝通事項，最後想出上述三個問題。 每日立會三原則這也是每日會議的運作方式，它存在一些規則。每天都要在同一時刻開會，每個人都必須參加。假如無法全員到場，就等於是沒有溝通。一天中的任何時刻都可以，只要是在同一時刻就好，重點在於給團隊一個固定的節奏。 第二個規則是，會議不能超過十五分鐘。我們希望會議乾脆、直接並且切中重點。假如有些事需要進一步討論就記錄下來，在每日會議之後再深入探討。這麼做的用意是希望在最短時間裡找出最多用於採取行動的珍貴資訊。 第三個規則是，每個人必須積極參與。為了促成此事，我要求每個人都站著開會。這可以讓大家積極交談、持續聆聽，也有助於維持會議的簡短。 正因如此，這樣的會議才會稱為「每日立會」或「每日SCRUM」。你要怎麼稱呼它其實都不是那麼重要，只要每天在同一時刻召開、同樣詢問那三個問題、每個人都站著，而且把開會時間控制在十五分鐘以內就可以了。 我常看到某個意外出現的問題是，大家都傾向於把每日立會當成只是一個向大家報告「我做了這件事??我準備做那件事」等個人事項的場合，一個人一講完就輪到下一個人講述。更理想的方式應該接近於美式足球，選手圍在一起商討戰術的景象。外接員可能會說：「那個防守前鋒礙到我了。」聽到這句話，進攻絆鋒可能會說：「他就交給我處理，我負責突破防線。」或者四分衛可能會說：「我們的跑陣碰到瓶頸，不如出其不意地把球往左傳。」用意在於讓整個團隊迅速決定如何完成衝刺，取得勝利。被動因應不但懶散，也形同主動拖累團隊裡其他人的表現。一旦找出問題點就必須即刻予以排除。 我要的是企圖心旺盛的團隊，他們在開完每日會議後，都很清楚自己在那天以內必須完成最重要的一件事。有人或許會聽到其他的成員說，某件事得花費一天才能完成，但是另一位成員或許就知道如何幫助對方在一個小時內完成。我希望我的團隊在開完會後，能夠說出「我們一起來把這件事搞定」、「我們一起來做這件事」之類的話。這個團隊必須有追求卓越的企圖心。 不管團隊是大是小，我對他們講的話都是這樣的：「你們真的想要永遠都這麼糟糕嗎？你們的人生就只有這麼一點動力嗎？這是你們的選擇，但是你知道，你可以不必是這副德性。」團隊必須主動以追求卓越為目標。 （本文為節錄，完整內文請見《SCRUM》第4章 × 掌握時間的節奏）
 |
||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||
規劃「衝刺」在SCRUM當中，我們稱這些循環為「衝刺」。在每個循環的一開始，都會有一場規劃衝刺內容的會議。團隊要在會中決定，他們在未來兩個星期裡能完成多少工作。他們會從已排好優先順序的待辦事項中領走這些工作項目，通常是寫在便利貼上，然後貼到牆上。團隊必須決定在這些工作項目中，他們在未來兩個星期內可以完成多少。 當一次衝刺結束時，團隊成員就要開一次會，展現出在這段大家一起合作的時間裡完成什麼工作。他們要檢視有多少個便利貼上的工作項目已經完成？自己是不是在這一段的衝刺中列出太多工作項目，卻沒有全部做完？或者工作項目是不是列得還不夠？這部分的重要之處在於，大家對於自己能多快做好事情，也就是速度，開始有了基本體認。 在他們展現出當下成果時（大野耐一的想法就在此刻發揮作用），他們不只討論過去這段時間做了什麼，也會提出問題：「我們如何在下一次的衝刺中更妥善合作？在上一次衝刺中曾出現什麼阻礙？拖慢工作速度的阻礙又是什麼？」關於SCRUM如何運作，附錄有更多的細節描述。 而這就是為何強生需要幾個月才能真正辨別出專案要耗費多久的時間才能完成。他希望能透過多次衝刺來評估每個團隊的工作速度，也看看能改善多少、能比原本快上多少。一旦他得知各團隊在各衝刺中完成的工作項目，而後比對在專案結束前仍待完成的工作項目，就能預估完工日期。 除了明瞭各團隊的進展速度以外，他也想知道有哪些阻礙在拖慢速度。他真正的用意在於提升速度以加快產出，但不是藉由更長的工時（稍後我會討論為何此舉將會徒勞無功，最後只會拖慢進度），而是藉由更好、更聰明的工作方式來實現。強生表示，團隊的生產力成長為三倍。大家上軌道後，速度就變成開始時的三倍。因為他們的合作默契變好了，最重要的地方在於，他們已得知拖累速度的因素，也會在每個循環、每次衝刺中努力地予以排除。 （本文為節錄，完整內文請見《SCRUM》第1章 ×世界的運作法則已瓦解）
|
||||||||||||||||||||||||||
 |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
