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

一个简单的问题，计划扑克就是打不出个结果，各持己见怎么办？也就是少数人无法说服大家，或者说根本无人去听回答：计划扑克的结束条件”近似一致“是个很有趣的标准，其实要回答”什么时候停止打扑克“，就要先解决”为什么要打扑克“的问题。如果打扑克的目的已经达到，

众所周知敏捷实施中，每个task的时间是团队自己定的，才能保证团队有效的高质量完成，这是不是和客户要求的deadline冲突了呢，团队自己定的时间如果过多就会影响准时的交付，而如果不影响交付，必然会产生加班以至于质量问题。在实际中怎么去协调这个呢？

问题：团队里有不同专业的人员，例如开发iPhone和安卓的手机人员，他们一起召开每日会议的话意义有多大？因为iPhone项目的进度和安卓项目的进度看似关系不大，iPhone开发人员遇到的问题安卓开发人员也无法解决。

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

这是敏捷开发绩效管理的第十一篇。（栏目总目录）也是敏捷开发一千零一问的第三十四篇。（栏目总目录）人员可用率字面上，人员可用率指每个人的所有工作时间中，多少比例被用于真正的工作。广义的人员可用率，还应该包括“战斗人员”的比例，如果各种行政、管理团队数量庞大，那么总可用率也会因此 降低。本文重点谈前者。深层的人员可用率，还应该指扣除返工、浪费后的实际可用率。关于人员可用率的数据很少，大致有两个很有参考

这是敏捷开发一千零一问系列的第三十三篇。（在这里提问，之一，之二，之三，问题总目录）原问题来自http://blog.csdn.net/cheny_com/article/details/6594507#comments六楼，经读者同意，摘录如下：“一般而言，大致每天高手能编写100多行有效代码（按分号计数），新手会多一些但也不超过200（他们编写代码比较费）。” 从整年平均来说，这个数据是不是有

这是敏捷开发一千零一问系列的第三十三篇。（在这里提问，之一，之二，之三，问题总目录）（续前文）4. 不会满足于现状对野路子而言，一般不相信“有最好的方法”。其实敏捷也不相信。那么两者有什么区别呢？野路子相信：反正也没有最好的方法，为什么要费劲不断改进？我们这样的野路子也挺好的啊。敏捷开发相信：由于没有最好的方法，所以一定还有比现在更好的方法，要不断改进进行寻找。这里的野路子相信的事情，也是做敏捷开

这是敏捷开发一千零一问系列的第三十一篇。（在这里提问，之一，之二，之三，问题总目录）这是在QQ群中偶然有人提到的一个问题，估计很多人都想知道。特别是有一次培训到半小时左右的，也就是刚听了敏捷概论的时候，有一位客户感慨说：“嘿，我感觉我们做的就是敏捷开发啊”。这是很多人第一次听到敏捷开发时候的正常反应。不过当然两天的课程下来，就会变成“哎呀，以为敏捷主要是一个理念，没想到还有很多具体要做的团队、管理

这是敏捷开发一千零一问系列的第三十篇。（在这里提问，之一，之二，之三，问题总目录）续前文，预计未来还要有一篇，暂时做为中篇。方案方案一：用早期功能点估算法进行报价或早期制定项目计划这个在之前谈到过很多次了，具体可以参考敏捷开发绩效管理系列的之六、之七。另外在敏捷开发用户故事分类与组织结构（一期） （整个活动1期）中有详细描述。这个是国际上迄今为止唯一被大规模推广使用的方法，中国即将发布的国标就是基

这是敏捷开发一千零一问系列的第二十九篇。（在这里提问，之一，之二，之三，问题总目录）问题估算和度量几乎是敏捷开发及其他开发方法永恒的话题。不过，在进行估算之前，必须理解估算的价值，并觉得为估算所付出的工作量值得。请看下面这段对话，它发生在2003年为一家企业做CMMI咨询的时候，涉及到代码行估算（有改动和扩展）：甲：假设一段代码是1000行。不估算，写完了一数是1000行；估算，写完一数还是100

