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

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

本文是敏捷开发一千零一问的第三十五篇。（栏目总目录）问题相比项目开发，产品研发中获取准确需求难度更大。因为客户和用户比较模糊，需求经常不知道问谁，而另外一个问题则是不知道该怎么问。本人有幸参加过由Lean Startup Machine主办微软协办的精益创业培训课程（Lean Startup），课程中一个议题就是如何获取准确需求。分析为大众软件/应用收集需求的时候，首先应该注意，不要问有导向性的问

这是敏捷开发一千零一问系列的第二十六篇。（在这里提问，之一，之二，之三，问题总目录）问题如何进行优先级排序？具体故事的优先级，和版本规划的优先级之间有何关系？分析敏捷开发里边有很多地方需要多次进行优先级排序，本文将探讨其不同的应用场景，及其关系。值得注意的一点是，敏捷开发中有无数的“自相似性”，比如估算，每年、每月乃至每天人们都在潜移默化地估计自己的任务；又如计划，也是每年每月每天都有成文或不成文

（序言，之一，之二，之三，之四，之五） 本文是《火星人》系列的子系列，将分期向大家分享火星人敏捷开发管理工具的开发和管理实践。一直以来，敏捷开发长期受困于各种名词、术语的堆叠、罗列、解释，而较少出现原创和实践分享过程。而敏捷实际上本来只把自己作为一个起点，需要大家的丰富和扩展。这可能与中国的软件业发展长期落后于国际所致，以及在PMP、CMMI推广中所养成的重标准、轻实践的的情况有关。本子系列会与大

（序言，之一，之二，之三，之四，之五） 第一个月：一个产品的诞生 没有国王，没有宰相，没有能讲故事的王后，也没有需求文档，开发就这样开始了：为何不先写需求文档？因为敏捷开发不写文档！不是的。策划这个产品的时候，有一个大愿：就是用这个产品管理这个产品自己的研发。虽然这不等于没有“长得像”Word的文档的需求，但是我们仍然想尽量只用产品本身的功能来写需求。所在在项目开始的那天，我们手里（确切说是脑海里

（序言，之一，之二，之三，之四，之五） 先开发整个框架，还是先开发故事群？         当用户故事的增删改查都还没做的时候，这个问题就被提了提出。         最初曾经想：只做故事的显示功能，增删改都在数据库内直接操作，然后迅速进入“迭代计划”部分，把迭代计划大致弄出个样子来后，赶紧做燃烧图、故事板……但是这个想法很快就被否定了，因为在此前做敏捷咨询的时候就曾经在用户项目里发现：如果把一个

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

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

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

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

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

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

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

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