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

作者：陈勇原文：http://blog.youkuaiyun.com/cheny_com        是否经常遇到这种情况：领导拿到某个报告，里边充满了各种精美报表（假设我们不再谈论由文字组成的报告了），然而整篇报告仍不知所云，领导看后不知所措，最后报告不知所终。       这是因为报告

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 愿景取舍——高层优先级排序画完图后，产品经理和项目经理一起找到马总。马总：一口气画了4张？第4张好像很强大啊，我们提到的需求都涵盖了，而且还把评价分为了文字和数值

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 本章讲解如何将非常模糊的高层需求，也就是愿景，表达为一个清晰、简单、确定的模型。基于这种简单的模型进行开发，要比基于大段似是而非的文字更容易得到最终想要的结果。什

QUML作为UML、功能点分析FPA、敏捷开发三种管理方法的集大成者，可以被应用于不同的场景。以下的图书各自侧重于一个方面，供不同领域的读者选择。《QUML：量化需求分析与建模》本书从需求分析与建模的角度，介绍QUML的结构、规则、使用方法，是QUML的基本图书。全书通过对一个电商网站的实例分析，分层次地介绍了QUML的结构、用途、规则和最佳实践；书中还概要地对如何将UML应用于早期估算、产品版本

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 第一个月从用例到用户故事，从用户故事到代码在敏捷计划会上——是的，他们采用敏捷开发，确切说是Scrum——产品经理正在给开发人员讲解需求。他并不是空手来的，而是带

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 第二个月从图形到Word测试经理正在审视第一个迭代的测试用例——因为历史原因，他们还没有形成真正的开发+测试的混合团队，独立的测试团队还只能在每个迭代后期单独执行

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 一个量化管理项目的一生​本章通过一个例子展示本书所述的量化需求分析与建模方法在项目中实际应用的情况。注意本章所有数字均只需要两个来源：本章中的配图，业界的数据。配

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 序言统一建模语言UML，量化管理，功能点分析FPA，三个令人敬畏的概念。只有被强制使用的时候，人们才会使用UML进行系统分析，而且多数止步于第一步：用例图。只有所

本文使用三个例子，来说明如何灵活使用不同类型的度量数据，来表征生产率在短期、长期、内部、外部的实际情况。

为了能够统一进行工作量的比较，ISO、ISBSG（国际软件基准比对标准组）/CSBSG（中国软件基准比对标准组）采用了一些分类方法。

这是简化功能点系列的第一篇。目标功能点的目标，是估算工作量，进而估算成本和造价。俗话说：“店大欺客，客大欺店”，银行这么大的客遇上IBM这么大的店，会发生什么呢？那就是功能点。大约在1979年左右，IBM发布了对功能点的基本定义，后来随着业界的发展，逐渐成为当前唯一被广泛认可的软件规模度量标准。功能点最大的特点，就是它和工作量的比例关系很好（应该是，功能点就是为了这个目标而设置的，因此这个不是偶然

这是敏捷开发绩效管理的第六篇。（之一，之二，之三，之四，之五，之六，之七） 直接估天数或用故事点估天数，都很“程序员”。如果在项目的甚早期，面临与客户相关的报价问题，或高层领导要统计公司绩效并想进行项目乃至行业间的比较，这两种方法都很难使用。敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法，是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情，比天数、故

这是敏捷开发绩效管理的第七篇。（之一，之二，之三，之四，之五，之六，之七） 续前文…… 功能点估算第一级简化上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。NESMA早就遇到过这个问题了，他们这么解决：通过统计发现每个数据差不多有7

这是敏捷开发绩效管理的第五篇。（之一，之二，之三，之四，之五，之六，之七） 度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。 度量敏捷生产率的目的真正难以回答的是度量生产率的目的是什么？很多人都认为是考核绩效，发奖金。根据上一篇文章的内容我们可以知道，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目

本书由本人编写，于2014-09-09在百度阅读首发，博客将转载试读部分的20%内容，以及非试读章节的某些片断。电子版链接：http://yuedu.baidu.com/ebook/c7a9a6dc680203d8ce2f24a6### 角色-业务图（RB图）下面是QUML中使用的方法，称之为“角色-业务图”（Role-Bussness Diagram，简称RB图）。通过分析角色和主要业务，表达愿