这是敏捷开发团队管理系列的第八篇（团队管理栏目目录）。还是敏捷开发一千零一问的第二十八篇（在这里提问，之一，之二，之三，问题总目录）。还是敏捷开发松结对编程系列的第十三篇（松结对编程栏目目录），与之前系列第六篇139团队、第九篇微软TechED上的讲座有密切关系。问题大致问题：若人数在30人左右开发一个产品，里边的子系统数量比较多，每个子系统都有各自的发布计划，而又要协调。如果作为一个团队管理，人

问题这是敏捷开发一千零一问系列的第二十七篇。（在这里提问，之一，之二，之三，问题总目录）来自提问帖 15楼 http://blog.csdn.net/cheny_com/article/details/7564388原问题摘录如下：开发组中可能同时进行几个专项开发，那么就有人参与这个专项，不参与另一个专项。那么扑克估算的时候，针对某一专项的任务，要怎样做，是否是开发组所有人员都参加评估，还是这个专

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

这是敏捷开发一千零一问系列的第二十五篇。（在这里提问，之一，之二，之三，问题总目录）问题：什么是敏捷开发的根本基础？What is the essence of Agile Software Development??来自LinkedIn热帖http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=15645

这是敏捷开发一千零一问系列的第二十四篇。（在这里提问，之一，之二，之三，问题总目录）也是敏捷开发团队管理系列的第六篇。（团队管理栏目目录）问题问：传统的团队如何转化为敏捷团队（步骤，要点，注意事项等）？问：如果使用敏捷开发，在公司组织架构上有没有什么建议？分析在谈到何为敏捷团队之前，先看看传统团队的问题，不要把团队转化完了，问题还存在；换言之，解决问题是目标，转化团队是手段。1. 各部门打架严重来

这是敏捷开发一千零一问系列的第二十三篇。（在这里提问，之一，之二，之三，问题总目录）续上文陈勇-咨询-北京(139107533) 13:27:03这个是我们的组织结构维护视图，本来是一个很简单的树控件，但就Domain而言，一个人只有看到长相如此的东西，才会理解它是一个组织结构图（尽管M就是树）但是，V里边的代码，不过如此：真正的代码，被放到M里边了。如果从这个案例分析，就会看到至少三个人都参与了

这是敏捷开发一千零一问系列的第二十二篇。（在这里提问，之一，之二，之三，问题总目录）问题这个问题，也来自QQ群的讨论，整理一下。问： 13:12:49 我问一个具体问题，我做移动OA 问题是  UI设计 怎么做到敏捷呢？  其实就是 设计稿变化 程序老跟着变  陈勇-咨询-北京 (139107533)2012-06-29 13:17:50恩，我们团队不大，我自己一个人做了产品经理、项目经理、主程序

这是敏捷开发一千零一问系列的第二十一篇。（在这里提问，之一，之二，之三，问题总目录）问题这个问题来自于QQ聊天记录。早期的对话大致是：问： 12:50:06 敏捷开发 提倡的是简单设计是吧？ 那么是不是就弱化了 设计文档了呢？ 陈勇-咨询-北京(139107533) 12:54:06 弱化设计是相对的，敏捷的目的只有一个：强化最后的可用产品。 对于本来设计有点过头的团队而言，需要弱化设计来省出时间

这是敏捷开发一千零一问系列的第二十篇。（在这里提问，之一，之二，之三，问题总目录）问题问题来自提问帖第14楼：http://blog.csdn.net/cheny_com/article/details/7564388问题原文：有迭代，有总结，也有人说话。但是下个版本，大家又忘记自己提的改进意见了。这个问题还有很多变形，比如怎样开好反思会什么的。初步分析反思会被认为是敏捷开发中最重要的两个会（另一

这是敏捷开发一千零一问系列的第十九篇。（在这里提问，之一，之二，之三，问题总目录）先说说一千零一问的来历。无论在培训、咨询中，还是在日常博客、邮件、QQ群中，都不断有人提出不同的敏捷开发问题，一一作答的时间消耗太大；如不作答，又知道这些不只是一个“感兴趣”的问题而已，而是关乎某个团队若干人月的工作，或一些人的职业生涯，或乃至企业的很多未来决策，虽然不怀疑大家迟早会找到答案，但以自己“曲折的经历”看

