廊坊网站优化/站长工具权重

既然价值不好控制也不易评估，许多Product Owner便将眼光放在「进度控管」上面，毕竟产品的释出进度也是Product Owner需要负责的部分。Product Owner 10 个里面有9个或多或少都觉得开发团队进度太慢。Product Owner经常公开或私下抱怨：

• 为什么这个sprint只拿那么少量的user story？
• 每个sprint承诺的user story为什么总是做不完？
• 承诺的user story做不完为什么没有「自愿加班」把它做完？

为什么快不了？

「预估进度与实际进度不符」是软体开发经常面对的问题。根据字面上的意思，「预估」原本就包含「猜测」与「误差」的涵义，而「实际进度」总是要等做出来之后才晓得。所以「预估进度与实际进度不符」实属正常现象，请安心服用。

但是，身为Product Owner还是要为产品的整体进度跟老板或客户交代，因此无法容忍实际进度跟「Product Owner脑袋中的进度」相差太大。

Scrum只是一面照妖镜。Scrum跑的好，可以反映出个人、团队与组织的现况。如果Product Owner觉得团队进度太慢，应该与团队一起探讨关于进度认知落差的原因，例如：

• 不熟悉Scrum：刚开始接触Scrum的团队，前半年可能都还在熟悉Scrum与敏捷开发的思维与团队合作模式，因此开发进度会比较慢。
• 团队的真实进度就是如此：以前隐瞒现实状况才让进度看起来符合预期，例如：牺牲品质、功能没有做完但却宣称已完成，反正有问题等QA测试再来除错就好了。现在跑Scrum，透明性增加，只是反应出团队的真实状况而已。
• 需求的不确定性高：需求的不确定性高，或是Product Owner与开发团队缺少问题领域的专业知识，导致边开发边厘清需求，以及增加重工（rework）的时间。
• 技术的不确定性高：开发过程采用太多新技术，因此团队成员需要花很多时间去学习与熟悉这些技术。加上新技术通常不太稳定，学习资源也比较少，因此增加团队的学习曲线。例如，采用新的JavaScript框架、新的程式语言、新的软体架构、新开发环境或建构工具。
• 多工与中断太多：除了开发工作，团队经常被中断处理其他产品或专案的维护或救火工作。这可能代表以前开发的品质太差，现在回过头来「讨债」。或是每个人负责的工作太多，多工切换导致浪费，虽然每个人看起来很忙，但真正花在工作上的时间反而很有限。
• 外部相依性高：开发的产品有很多外部相依性，例如需要与协力厂商配合，或是开发软体相依于公司其他部门的韧体与硬体。无法有效管理外部相依性，因而影响到产品开发的进度。
• 开发环境与设备太烂：有些公司业务团队就在开发团队的隔壁，业务与客户讲话自然音量比较大，干扰了开发团队的思绪。另外，开发设备太烂也会严重影响开发进度，例如开发电脑太慢、记忆体太小、没有双萤幕、键盘太难打、持续整合伺服器跑太慢、测试设备不足等，都会影响开发进度。
• 开发人员不适任：进度太慢当然也可能是开发人员本身的问题，可能能力不符合团队的期望，而且一直无法有效提升自己的能力。或是有些团队成员立志当米虫，能捞就捞、能混就混。也有些人比较适合传统瀑布式专案，一个口令一个动作，不习惯Scrum团队的自组织模式，因此表现不佳。遇到这种情况，就不需要客气，该换人时就需要换人。

(摘录: teddy-chen Blog)

Agile & Scrum Basis

• Comprehensive Scrum Guide
• What are Scrum's Three Pillars?
• What is Agile Software Development?
• Scrum in 3 Minutes
• What are the 5 Scrum Values?
• What is the Evolution of Scrum?