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

敏捷开发培训咨询敏捷开发免费工具免费培训教材《火星人敏捷开发手册》 IIOM咨询总监火星人首席架构师兼主程序员

12月 11月 10月 09月 08月 07月 06月 05月 04月 03月 02月 01月

原创敏捷开发一千零一问系列之十：总体架构什么时机进行？（下）

这是敏捷开发一千零一问系列的第十篇。（在这里提问，之一，之二，之三，问题总目录）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？方案之前提到了在时间的角度上，从技术和商业层面上的架构设计，下面看看横向的架构设计。方案1：开发人员全体参与架构设计敏捷开发整体上是一个崇尚“跨职能”的管理方法，开发和测试融合（所以才有很多类似自动化测试、单元测试、持续集成这些需要开发人员强参与的测试活动）

2012-01-30 18:09:25 10655 9

原创敏捷开发一千零一问系列之九：总体架构什么时机进行？（上）

这是敏捷开发一千零一问系列的第九篇。（在这里提问，之一，之二，之三，问题总目录）问题总体架构设计在什么时机进行？是每个迭代做还是先做完再迭代？这是少数几个被提到的技术问题。在两天的培训课程之后，最后剩下的纯的技术问题一般只占1/5都不到，多数都是管理问题，而管理问题中，又基本上是人的管理问题，这也说明了在“心法人事物”中，心总是第一位的。方案最早想写成方案1、方案2，但感觉有点像说是有不同的很多并

2012-01-20 10:48:13 11569 3

原创敏捷开发一千零一问系列之八：团队习惯了分工怎么办？

这是敏捷开发一千零一问系列的第八篇。（在这里提问，之一，之二，之三，问题总目录）问题在Team中，TeamLeader给人指定任务时，基本没有选择怎么办？（因为大家对别人的工作都不熟悉）方案步骤1：如果团队已经习惯了沉闷地自己开发自己的工作，办公室里边总是静悄悄的，那么一个可行的起点，是Leader可以先与大家进行松结对，就是不断地指导有难题的人。实际上当大家听到有人在交流的时候，就会侧耳听听，如

2012-01-19 11:58:39 10552 10

原创敏捷开发一千零一问系列之七：怎样对待有看法的徒弟？

这是敏捷开发一千零一问系列的第七篇。（在这里提问，之一，之二，之三，问题总目录）问题松结对编程中，师傅对徒弟安排任务时，对于有想法的徒弟提出的意见怎样解决？方案步骤0：正心，诚意。人们到底是在管理一个人（控制，监督，指令）还是领导一个人（帮助，引导，培养），被管理者和被领导者其实心里是一清二楚的。因此在师徒关系中，不能为了师徒而师徒，而是要找到师+徒这个体系的目的，把心态放在把事情做好而非维护师徒

2012-01-17 10:18:45 13085 27

原创敏捷开发一千零一问系列之六：业务人员怎样参与开发？

这是敏捷开发一千零一问系列的第四篇。（在这里提问，之一，之二，之三，问题总目录）有一次课程上居然来了一个非开发人员，他是个网站的业务人员，提出了这个问题，并被评为课堂最佳问题之一。问题一线业务部门应该怎样具体参与到敏捷开发中来？答案方案1：敏捷开发中有很多活动是需要业务部门参与的，如果没有时间，第一个要参与的事情是“评审会”，就是阶段性验收产品的会议。在会上应该思考产品在实际应用中是否可用，并提出

2012-01-12 12:04:10 8359 9

原创敏捷开发一千零一问系列之五：怎样让队员主动要活？

这是敏捷开发一千零一问系列的第五篇。（在这里提问，之一，之二，之三，问题总目录）本问题被评为某次课程最佳问题之一（每场2～4个）。问题怎样让团队成员完成从派活到主动要活？方案步骤0：在一个传统团队中，多半是由一个人（一般是项目经理）估算、分配、监督任务完成。由于这个人处于鸡的角色（请参考百度“猪与鸡”），所以真正承担任务的人要冒任务被错误估算和分配导致绩效低下的风险，引起大家的不满。按时完成了经理

2012-01-11 11:42:38 10665 16

原创敏捷开发一千零一问系列之四：优先级排错怎么办？

