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

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

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五细节故事的组织，故事树从属关系 陈勇-创业-北京(**9107533) 13:56:39有了这个高层计划表，再看细节，比如：陈勇-创业-北京(**9107533) 13:57:44哦，原来计划会/日历/意向表……，里边有这些细节故事，他们又有轻有重，有些尽量早一

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五众多用户故事如何组织？（主干故事的组织与排序）陈勇-创业-北京(**9107533) 13:47:24 第二个大问题：这些用户故事如何组织？ 一个真正的系统开发下来，我们一人年就造了300个用户故事，大大小小，有的从属于某些，有的单独存在，有些最后排在别人后面…

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五关于如何描述“纯技术问题”现场讨论阚野-pm-北京(36916487) 13:38:12 勇哥 可以问问题吗 陈勇-创业-北京(139107533) 13:38:20 好，请 阚野-pm-北京(36916487) 13:38:27 对于代码结构重构 这个价值如何

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五非功能性需求的用户故事描述（缺陷） 陈勇-创业-北京(**9107533) 13:27:44下面这个，则是缺陷。缺陷的语法，也想过一些，现在还不太稳定：话说火星人上面，可以同时对多个产品进行计划（就是一个项目组可以同时开发多个产品）这就有一个“如何平衡每个产品这

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五 非功能性需求的用户故事描述（增强，重构）陈勇-创业-北京(**9107533) 13:14:08基于这个出发点，我们就可以看看另外的几种”细枝末节“的故事怎么写了。比如这个增强：突出显示本次/上次/下次意向表增强是说：一个产品经理做计划的时候，如果能同时看到本

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五回顾及普通用户故事（功能）的写法陈勇-创业-北京(**9107533) 13:02:13 这个讲座分为两期，原因是用户故事在早期和晚期有两种重要功能。 早期，是描述、分解和估算需求的数据；晚期，则是指导开发并反应开发的进度。这是需求条目化的优势。 我们特别提到，

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五 利用功能点数据对业务数据和业务操作进行早期快速估算陈勇-创业-北京(**9107533) 13:25:06好，暂停一下，看大家有没有什么问题？中惠 李-GZ(**215419) 13:26:17你所描述的业务数据，可能需要加以区分陈勇-创业-北京(**9107

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五 大数定理，从功能规模到到人天陈勇-创业-北京(139107533) 13:40:22@听说：好，下面就说说这个甚早期估算的用法。先说说为什么不让资深人员在甚早期做估算？原因是资深人员都是技术专家而非业务专家，所以如果能知道业务是什么并精确描述，这个人估算很准的

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五 总结，大量“主干故事”的组织方式预览（详情在下期）（最后有下期内容预告） 好了，总结一下说了这么多，到底这个分类法有什么好处：１.　文件＋操作，简单地勾勒出产品的结构，清晰描述了产品的对外功能２.　文件和操作的数量，可以直接表征产品的规模，并能在甚早期就可以科

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五以下，是2012-06-26的现场交流文字及图片，请参考。下一期时间，请关注本博客。哪些用户故事是“主干故事”？回复谷雨霖(**58818) 13:00:09今天我们非常有幸请到了敏捷实践大师，PMBar老朋友，PMBar专家顾问团资深专家@火星人陈勇晋智红-P

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五 两种主干故事-业务数据与业务操作陈勇-创业-北京(**9107533) 13:13:32好了，先确认哪些是重要功能呢？借用了FPA就是功能点分析里边的概念，发现有两类故事最重要。1. 用户的业务数据。比如火星人需要对用户、权限、角色进行管理，那么“用户”“权限

这是敏捷开发一千零一问系列的第三十三篇。（在这里提问，之一，之二，之三，问题总目录）也是敏捷开发用户故事系列的第十篇（栏目目录）。问题需求清晰到什么程度可以进行开发？一定要弄清楚需求才能开发吗？怎样才能弄清楚需求？注意下面的分析是在基于合同的项目开发的语境中的。产品和互联网需求开发的过程，日后另有讨论。分析与步骤以下文字摘录于群聊天记录，未做深入修改，见谅。项目语境如果只分两种，那么整体上有两种项

面对一张白纸的时候，如何才能迅速理清头绪写出一个结构相对完整、颗粒度适中的功能清单，而且程序员就知道了要写哪些类和函数？下面是简单的八步走法。

这是敏捷开发用户故事系列的第十一篇。（栏目目录）经常有人问起有没有完整的用户故事案例。本人在网上找了一下，大约能找到两三篇，但多数只是为了描述用户故事的语法而已，都不涉及用户故事的颗粒度、大量故事的组织结构这类内容。本来想用我们自己的火星人做案例，但考虑到大家都不熟悉我们的工作内容，一直没有动手。前天突然想到何不用大家都熟悉的优快云博客系统做一个演示，所以才有此文。分析过程使用的方法是敏捷开发用

7月16日周二晚上，陈勇，【敏捷网络课堂第六期】【免费】敏捷开发早期估算课程简介：“响应变化胜过遵循计划”，所以敏捷开发中的估算过程主要指在每个迭代计划会中，由开发人员自主估算本次迭代的工作内容。可是，随着一个个迭代结束，开发人员可能才逐渐感觉到整个项目需要一年，而实际上，高层领导早就签订合同或立项要求整个项目在半年内完成……而这个项目如果真的超期了一倍，那么到底是高层领导的决策失误，还是团队的生

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五之一：关于统一过程UP的讨论陈勇-创业-北京(**9107533) 13:02:11这三期，都是关于用户故事的管理的。不过，每次的话题不太一样。现在，先回顾一下以往的两期。在回顾之前，先说一下“UP”的问题。陈勇-创业-北京(**9107533) 13:03:1

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五之三：用户故事树与MVC中Controller和Action的关系陈勇-创业-北京(**9107533) 13:26:18当然，只解决模块设计，还是不够的。不过，再仔细看看两张图：代码图：故事树：对比上面最近的两张图下图SprintCalendars = 上图S

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五之四：非Web和非MVC的MUP设计思路听说-码农-SH 13:39:39 问个问题，多少比例的项目都可以如此容易分解为这样的 {category}/{name}/{action}的模式 我感觉过去 应该有一些项目没法这样搞 陈勇-创业-北京(**9107533

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

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

这是敏捷开发用户故事系列的第九篇。（栏目目录）本文适合听过MPD上《敏捷开发需求管理：用户故事分类、颗粒度及组织结构》，或参加过《火星人敏捷开发培训》听过第一天下午课程的读者。若您阅读过程中感觉缺少铺垫的信息，请先阅读：敏捷开发绩效管理之六：敏捷开发生产率（中）（功能点分析，FPA，简化的功能点）敏捷开发绩效管理之七：敏捷开发生产率（下）（简化功能点分析，NESMA，两级简化）若需要更详细情况，请

这是敏捷开发日常跟进系列的第五篇。 （栏目目录） 用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易把故事写坏。但是MVC和用户故事有很大的关系，如果用户故事写好了，做MVC的时候，一定要记得参考用户故事。本人在C++的年代用过MVC，但那个时候MVC还只是一种编程思想，说用了也行，说没用也行。但到了C#之后，就出现了正牌的自称是MVC的东西（

这是敏捷开发日常跟进系列的第六篇。 （栏目目录） 要想不在评审会上得到“惊喜”，Product Owner最好提前约定好用户故事的验收标准，而且每个用户故事可能各不相同。面向客户价值设定验收标准简单说，就是客户看到说“完成了”，才算完成了。从这一点上说，用户眼中的“可工作软件”和我们认为“可以运行，自动化测试了的，没有缺陷的”软件还是有差别的。用户拿到软件，是要使用从而获得价值的，这常常需要多个功

这是敏捷开发日常跟进系列的第六篇。 （栏目目录） 产品负责人常常被描述成在计划会前准备好用户故事，在计划会上讲解并帮助开发团队估算后就万事大吉，只等月底接收“可工作软件”的样子，其实如果真的这样，很容易出问题。需求精化这是发生在迭代周期中间的常规活动，产品负责人会与团队密切接触（确切说如果能经常坐在一起更好），在每个故事开发的前夜或中间，将之前讲解过的用户故事更详细地描述一番（有时候是在看到开发一

这是敏捷开发用户故事系列的第一篇。（栏目目录）全系列将涉及何为用户故事，面向客户价值编写故事，用户建模，产品待开发项的分类，故事颗粒度，故事的组织结构，等等若干问题，力求将此中问题尽量解决干净。本系列文章假设正在编写一个“敏捷开发管理软件”，因为来阅读的都是做敏捷开发的，又都是做软件的，会更熟悉一些。用户故事三要素：角色，功能，价值按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就

这是敏捷开发用户故事系列的第二篇。（栏目目录）敏捷开发中的用户故事采用的语法模式看似简单，却蕴含着深刻的思想。“作为一个……，可以……，以（以便）……”不同于一般专注于功能的需求条目描述方法，三个……把角色、功能、价值跃然纸上。然而使用不当，却有可能形似而神不似。下面就三个部分分别举出一个例子。网络游戏的排行榜功能“作为一个玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可。”这个功能可以

这是敏捷开发用户故事系列的第三篇。（栏目目录） 用户建模的目的，是为了更好地分析用户行为和用户价值，并因此获得商机。用户建模四部曲有一次培训中，分组建模的时候，一位学员就自言自语地说了一句话：“真的啊……我好像不知道谁会使用我的产品……”这其实是一种常见的现象。比如前文所说的敏捷开发管理软件，如果想把一个用户故事描述为“作为一个用户，可以登录“我的空间”，以查看我我在的所有项目的进展以及自己的任务

这是敏捷开发用户故事系列的第四篇。（栏目目录）优先级排序听起来是一个很简单的工作，一个字段无外乎“重要/一般……”，调整一下然后按排序，就出来了。但其实里边有不少名堂：谁应该负责排序工作？谁最终拍板？研发因素要不要考虑？需求依赖关系导致的顺序如何处理？持续交付的考虑？商业决策的考虑？以下知识与经验，来自于多个来源，主要是部分网上资料、实际项目的访谈，并在自己现在正在做的一个项目中得到验证。具体应用

这是敏捷开发用户故事系列的第五篇。（栏目目录） 引子在之一、之二、之三中，我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式，还提到应该如何描述用户故事，才能更好地反映客户价值。下面请尝试一下描述这两个故事：1. 如果把“保存按钮”统一放在页面上端而非下面，有些屏幕上侧控件的修改，就无需滚屏即可保存。2. 所有自定义字段，统一改为4000长度的nvarchar。第一个勉强可以写为：“

这是用户故事系列的第六篇。（栏目目录） 一条需求敢跳出来，基本上就能被化成一条用户故事，看完一二三四五，上山打老虎都不怕，这个似乎已经不太难了。难的是，项目或产品的第一天，给一张白纸：“请列出有哪些故事”。那个时候其实不是大脑空空，而是有千言万语就是说不出。前年做另外一件事情的时候偶然得到一种方法，去年到今年用在一个敏捷项目上，果然很舒服地列出了大量故事，后来的开发过程证实它们都满足独立交付、可测

这是敏捷开发用户故事系列的第八篇。（栏目目录） 本文内容来自火星人团队对火星人产品中300个用户故事编写后总结的经验和成果，欢迎致力于敏捷开发而又对用户故事感到困惑的开发者参与讨论。本篇文章尤其适合参加MPD专场“用户故事颗粒度、分类及组织结构”的学员，及参加火星人敏捷开发产品培训的学员。 用户故事中，最有名的就是三段式语法了：“作为一个……（角色），可以……（功能），以便……（客户价值）。”然而

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五主题：《用户故事与计划/架构/开发/测试——火星人的需求管理理念（三期）》日期：2012-08-28（周二） 13：00～14：00对象：面向产品经理、项目经理和开发骨干，偏向需求管理和产品设计。关键词：计划，架构设计，任务管理，测试往期回顾：一期主要讲了在项目

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五 主题：《用户故事分类与组织结构——火星人的需求管理理念（一期）》日期：2012-06-26（周二） 13：00～14：00对象：面向产品经理和开发骨干，偏向需求管理和产品设计。关键词：敏捷开发 用户故事 史诗故事 重构 增强 缺陷 MVC FPA 功能点分析内

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五之五：用户故事树与测试用例/测试结果的关系，总结陈勇-创业-北京(139107533) 13:59:44下面说说测试以往的时候，测试用例基本上是基于测试人员的理解分条目写出来的。那这些条目和用户故事什么关系呢？这个是我们现在基于用户故事管理测试用例的界面：注意看

公开课名称：产品研发敏捷统一过程AUP2.0官方链接：http://huiyi.youkuaiyun.com/activity/closed?project_id=2619本来今天答应大家在这里上传附件的，刚发现“您因违反优快云下载频道规则而被锁定帐户，如有疑问，请联络:webmaster@youkuaiyun.com”，估计是个Bug。等解决后，我会上传课件和模板并把链接放置在这里。其中提到的关键需求分析技术在此免费