如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案（下）

[上一篇]

前兩篇文章所提的瀑布式和階段式方法，都是傳統的專案管理方法，有人鼓吹，為了要讓專案工作的時間估得準一點，那就多估幾個時間值好了，分別叫它們為「最樂觀」、「最悲觀」、「最可能」，也就是所謂的「三點估計法」。關於這一點，我的提問是，如果一個人對一項他沒做過的工作都「猜」不準所需要的時間了，那叫這個人多「猜」兩組時間，這樣就會比較準嗎？這不是畫蛇添足，脫褲子放屁嗎？

如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案（中）

[上一篇]

二. 階段式方法

看到前一篇文章提到的瀑布式方法的缺點，我相信多數組織都可能感同身受。接下來的問題是，組織當中有沒有人有膽識、有魄力，而且還有權力可以推動專案管理的改革。

很慶幸地，本案例的公司就有這樣有遠見的主管群。該公司的主管們痛定思痛、下定決心去做專案管理的變革，開始採用階段式開發方法。整個流程大致演化為像下圖這樣：

如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案（上）

「老師，聽說 Scrum 敏捷式產品開發方法比較適合軟體產品開發，可是我們公司的產品是 IC，硬體的成分居大部分，軟體開發人員大都是在最後階段才參與產品的開發，這樣還適合導入 Scrum 敏捷式產品開發方法嗎？」

想導入敏捷式方法，我該怎麼跟老闆溝通？

有些組織在嘗試導入 Scrum（讀音：「思逛」）敏捷式方法的時候，老是遭遇到一些奇奇怪怪的現象，效益也常常不如當初想像地那般美好，為什麼會這樣呢？

敏捷方法的成功密技（16）：中、大型專案可以導入 Scrum 敏捷式開發與專案管理嗎？

許多對敏捷式開發方法有興趣的客戶，經常會問我一個問題：「老師，敏捷式專案管理鼓勵以小規模團隊來做專案，可是我們公司的專案都很大，專案團隊的成員也很多，我們能用敏捷式管理方法嗎？」

敏捷方法的成功密技（15）：未完成的用戶故事的進度怎麼算？

在運用敏捷式產品開發與專案管理方法時，我們知道，應該以「對用戶的價值」的角度來對工作（用戶故事 User Story）的優先級做排序（參考《能讓需求簡化，還能更省時、更省錢，提供更多價值，這…可能嗎？》一文），然後，將這些工作，「依序」安排到固定週期的各個衝刺（Sprints）去，並且盡可能地將每個衝刺都塞滿、都最佳化（參考《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》一文）。

但是，就算規劃得再完美，一定還是會有意外狀況，導致這些規劃好的事情生變。例如，在衝刺結束時，某些該完成的用戶故事，卻無法被驗收！這該怎麼辦？

敏捷方法的成功密技（14）：你不可不知，影響專案開發速度的八大障礙

在《開車旅行跟敏捷式專案管理有什麼關係？》一文當中，我們談到了，只要能掌握團隊的產品開發速度，幾乎就等於掌握了整個專案的進展。

其實，不論是傳統式還是敏捷式的專案管理，道理都是一樣的。但，到底有哪些因素會影響到團隊的開發速度呢？我們還是先來看看開車旅行的例子。

開車旅行跟敏捷式專案管理有什麼關係？

如果你正開車到一個陌生的新景點去旅行，總距離大約是 200 公里左右，而你現在已經開了 160 公里，花掉了你兩個鐘頭，那麼，你知道，過去這段時間，你的平均車速是大約每小時  80 公里左右。現在我們來考慮以下的三種情境。

《EZ敏捷式專案管理》入門一日班簡章（６或７Hrs）

敏捷方法的成功密技（十二之二）：Scrum 如何精準估算用戶故事的點數？

[承上篇]

敏捷方法的成功密技（十二之一）：Scrum 如何精準估算用戶故事的點數？

在上一篇文章《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》當中，我們談到了怎麼將點數／心力（Point、Effort）大小不一的各個用戶故事，依照用戶故事的優先級先後，排進衝刺（Sprint）內去實做。也談到了如何拆解肥大的用戶故事為數個小故事，以便能繼續將該衝刺的剩餘空檔也能盡量地塞滿，以最佳化該衝刺的負載規劃。

可是，這些作法都必須奠基於「夠精準的用戶故事點數估算」這個前提之下才有意義！那麼，實務上，我們到底應該怎麼來估算用戶故事的點數，才能稱上「夠精準」呢？

敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？

在上一篇文章《敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？》當中，我們談到了衝刺（Sprint）目標，雖然名義上應該由 Product Owner（產品負責人）來制定，但為免團隊根本就不 buy-in，或是團隊實在是無力可達成，故，實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論，來制定各個衝刺的目標，這樣才像一個符合 Scrum 精神的「團隊」！

敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？

在上一篇文章《敏捷方法的成功密技（九）：Scrum 的衝刺目標怎麼訂？》當中，我們談完了衝刺（Sprint）目標的制定技巧，但是，這些衝刺目標，到底該由誰來制定呢？我們先來看一下這樣的一個場景…

敏捷方法的成功密技（九）：Scrum 的衝刺目標怎麼訂？

綜合本系列之前的文章，Scrum 其實就是一個小團隊（約５－９人），利用一個個固定短週期的衝刺（Sprint），跟客戶一同逐步漸進地，完成一個產品，而這個產品的功能，就是由一個個，由客戶主導、撰寫的用戶故事（User Story）來呈現需求的（關於用戶故事的簡要陳述，有興趣的朋友可以先參考一下《能讓需求簡化，還能更省時、更省錢，提供更多價值》這篇短文，容日後有空再專文細述之）。

敏捷方法的成功密技（八）：Scrum 的衝刺時間長短怎麼訂？

一個衝刺（Sprint）的時間長短到底應該是多少才是最好的呢？如果衝刺的時間設定得太長，那麼，應變的彈性就會變得比較小，而如果衝刺的時間設定得太短，那麼，又容易讓開發團隊能產出的成果出問題。怎麼說呢？

敏捷方法的成功密技（七之二）：Scrum 的夢幻開發團隊該怎麼來建置？

[承上一篇]

接續上一篇文章《敏捷方法的成功密技（七之一）》，除了新領域、新團隊，最有機會嚐試新作法之外，我們也談到了，只要開發團隊夠紮實，產品的開發就能夠打帶跑，因為品質才能夠被掌控得好。怎麼說呢？

敏捷方法的成功密技（七之一）：Scrum 的夢幻開發團隊該怎麼來建置？

在上一篇文章《敏捷方法的成功密技（六）：Scrum Master  並非你想像的那般卑賤！》中，我們談到了 Scrum Master 這個角色，其實最好是由一位開發和管理經驗豐富的人來擔任，工作經歷不足的菜鳥，是很難勝任得好，更很難以服眾的。

敏捷方法的成功密技（六）：Scrum Master 並非你想像的那般卑賤！

在上一篇文章《敏捷方法的成功密技（五）：Scrum的三種角色》中，我們談到了Scrum定義的三種角色，而其中Scrum Master這個角色應該是最令人感到困惑的一個。

敏捷方法的成功密技（五）：Scrum 的三種角色

在上一篇文章《敏捷方法的成功密技（四）：Scrum的理想與現實的障礙》中，我們談到了Scrum明確定義的三種角色，Product Owner產品負責人、Scrum Master 大師，以及Development Team開發團隊，接下來我們就一一來看看。

敏捷方法的成功密技（四）：Scrum 的理想與現實的障礙

在上一篇文章《敏捷方法的成功密技（三）：Scrum如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？》中，我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題，則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。