这是敏捷开发一千零一问系列的第四篇。（在这里提问，之一，之二，之三，问题总目录）这个系列的文章太多，除了用于总结性篇章外，请访问“问题总目录”查找感兴趣的具体问题。初始问题对于不断更新的需求，导致需求优先级的判断出现了错误，知道项目周期后期才发现，怎么办？答案1. （临时方案）确保所有排序均是由PO完成的常常出现所谓现场客户、由客户出PO、由一个销售当PO的情况，都是应该避免的。PO一方面要熟悉具

2012-01-10 11:26:26 9295 6

原创敏捷开发一千零一问系列之三：序言及解决问题的心法（共振）

这是敏捷开发一千零一问系列的第三篇。（在这里提问，之一，之二，之三，问题总目录）也是般若敏捷系列第十二篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九，之十，之十一，之十二）共振共振是以无我、无住精神推广敏捷时的具体做法。很容易被简单理解为循序渐进，但这样理解不全面，这也是为什么会出现“共振”这个奇怪的词汇。之前的无我、无住，也都很难找到完整替代的又没有歧义的词汇或语句。循序渐进很多人都

2012-01-10 10:38:33 8951 7

原创敏捷开发一千零一问系列之二：序言及解决问题的心法（无住）

这是敏捷开发一千零一问系列的第二篇。（在这里提问，之一，之二，之三，问题总目录）也是般若敏捷系列第十一篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九，之十，之十一，之十二）无住在般若敏捷系列中已经提过，包括不住于法，不住于空。不住于法就是不停留在一种固定的方法上。如果把“敏捷”理解成一个名词，就会出现一个问题：什么是敏捷？又会扩展成Scrum是敏捷，还是XP是敏捷？RUP是不是敏捷？

2012-01-10 10:37:34 9203 4

原创敏捷开发一千零一问系列之一：序言及解决问题的心法（无我）

这是敏捷开发一千零一问系列的第一篇。（在这里提问，之一，之二，之三，问题总目录）也是般若敏捷系列第十篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九，之十，之十一，之十二）做敏捷开发时间长了，就感觉很多事情都理所当然，越发觉得“问题很可贵”，最近做培训的时候收集了一些问题，很多现场来不及解答，逐一发表在这里。如何解决一个问题知识多了自然可以解决问题，经历多了自然也可以积累经验，但是在一

2012-01-10 10:36:43 16292 24

功能点需求模板

注意如果使用工具，Jira和TFS都有三层需求结构，分别对应Word目录中的：一级目录：项目名称二级目录：Jira-Theme，TFS-Epic 三级目录：Jira-Epic，TFS-Feature 四级目录：Jira-Story，TFS-Story。注意Jira和TFS都不约而同地采用了三级目录，但是都没有提到如何划分和获取三级目录，以及三级目录的实际物理含义（比如在软件中到底是个页面，还是个表，还是个Controller……）。而本方法可以让需求直接与软件对应起来。

2015-11-26

产品研发敏捷统一过程 AUP2.0

产品研发敏捷统一过程 AUP2.0的课件，另附有一个Word模板用来演示以这种方式形成的需求文档结构，可作为Scrum中的Product Backlog。请参考：http://blog.csdn.net/cheny_com/article/details/50020243

2015-11-26

火星人敏捷开发早期估算

“响应变化胜过遵循计划”，所以敏捷开发中的估算过程主要指在每个迭代计划会中，由开发人员自主估算本次迭代的工作内容。可是，随着一个个迭代结束，开发人员可能才逐渐感觉到整个项目需要一年，而实际上，高层领导早就签订合同或立项要求整个项目在半年内完成……而这个项目如果真的超期了一倍，那么到底是高层领导的决策失误，还是团队的生产率只有别人的一半？这就让我们不禁想问：有没有一种方法，在签署合同或立项前，仅仅凭借几页Word和有限交互，就能把十几人年的项目推算到±20%的精度内？有没有一种方法，不仅能在早期做估算，还能把估算结果直接演进为敏捷开发中的史诗故事和用户故事？有没有一种方法，不仅能让开发者意识到代码的不断增长，也能让客户和领导同步地理解并认可需求的蔓延？有没有一种方法，能在项目结束时，简单数数史诗故事和用户故事，就能将项目的完成情况与此团队的历史做纵向比较，甚至还能与其他团队、乃至业界的数据做横向比较，并让客户和老板信服？

2013-07-14