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

历时2周才完成的敏捷游戏研发过程海报。整体思路是在游戏研发过程中应用Scrum敏捷方法进行管理，在其他大团队/长周期项目，或普通团队实施Scrum时也可以借鉴。最上面的标题对应Scrum的各个活动，左边则以概念-活动-实践-文化-目标来诠释各个活动的精华内容。如果想从头读到尾，请按各个文字框中间的连接箭头逐个阅读。中下部的大图和Scrum常见的图差不多，但由于游戏团队往往是大型团队，必

Scrum敏捷开发方法是一种关于“可能性的艺术”，在实际实施过程中，常常因为种种环境约束而造成某些实践不可能完全实施（比如小型开发团队/开放办公环境/每日立会/跨职能团队/开放的反思会等等），并因此造成了一系列的衍生问题。本文以大团队的计划过程为例，揭示了Scrum中隐含的生态系统，以及各种“生物”之间的依存关系。这样具体实施时，Scrum Master在挑选变通做法的时候，应充分考虑到原

诺基亚标准是诺基亚内部的一个简单测试问题列表，用于判断一个团队是否真的在使用Scrum。问题如下：PART 1: ARE YOU DOING ITERATIVE DEVELOPMENT? 你们是否在使用迭代测试（做Scrum的一个基础）1.1 Iterations must be timeboxed to less than 4 weeks * 迭代周期必须是限制长度的且少于4周？

欢迎报名：QCon北京2010解析多个知名网站背后的技术架构http://www.infoq.com/cn/news/2010/03/qconbeijing2010-case-studies距离 QCon北京还有45天，会前培训悉数上线http://www.infoq.com/cn/news/2010/03/qconbeijing2010-trainingFacebook 架构师Q

前几天写培训PPT，突然发现不知道把敏捷宣言放在那里好。因为看上去，敏捷宣言中既有体现价值观的内容，也有直接的操作层面上的内容。大家请看（前后删除了一些）： 个体与互动 胜于 过程与工具可工作软件 胜于 复杂文档用户协作 胜于 合同谈判响应变化 胜于 遵循计划 如果感觉看不太明显，那么我们来两个对照版本，就会感觉更加清晰。 “价值观”版本的敏捷宣言 

 无烟会议室：CMMI vs. Scrum vs. XP（QCon 2010 感受） 作者：陈勇原文：http://blog.youkuaiyun.com/cheny_com 公司开发部门要建无烟会议室，三种人做法如下： CMMI 公司级订立无烟会议室制度，宣贯，张贴海报。经过大家提醒执行，行政部小王不定期抽查，秩序井然。 直到老板李总带着客户张总来到会议室，而

最近几天没写博客，一方面因为有几次培训和会议占用了时间，另一方面在编写一个免费敏捷教材及宣传材料。最后有几张已经完成的草图。 编写到初衷有两个：1. 希望每次培训课前，大家已经对基本概念有所了解，而不是从头听，这样有限的时间就可以用来解决真正的“敏捷如何应用”的问题而不是“敏捷是

这是敏捷开发与中医理论系列的第二篇。（之一，之二）由来中国古代的很多技术或艺术，都是没有学校教授的，譬如中医，戏曲，民间艺术，食品，酿酒……但却不乏流传千古的名家和作品，唯一问题就是流传缓慢，传内不传外，传男不传女……。现在终于有了大学，流传速度应该加快了，但是呢？上次路过中国X

这是敏捷开发与中医理论系列的第一篇。。（之一，之二）最近一个世交的中医朋友到梁冬的正安药坊上班，也去实地参观了一下。因为之前的一些经历和最近的几天的交流，一点点悟到一些中医理论与软件研发管理的共同之处，写在这里成一系列。这里的很多内容来自于与这位朋友沟通所得，并与之前更早听《冬吴

《程序员杂志》的文章，原帖位于http://www.programmer.com.cn/7760/ 写的很好，自己转贴存储一下，也符合Product Owner的要求，就是……要求太高了！ 本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享，谈到了招聘产品经理的标准，

虽然最早来源无从考察，但将最佳实践（Best Practices）一词发扬光大的无疑是CMM/CMMI。以本人接触的先后顺序，CMM是在2001年同方听到的，而极限编程（那时候基本上还没有Scrum）也是同时听到的，所以算是同一时期的东西。但是为何10年来，“最佳实践”在CMMI

