在Scrum项目中执行发布计划时，产品负责人需要避免下面这些错误：没有实施发布燃尽或者发布计划；产品负责人很消极而没有参与发布计划；爆炸式发布，一次性交付大量功能；牺牲质量。
没有发布燃尽或者计划
我曾经见过有的组织走入另一种极端：提前创建非常详尽的项目计划，但根本不执行任何发布计划。单纯考虑Sprint很危险——人们也很容易落入这样的陷阱之中。这样一来，我们很难评估项目的进展情况，也难以正确调整产品和项目。发布燃尽或者发布计划是不可或缺的。我们要将其放在团队的办公室内以及项目的维基页面，以便大家一目了然。
产品负责人袖手旁观
产品负责人应当积极参与发布计划的活动，而不应该将其推诿给ScrumMaster或者团队。发布计划与产品backlog的梳理一样，也是一种协作性练习。这本身就要求产品负责人的全程参与。实际上，产品负责人应当亲自驾驭发布计划活动，作为项目的首要负责人和最重要的负责人，产品负责人要发自内心地对项目加以积极指导。
爆炸式发布
如果你能从本章中学到哪怕是一条经验，也要竭尽所能地尽早而频繁地发布软件。避免爆炸式发布——只有当所有的功能都实施完毕后再交付产品。这样一来，很难从客户和用户那里收集反馈，也不太可能开发出大众喜爱的产品。另外，这种方式还有一种缺陷。爆炸式发布意味着团队只有在软件即将发布时才开始部署软件。这经常会增加团队成员的心理负担，并错失发布良机。
牺牲质量
产品负责人可能会为了追求发布更多的功能而牺牲质量。毕竟，过去人们常常采用这种办法来加快进程。例如，找机会偷工减料，少做些测试，以及推迟文档的写作。问题在于牺牲质量会使团队更难对产品进行维护和扩展，代价也更高。的确，团队现在的工作是完成了不少。但是在未来的几个月内，团队能够完成的任务会变少。削减质量也会降低团队对工作成果的自豪感。这样会埋没他们的技艺水平和优秀的工程实践。团队必须对完成标准了然于心，明确要求只要是标准的产品增量，就必须遵照执行，产品负责人必须将此标准应用于每次的Sprint评审中：部分完成或者作品有缺陷是无法接受的。通过项目纳入时间盒并建立起一个稳定的创新节奏，可以简化发布计划。
--文章摘自《Scrum敏捷产品管理：打造用户喜爱的产品》
Roman Pichler著，李忠利 译
=================================================
