在「工程師幹話」的『老闆想要成長 — 我們就讓老闆「看見」成長』這篇裡面提到了 Scrum：
台灣最接近 Scrum 的組織是國軍。一個 Scrum team 不應該太大，所以一個班只有九個人，然後有一個直接的 PO，叫做班長；每天工作之前都有的 standup meeting 呢，叫做早點名；至於固定時間都有的 retrospective 會議呢，叫做榮團會。所以，如果我們真心相信有個 Scrum 外型的組織就可以提昇效率的話，就等於，我們居然會願意相信：中華民國國軍是個高效率的組織。
這篇文章花了半個小時才看完，真是有夠長的... 裡面描述了很多事情，與一些時間線對一下，大概知道哪個段落在講什麼事情。
之前跟其他朋友聊到 Scrum 的時候我都有先說我的結論，就是我覺得 Scrum 只適合用在「外包團隊」與「業主」之間的互動，目前看到的其他情境都不合理。
利用 Scrum 的架構，可以改善傳統的外包情境：
- 通常業主給不出完整的 spec，於是外包團隊無法估算成本，所以外包團隊利用 Scrum 機制，每個 sprint 可以要求業主每次提供一點 spec，然後依照這些 spec 估時 (點數) 並且計費 (換算成 manhour，然後得出人力成本與利潤)。
- 如果業主一開始就可以給出完整的 spec 也沒關係，spec 先切出第一個 sprint，在每個 sprint 結束後，跟業主確認下一輪的內容。
Scrum 在外包團隊可以掌握的範圍，大幅改善了傳統外包簽約的困難。
對於業主不知道要做什麼的，可以降低業主一開始就需要提供很多資料 (spec) 的門檻。
而對於業主已經知道要做什麼的，可以提供修改的時間點。這對於超長期的合作時特別有用，像是軍事外包案常常一個外包就是五年或是更長，sprint 的機制讓業主可以在中間很自然的修改規格，而不是加簽附約的方式修改 spec。
另外，在簽署 Agile Manifesto 的 17 人名單也可以看出來，裡面專搞 Scrum 的差不多都是在外包或是在當顧問，那麼，推出一個「學派」再告訴客戶這樣做會更好，是個自然不過的事情了。
而從 Scrum 裡面的其他細節也可以看出來他們怎麼把外包團隊想要避開的問題「包裝」起來賣給客戶：
- 透過大幅縮短 milestone 的設計「sprint」，可以依照每個 sprint 收款，也因為通常 sprint 的單位長度比 milestone 的時間短很多，外包團隊的現金流的品質會比以前好。
- 在 daily standup meeting 可以取得目前專案的進度，一方面可以在內部追蹤，避免有項目出事，另外一方面可以向業主回報，讓業主有安全感。
- 再來是 Scrum 要求每個 sprint 的內容不可以被變更的問題，這點則是避免了客戶端的手伸進來，而改變了成本結構導致虧本。但也提供客戶修改的空間：允許下個 sprint 修改，重點在於該收的錢有收到。
而以上的這些東西放到公司內就會變得很奇怪：
- 外包公司不在意手上做的產品是不是合理，只在意工時 (人力成本) 合不合理。而公司內的團隊合理性的才會下去執行，甚至有可能做到一半才發現不合理而需要全面中斷 (因為 startup 常常在做一些以前的人沒做過的事情)。
- 在外包公司裡，PO 無法伸手進 sprint 修改既定事項，要硬改就是得照合約先把這個 sprint 的錢付掉，所以這情不太會發生。而在公司內 PO 常常是老闆或是大主管，伸手進來改不會有什麼賠償成本，Scrum 的這條規定在公司裡面就是沒有罰則的法律。
- 公司成員遇到問題卡住 (不知道怎麼解、自己不會解、需要別人一起幫忙解) 或是進度會跟不上的情況應該是發現時馬上通知，而不是擺爛等到隔天的 standup meeting 才提出來。於是你會發現找不到 daily standup meeting 的目的。
另外一個問題是：
- 營運端的成本造成估時不準確。像是上線後，系統的 downtime、bugfix 而使得原來團隊成員需要支援的情況，導致一個人的輸出不可能有 40 hours/week。
這點也是在外包公司不會遇到，而公司內不可避免會遇到的情況。
差不多把該講的都列出來了，這是我覺得外包時用 Scrum 適合的原因。
