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