这是敏捷开发一千零一问系列的第十七篇。（在这里提问，之一，之二，之三，问题总目录）方案3：培养产品经理，想到客户前面被客户牵着鼻子走本来不是坏事，还少了做需求分析的工作，但关键是客户一会牵着向东，一会牵着向西，好像自己也没有主张的样子，这就令开发团队郁闷了。这时候，无论是不是产品化了，都应该培养一个人，看到客户前面去，看他自己是不是都迷路了。客户“迷路”大体有两种情况，一种是有路但自己不知道。曾经

这是敏捷开发一千零一问系列的第十七篇。（在这里提问，之一，之二，之三，问题总目录）这个是在一次面向电信行业供应商的公开课上提出的问题，被评为本场最佳问题。对于这类“供应商”而言，一方面业务根深蒂固，一般固化在某些专有领域因此很有必要产品化；另一方面又受制于客户总是来回改动，很难有自己的自主权。两者的矛盾，可以通过逐步推广敏捷开发而解开，也需要大量的周边技术、管理、市场手段来辅助。甚至应该反过来说，

这是敏捷开发一千零一问系列的第十六篇。（在这里提问，之一，之二，之三，问题总目录）这个和上一篇“敏捷开发与CMMI谁为主”都是最近一次培训被大家选出来的最有价值问题。问题开发人员一般都只关注开发，如何让他们去关注产品呢？方案方案1简单但不彻底，方案3彻底但不简单。方案1：产品经理在计划会讲解产品背景计划会是一个产品经理宣贯产品的好地方，但是我们山东籍的程序员就会问：“你啰啰这些没用的黄子做么”，西

这是敏捷开发一千零一问系列的第十五篇。（在这里提问，之一，之二，之三，问题总目录）也是敏捷与CMMI系列的第三篇。（总目录）问题原来问题是这么写的：“一家企业既要过CMMI，又要过ISO，还要实施敏捷，应该怎样做？”之所以改成“哪个好”，是因为如果要多头并存，就要有主次关系。那么，到底哪个好，应该以哪个为主呢？分析每次说到这个问题，都会有不同的角度可以分析。一个常见的角度是说：CMMI比较完整“大

这是敏捷开发一千零一问系列的第十四篇。（在这里提问，之一，之二，之三，问题总目录）正逢周末，又是愚人节，群中有人正在加班，想起上次培训中间休息的时候，讨论起这个“敏捷开发加班吗”的问题，虽然后来没有作为课后投票入选，但这里也完整回答一下。问题敏捷开发加班吗？楼下有人问到“敏捷和加班有什么关系”，补充这两句。有些程序员认为，敏捷开发从制度上要求不加班（可持续的步调），因此会说“老板，现在你不是推敏捷

这是敏捷开发一千零一问系列的第十三篇。（在这里提问，之一，之二，之三，问题总目录）问题这是课堂上提的一个问题，这是一家外企，PO在国外，研发在国内；PO希望大家用故事点估算，而团队习惯用人天估算，问用哪个好，或者两个都用好？分析先分析，后出方案。这个是一个典型的有关无我、无住的问题。所谓无我，就是先弄清楚为什么不同的人想要不同的东西，然后本着到底“谁应该要，应该优先满足谁”而非“我应该要，应该优先

这是敏捷开发一千零一问系列的第十二篇。（在这里提问，之一，之二，之三，问题总目录）问题原问题：敏捷的具体实施是否按照一定的步骤？方案越前面的方案月容易实施，但是也越容易流于肤浅而失败。方案1：循序渐进这个可以说是所有事物推广的方法，不只是敏捷，而作为“敏捷”而言，崇尚迭代交付，自然更符合循序渐进的思想。方案2：面向问题常常听到这样一个问题：我是过程改进人员，以前CMMI过级的时候很忙碌，也很充实，

这是敏捷开发一千零一问系列的第十一篇。（在这里提问，之一，之二，之三，问题总目录）问题原来问题是这么写的：“每个人对美的认识不一样，在产品开发过程中，该怎样有效控制界面设计用时？”大致是说有些人觉得这样就得了，另外一些人觉得还不够漂亮，不知道评审的时候该听谁的。这个问题有点另类，所以泛化成“需求谁做主”。方案方案1：听产品经理PO的这个是简化的方案。一般而言，我们总会挑选出正确的人，或至少是最正确

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

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

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

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

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

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

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

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

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

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