敏捷发布路线图_产品路线图具有敏捷性

敏捷发布路线图

我最近在收听“ 全球产品管​​理讲座 ”现场播客（顺便建议，我推荐）。 演讲者谈到了创建产品线的路线图。 对我来说，这是一个有趣的话题，因为我每天都在玩各种产品。

随着采访的进行，我在Twitter上问：路线图与敏捷性有何关系？

我想我得到的答案有点平淡。 似乎是与市场和销售部门，甚至每个人都进行了敏捷的协作。 这不是我想要的，我解释了我真正要问的问题：路线图是一项巨大的计划工作。 敏捷就是要适应变化。 他们怎么能一起生活？

路线图抗拒变化

自从放弃产品经理一职以来，我就制定了路线图，主要是因为有人要求我这样做。 包括我在内的一些人将它们视为我们当前计划的快照。 事情改变了，计划改变了，因此“路线图”也改变了。 那是敏捷的观点，不是吗？

但是，有些人对路线图的尊重程度更高。 如果您不那么敏捷，但是花时间跳过瀑布，该怎么办？ 路线图不仅会产生计划时间，还会为该计划投入资源。 然后该计划可以继续进行，使之具有完美的瀑布意义。

问题在于，通过尽早作出承诺，我们会关闭可在遇到麻烦或机会时帮助我们进行变革的选择。 路线图是早期承诺的缩影。 他们抵制变化。

我还没有设法通过点子传达我的观点。 我希望现在情况会更加清楚。

但是，我的故事并没有到此结束。

在路线图上进行协作是整个团队的工作，这是很大的敏捷价值。 但是我在演讲和推文中有一个细微的差别：“ [Roadmapping]要求与Roadmapping过程中包括的敏捷开发人员保持一致”。

敏捷是开发人员管理工作的方式

一旦制定了路线图，开发人员便可以根据需要开发产品。 如果他们也选择敏捷。 他们可以并且应该具有持续的集成，自动测试以及全部功能。

因为他们是敏捷团队。

请注意，“他们”不是“我们” 产品经理，项目经理，决策者。 我们决定，他们工作。

命令与控制与瀑布齐头并进。 我们可以尝试通过各种协作，更好的沟通，共同的愿景和统一性来包裹整个过程。 但是，当您听到“我们”和“他们”时，您就会知道那里没有真正的敏捷性。

开发团队做站立式训练不会使您敏捷。 进行回顾不会使您敏捷。 即使以恒定的速度交付（不停！）也不会使您敏捷。

敏捷性不是开发人员的事。 这是一件商务事。 如果您发现路线图因为竞争对手在您所在的地区获得牵引力而毁了，并且您无法竞争，那可能不是您的开发人员不够敏捷。 可能是您过度使用了资源，现在无法扭转局面。

那时，“我们”或“他们”谁是错的都没关系。 都是海底的“你”。

那这些路线图呢？

路线图是工具。 他们形象化了一条前进的道路。 但是只是一种方式。

睁大眼睛，因为您可能需要很快意外地利用另一个选择。

发生这种情况时，您将很高兴成为敏捷团队的一员。

参考：我们的JCG合作伙伴 Gil Zilberfeld在Geek Out of Water博客上提出的产品路线图具有反敏捷性 。

翻译自: https://www.javacodegeeks.com/2014/02/product-roadmaps-are-anti-agile.html

敏捷发布路线图