大家好，我是馬在飛的馬。
本週專案管理界發生一件大事，就是繼2017的更新後，2020/11/18 scrum guide又進行了一次更版！這次的文章就讓我們來看一下，Scrum經過3年的演進，有哪些新的變化？
Scrum怎麼來的？
Scrum的原意其實是一種橄欖球術語，最早於1986年被用於商業管理的概念，竹內弘高和野中郁次郎提出的概念，希望透過速度與靈活性的改善，加快新商業產品進入市場的時間，他們把這個想法用橄欖球形容，wiki如是說：
前者各階段相互重疊，並且由一個跨職能團隊在不同的階段完成整個過程，而團隊「作為一個整體前進，把球傳來傳去」
1990年代初期，Jeff Sutherland和Ken Schwaber各自用這個概念，在自己的公司推行快速、敏捷的開發，1995年，這兩人合作，以論文的形式發表了Scrum理論，接下來幾年他們密切合作，依據他們的執行與業界推行的經驗，發展出了我們現在所熟知的Scrum。直到現在Jeff和Ken仍持續在維護他們所提出的Scrum guide，2020年Scrum已經25歲了，在實際操作上，證實可以更有效的提高團隊的效率與產出週期，也成為不論是軟體開發或是其他產業中，都相當受歡迎的管理方式。
現在去Google搜尋Scrum出現的都不是橄欖球，橄欖球QQ
2020有些什麼不同？
2020版相較於2017的版本，篇幅短小了許多，但在開篇的Scrum精神闡述上，沒有太大的變動，Scrum的定義仍然是一個適用於處理複雜問題的管理架構，由多功能的團隊成員組成，透過密切的合作，並依據經驗法則，持續的進化並增加產品的價值。 透明Transparency-檢驗Inspection- 適應Adaptation是Scrum的三大基石，並要求團隊的成員要能依循5大精神：承諾Commitment-專注 Focus-開放 Openness-尊重Respect-勇氣 Courage，在這兩大基礎上，使用迭代增量的理念去持續感善產品以及團隊合作。新版基礎精神不變，變動的主要在於一些概念的調整，並在一些遣詞上調整希望減少使用上的誤會，同時也消減針對軟體開發的用詞，因為Scrum可以應用的領域遠不止軟體開發。
Product Vision 變成Product Goal
新版的將Vision替換成了更明確的Goal，Vision有遠見、夢想之意，相較於Goal目標更高大上但也較為廣泛，Scrum強調團隊的齊心協力，相較於可能只有老闆能感同身受並充滿熱情的Vision，要能有效驅動團隊的，應該要是大家都能理解、認同，並且能夠被清楚說明與衡量的Goal目標。
Development Team到Developer的差別
Scrum的組成需要有3大角色：Product owner、Development team以及Scrum master。Product owner負責決定開發的順序並且將明確的功能與目標傳達給Development team開發人員（不一定是指軟體工程師，而是為了達成產品增量的執行團隊），Scrum master則在每個階段協助團隊用正確的敏捷精神去執行並協助解決問題與障礙，如果有需要Scrum master也要負起協助組織去理解、接受、轉型成為Scrum。
在舊版中Product owner與Development team的措辭，會讓許多執行Scrum的團隊誤解了Product owner屬於較高的管理階層，但Scrum是希望能盡量消除團隊中的階級制度，因為過度強調階級，反而會造成資訊的不透明以及溝通低效率。在最新版中Development team改成了Developer，希望凸顯出Product owner和Developer是在同一團隊中的成員，並且都扮演達成目標不可忽略的角色，新版的Scrum guide也更鼓勵Developer可以多去和Product owner討論，甚至質疑Product owner提出的目標，從原先的Self-organization改為了Self-management，從只管誰去做、怎麼做，提升到還會關心做什麼、為何做，希望以此消彌Product owner和Developer是從屬關係的錯誤印象，而是作為一整個團隊去為產品努力。
想一下你平常和老闆/上司說的話有經過多少修飾，就會明白追求透明的Scrum
為什麼希望盡量消除團隊中的階級感
Product owner是Responsibility還是Accountability？
相較於以往使用Responsibility責任這個詞，新版更強調Product owner的Accountability問責的功能，一樣是要對專案負起責任，這兩個詞有什麼差異呢？相較於Developer對於分配的執行內容要「負責」，Product owner則要去承擔/回報專案的成敗，Responsibility可以多人同時承擔，Accountability通常只有一個人負責，Developer要專注於能讓產品產生增值的任務，Product owner則要專注於產品的結果。
Planning cycle與Release cycle的轉換
這次的Scrum guide特別強調，在每個Sprint週期中，不一定要週期結束時才釋出增量的內容，在週期的中間如果提早完成，也可以釋出增量。每個週期循環中，雖然產出新價值是希望的成果，但在執行時要著重於是否有依據規劃與目標去產出，而不是只關注於要在Sprint結束前有產出，以Planning為基準去循環，而非Release。
定義與教條的簡化
此次的篇幅縮短了不少，很多名詞定義或規章說明都大大的簡化，可以看出Jeff和Ken希望大家更專注於Scrum所強調的精神，而非拘泥於文字上的理解或執行。
例如原本在Scrum Daily中的三個提問：
• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
在新版中整個被移除掉，在訪談中Jeff提到，因為他看到太多執行Scrum的團隊把這件事變成例行公事，而沒有去實踐Daily存在的意義，他曾看過一個Scrum Master用更簡便的方式達成Daily的目標，這個Scrum Master只問：「為什麼還沒完成？我們可以做什麼讓它盡快完成？」這個小故事可以讓我們理解到，為什麼Jeff和Ken要移除這些教條式的說明，與其案表操課，能理解Scrum精神並達成目標才是最重要的。
希望讓管理變得更好、更有效率
以上是針對這次Scrum guide更新，我挑出的幾個重點項目或觀念的調整。從整個Scrum guide的閱讀以及訪談影片中，可以深刻感受到Jeff和Ken對於Scrum 所作出的努力，透過他們自己執行以及幫助別的企業導入的經驗，他們持續的去修改調整，希望大家能使用Scrum精神去創造更有效率、更團結的工作環境，並且鼓勵大家以Scrum guide為基礎但不拘泥，把Scrum當成一個解決問題的方法，持續去進步、去開創更好的工作方式，畢竟迭代增量不就是Scrum的核心精神嗎？
There is no sliver bullet. 但我們永遠可以選擇試圖作出改善與進步，讓事情變得更好
希望這篇文章有幫助到對Scrum有興趣的你，如果你有什麼經驗想分享，或是補充我沒有完善的部分，歡迎你留言喔！我們也很希望可以認識更多努力用敏捷思維解決管理問題的大家。以下有這次Scrum guide更新以及訪談的連結，歡迎自行取用。那這篇文章我們先到這邊，謝謝閱讀的大家！
------------
若你有軟體開發或專案管理的需求，請點擊此並留下你的需求，我們會盡快與你聯繫
你也可以在Medium上看到馬在飛的文章喔！前往Medium