本文件做通知，下载链接/版本记录/讨论请前往主贴：http://blog.youkuaiyun.com/cheny_com/article/details/6616794  更新时间：2011-09-12 16:18更新内容：新增两页“敏捷绩效管理”。另有一些页面已经做好，但更接近“松结对编

最近有一篇“为什么Scrum不行”的文章很热，本来路过打酱油的时候看到过，但是后来在另外一个网站的敏捷诊室里边被要求评价一下，所以顺便转发到这里。为了不让大家再去找原文，原文发在这里（好像是由一篇外文翻译的？没找到原始出处）：因为本人经常站在Agile的风口浪尖，所以我有必要也来

软件“可运行”了就可以评审且通过了？这是个问题。在多年前参加Scrum Master培训的时候，老师拿出一个很好的表格，每行是一个故事，每列大致如此：编码完成功能测试单元测试集成测试压力测试自动测试……这样在计划会的时候，PO就告知大家每个故事他的要求是什么，一方面大家会因此对于

最近被两次问到同一个问题：如果一个软件需要大量密集的设计工作，导致存在独立的设计和开发团队，应如何实施敏捷开发？整体上讲，敏捷开发不希望存在设计和开发的分离，因为这样就会产生“设计文档”这种东西，而且因为两个团队分离，设计文档一定相当详尽，而且在交接的时候多半要进行评审，否则很难

在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通

敏捷开发中的用户故事采用的语法模式看似简单，却蕴含着深刻的思想。“作为一个……，可以……，以（以便）……”不同于一般专注于功能的需求条目描述方法，三个……把角色、功能、价值跃然纸上。然而使用不当，却有可能形似而神不似。下面就三个部分分别举出一个例子。 网络游戏的排行榜功能：“作为

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在产品版本规划的高度来看这个问

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 很多人都知道甚至感觉到敏捷开发的生产率比传统开发高，但到底敏捷开发是怎样提升生产率的呢？以及当前自己正在实施的敏捷开发还有多大的生产率潜力？当然“受激励的个体”会产生生产率，但只是这样解释恐怕难以服众，更难说服老板。

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 定义简单看，139团队就是1个项目经理，3个小组长，9个开发人员，小组长管理各自管理3个左右开发人员。139团队从管理上缩减了团队规模，可以被视同只有1个项目经理和3个小组长，细节交由小组长处理。这样就方便在大型团队

作者：陈勇       出处：blog.youkuaiyun.com/cheny_com       自相似性是指一个事物的局部与其更大的局部乃至整体具有相似性。从大的方面看，敏捷开发具有重视客户价值，提倡持续交付等思想。但一般而言，Product Owner常常具备相当好的客户价值意识，而

2001年的时候，我们注意到程序员个体差异很大，尤其是质量差异很大，即使他们天天坐在一起。原因在与大家几乎各自分工干各自的活动，中间缺少交流（不是交流学习会那种，而是每时每刻发自内心的交流）。而对于一个软件而言，质量最好的部分并不能导致整个软件质量好，但质量差的部分却可以导致整个

作者：陈勇       出处：blog.youkuaiyun.com/cheny_com       用户故事的颗粒度一直是一个谈论已久的话题，但参加了很多研讨会，搜索了很多网络资源后发现一直没有定论，只好在这里原创一下。 前言：为何需要讨论用户故事的颗粒度 其实需求颗粒度的问题由来已久，即

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能

本文长期更新，请常来看看。 •    序言–  从代码行到故事点敏捷估算：故事点与直接估算天数的差异 –  下一步？•    敏捷团队绩效管理–  谁来管理团队中的个体？同行压力（兼谈敏捷团队，绩效管理，自组织团队）目标管理（百度百科）–  敏捷团队的目标–  从团队外部认识团队

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在研发心理学的高度来看这个问题

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 笔者遇到过的很多企业做敏捷时都遇到这个问题，因为Scrum Master属于西方文化的产物，在国内很难找到一个人非常适合地来做这个职位，而且也很难给出一个统一的答案。不过这些企业倒是都有自己的解决办法，这些方法及优劣

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 主程序员团队是曾经风靡一时的小型研发团队组织架构形式，很多团队都曾经有意无意地使用过。其模式是：由一个最好的程序员编写所有最终代码，其他人只进行测试及辅助工作。乍看起来与Scrum的“跨职能团队”差别很大，但由于其提

