Product Owner 正面且积极的看待团队开发人员能力上的问题，Product Owner 才能即时的淘汰不适任的开发人员。团队也才能真正的拥有效率，产品也才能真正的获得质量上的保证。
借由 Story 场景树，Product Owner 在 15 分钟内便可确定：开发人员是否真的具备能力去开发 User Story。
但，为何 Product Owner 已借由 User Story 场景树，确定某个开发人员并不具备开发 User Story 的能力时，为何还是允许这个能力有问题的开发人员，继续去开发 User Story？
这个问题我深思了许久，我想最根本的原因在于：
1. Product Owner 往往是在迭代进行中才识别出不适任的开发人员。而 Product Owner 所承接的版本工作量与所承诺的交付日期，是在迭代前便已确认了。所以，Product Owner 在当下一时找不到更适合的开发人员，另一方面又无法更改已承诺的版本需求与交付日期时，只好先硬着头皮，让不适任的开发人员继续开发。即使不适任的开发人员所真正交付的是 “问题单”，而不是 “产品”。
2. 当 Product Owner 更热爱的是技术，更擅长解决的是产品的问题单，而不愿意且不擅长去解决与提升团队开发人员的能力。同时 Product Owner 也欠缺观察团队与识别项目风险的视野与能力时；Product Owner 眼中往往便只有交付; Product Owner 整天只会简单粗暴的带领著团队作交付；最终, 等一大堆的问题单被发现了，自己再来熬夜的来解决。
也就是说.....
Product Owner 并不认为让不适任的开发人员，开发 User Story 是问题; Product Owner 往往只认为无法交付是问题。
Product Owner 也并不认为熬夜改问题单是问题。
Product Owner 只会认为有一大堆的问题单，都是因为需求太多所造成的；而不是因为不适任的开发人员所造成的。
所以，虽然产品级敏捷的工程实践，已确定能即时识别出团队开发人员的问题。但，我们仍必需要再好好的培养 Product Owner；使 Product Owner 在面对庞大的版本交付压力与形形色色不适任的开发人员时，依旧有意愿与能力去面对与解决, 团队某些开发人员在能力上不足的这个根本上的老问题...
