观念不对！转型不应该只重开发团队

　　组织想做敏捷转型，首先，应该要知道「组织敏捷转型」的目标是什么？如果只是追逐一种潮流，那转变的可能性就非常少。一定要目标明确，"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与敏捷结合的工作方式，希望想实施敏捷的组织可以更加地清楚「企业性的敏捷」实务。