陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》

本文是敏捷开发产品管理系列的第九篇。（专栏目录）其实子系统不是一个严格的定义，这里指任何产品（当然还有一个问题，什么是一个产品……）的第一级功能目录，也就是最大尺度上的产品分解方法。由于业界一直缺少标准分解方法乃至一些简单规则，可能一百个产品有一百个分法。在开发火星人的过程中，“我们”偶然发现了一种易于掌握的方法。“我们”加上引号，是因为实际上是我在培训课的学员看了我们实际的分解结果后发现的；被他一语道破之后，我本人也恍然大悟。

本文是敏捷开发产品管理系列的第八篇。（专栏目录）在产品开发中，常常遇到产品性能问题，这些性能问题会很大程度上影响到产品的架构。但解决这些性能问题，切莫认为只是技术人员的事情，产品经理和产品总监也要参与其中，甚至是业务人员（销售、售前）。下面以12306的售票问题为例，来做一个完整的说明。本文的目的，不是说技术性优化不必要，而是说作为开发人员不要闷头只想技术，而作为产品经理不要把所有“技术”问题推给

本文是敏捷开发产品管理系列的第七篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理），也是敏捷开发团队管理系列（拟）中的一篇。目的在之前的《Product Servant》一篇中曾经提到，作为产品经理或产品总监，都应该有自己的方式来根据市场和用户情况来管理产品的走向，其中前者更倾向于具体的功能，而

本文是敏捷开发产品管理系列的第六篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）马与马车夫的故事这是心理学上的一个比喻。马拉着车向前走，它说：控制车去哪里的是我，我走，车就走；我停，车就停；我转，车就转。马车夫笑了，他说：控制车去哪里的是我，我让车走，车就走；我让车停，车就停；我让车转，车就转

本文是敏捷开发产品管理系列的第五篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）粗估会议是一个较少使用的敏捷实践，但其作用还是很明显的。WhyScrum里边，有两个关于需求的比较头疼的问题。一个是PO不太懂技术，不知道故事大约需要多久才能完成。为什么PO要知道？因为如果划分的颗粒度不好，会导致

本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）这里所指的新产品研发，不是指自己企业的新产品，而是特指那种在行业中初创，前途不明，尚需市场检验的新产品。敏捷开发可以在很大程度上帮助这种产品的开发过程。新产品的第一要务策划新产品的第一要务是：谁会买这种产品？为什么

本文是敏捷开发产品管理系列的第三篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）上周在培训做“用户故事的用户建模”练习的时候，就有人提出一个疑问：这么短的时间里边，能定义好用户群和用户群分类吗？答案是：不能。用户群的规划是产品概念期就应该完成的工作，它是一个产品管理工作，而非需求管理工作。用户

本文是敏捷开发产品管理系列的第二篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）本文是一篇旧文，原名为《“迭代期内无变更”与敏捷开发产品版本规划》，因符合本系列内容，做相应修改后重新编排发出。迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求

本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）序言之前的“敏捷开发用户故事系列”已经提到了微观层面的需求管理问题。由于敏捷开发的提出者和实践者主要是开发团队及其领导，因此一般较少提及产品的整体规划、商业目标这些内容。本系列汇集了本人在做产品管理的时候的一些心得