刚开始的时候非常认同asp.net中MVC的Action的布局方法：无论大小，只要是一个动词，都给一个单独的页面，比如Create/Edit/Detail/Index。编写了一段时间后，又发现这样很不方便，尤其是像“创建角色”这样的页面，就一个TextBox,其他什么都没了，单独

各种思路和顺序都试过。最开始时先编写Model，毕竟Model是所有一切的基础，再说没有Model，Controller里边用到该怎么办。后来改成先编写View，View才是用户能看到的东西啊，不知道用户看什么，怎么知道应该提供什么Model。现在先编写Controller。在讨

作者：陈勇出处：blog.youkuaiyun.com/cheny_com     有没有遇到某个重要的条目每次都被漏下完不成的情况？    有没有遇到冲刺结束的时候发现一大堆条目都已经开工了但都没有完成的情况？    有没有遇到Product Owner想用一个重要的变更来替代原来Spri

作者：陈勇       出处：blog.youkuaiyun.com/cheny_com       自相似性是指一个事物的局部与其更大的局部乃至整体具有相似性。从大的方面看，敏捷开发具有重视客户价值，提倡持续交付等思想。但一般而言，Product Owner常常具备相当好的客户价值意识，而

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 所谓生产线，就是大家各司其责，在一个线性的过程中配合工作。生产线尝试借助专业分工来提升效率，但也导致了问题：在传统生产线中，下游获得的中间产品是不太需要理解就可以在其上继续工作的，比如装配了一半的汽车，加工了一半的食

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 在敏捷中直接估算天数最大的好处是直观，坏处是很难衡量是否有故意的高估和低估，也不能比较生产力是否在提升，于是基于故事点的估算应运而生。基本使用方式故事点的基本做法是：把一些常见的“标准任务”给出一个“标准点数”，形成

作者：陈勇原文：http://blog.youkuaiyun.com/cheny_com  概念同行压力是一种团队队员进行自我组织自我管理的管理方法。 传统管理中，压力一般来自于两种途径：领导压力，目标压力。   领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时

2011-08-18    新增Scrum概述1页，敏捷生态系统5页，中英文对照表1页。新增部分页面预览：本文仅做通知，请到主贴查看更新历史及下载链接：http://blog.youkuaiyun.com/cheny_com/article/details/6616794

•    谁在管理团队中的个体？•    从领导指令到自组织团队-敏捷生态系统 –  自组织团队的潜在问题 –  敏捷Scrum是怎样解决这些问题的？ –  敏捷生态系统         同行压力（兼谈敏捷团队，绩效管理，自组织团队）        敏捷生态系统：2009敏捷中国大会上的演讲稿–  大团队/强分工下易受影响的生物 •    习惯性分工与事实性分工 •    大型团队：139团队模型

2011-10-14：新版本已经发布，新增内容6页，增加目录及《敏捷开发用户故事》系列。此版本就是原定10.31才发布的版本，因下半月要参与一本杂志、一本书的编写，所以提前写好免得惦记。本文仅作通知，下载请访问主贴：http://blog.youkuaiyun.com/cheny_com/a

作者：陈勇出处：blog.youkuaiyun.com/cheny_com 这是CMMI与敏捷开发比较系列的第一篇（之一，之二，之三）。   本来不需要比较的两样东西，因为总是被安排到企业的一个部门（EPG）去管理，所以已经被比较了N多次，纷争已久。2011过程改进年会的锵锵N人行（其实就是原来的PK会）上几位嘉宾被问及问一个本来可以解决这种纷争的问题：CMMI的管理目标是？敏捷的管理目标是？嘉宾答：CMMI

这是敏捷生态系统系列的第二篇（之一，之二，之三，之四，之五）。如果说需求管理中尚有一些团队无法控制的因素导致实施困难，计划与跟踪过程总归就没有问题了吧？其实不然，笔者见过领导很放权的全团（很多是因为领导根本管不过来了），但在团队内部仍然存在很大的问题，一般最为突出的，就是每日立会开得毫无生机。这不完全是因为文化差异问题，而是生态系统出了问题。  敏捷开发中的计划跟踪生态大致如此（黑体字即图片中的元