整理編輯／周孟柔, PMP, PMI-ACP

說起企業性的敏捷，Vernon老師說：現在有許多的組織想進行敏捷轉型，但大多數只注意到組織底層的層面，認為「團隊」要敏捷，並沒有真正的理解到敏捷其實是「組織性的轉變」，而不僅是「開發團隊的轉變」。

組織想做敏捷轉型，首先，應該要知道「組織敏捷轉型」的目標是什麼？如果只是追逐一種潮流，那轉變的可能性就非常少。一定要目標明確，"Start with why"，也要有足夠的勇氣及開放性，刻意地開始轉變，這是企業性的敏捷轉型關鍵。

敏捷及Portfolio都有該做的事情，從Scrum的角度知道有Product Backlog或全檢的一個列表(全貌圖)，而Product Backlog的來源可能就是一個Portfolio，在實務操作上，將Product Backlog按每一個功能的投資報酬率做排序，相對應地，原本的Portfolio就有投資報酬率了。所以，不是只有Product Backlog可以排序，不同的Portfolio、Product也同樣地可以按投資報酬率做排序。

Portfolio可以再細分為同時有多個團隊開發多個產品。例如：某一個團隊在開發一個產品，另外一組團隊，則開發另一個產品，這兩個不同的Product Backlog及團隊，就是不同的產品，這種Product Backlog的概念就是把一般認為「多個」混成「一個」團隊的概念，應用在更高一級的Portfolio上。

Vernon老師繼續分享，他發現組織會過於虛擬地判斷投資報酬率。

敏捷從Lean精實生產的概念引進很多想法，這幾年還有一個Lean Startup開始流行，Vernon老師認為Lean和敏捷的共通點非常多，甚至可以說敏捷是Lean的演進。如果能將Lean的理念用在敏捷的環境裡面，投資報酬率就不應該是一個虛擬的數字。

從Lean Startup的角度出發，在實務作法上，可以用Crowd Funding的方式做開發前時程的確認。Crowd Funding是群眾募資，讓大眾投資產品，就可以知道這個產品有沒有市場，也可以用它來支撐Portfolio，這樣公司就可以不使用自己的本金開發產品，而是以用戶募資直接投資，第一證明市場的存在，第二則可以幫助公司做投資。

舉例來說，以Ubuntu.com網站為範例說明，從網站內可以發現Ubuntu正在使用類似的方法做事。從Portfolio的角度探討，Ubuntu執行過一個失敗案例，是想推廣一款叫Ubuntu Edge的手機產品。Ubuntu選擇用群眾募資的方式來確保Ubuntu Edge有沒有市場，根據群眾募資的結果，產品沒有達到預期的價值，就沒有繼續發展、沒去做了。

當然，Ubuntu也有執行過成功案例。在網站頁面上可以看到Feature Set，某一些功能會集中在一起，並顯示群眾募資的數字，這樣就知道哪一些Feature在市場上有好的響應，對於Ubuntu來說，可以清楚知道在Feature、Product Backlog之間應該如何做排序，如果市場沒有好的響應，該Feature可能可以不做。因此，使用群眾募資的方式，更便於企業選擇應做哪些東西，也是發展企業性的敏捷轉型時，更重要的做事方法。

相較於敏捷式開發，預測式專案會有一個常見的問題，是Profolio或Product相關的需求眾多且無法有效地把需求縮小。敏捷有一個Simplicity原則，簡化不必要的工作。例如：沒有時程就不做。從開發功能的角度來說，做產品時會發現產品部份的功能可能不會被使用到，如果這部份的功能不會被用到，就從Product Backlog內移除，不需要製造出來。所以，PO其中一個職責是要確保每個PBI(Product Backlog Items)在市場上的投資報酬率，並將Product Backlog的排序排出來，決定做哪些東西、不做哪些東西。

敏捷有個很關鍵的概念，就是增量式開發。預測式專案需要等最終專案結案，才會有一個Feedback（回饋）及產出。也等於是在每個階段，比如說開發階段，就必須把所有的東西都考慮及完備，百分之百的估算及投入，才可以得到百分之百的回報。但從敏捷的角度來講，會分階段產出，每一個階段都有一個交付物。PO的職責除了做排序外，也要保證在每一個迭代完成之後，都有交付物的產出，且這個產出物是可以實現商業價值的。另外還有一個判斷的方法，如果發現某些東西的成本高於它的價值，就可以決定不做，這也能避免投入工作卻沒有轉換為投資報酬率。

很多人可能認為敏捷著重於團隊怎麼去操作，而不太了解敏捷組織性的轉變對企業的影響，透過Portfolio與敏捷結合的工作方式，希望想實施敏捷的組織可以更加地清楚「企業性的敏捷」實務。