看到前一篇文章提到的瀑布式方法的缺點，我相信多數組織都可能感同身受。接下來的問題是，組織當中有沒有人有膽識、有魄力，而且還有權力可以推動專案管理的改革。
很慶幸地，本案例的公司就有這樣有遠見的主管群。該公司的主管們痛定思痛、下定決心去做專案管理的變革，開始採用階段式開發方法。整個流程大致演化為像下圖這樣：
如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案（上）
「老師，聽說 Scrum 敏捷式產品開發方法比較適合軟體產品開發，可是我們公司的產品是 IC，硬體的成分居大部分，軟體開發人員大都是在最後階段才參與產品的開發，這樣還適合導入 Scrum 敏捷式產品開發方法嗎？」
敏捷方法的成功密技（16）：中、大型專案可以導入 Scrum 敏捷式開發與專案管理嗎？
許多對敏捷式開發方法有興趣的客戶，經常會問我一個問題：「老師，敏捷式專案管理鼓勵以小規模團隊來做專案，可是我們公司的專案都很大，專案團隊的成員也很多，我們能用敏捷式管理方法嗎？」
敏捷方法的成功密技（15）：未完成的用戶故事的進度怎麼算？
在運用敏捷式產品開發與專案管理方法時，我們知道，應該以「對用戶的價值」的角度來對工作（用戶故事 User Story）的優先級做排序（參考《能讓需求簡化，還能更省時、更省錢，提供更多價值，這…可能嗎？》一文），然後，將這些工作，「依序」安排到固定週期的各個衝刺（Sprints）去，並且盡可能地將每個衝刺都塞滿、都最佳化（參考《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》一文）。
但是，就算規劃得再完美，一定還是會有意外狀況，導致這些規劃好的事情生變。例如，在衝刺結束時，某些該完成的用戶故事，卻無法被驗收！這該怎麼辦？
敏捷方法的成功密技（14）：你不可不知，影響專案開發速度的八大障礙
在《開車旅行跟敏捷式專案管理有什麼關係？》一文當中，我們談到了，只要能掌握團隊的產品開發速度，幾乎就等於掌握了整個專案的進展。
其實，不論是傳統式還是敏捷式的專案管理，道理都是一樣的。但，到底有哪些因素會影響到團隊的開發速度呢？我們還是先來看看開車旅行的例子。
開車旅行跟敏捷式專案管理有什麼關係？
如果你正開車到一個陌生的新景點去旅行，總距離大約是 200 公里左右，而你現在已經開了 160 公里，花掉了你兩個鐘頭，那麼，你知道，過去這段時間，你的平均車速是大約每小時 80 公里左右。現在我們來考慮以下的三種情境。
敏捷方法的成功密技（十二之一）：Scrum 如何精準估算用戶故事的點數？
在上一篇文章《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》當中，我們談到了怎麼將點數／心力（Point、Effort）大小不一的各個用戶故事，依照用戶故事的優先級先後，排進衝刺（Sprint）內去實做。也談到了如何拆解肥大的用戶故事為數個小故事，以便能繼續將該衝刺的剩餘空檔也能盡量地塞滿，以最佳化該衝刺的負載規劃。
可是，這些作法都必須奠基於「夠精準的用戶故事點數估算」這個前提之下才有意義！那麼，實務上，我們到底應該怎麼來估算用戶故事的點數，才能稱上「夠精準」呢？
敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？
在上一篇文章《敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？》當中，我們談到了衝刺（Sprint）目標，雖然名義上應該由 Product Owner（產品負責人）來制定，但為免團隊根本就不
buy-in，或是團隊實在是無力可達成，故，實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論，來制定各個衝刺的目標，這樣才像一個符合
Scrum 精神的「團隊」！
敏捷方法的成功密技（九）：Scrum 的衝刺目標怎麼訂？
綜合本系列之前的文章，Scrum 其實就是一個小團隊（約５－９人），利用一個個固定短週期的衝刺（Sprint），跟客戶一同逐步漸進地，完成一個產品，而這個產品的功能，就是由一個個，由客戶主導、撰寫的用戶故事（User Story）來呈現需求的（關於用戶故事的簡要陳述，有興趣的朋友可以先參考一下《能讓需求簡化，還能更省時、更省錢，提供更多價值》這篇短文，容日後有空再專文細述之）。
敏捷方法的成功密技（八）：Scrum 的衝刺時間長短怎麼訂？
一個衝刺（Sprint）的時間長短到底應該是多少才是最好的呢？如果衝刺的時間設定得太長，那麼，應變的彈性就會變得比較小，而如果衝刺的時間設定得太短，那麼，又容易讓開發團隊能產出的成果出問題。怎麼說呢？
敏捷方法的成功密技（七之二）：Scrum 的夢幻開發團隊該怎麼來建置？
[承上一篇]
接續上一篇文章《敏捷方法的成功密技（七之一）》，除了新領域、新團隊，最有機會嚐試新作法之外，我們也談到了，只要開發團隊夠紮實，產品的開發就能夠打帶跑，因為品質才能夠被掌控得好。怎麼說呢？
敏捷方法的成功密技（七之一）：Scrum 的夢幻開發團隊該怎麼來建置？
在上一篇文章《敏捷方法的成功密技（六）：Scrum Master 並非你想像的那般卑賤！》中，我們談到了 Scrum Master 這個角色，其實最好是由一位開發和管理經驗豐富的人來擔任，工作經歷不足的菜鳥，是很難勝任得好，更很難以服眾的。
敏捷方法的成功密技（五）：Scrum 的三種角色
在上一篇文章《敏捷方法的成功密技（四）：Scrum的理想與現實的障礙》中，我們談到了Scrum明確定義的三種角色，Product Owner產品負責人、Scrum Master 大師，以及Development Team開發團隊，接下來我們就一一來看看。
敏捷方法的成功密技（四）：Scrum 的理想與現實的障礙
在上一篇文章《敏捷方法的成功密技（三）：Scrum如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？》中，我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題，則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。
敏捷方法的成功密技（三）：Scrum 如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？
理由其實很簡單，在這個溝通的鴻溝沒有被妥善處理、弭平之前，所有後續的努力與投入都會事倍功半，形成「產品客戶不愛，團隊熱情不再」這個賠了夫人又折兵的窘境。那該怎麼做才能「盡可能」地弭平這個溝通鴻溝呢？（注意，我沒說能完全弭平！）
訂閱：
文章 (Atom)