JJiaoAo的专栏

[size=medium]道德经说太极生两仪，两仪生四象，四象生八卦，八卦生六十四卦，六十四卦生万物。但是多数企业的敏捷开发都太“八卦”了，上不能掌握太极的根本，下不能根据企业具体情况衍生出万物。博客上的其他文章描述描述“万物”已经够多了，这篇文章只说说两仪。在前面的帖子里边，有几个人支持fast feedback/short iteration，另外一些人则支持transpare...

[size=medium][b]缘起[/b]“我们产品已经做完了，客户说要补上需求文档，可我们只有用户故事，这个文档应不应该写呢？”“没有这个文档，客户能验收吗？”“不能，客户要开课题评审会，这个是评审会材料之一。”这个文档要不要写呢？写，为什么？不写，为什么？写怎么写？不写，怎么不写？[b]为什么敏捷不写文档？[/b]先把话说绝点，敏捷就是不写文档。那...

[size=medium][b]缘起[/b]（立项时）甲：“你们的设计文档打算怎么写？”乙：“到时候再说。”甲：“应该有规范的开发流程和模板，才能写好设计文档。”乙：“预先定义的流程和模板未必适用，敏捷开发崇尚推迟决策，只有在具体工作之前才能决定是否写，怎么写最好（maximizing the amount of work not done）。”甲：...

[size=medium][b]问题[/b]原来问题是这么写的：“一家企业既要过CMMI，又要过ISO，还要实施敏捷，应该怎样做？”之所以改成“哪个好”，是因为如果要多头并存，就要有主次关系。那么，到底哪个好，应该以哪个为主呢？[b]分析[/b]每次说到这个问题，都会有不同的角度可以分析。一个常见的角度是说：CMMI比较完整“大气”，可以做整个公司的管理...

[size=medium][b]问题[/b]敏捷开发加班吗？楼下有人问到“敏捷和加班有什么关系”，补充这两句。有些程序员认为，敏捷开发从制度上要求不加班（可持续的步调），因此会说“老板，现在你不是推敏捷开发吗，那我们就不能加班了，因为敏捷开发不能加班。”结果肯定是：“敏捷要敏捷，加班也要继续加班。”“存在的就是合理的”，既然加班，至少还是有目的或好处的，要想把加班废...

[size=medium][b]大型团队的切分[/b]如果团队大到一定程度，比如40人，那么怎样切分团队最好呢？答案是[color=blue]纵向切分[/color]，就是按产品而非按职能切分，也就是事业部化，而非开发-测试-支持这样划分。原因大致如此：1. 纵向切分的团队之间不会有直接竞争、对抗关系，避免了各种对抗和办公室斗争。2. 纵向切分的团队内部目标清晰，都...

[size=medium][b]正法，像法，末法[/b]任何事物，都会经过这三个阶段，有的短至几年，有的长达几千年。[b]正法时代一般是原创者掌握话语权的时期，因此能正确地解释和传播。正法时代传播的是智慧和般若，而不是知识（方法，具体的实践等）。[/b]本人先是学习了敏捷开发的方法，之后一年多才有幸读到Ken Schwaber的图书，其中一本大量介绍了以往他推广敏捷...

[size=medium]经常听到有人提到敏捷开发与“本能反应”非常近似，比如凡事都需“看着办”，比如“不拘泥于形式”，比如“直击代码，不写无用的文档”等等。那么敏捷开发与本能反应之间的差别是什么呢？简单地说，[b]敏捷开发就是[/b][color=blue]无我状态的本能反应。[/color][b]无我，无人（无我，无人，无众生）[/b]按理说，本能反应是最接近最...

[size=medium]所谓无住，包括两个含义：不住于法，不住于空。前者比较好理解，后者会在下篇详述。不住于法，就是不执着于具体方法的意思，就是所使用的方法应该基于实际情况作出判断，而不是认为世界上有最好的方法，必须遵守。[b]法执对法的执着，称为法执。[/b]典型的法执，是很多企业使用CMMI的方法。本人曾经做过10多家企业的CMMI培训、咨询，所需工作...

[size=medium]破除法执之后，很容易落入空执，就是认为不存在绝对最好的方法，因此无需追寻，甘于现状。平衡空与有非常困难，这是本篇的内容。[b]法与空[/b]法与空的对立统一由来已久。吴伯凡老师举了个例子：“一切事物都是相对的”这句话有什么问题？这句话看似相当辩证，无懈可击，但它本身就“非常绝对”，有一种内在的矛盾。[b]软件界的法与空[/b]是...

[size=medium][b][color=blue]人员与结构[/color][/b][b]在团队中使用层级结构，是否阻碍了个体与外界的沟通？[/b]极少有底层程序员或新手能和产品经理做深入的沟通的，所以中间放上师傅这一层，让其代为问问题，徒弟旁听，不但不会阻碍，反而会促进。这样徒弟可以更快地学会问答技巧或熟悉业务，真正学成了，师傅才懒得在中间“阻碍”呢，呵呵。...

[size=medium]松结对和紧结对不一样，两个人不是总坐在一起随时发现问题解决问题，而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个：一是看结果是否符合需求（做什么），而是看代码是否存在问题（怎么做），后者就是代码检查。代码检查（也称代码审查Code Inspection）是一种由来已久但是很神秘的东西，最初引入是在一些生命攸关、重大财产相关的软件开发中，典型的就是SSOS...

[size=large][b]敏捷软件宣言[/b][/size][size=medium]我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：[/size][size=large]个体和互动[/size] 高于 流程和工具[size=large]工作的软件[/size] 高于 详尽的文档[size=large]客户合作[/...

[size=medium]松结对编程是小型团队的实践，大约运行在1个师傅+1～3个徒弟的尺度上，当面临更大尺度的时候，就需要大型团队模型。这里推荐139团队模型，因为它不但可以让松结对编程运转顺利，还解决了大团队沟通、绩效考核、师傅的出路等问题。139团队的整体情况相当复杂，将另有系列博文描述，这里只描述与“松结对编程”相关的内容，以保证本系列博文的完整性。[b]基本概念[/b...

[size=medium]做敏捷开发时间长了，就感觉很多事情都理所当然，越发觉得“问题很可贵”，最近做培训的时候收集了一些问题，很多现场来不及解答，逐一发表在这里。如何解决一个问题知识多了自然可以解决问题，经历多了自然也可以积累经验，但是在一个只出现10年的领域，还有一堆只工作了10多年的年轻人中间，必然有一天会遇到从来没有人解决过的问题，这时候怎么办呢？[b]掌握解决问题...

[size=medium][b]无住[/b]在般若敏捷系列中已经提过，包括不住于法，不住于空。[b]不住于法[/b]就是[b]不停留在一种固定的方法上。[/b]如果把“敏捷”理解成一个名词，就会出现一个问题：什么是敏捷？又会扩展成Scrum是敏捷，还是XP是敏捷？RUP是不是敏捷？等等问题。如果把“敏捷”理解成一个形容词，也就是“敏捷的开发方法”，大致能找到敏捷...

[size=medium][b]共振[/b]共振是以无我、无住精神推广敏捷时的具体做法。很容易被简单理解为循序渐进，但这样理解不全面，这也是为什么会出现“共振”这个奇怪的词汇。之前的无我、无住，也都很难找到完整替代的又没有歧义的词汇或语句。[b]循序渐进[/b]很多人都梦想有一家企业，高层领导支持，企业文化适合，队员个人能力超强，团队合作顺畅，就只差自己这个项目经理去推...

[size=medium]传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况。二是来自基层的，两人若有高低，高手肯定觉得还不如我一个人干的快；两...

[size=medium]新人其实很少偷懒，因为一方面正处于入门学习的高峰期，另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢？新人的真正问题在于无心办错事和好心办错事。无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。好心办错事包括想做一个比领导想想的更好的功能、过度思考了可复用性可维护性等。这两个...

[size=medium]估算是经久不衰的管理话题，大致分为两种流派。第一种是领导指派，领导说这是10天的活，就必须当是10天的活来干，如果干不完，可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算，但是交给领导审批；领导审批其实就是砍一半的过程，还好大家之前就已经加了一倍，所以不怕。第二种是自我管理派（偏敏捷），就是由具体开发的人员自己说开发工作量，领导和...

[size=medium]团队中常见的一种情况计划、估算、设计的时候大家还在一起，但编程的时候就会分开。分开看似是安全的，但是却充满隐患。2001年，一位招聘考试前三名（一共120员工）的程序员的两个月的成果被彻底放弃重写，原因是里边包含3000多个常数，而且很难修改（码流参数），重写的人座位距离他只有4米，重写也只花费了2周；2002年，一位月薪7000（那时候北京房价才3000多）的程...

[size=medium]Beck全家似乎都弥漫着技术的味道。生长在硅谷, 有着一个对无线电痴迷的祖父，以及一个电器工程师父亲。从小就引导Kent Beck成为了业余无线电爱好者。在俄勒冈州大学读本科期间，Kent Beck就开始研究起模式。然而在他最终拿到计算机学位之前，他却是在计算机和音乐中交替学习。似乎Java大师都能够有这样的能耐，另一Java大牛Rod Johnson同样也拥有音乐学...