博客园_大卫张33

债思维——软件研发新视角

2012-05-27T04:26:00Z

在软件研发中，我们做过的事、写过的代码、留下的文档，都不是资产，而是债务。——债思维

生产思维统治着软件研发的世界

债思维是一种颠覆，与大多数人对软件研发的看法相反。生产思维已经统治软件研发的世界很长时间了。一直以来，软件研发都是生产代码、文档，以构建可工作的软件的过程，毋庸置疑，这就是生产。

嗯，宣言体挺棒的，就来段软件生产宣言吧。

软件生产宣言

软件研发是生产代码、文档以不断构建可工作软件的过程。为此：

生产正确的文档软件 高于客户价值（目标债）

流程规范合同分工 高于沟通协作（过程债）

按产出评价 高于维护重构（结果债）

人是机器，聪明人 高于群体创造（人员债）

可预测、可重复的生产是成功的关键。右边那些虽然也有价值，但是重点是完成左边的部分。

衡量是基础，产出是目标，分工是核心，这就是典型的生产思维。在这种思维的指导下：1）产出来自于生产，所以生产更多的东西就能够得到更高的收益；2）不可衡量的就不可管理，要遵循SMART原则；3）目标可以分解，在分解后衡量并管理，分解后的目标也要符合SMART原则；4）目标是基于分工分解的，基于分工的目标分解是把自己的事情做好，优化自己的生产效率将提升整体的生产效率；5）协作是简单的，是建立在分工基础上的，在分工后确定协作界面，按此步骤操作即可；6）在分工步骤可衡量的基础上，追求可预测、可重复；7）人是拥有某些技能的机器，我们的目标是建立一个培养体系，让这些机器具备所需的技能。

生产思维已经落伍，并且不适合软件研发

时代变了，社会形态从生产驱动转向消费驱动，消费者的选择成为决定收益的关键，生产不再是决定收益的关键因素。生产更多的东西，然后卖出去，是很多企业遵循的规则。苹果首席设计师Ive曾这样说过，“我们大多数的竞争对手执意要做出些不同的东西，或至少看上去新鲜——我觉得这些都是错误的目标。一款产品必须要精益求精，做到真正意义上的更加出色。”苹果的每一款产品都是如此成功，甚至很多人认为它们颠覆了它们所在的产业。在同一行业中，三星和HTC不同的命运也说明了这一点，三星依靠Galaxy系列成为智能机方面苹果最大的竞争对手，而HTC天天发新机却带来衰败。在互联网行业，近期Facebook以10亿美元收购了仅有13名员工的Instagram，更说明了同样的问题。

时代变了，在现代经济中，分工不再是核心，个体创造走向群体创造是一个趋势，知识、信息的缺失和人与人的协作障碍是两大关键点。韦尔奇的成功是二十世纪的奇迹，他提倡无边界管理，“在传统的意义上，企业靠严格的边界制胜，未来的企业则要靠无边界赢得竞争。”稻盛和夫的阿米巴哲学，将公司组织分为一个个“阿米巴”小集体，而各个小集体以“单位时间核算”这种独特的经营指标为基础，彻底追求附加价值的最大化，这为带来了京瓷的持续成功。海尔在张瑞敏的领导下，倒三角引出的灵活的人单合一的自主经营体模式，让海尔这样一个庞大的集团充满活力，更快速响应市场的需求。与此类似的还有Facebook。

软件研发是独特的，其结果债导致生产思维不可用，遗留系统、昂贵的过程资产、无人问津的长篇累牍成为后续研发的重重阻碍。生产可以重复是因为产品不会影响后续的生产，然而软件研发却并非如此。生产第一个杯子和生产第100个杯子几乎没有什么不同，而研发第一个功能和研发第100个功能存在巨大的不同。在软件研发中，每个人都试图将自己的想法加入到软件中，在Infoq上最近有不少关于架构腐化的文章明确指出架构腐化不是设计问题，而是时间问题，这些时间问题带来了结果债。

最后，也最重要的当然就是人。关于客户价值，存在太多未知。关于减少知识、信息的缺失，并有效协作，存在太多未知。关于软件研发的独特性——结果债，存在太多未知。这一切都需要人的改变，但被生产思维教育、招聘、培养和绩效考核的人们如何来适应和推动这种转变，这是个大问题。

上述描述了债思维提出的软件研发四大债：目标债、过程债、结果债和人员债，传统的生产思维不能解决这四个问题。

债思维——软件研发新视角

生产思维已经落伍，但它仍然统治着软件研发的世界，这就是我们需要面对的现实。改变或被改变，这是个问题。

嗯，宣言体挺棒的，再来段债思维宣言吧。

债思维宣言

在软件研发中，我们做过的事、写过的代码、留下的文档，都不是资产，而是债务。为此：

客户价值 高于软件生产（目标债）

沟通协作 高于精确分工（过程债）

降低债务 高于鼓励产出（结果债）

群体还债 高于完成工作（人员债）

尽管右边部分也有价值，但是离开左边的部分，债务的堆积将让我们自尝恶果。

相关链接，摸索的足迹

从2月份提出管理债到现在，探索充满乐趣。重新学习了债、管理、软件工程、经济等基础概念，思想也从管理债到债管理，再发展到债思维。能够把自己固定在一个话题上持续的深挖，收获总是超出自己的预期。一些博文记录了摸索的足迹。

《得懂点财务 - 从房奴养成四部曲到管理债》http://www.ituring.com.cn/article/1192

《管理是资产？不，管理是负债》http://www.ituring.com.cn/article/1204

《管理是这样从资产变成负债的》http://www.ituring.com.cn/article/1258

《软件研发之管理债》http://www.ituring.com.cn/article/1774

本文链接

软件研发之管理债

2012-05-10T04:36:00Z

这是即将在Scrum Gathering上海2012大会http://scrumgathering.cn上演讲话题《软件研发中的管理债与债管理》的第一部分。如果你是一位软件研发人员，想了解软件研发为何如此困难，怎样才算做好软件；如果你是一位管理者，想知道哪些管理措施可以奏效，为什么一些管理措施效果不佳；如果你是一名敏捷精益实践者，想深入了解敏捷精益背后的思维模式。你可以来看看，以债出发的视角也许会给你带来惊喜。

在软件研发组织中“管理债”不断堆积，这是因为采用了与软件研发的特点不匹配的管理模式。

软件研发管理债是什么？

“技术债”是一个隐喻，这几年已经被大家熟悉并接受。如果向一个软件系统增加功能时需要额外的工作量或难度，那么这个软件系统存在技术债，这些额外的部分就是为技术债支付的利息。

受到“技术债”的启发，在此提出软件研发“管理债”的概念。当一个软件研发组织达成软件研发目标时需要额外的工作量或难度，我们就认为该软件研发组织存在管理债，这些额外的部分就是为“管理债”支付的利息。

软件研发“管理债”普遍存在于软件研发组织中。随着时间的流逝，债务从开始的小瑕疵变成庞然大物，越来越成为生命不能承担之重。其在软件研发管理上的主要表现为：1）成本越来越难以控制，超出预算；2）达成目标的时间越来越长，超出时间；3）开发出的软件不能达到市场期望，不符合需求；4）质量低下；5）软件越发庞大，难以维护。

谁应该为“管理债”负责？当从软件研发管理的角度去看时，似乎管理应该为此负责。（画外音：命名为管理债，肯定是管理负责啦，这种提法有诱导性，说服力不足。）

“管理债”与40多年前的软件危机非常类似。软件危机的主要表现是：1）软件常常超出预算；2）软件研发超出时间；3）软件不符合需求；4）软件质量低下；5）难以维护。为了应对软件危机，对应的解决方案是软件工程。软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。然而40多年过去了，仍然没有一种得到证明的软件工程方法能够解决软件危机的问题，它仍然以“管理债”的形式大量存在。

是何种假设导致问题在持续？

如果方向是正确的，那么顺着方向走，找到答案只是时间问题。然而，方向不正确的时候再多的努力也不能真正解决问题，就如牛顿力学与相对论，欧几里得几何与非欧几何。

我们认为的正确往往都建立在假设上，如果假设不成立，那么结论亦不成立。那软件工程、软件研发管理对应的假设是什么？

先来审视管理与软件工程的定义。管理是管理者和他人及透过他人有效率且有效能地完成活动的程序。管理就是计划、组织、领导、协调和控制。软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。再观察大多数软件研发组织的做法，常见的包括：以产出为导向、明确的分工、规范的过程、精确到人的绩效管理、计划管理和不断积累的最佳实践过程资产。

可以观察到一个核心假设，那就是：假设存在一种正确的管理方式，这种管理方式能够规范的、定量的解决软件研发中的问题，我们的工作就是积累经验，找到该管理方式，不断修正我们的行为直至完美遵循为止。这个假设是否真的成立？

在软件研发中该假设不成立

假设存在正确的管理方式，假设可以通过系统性的、规范化的、可定量的过程化方法进行软件研发，这是软件工程得以存在的基础。然而，这一假设在软件研发中并不成立。

定量、规范、系统性、过程、管理，这一切是典型的现代管理思路。而现代管理是建立在物质经济的基础上的。物质具备三大特点，首先是可衡量性，产出和中间产物都是物质的，可衡量的；其次是不变性，除加工步骤外，中间产物在传递过程中保持不变；最后是不相关性，产出与原材料不相关，第100个产出和第一个产出间不相关。因为产出可测量，并且不同产出间的生产过程相关性小，可重复性高，从而提升产出效率成为现代管理的核心追求；传递无损耗有利于进行步骤分解，步骤分解后可对步骤进行单独的测量和效率优化，使得精细化分工成为可能，这有带来了整体产出效率的提升。简单总结一下，现代管理的核心思想就是“衡量是基础，产出是追求，分工是核心”。一个典型的例子就是：澳大利亚生产铁矿石，在中国粗炼，到日本精炼，在德国加工成零部件，在美国生产成精密仪器，卖到中国。

现代管理对知识经济的代表-软件研发并不适用，知识的特点与物质截然不同。首先是产出的不可衡量性，知识没有体积、重量和其他任何可见的测量方式，知识与知识间无法直接比较，知识的价值取决于使用这些知识的人而不是生产这些知识的人；其次是高损耗，知识存在与大脑之中，必须转换为信息后才能进行传递，而接收者需要从外界获取信息并将之转换为自己的知识，这一过程存在巨大损耗；最后是强相关性，开发第100个功能和前面的99个功能存在巨大关联，这大大有别于物质生产。这三大特点打破了现代管理的基础，因为这三大特点，产出不可衡量导致分步骤优化的作用受到质疑，如果强行优化仅能带来局部优化，全局作用不一定明显；巨大的传递损耗使得步骤分解变得不合理，使用者决定价值的特点使得步骤间无法隔离，步骤划分难以执行，并且无法衡量步骤划分的价值，这使得建立在步骤划分上的分工不再可行；产出间的强相关性导致做的越多，负担越重，以后做的越慢，所以用做的更多来进行产出衡量意义不大。“衡量是基础，产出是追求，分工是核心”这些现代管理的核心思想被打破，以现代管理思想驱动的软件研发管理迟早陷入困境。

软件研发管理债来源于不匹配的管理模式

将基于物质经济的现代管理应用于知识经济的代表-软件研发是软件研发组织的常见做法，这必将带来软件研发管理债的不断增长。软件研发管理需要不一样的管理模式，这种管理模式应该是什么呢？可否从管理思想和软件研发方法的发展上获得一些启示？后续大家来共同探讨吧。

相关链接，摸索的足迹

从2月份提出管理债到现在，跌跌撞撞摸索之中。重新学习和摸索债、管理、软件工程、经济等基础概念，这种不断学习的感觉实在是太好了，一些博文记录了前期的收获。

《得懂点财务 - 从房奴养成四部曲到管理债》http://www.ituring.com.cn/article/1192

《管理是资产？不，管理是负债》http://www.ituring.com.cn/article/1204

《管理是这样从资产变成负债的》http://www.ituring.com.cn/article/1258

本文链接

管理是资产？不，管理是负债

2012-03-14T10:26:00Z

模仿XX体，纯属娱乐，如有雷同，必属巧合。

1. 管理是绝对正确的

2. 所以管理者是正确的

3. 如果结果有问题，首先是执行问题

4. 如果还有问题，是管理者未能理解管理

5. 如果还有问题，请参考第一条

在知识经济时代，管理已经不再是资产，而是负债。

“管理债”提法的由来

2012年2月18日，敏捷之旅2011的最后一站来到了南京，敏捷之旅2011全国14个城市的组织者们走到了一起进行回顾并参加南京敏捷之旅。在2月19日的南京敏捷之旅上，@大熊Stanly的敏捷DNA游戏让一部分对企业转型有兴趣的参会者集体进行了探讨，期间我突然脱口而出的“管理债”一词得到了大家的认同。午餐时还被大家戏称为“管理债”第一人。

知识经济与知识经济时代

为避免误用，本系列的内容将限定于知识经济。目前能够找到的最清楚详尽的解释请看这里：知识经济知识经济时代。

此处所谓的知识经济是指“以知识为基础的经济”，这是相对于现行的“以物质为基础的经济”而言的。现行的工业经济和农业经济，虽然也离不开知识，但总的说来，经济的增长取决于能源、原材料和劳动力，即以物质为基础。

知识经济的关键是知识生产率，即创新能力。只有信息共享，并与人的认知能力——智能相结合，才能高效率地产生新的知识。所以，知识经济的概念，更突出人的大脑，人的智能。反过来，人的智能，只有在信息共享的条件下，才能有效地产生新的知识。所以，信息革命——数字化、网络化、信息化——为信息共享，高效率地产生新的知识，打下了坚实的技术基础。在知识经济时代，一切生产都以知识为基础，所有财富的核心是知识。知识一般是通过信息表现出来。知识经济生产的特点是不断创新，从事生产的劳动者必须是掌握了大量知识的人，也就是知识工作者。

软件行业是知识经济时代的典型行业之一，软件也日益成为各行各业的基础设施。限于个人的经验，虽然主题是知识经济，后续讨论主要以软件行业为蓝本。

管理是资产？不，管理是负债

当持有一项物品时，这物品会自动让现金流向你的口袋，这项物品就是资产。而让现金从你的口袋流出的物品，就是负债。

我们一直以为管理是资产，这是常识。因为管理就是管理者和他人及透过他人有效率且有效能地完成活动的程序，所以管理能够提升工作效率，能够带来收益，是资产。然而这种思想仅适合于工业时代，因为在工业时代，结果是可以精确定义的，工作效率的提升将直接带来产能的提升，在抵消了管理带来的成本后依然提高收益。这让一部分人可以脱离生产专注于生产效率优化，这部分人成为了管理者，并大大促进了工业时代的发展。

然而到了知识经济时代后，管理是负债。这是一个非主流观点。不过在忙于反驳之前，请先找出一种不是负债的管理。请找出一种是资产的过程制度，它满足如下几个条件，1）带来明显的产出提升；2）执行情况良好，具备持续性，执行成本较低；3）可推广，不受限于管理者本人的聪明才智。

在知识工作中目前尚没有发现能带来明显产出提升的管理措施。因为知识工作者的产出是大脑的一种创造，不仅无法准确的衡量过程，甚至连结果也无法准确衡量。产出完全取决于知识工作者本身，而管理上所谓的完成不过是在当前投入情况下可以接受的一个结果而已，所以要找出一项直接提升产出的过程制度几乎不可能，这与工业时代明显不同。所有可见的，被称之为有效的过程制度措施全部是还债用的保障型程序，用于保障产出不至于差到不可接受的程度，即使如此，保障措施的有效性依然值得怀疑。

说到执行情况良好，具备持续性，执行成本较低，由管理创造的，持续性强而且执行情况良好的过程制度措施不是没有，不过成本的确高昂。例如一种典型的管理产出就是部门墙，它具备强有力的持续性和极低的维护成本，将持续导致企业运行成本上升。然而，即使是众所周知的不好，部门墙却具有强大的生命力，因为这种生命力来自于管理自身。相比而言，其他相对有用的过程措施其持续性都很差，维持成本很高，在执行时需要企业投入不少的人力成本，并且为维持其存活更是需要不菲的管理成本，例如设计评审、Code review。

更有甚者，管理还带来了其他负债。对很多企业来说，管理就是用最优化的方法取得最好的结果的最佳工具，“最”优化思维带来“最”强烈的排他性。这种管理成为了消灭不同政见者，扼杀公司的生态系统，僵化公司组织文化的最好武器。

管理是负债？

不，这不是管理的错。管理是负债的提法一定会触动管理者们的神经。管理是达成目标的方法，所以管理不会，更不可能有错。管理是科学的、有道理的、对的，它当然也应该是有效的。有错的只可能是不合格的管理者们，他们没有制订出足够好的管理措施；更可能的是执行者们，是他们执行不力导致了管理措施的失败。所以执行力开始风行，网络名言“一流的战略加上三流的执行，远远比不上三流的战略加上一流的执行。”

事实胜于雄辩，而选择性失明胜于事实。管理者们的集体选择性失明更加可怕。管理有效论背后存在的本质假定就是“管理是资产”，既然是资产，它就一定会带来收益。管理者们精通ROI（投资收益率）分析，然而在他们的根本——管理上，却很少以ROI的方式进行思考。不以ROI方式评估管理本身是因为“管理债”本身是无形的，很难被衡量的，然而这将落入另一个陷阱“不可以被衡量的就不可以被管理”，这是另一个选择性失明绝招。

企业经营者深受其痛，却无能为力。的确，目前没有有效的办法能够精确衡量“管理债”。不过这种情况也可能是因为资产管理的思想占据主流，从而让“管理债”从来没能真正进入视野所导致。即便如此，不能被测量也并不代表着不能被感知，企业经营者们可以明显感觉到，随着时间流逝，新的战略难以落地，企业开始缺乏创新和活力，新产品研发能力下降，质量降低，企业“管理债”在持续上升。面对这种现状，目前能够依靠依然只能是现有的管理系统，结果是企业经营者被自己创造的环境所束缚，无力改变现状。也许，是到了让企业转型，修生养性的时候了。

篇后语

如上所说，“管理债”是能够被感知，却很难被测量的。因此，后续一个很大的问题在于如何建立“管理债”模型，让“管理债”可视化，从而让负债管理真正能够帮到企业。欢迎各路同好加入探讨。

讨论

1. 你如何看待“管理是资产”的提法？能够举出现实中的例子说明吗？

2. 文中提到“不可以被衡量的就不能被管理”，对此观点，你的看法是什么？

本文链接

得懂点财务 - 从房奴养成四部曲到管理债

2012-03-12T13:50:00Z

最近本人疯狂的迷上了“管理债”话题，后续将以“管理债与债管理”为主题完成一个简单的系列。

既然涉及到债，财务知识当然要有，下文就算是简单财务知识普及吧，顺带推荐《穷爸爸，富爸爸》。

房奴养成四部曲 - 财务意识很重要

房子是资产。当我想到房子的时候，房子是一生中最重要的资产。因为房子是温暖的港湾，让漂泊的心有了归宿感，给我带来幸福。还因为没房子就没结婚证，就没老婆，这么现实的问题。

房子是投资。看啊看，诱人的房子实在太多，但实际行动起来才发现这世界是这么现实。没钱怎么办？一生的资产难道就这样离我远去。我不甘心，为了一生中最大的投资，豁出去了。死磨硬泡，花光积蓄，找到父母资助，找亲朋好友借贷，终于筹足了首付款。说到期待房子增值吧，作为只有第一套房的工薪阶层，卖了房你住哪去啊？遇到房价下跌，谁负责啊？

房子是负债。买到房后，东挪西借忙装修；工资收入还房贷；还要存钱还借款。每月穷的叮当响，下月还不知怎么开锅。

房子是负债。最后，我终于懂了，原来房子是负债。它让我的生活质量直线下降，归属感还没找到，幸福感先没有了。回家的感觉完全变了味道，回家后只看到家徒四壁，两个人吃着方便面相对无言。现在，我有了一个新名字，请叫我房奴。

这便是房奴养成四部曲。当我们从希望开始，以失望结束的时候才知道财务知识很重要。本来想获得资产，却不知不觉收获了负债，都是吃的没文化的亏。

资产负债表让我们了解了资产和负债，从财务上讲，资产会让现金流入我们的口袋，负债会让现金流出我们的口袋。对各位打工者来讲，唯一的收入就是每月工资，唯一的财务资产就是自己，所以各位知道健康是多么重要了吧。但资产负债表还不是最重要的，虽然为了资产我们可以放弃一切。

现金流量表才是对我们影响最大的。从财务上讲，没有能够比增加每月现金流入更重要的事情了，缺乏现金将带来直接的生活质量下降。比生活质量下降更加严重的是，如果连续几个月不能偿还房贷，我们就会因为现金流量不足而导致破产，房子被银行收回，前期的投资全部打水漂。

还有一张重要的报表是利润表。每年到了年底你盘点一下，去年剩下多少，今年的收入多少，支出多少，最后剩下多少。利润表可以让我们清楚的看出今年是白忙活了，还是有所收益。

管理与财务 - 管理是资产？

管理从诞生时就与财务密不可分，管理在企业经营过程中必不可少。资产负债表，现金流量表和利润表并称为企业经营状况的三大财务报表，能够方便的展示企业经营的结果。

管理是一项非常强调投资回报率（ROI）的活动，投资回报率也是管理者们最强大的管理工具之一。因为管理就是管理者和他人及透过他人有效率且有效能地完成活动的程序，所以在企业经营过程中，会依赖管理帮助企业选择更加优化和有效，也就是更有投资回报率的方案，从而让产出增值，最后提升企业的经营回报。看上去，为管理投入是完全值得的。

记得在很久以前，当时我还在创业。老大要求加强管理，要更加制度化和规范化。我当时问过一个很傻的问题，为什么要加强管理？当然，我被狠批了一顿，这还用问，没有管理怎么会有好的结果。言下之意就是，管理是资产，这有什么好质疑的。但这和我老婆买房时斩钉截铁的口气实在是太相似了。管理真的是资产吗？会不会绕着绕着又变成负债，而我们也幸运的荣升为管理奴？

篇后语

我们通常会用资产的眼光看待房产，却忘记了对于我们而言，房产往往是负债。良好的负债管理能力能够让我们有效管理房产这项资产，否则，很容易就变成了房奴。管理是否也是如此呢？用负债的眼光看待管理，能带来什么新的收获呢？

讨论

1. 房子是负债还是资产？上述的图表是否有解法？

2. 管理在你当前的公司是资产还是负债？为什么？

名词解释（下列定义均来自于网上各百科，主要是维基百科）

资产：当持有一项物品，这物品会自动使现金流向你的口袋，就是资产。

负债：当持有一项物品，这物品会自动使现金从你的口袋流出去到别人的口袋，就是负债。

资产负债表：资产负债表是会计、商业会计或簿记实务上的财务报表之一。资产负债表利用会计平衡原则，将合乎会计原则的资产、负债、股东权益交易科目分为“资产”和“负债及股东权益”两大区块，在经过分录、转帐、分类帐、试算、调整等等会计程序后，以特定日期的静态企业情况为基准，浓缩成一张报表。其报表功用除了企业内部除错、经营方向、防止弊端外，也可让所有阅读者于最短时间了解企业经营状况。

现金流量表：现金流量表是财务报表的三个基本报告之一，所表达的是在一固定期间（通常是每月或每季）内，一家机构的现金（包含银行存款）的增减变动情形。现金流量表的出现，主要是要反映出资产负债表中各个项目对现金流量的影响，并根据其用途划分为经营、投资及融资三个活动分类。现金流量表可用于分析一家机构在短期内有没有足够现金去应付开销。

利润表：利润表是会计重要财务报表之一，主要用于计算及显示公司的盈利状况。

管理：管理就是管理者和他人及透过他人有效率且有效能地完成活动的程序。

投资回报率（ROI）：投资回报率（ROI）是指通过投资而应返回的价值，企业从一项投资性商业活动的投资中得到的经济回报。它涵盖了企业的获利目标。利润和投入的经营所必备的财产相关，因为管理人员必须通过投资和现有财产获得利润。

本文链接

结对Review后续进展（看看团队怎么说）

2012-03-01T02:31:00Z

好久没有更新结对Review的实际情况，让我们来看看团队自己的理解和总结。下述内容摘自团队成员的邮件，隐藏了敏感信息。

结对Review在好几个项目（项目名称隐藏）中试点以后，在项目各阶段都进行了一些尝试，也收获了许多，其中最大的收获就是项目信息更流畅了，项目成员相互补位更容易了。很多项目组同学也想尝试一下，方便大家分享更多结对Review的经验和感受，整理了一个参考的模板提供给大家，大家可以在一定阶段后将结对Review的心得分享出来，晒一下，邮件抄送xx（人员姓名隐藏），我们可以帮助一起收集，形成知识积累。

结对Review的核心价值：通过分享和互通让结对Review成为习惯，成为形成知识库的一种渠道，成为成长的一种锻炼。

============================================================================================================================================================

结对Review建议开展形式：

分享途径

被Review者发出分享文档
命名：项目_yyyyMMdd_被Review者
项目_yyyyMMdd_问题清单汇总
项目_yyyyMMdd_发布清单
发送：项目组成员
抄送：高远;岳震

编码阶段
自测阶段
子模块设计阶段
测试用例评审阶段
测分阶段
系分阶段
发布阶段

项目阶段

尝试形式

产出分享文档

综合性价比

需求分析阶段

暂时未尝试，后续持续改进

系分设计阶段

1.系分评审前
2.参与人：系分+架构+测分

Review详情

优点：系分设计符合架构规划，系分和测分对需求的理解达成一致

推荐等级：***

测分设计阶段

1.测分正式评审前
2.参与人：测分+测分Review人+系分

Review详情

优点：系分和测分在测试边界，异常关注点上达成一致，指导系分代码设计考虑全面

推荐等级：***

子模块设计阶段

1.编码开始前
2.参与人：各模块开发+系分

Review详情

优点：开发针对各自模块进行子模块设计，
开发和系分结果达成一致
推荐等级：****

编码阶段

1.晨会确定计划代码产出模块及结对Review对象
2.坚持每日结对Review
3.参与人：开发和测试

Review详情

优点：可操作性强，消除业务理解不足和设计上不足，促进组内规范大协作

推荐等级：*****

测试用例评审阶段

1.开发和测试对各自模块测试用例结对Review
2.参与人：开发和测试

Review详情

优点：开发和测试在用例上达成一致，指导开发自测

推荐等级：****

自测阶段

1.开发和测试一起配合自测，记录问题记录表
2.参与人：开发和测试

问题记录表

优点：自测问题跟踪，避免细节问题因为疏忽而遗留到线上
推荐等级：*****

测试阶段

暂时未尝试，后续持续改进

发布评审阶段

1.各模块开发和系分测分一起整理开发过程中
影响发布的点
2.参与人：各模块开发测试+发布接口人

发布清单

优点：发布关注点提前check，项目成员信息互通

推荐等级：***

发布阶段

暂时未尝试，后续持续改进

本文链接

用敏捷玩转软件开发 - 序

2012-01-20T07:41:00Z

龙年即将到来，先预祝大家新年快乐，龙年大吉！在新年来临之际，也许下自己的新年心愿，2012年将写一本敏捷软件开发方面的书，至少也是电子书吧，以帮助更多的人认识敏捷和玩转软件开发。暂定书名为《用敏捷玩转软件开发》。如果你有更好的建议，欢迎提出。

其实是否玩转敏捷并不是那么重要，真正重要的是如何玩转软件开发。作为一个软件开发实践者，我的职业生涯一直与软件开发相连，一直在思考和实践各种软件开发方法，希望不断取得软件开发的成功。本书的目标是借机总结自己软件开发的认识和经验，以帮助自己和他人在软件开发的路上越走越好。2011年9月在北京与@Thinker姜志辉和@我是晴耕雨读聊到，国内现在已经有大批的10年以上的软件开发人员，在软件开发领域已经有了相当的积累，应该把社区搞起来，沉淀和推广适合我们自己的方法实践，而不应该一味模仿照搬。然而敏捷宣言说的好，“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。”这将敏捷和软件开发有机地联系到一起，我们一直在追寻探讨的这些可以有效地纳入到敏捷这个大框架中，而不需要一定要自己发明轮子。

当然，敏捷已经很流行，不需要推广。然而，敏捷却远比看起来艰难，很多人碰得头破血流。这与敏捷本身和实践者过于注重实战，相对缺乏理论指导有很大的关系。大多数人都是知其然而不知其所以然，盲目照搬，为敏捷而敏捷。成功者不知道为什么成功，失败者也不知道为何失败。应了一句网络名言，【我的成功不可以复制】。如何让成功可以复制是敏捷急需解决的最大问题。

上述就是本书想解决的两大问题，首先是把软件开发做得更好，其次是让敏捷可以复制。

本书主要由两大部分组成，第一部分是解读敏捷，第二部分是实施敏捷。第一部解读敏捷将分为器法术道篇、道法术器篇、天地篇、他山之石篇。首先，器术法道篇将从最基础的敏捷实践开始，不断抽象共性，去寻找敏捷能够帮助我们解决哪些问题，这是悟道的过程；然后，道法术器篇将从软件开发的本质特征开始探讨，不断分解阐述，让我们认识实践为什么应该这样做，这是理论指导实践的过程；再后是天地篇，敏捷不可能独立存在，文化、人、管理、环境等等都对敏捷有这样那样的影响，理解这些影响对于让敏捷可以复制至关重要；最后是他山之石篇，他山之石中的理论部分将收录敏捷背后的一些理论，他山之石的杂文部分将收录各种关于敏捷的感悟。第二部实施敏捷将由实施方法与理论篇和案例分析篇组成，在实施方法与理论篇中我们将分析总结在实施敏捷方面正确的、错误的实施方法和理论，案例分析篇则非常直接，就是实战案例分析。（有朋友说：实施敏捷部分的实施方法与理论和案例分析与前面道法术器天地的意境相去甚远，我也这么认为，但暂时没有找到好的名称，欢迎朋友们提出更好的提议，非常感谢。）

本书思想体系的最初起源来自于@Thinker姜志辉的道法术器思想体系，并在此基础上有所扩展和发挥。天地是对我们所处的环境的总称，我们处身于天地之中，天地也可称呼为自然。道是天道，所谓道法天地，道是天地的运行规律，也是我们对天地的运行规律的认识。法是我们应对的方式方法，法具备通用型和普遍性，符合天道的就是善法，违背天道的就是恶法。将法应用于实践中，就得到了术，相对于法，术具备针对性。器原指有型的物质或者有形的工具，也可以泛指具体的、较小的实践。术可以泛指为器的组合，器可以泛指术的局部。

道法术器天地组成了认知循环，由器入道，以道御器，道法自然。

本书试图解决的两大问题直接对应着两种主要读者。一种是在软件开发领域已经拥有一些经验的软件开发人员和软件开发管理者，如何更上一层楼是他们当前面对的问题。另一种是敏捷爱好者或者实践者，无论是成功还是失败，相信本书都能加深他们对敏捷的理解，让成功更能复制。

大卫张33

2012龙年春节前

本文链接

解读敏捷3 - 解读敏捷实践之结对Review

2012-01-04T02:24:00Z

程序员A碰到了程序员B。“Scrum糟透了”程序员A说。“为什么啊？听说Scrum很好啊，我们公司也在准备实施Scrum。”程序员B回答。“千万别，你们会后悔的。”“你们实施的是真正的Scrum吗？”“当然，Scrum里面的3个角色、4个会议和3个产物我们都有啊。”

敏捷非常简单，却又极其困难。敏捷方法学由一系列敏捷实践组成，而当人们实施敏捷的时候，却急于一次性实施整个方法学。他们看重敏捷实践简单的形式，却不了解或者不想花费心思了解任何一个敏捷实践背后的内涵，从而导致没有一个敏捷实践能够做到位，不能享受到对应的好处。最后却发现投入那么大，期望那么高，收获却那么少。敏捷实施带来的只是无穷无尽的伤痛，不得已只好告别敏捷。

“谁说我看不见，我只是把视力集中到一点，以改变我以往对事物的看法”——周星驰《大话西游》。让我们把视力聚焦于单个敏捷实践，看看能否改变以往对世界的看法。

敏捷实践之结对Review

1. 是这样做的

结对Review是由两个开发人员一起进行代码Review的方式。它发生在其中一个开发人员完成了一段代码功能后。两位开发人员的分工是写代码者和Review者。Review者通过与写代码者面对面的交流来完成结对Review。Review者依次向写代码者提出6个问题：“这段代码完成什么功能？”“为什么要完成这个功能？”“设计思路是什么？”“符合架构思路吗？”“符合代码规范吗？”“我们一起来看看代码和你回答的前五个问题能够对应吗？”（不限于，还可以有安全性能等方面的问题。）

一次结对Review的时间最好不超过30分钟，Review的代码最好是最近1-2天的代码。

可以简单描述为2个人，1段代码，6个问题，30分钟。

2. 可用于

2.1 代码Review

结对Review能够有效地解决传统代码Review所存在的问题。传统代码Review存在如下问题：1）投入产出比低，检出的问题大多是低级问题；2）效果不稳定，严重依赖于Review人员；3）制度化推行，可持续性差。现实中，没有几个软件企业能够做好代码Review，因此我以前说过，这是检验软件企业软件开发能力的一个基本指标。这里的传统代码Review是指由代码能力更强的人Review写代码人的代码这一传统方式。

2.1.1 投入产出比

代码Review有3个级别，1）代码是规范的：代码可运行、符合编码规范、无低级错误；2）代码是正确的：正确理解需求、符合架构、设计正确；3）代码是可维护的：业务和应用架构清晰、设计简单、代码可读性好。

传统代码Review侧重于第一个级别，兼顾二三级别，而结对Review则主要作用于第二三个级别，兼顾第一级别。传统代码Review在Review频度上没有明确的规定，要读懂并发现二三级问题要求很高，付出的代价很大。剔除偶然因素，传统代码Review追求的最高目标就是所有的代码都符合代码规范，对促进代码进化的帮助不大。而结对Review的目标则要高得多，能够激发思维，促进代码演进。

结对Review的6个问题考察了代码实现、业务理解、设计思路、架构理解等各维度的关联性，除了代码规范问题外，能够更有效的发现以前很难找出的业务理解问题和设计缺陷。并且采用双人相互监督方式，在结对Review过程中两个人的对话和思维碰撞，能够活跃思维，从而更好的帮助发现关联性问题。

结对Review能够超越正确性，关注可读性和简单性，从而提升整个系统和产品的可维护性、可扩展性。在结对Review过程中，要求在短时间内把业务、设计和代码实现说清楚。这就要求不仅仅做到代码正确，还要做到思路清晰、代码简单，并且能够有效的避免偶然性编程。

2.1.2 人员依赖

每个软件企业都希望代码更好。为了保证Review的效果，使用传统代码Review的方式严重依赖于代码能力更强的人员来Review代码能力更弱人员的代码。这种方式有极大的副作用。1）代码能力强的人的时间被大量占用，以至于他们没有时间去完成他们的工作；2）这甚至会引起权力争夺，谁有资格谁没有资格是代码能力是否得到公司认可的评判标准。如果人们热衷于去钻营代码Review资格，就会大大增加公司的内耗和影响到整个公司开发人员技术能力的提升。

结对Review则不是这样，它对人员没有多少业务技术上的依赖。事实上在结对Review过程中，代码问题往往是写代码的人自己找出来的，参见《从小工到专家》中的“橡皮鸭”。第一次看到这一点的时候不会相信，这有点违反直觉。实际上，大多数高级别问题都是关联性问题，而人的注意力是有限的，在写代码时常出现关联性遗漏。结对Review的6个问题考察的重点就在关联上，往往是Review的人还没有反应过来，写代码的人都发现了。

当然，结对Review对人员有性格和其他方面的依赖。如果总是批评，或者写代码的人不愿意向他人展露自己的理解和设计思路，这时候就会故意找茬，引起争吵。

2.1.3 可持续性

传统代码Review依据的是传统的管理理念，正确的事情就应该做，应该做的事情就变成制度逼着做，制度带来的就是抵触和阳奉阴违。这就是中国最爱的运动式管理。领导重视了，就好一些，领导不重视了，就基本无效了。时间都在运动中过去了，企业却还是一年又一年的原地踏步。

结对Review一开始就考虑了可持续性。结对Review的成本随着熟练度会持续降低，到了后期，每天15分钟足矣。而它带来的收获却是可以持续的，基本每次都可以发现一些问题，而且还有其他的收获，参见下面的个人学习、团队建设。相比枯燥的代码，与人进行交流有趣多了，还可以开开玩笑什么的。有趣又有收获的事情，又不累人，可以经常做，甚至可以成为习惯。

2.2 个人学习

学习是软件开发人员必备的能力，然而学习却是个问题，参见《为未来学习》系列。新人面对的问题人称“种蘑菇”，很多老人都面临增长极限的问题。

2.2.1 新人

有一种新人培养方式叫“种蘑菇”。参见蘑菇管理定律：“蘑菇管理”是许多组织对待初出茅庐者的一种管理心态，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。——互动百科

还有种新人培养方式是“导师制”。新人入职后指定一位导师，负责指导新人。而导师无法面面俱到的满足新人的要求，企业也缺乏足够多的优秀导师。

还有种脱产式新人培训，3-6个月给新人集中培训。这种培训模式成本超高，大多数小企业均无法承担。

结对Review是一种工作中培训的有效方式，可以和上述3种方式形成有效的补充。

那些表现优秀的新人天生就会结对。他们知道自己的代码有很大的提升空间，他们会主动向团队中的其他人请教，你会经常看到他们参与讨论，积极请教，他们成长的很快。然而中国人比较被动，也有很多新人还不会结对，他们的成长可能不如预期。所以新人为了自己的成长，企业为了新人的成长，有必要推广结对Review。

结对Review为新人提供了更好的环境，让新人可以得到更多的指导。新人可以通过参加结对Review了解到更多的业务、架构、设计、代码等方面的知识，并且因为是实战代码，比培训的效果强很多。新人写的代码可以被结对Review，在Review的过程中发现各种各样的问题，接受各种各样的指导，从而既可以提升代码质量，也可以学到更多。

2.2.2 老人

软件企业中的老人面对的问题是增长极限。经过3-5年的工作，很多人都到了极限，无法从日常的工作中得到更多的收获。而公司内高端的岗位就那么多，也无法让每一个人随意的做实验，虽然提拔实验的方式在软件行业很普遍。

结对Review可以给老人锻炼的机会，让他们能够从日常的工作中得到更多的收获。

当老人Review新人的代码时，他们要学会如何提问，如何从信息中挖掘更深层次的内容，同时还不能让新人觉得难受。结对Review让老人学会如何鼓励他人，如何与他人沟通。

当老人的代码被新人Review的时候，他们要学会如何简明扼要的说明重点，如何用简单的方式说明复杂的问题，这将有效的帮助老人们沉淀总结自己的知识技能。

当老人间相互Review的时候，他们要学会如何PK，如何把话题控制在一定范围内，如何妥协和达成一致，如何更有效的说服别人。

上述的沟通能力、影响力、冲突解决能力和问题解决能力是每一位高端人才必备的能力，但很多人没有在工作中刻意的培养这些对自己未来发展至关重要的技能。

2.2.3 学习

每个人都想成为终身学习者。能够在任何环境下都比别人优秀，都能脱颖而出，想想都让人激动。然而大多数人都放弃了，因为工作的目的是结果，所以他们不得不一天又一天的重复使用自己以前学到的经验和技能。

结对Review让工作和学习有效的结合在一起，一方面在同样时间投入的情况下可以拿到更好的结果，另一方面可以满足终身学习的期望。

通过结对Review，可以学习知识。无论是新人还是老人，你都可以通过更多人的眼睛看世界，了解到很多业务和技术知识，新人可以快速成长，老人可以避免自己的知识结构变得陈旧过时。

通过结对Review，可以掌握技能。例如设计模式，关键不在于设计模式是什么，这种知识可以通过书本学习。在结对Review过程中可以了解到别人关于设计模式的很多思考，了解设计模式在什么情况下适合使用，在什么情况下不适合使用，发现和应用设计模式解决现实中的问题。这种实战锻炼是掌握技能的最好方式。

通过结对Review可以锻炼能力。沟通能力、影响力、冲突解决和应变能力等等都可以通过结对Review进行提升，而很多人都在抱怨平时没有机会进行这些能力的锻炼。

通过结对Review可以学习如何学习，养成学习习惯。很难找到能与结对Review比美的学习方式，它简单、安全、有效、可持续。它简单，因为只需要找到一个愿意和你谈30分钟的人就可以开始。它安全，你们在找出代码哪些地方可以提升，不会让你在大庭广众下丢脸，不会影响你的考评。它有效，能够快速的得到有效的反馈。它可持续，这是一个可以使用一辈子的技能，可以在任何公司使用。

2.3 团队建设

我们都知道，团队和一群人是不同的。每个人都期望为一个团队工作，在这个团队中人们不仅仅为了完成任务而走在一起，他们是为创造出超越期望的产品，工作有趣而且充满挑战，每个人都能感受到尊重和信任，团队充满友善的氛围，每个人都有成长。然而遗憾的是，这样的团队可遇不可求。敏捷就试图向大家描述这样一种情景，很多人都信了，然而在试验后他们发现自己做不到。最后的结论是，敏捷对人要求太高了，只有足够优秀的人才能玩转敏捷。

其实真正的原因是我们不知道怎么去建设这样一支团队，我们不知道如何达成我们的梦想。结对Review可以帮助我们吗？

软件开发团队的关键在于协作，而不在于分工。结对Review是两个人使用的最基础的协作方式。

2.3.1 暴露团队问题

在大多数软件项目中，人与人之间不交流，甚至有点矛盾也只是小问题而已，只要他们能够完成分配给他们的工作，毕竟软件开发人员是内向、不善交流并且很难管理的，同时传统的管理方式更强调分工而不是协作。然而那些我们忽略的最后会伤害我们，从软件开发中的Bug类型就可以得出结论，70%以上的问题来自于需求误解、遗漏等问题，而这些问题是可能通过沟通协作解决的。

结对Review强制两人坐在一起交流，如果他们不能很好的沟通协作，立刻就会暴露出来。提前解决协作问题既可以锻炼团队的冲突解决能力，还为未来的工作消除了一个隐患。

2.3.2 团队氛围

一个良好的团队自然有良好的团队氛围，但这种氛围是如何形成的呢？

有一种方式叫“破冰”。破冰是一种让团队成员快速相互熟悉的有效手段，不过控制不好就会“又黄又暴力”，会超出有些人的承受底线，反而破坏了团队的形成。并且因为破冰的内容大多与工作无关，所以人们在工作中能否像工作外一样很好的合作，还是个未知数。

结对Review是一种融入到工作中的、温柔的团队氛围建设方式。从两个人开始，在结对Review的过程中，被Review的人需要打开心扉，坦诚自己的思考，Review的人需要努力思索，通过提问激发更多的灵感，双方共同发现问题，解决问题，并共享Review带来的小小成就。相互间感恩、尊重、开放透明的团队氛围随着工作中的小细节逐渐开始形成，而这种团队氛围通过长期结对Review小心的呵护和培养逐渐成型。

当然，破坏永远比建设容易。即使结对Review有用，好不容易建起的团队氛围也可以被其他措施在几天内破坏殆尽。

2.3.3 补位备份

主动补位是一种强大的团队能力，让团队能够从容的面对病事假等多种人员减员意外。但要做到被动补位都很难，可能是由于人们相互间不熟悉对方的工作，也可能是人员积极性不够，还可能是人员的能力不够。通过结对Review，上述的3个问题都不是问题，补位的基本难题解决了。

很多公司都有强制的备份措施，其含义就是有人离职了公司不会受到损失。这种措施往往会受到有意无意的抵制，通常是形同虚设。而通过结对Review形成的网状备份关系则是一种更加先进的备份关系，其建设并不需要额外的强调和努力。

2.3.4 团队行为规范

每一个优秀的团队都有自己的默契和行为规范，这些行为规范不是写在纸上的制度，而是被团队成员骄傲的宣称，这就是我们的做事方式。这种行为规范需要长时间紧密的配合才能形成。结对Review就是紧密配合的一种典型形式，它能够促进团队统一认识，相对快速的形成团队行为规范。

“你这种代码看起来怪怪的，和我们以前的风格不一样啊。你看，应该这么写。”“这个业务不是这么理解的。”“这种方法太棒了。”上述的话语通过结对Review在团队中快速传播，从而形成执行中的代码规范。

2.4 组织转型

很多企业对现状并不满意，期望改变。然而企业往往发现，他们自身被自己长期以来形成的组织文化所绑架，所谓的转型困难重重，能做到的无非是换一换领导，改一改流程，并不能影响到企业内大多数人的行为。

前一段时间做了一个小统计，开发人员的时间都用到哪里去了？发现一个开发人员只用了1/3-1/5的时间写代码，其工作有一半以上的时间在申请权限、了解需求的细节、各种各样的会议、等待测试结果、等待上线、翻查日志等工作中。他们的工作可以优化、效率可以提升吗？从他们自己那里得到的答案是肯定的，然而企业的领导可能却无法看见这一切。

结对Review不一定有这么大的效果，它每次只能改变一个人的工作成效和两个人的合作关系，但我坚信，微观的优化最后一定会反映到宏观上。如果任意一个人的工作有做得更好，任意两个人之间的关系都有改善，整个企业一定会被影响改变。

2.4.1 企业文化/价值观/复杂系统

具备一定自组织特征的个体以简单的方式组成的关系网络往往都是复杂系统，企业就是这样一种典型的复杂系统。而改变复杂系统有一种简单的方式，改变这些个体之间的互动关系。常见的组织转型方式包括组织重构、流程制度转变，这些方式的根本都在于改变了人与人的互动关系。

结对Review改变了软件开发人员间的互动关系，当推广到整个组织，其带来的涌现效应能够改变整个组织。

企业文化/价值观就是这种涌现的样例。企业文化是一个企业表现出来的，内部员工的做事方式和行为规范，是企业内部所有人共同遵循的价值观。

最近听到比较多的“开放、透明、分享、责任”，这些价值观相信在很多企业的企业文化中都或多或少有提到。如果一个企业本身的管理方式就是建立在信息不对称、从上至下的基础上，这种控制式管理方式本身就与上述企业文化违背，最终企业文化要么挂在墙上，要么四不像。

结对Review能够从微观上为企业文化打下基础。被Review的人在结对Review的过程中必须向Review的人开放和透明，讲述他自己在这段代码开发过程中的思考和理解。他们分享他们对业务和技术的理解和认识，共同承担软件开发的结果。当结对Review成为习惯，开发人员相互间的信任建立，人们做到更加“开放、透明、分享、责任”，这一切为企业文化打下了很好的基础，帮助了企业文化落地。

2.4.2 知识管理/学习型组织/社交网络

企业中的知识管理是指企业针对个人及社群所拥有的显性知识和隐性知识的确认、创造、掌握、使用、分享及传播进行积极及有效的管理。彼得圣吉的《第五项修炼》让学习型组织广为人知，学习型组织是指企业通过组织学习实现员工知识更新和保持企业创新能力。

不过大多数企业都是心有余而力不足。企业中的知识管理就是形成了一个有一个文档库，成立培训机构和组织了大量的培训。然而落到微观层次，员工的成长是否符合预期？是否涌现了足够多的人才？

知识管理的一个关键是知识的流动。当前我们处于知识极大丰富的时代，迷失在知识的海洋是一件很正常的事情。在这种时候，知识的受控有序流动，知识的应用才是知识管理的关键。

结对Review在理论上可以成为企业中任意两个人之间显性知识和隐性知识流动的途径。如果我们把企业看做两两间关系构成的社交网络，那么通过定义两个人之间知识流动的方式，与工作密切相关的知识在企业中流动起来。君不见，通过两两间互粉的关系，信息在微博上的流动速度。

还有一种战术，称为“信息轰炸战术”。就是利用频繁的结对Review，形成以工作为中心的信息弥漫的氛围，利用员工的潜意识思考时间，说不定有什么好主意从此诞生。

3. 与……相关

3.1 变形

结对Review虽然在描述上是两人，人员可以增加。例如增加到2-3个人Review一个人的代码，其中一个人作为主要提问者，另外1-2个人作为附属提问者。

在形式基本保持不变的情况下，结对Review有多种变形方式。

3.1.1 时间上变形

结对编程：结对Review可以看做编程的后续，向前移动就变成了结对编程。结对Review与XP中的结对编程很像，那是不是应该称为结对编程呢？不然，在极限编程的维基百科中，结对编程都已经被改称为结对程序设计了。结对编程那苛刻的实现条件让人望而生畏，并且不能得到管理层有效的支持。结对Review能够得到开发人员的认可和管理层的支持，可以为结对编程打下基础，未来可以在关键代码编写时部分采用结对编程。

结对设计（敏捷建模）：将结对Review移动到程序编写之前，就成为了结对设计，甚至是敏捷建模。可以用于关键代码设计，用户故事设计思路Review。

3.1.2 角色上变形

结对Review可以用于测试与测试之间的测试用例Review，开发与测试之间的用户故事设计思路、代码或者测试用例Review，开发测试PO之间的用户故事Review等等。

3.1.3 内容上变形

结对邮件Review：通常见于外企，多数开发同学缺乏与外国人沟通的英语能力和沟通技巧，结对邮件Review能够让你发出有效的邮件并能快速掌握写好邮件的能力。在第一个外企工作时，我的一个经理每次都和我一起Review发给外国人的邮件，让我快速掌握了英语邮件的基本能力，非常感谢她。

还有结对方案Review，结对计划Review，结对总结Review，结对PPTReview等等无数多种变形。

3.2 有助于何种敏捷实践

在结对Review得以推行后，会对下述的敏捷实践执行有帮助。

简单设计（XP）：结对Review有助于简单设计实践的推行。什么样的设计能够称得上简单设计？能够在短时间内陈述清楚，并达成一致的设计方案很难变得很复杂。并且结对Review可以让代码变得更简单，具有更好的可读性和可维护性。

代码标准（XP）：几乎所有的软件企业都有代码规范，放在文档里的。然而代码规范只能在一定程度上防止代码变得更烂。符合代码规范的并不一定是好代码，代码规范只是表明，我们企业受过伤了，我们的代码不能比代码规范里面的更烂。结对Review有助于形成执行中的代码标准，并能够保证持续的对代码进行优化，从而可能不断提升代码标准。

敏捷建模：在结对Review养成的开放的讨论分享习惯非常有助于推行敏捷建模。

3.3 受益于何种敏捷实践

如果已经执行了下述的敏捷实践，可以帮助实施结对Review。

每日立会：在每日立会上关注结对Review，是一种有效的推行结对Review的方法。

回顾会议：回顾会议能够让团队更容易达成对结对Review的一致认识，从而有助于推行结对Review。

完整团队：团队中的成员不能像资源一样随意变动，这会阻碍结对Review的前期推广效果，完整团队实践能够提供一些帮助。

3.4 采用了何种敏捷方法

从上面的变形就可以看出，结对编程、结对设计、结对Review，结对才是关键。从这里我们总结出了一种基本的敏捷方法，结对。看来所谓的敏捷实践，也许就是几种敏捷方法应用于软件开发实践的结果。而这些敏捷方法也可以应用于非软件开发领域。

到底存在哪些敏捷方法？如何应用这些敏捷方法？理解敏捷方法是不是更能了解敏捷的本质呢？期待后面有机会来分享一下这方面的认识。

3.5 与敏捷价值观的关系

参见《敏捷价值观》和Scrum与XP中的价值观，在此就不复述了。

这篇文章实在是太长了，请参见上面结对Review与企业文化/价值观之间的关系。

3.6 应用了何种敏捷理论

复杂系统：敏捷中的自组织、涌现等很多概念和提法都来自于复杂系统理论。现代的学习型组织/知识管理和企业管理理论很多也与复杂系统理论相关。供希望更深入钻研的同学参考。

4. 实施方法和案例

请参见以前写的《结对Review》系列文章，考虑在后面推出更完整的敏捷实施方法论和案例。

5. 后记

完全没有想到这篇文章会写的这么长，这么累。其实我的本意是想给今年一直在做的结对Review实践进行一次总结，完整收尾。不多说了，后面还想对相关的敏捷实践都进行类似的剖析，并以之为依据展开对敏捷的理解和认识，讨论敏捷实施方法论和描述一些案例。现在看起来，上述目标完全就是一本书，就把写这本书作为2012的目标之一吧。祝所有的读者新年快乐！

PS：在未做特殊说明的情况下，本文的大多数名词解释均来自维基百科。

本文链接

解读敏捷2 - 敏捷实施的六个陷阱

2011-12-14T04:51:00Z

随着敏捷日益成为主流，各种各样的敏捷会议召开，一本又一本的敏捷图书出版，一个又一个的公司前赴后继的迈向敏捷，好一番火热景象。这让我回忆起了当年看报时的一个感受，当时每张报纸的显眼处都能看到牛皮癣和肝病的广告，咋一看感觉会治病的人很多，仔细思考下才发觉是根本原因是能治好病的人很少，否则市场上不会那么热闹。敏捷的现状是不是也是如此呢？

“与其做敏捷，不如变敏捷！Be agile rather than do agile.”但对于大多数公司来讲，如果没做过敏捷，怎么知道如何变敏捷。而且做敏捷可以检查和测量，变敏捷则不能，这违背了“不能被测量则不能被管理”的管理定律。但大多数敏捷实施会失败！那些被敏捷后的美好前景吸引、前赴后继奔向敏捷的公司基本上是在自寻烦恼，“苦逼敏捷”开始盛行。

窃以为要想成功实施敏捷必须先解决下面六个问题：

1. 没有目标，为敏捷而敏捷

为敏捷而敏捷，并不是为了解决真正的问题，把手段当做目标。不少公司简单的被市场宣传打动，认为敏捷就代表着好，不敏捷就不好。这些公司往往会被轻易的忽悠，高估敏捷实施的效果，希望通过简单的敏捷实施就能解决面临的很多问题。因为没有目标，他们在实施的时候只能力求规范。这是一种符合国情的管理方式，俗称运动式管理。运动式管理的目标仅仅是为了运动，运动之后才知道自己在裸泳。

贵公司当前的主要问题是什么？实施敏捷要解决哪些问题？哪些问题是不能通过实施敏捷解决的？

2. 没搞懂敏捷

不想变敏捷，只想做敏捷。没有真正投入成本研究敏捷的公司并不知道敏捷因何生效。当然，他们也有研究，例如派人参加两天的CSM培训，拿到证书；或者买进两本敏捷的书籍，看看红绿模式或者知道每天早上要回答三个问题。这种肤浅的研究把敏捷看做过程，而且是非常简单的过程。他们往往会低估敏捷实施的难度，高估敏捷实施的效果，结果在真正实施的时候碰的头破血流。在这种情况下实施敏捷就是一个悲剧。“我遵守所有的规则，人的和神的。而你不遵守规则，但他们爱你胜过爱我。“——《燃情岁月》

敏捷是什么？敏捷到底是怎样发挥作用的？需要多长时间？敏捷对什么没用？

They told me that the world would be changed if I could answer three questions every morning. Now I’ve answered them for a month, why hasn’t the world been changed?

3. 错误的方法：套装癖

套装癖是指人们更喜欢看起来完整的东西来满足他们的心理愿望，以逃避独立思考和解决问题的真正困难。套装癖现象不仅仅发生在敏捷软件开发，它体现了人们对解决方案而不是解决问题的热爱。瀑布模型并不是瀑布模型提出者的本意，但它被曲解成了瀑布模型这样一个软件开发解决方案；之所以提出CMM是为了衡量过程中的质量，但它变成了解决软件开发企业管理问题的解决方案；Scrum不是解决方案，但人们或者是抱怨Scrum解决方案没有提供足够的实践，或者是自己为它加上用户故事、计划扑克和其他实践，一定要把它变成解决方案。人们一边在市场上追逐套装，一边在抱怨套装原来是中看不中用啊。的确，实施一个套装比实施一个实践难多了，但套装癖们还是乐此不疲。

实施敏捷就是实施Scrum吗？真的需要所有的实践吗？有没有哪一个实践做好了，真的有效了？

4. 基础不行

敏捷软件开发还是软件开发，不会因为实施了敏捷，就可以招聘技能更低的人完成工作了。以Scrum为例，Scrum是暴露问题而不是解决问题，解决问题还是要靠人。人与人之间的冲突需要冲突解决能力，团队建设需要领导能力，对业务的深入理解需要对业务的掌握和分析能力，开发人员的设计编码能力更别说。Scrum的创始人说过，白痴也可以用Scrum，然后他又补充了一句，当然，他们只能产出垃圾而已。你们公司需要垃圾吗？

贵公司现在的软件开发能力如何？经过6-12月后，代码的质量能保障吗？开发人员理解业务吗？架构是不是让人很崩溃？

5. 环境冲突

要实施敏捷，却没有实施敏捷所需的环境、人和文化。大多数的公司无法包容为了解决问题突破公司规定，敢指出领导问题的人，在这种公司大规模实施敏捷，纯属找抽。这也是很多人谈到敏捷都会说，敏捷很好，但是在我们公司不适合的原因所在。而且实施敏捷带来的透明性会让坏消息在开始的时候满天飞，能否容忍坏消息？能否正确引导团队的认识？对管理层是极大的考验，其实坏消息一直存在，只是以前被捂住了而已。“贪官奸，清官要更奸。”——来自周星驰《九品芝麻官》

贵公司有没有更奸的清官？能不能容忍坏消息？能容忍多久？鼓励尝试吗？还是对任何“错误”都要惩罚？

6. 高估研发管理能力

软件研发管理能力是被软件开发公司忽视的癌症。有一个非常简单的问题来考察软件研发管理能力，“请问贵公司Code review做的怎么样？”看看管理层如何回答这个问题，到几个项目团队去看看实际做的怎么样，问问开发人员对Code review的感受。Code review是搞软件的人都懂的实践，人人都知道应该做，但是大多数公司在这一点上都不合格。

贵公司有没有一个软件开发实践是真正推下去了，没有应付了事的？哪一个敏捷实践是贵公司准备实施的？怎么真正推下去？

解读敏捷

这就是解读敏捷这个系列的目的了，希望通过这个系列达到如下目的：1）展示我对敏捷的理解，以帮助更多的人真正了解敏捷；2）对实施敏捷提出想法和建议；3）提供一些实例供参考。

虽然看起来很容易，但是敏捷真的很难，需要多年的学习和实践。只想按葫芦画瓢，结果就会是按下葫芦浮起瓢。我的格言是：简简单单就能做好的事不值得付出努力。就是因为难，所以做好了才能成为竞争力，才能与众不同，是这个道理吧。

后续的内容还没有全部构思好，但考虑中的内容包括：

1）实践与理论解析

敏捷有多难？从细节看全局，如何将细节做到极致，从细节理解敏捷。请看后续：解读敏捷实践之结对Review，解读敏捷实践之每日立会。怎么理解套装的Scrum、XP等等。

敏捷背后的理论解析，排队论，博弈等等。

2）实施方法与样例

你想解决什么问题？采用什么方法？问题域分析与道法术器。

3）杂谈

一些相关的事例与感悟。

PS：@larrycaiyu 建议我把名字从《大多数敏捷实施会失败》改成《敏捷实施的六个陷阱》，欣然改之。

本文链接

解读敏捷1-你在做苦逼敏捷吗？

2011-12-08T13:50:00Z

一天，程序员甲遇到了程序员乙。程序员甲就问程序员乙了，“听说你们公司也在搞敏捷？”程序员乙答：“是啊，别提了，纠结着呢。感觉现在加班比以前还多了，一个迭代接着一个，比以前累多了。你们公司呢？”“我们啊，现在不怎么提敏捷了。敏捷这一套东西在我们这里不好用。”

上述对话并非个案。对大多数人而言，敏捷实施给他们带来的更多是痛苦，而不是成功，而且即使是成功，大多也与他本人无关。所以一方面来讲，敏捷越来越火热，敏捷大会上人潮汹涌，另一方面，又有很多的声音在声讨敏捷，包含那些在敏捷上栽了跟头吃了亏的。

如何才能形容很多公司敏捷实施的现状呢？我苦苦思索。当“苦逼敏捷”这个概念从我脑海浮现出来的时候，它牢牢地吸引了我的注意。对的，这就是大多数公司实施敏捷的现状。

苦逼敏捷宣言

我们一直在实践中探寻更苦逼的软件开发方法，最近我们找到了敏捷，我们在身体力行的同时也强迫他人。由此，我们建立了如下价值观：

流程和工具高于个体和互动

可信的文档高于工作的软件

搞定合同高于客户合作

遵循计划高于响应变化

也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷变成了苦逼敏捷，Scrum也变成了苦逼Scrum。而且，苦逼敏捷不会介意你是否遵循Scrum规范，不会给你套上Scrum-but的帽子。

苦逼敏捷宣言虽然有点极端，但是不得不承认，这符合现实。当敏捷变成一种时尚和公司逐利的目标时，在市场的力量推动下，敏捷终于变成了苦逼敏捷。

目前在国内实施的Scrum,太注重形式上了过程实践，但是对于团队的组建，文化，进而整个公司治理上的理念等软的层面都没有得到关注。从而在员工的考核，激励，责任感上总是有问题。——@陈皓RoyChen，原文地址：http://weibo.com/1322589482/xAO3zehMQ

Scrum只是起跑线，大多数人却把它当成了终点。——@ 乔梁QL

这是实施了敏捷n年的N公司传出来的内部对话。1）N公司被敏捷害惨了，现在要去害别人了啊；2）关键是要把H给害了才有用，但人家已经抛弃Agile了；3）实在没搞懂，开发的路千万条，N公司怎么就选了敏捷呢。

非要那么苦逼吗？

苦逼需要理由吗？不需要吗？需要吗？如果一定要找点理由的话，下述理由不知是否合适。

1）天生苦逼

不少公司的管理层其实并不真正关注敏捷，他们并不想改变自己。他们被广告打动了，“用敏捷吧，交付更快，质量更高。”于是敏捷成为了他们的新玩具。敏捷好啊，简单易懂，成本低廉。就这么定了，记得要更快交付哦。于是。。。。。。

这些公司天生信奉苦逼敏捷宣言，执意于将苦逼进行到底。

2）自愿苦逼

不知道是被代表惯了，还是怎么回事，受害者妄想挺流行的。“加量不加价”的事情是坚决抵制的，这也是很多同学的口头禅。不改变，他们觉得现在的工作很苦逼；改变，他们觉得改变让他们很苦逼。

对这些同学来说，工作就是件苦逼的事。做不做敏捷，反正苦逼定了。

3）被迫苦逼

也有人是真的关注敏捷，相信敏捷能够带来改变。但是，敏捷远比看起来难多了。真正进去一尝试，苦逼了，干不下去，欲罢不能。

被迫苦逼的同学可怜了，希望能够找到名师，锻炼能力，早日走出苦逼境地。

本文链接

我不信奉Scrum，我信奉敏捷

2011-11-27T00:33:00Z

Scrum一直以来争论不断。虽然创始人Ken在演讲中曾说过即使是白痴也可以用Scrum，但是依然有很多人认为Scrum对团队成员的素质要求非常高。另据统计，75%以上的Scrum都可以称得上失败。

去年十月，有幸参加了Outsofting鲍央舟老师的Scrum培训。培训期间，另一位敏捷教练Julien问我：“你信奉Scrum吗？”当时我冲口而出的回答是：“我不信奉Scrum，我信奉敏捷。”回想起来，了解Scrum这几年来，一直对Scrum有一种怪怪的感觉。这难道就是传说中男人的直觉？呵呵。

1. 我们这样走向Scrum

1.1 在Scrum之前，我们是这么干的。

任何一个项目都可以划分为活动，角色和产物。在典型的瀑布模型中，活动分为计划、需求、设计、实现、测试和发布，当然全生命周期还要增加维护。角色是项目经理，需求分析人员，设计师，代码人员和测试人员。产物有项目计划，需求文档，分析设计文档，代码，测试用例和最后的软件包。

1.2 Scrum是这样的

Scrum也符合这一原则，分为活动，角色和产物。活动分为计划会议，每日立会，评审会议和回顾会议。角色是ScrumMaster，产品负责人和团队。产物有产品订单（Product backlog），冲刺订单（Sprint backlog）和燃尽图。

听说Scrum非常神奇，看看Scrum如此简单，不如我们开始吧。

1.3 然后就郁闷了

Scrum并不像想象中那么美好，只是看起来简单而已。

迭代中的任务总是不能完成，问题非常多。计划会议时间太长，感觉效率低下，准备不足，有效信息不足。每日立会是个比较严重的负担，时间超时，让人窒息。评审会议走过场。回顾会议变成抱怨大会。

QA开始抱怨测试工作压力非常大，每个迭代只交付部分功能让QA工作不好安排，效率太低；随着迭代的增加，回归测试工作量不断增加，而引入自动化成本又太高，当前的团队在自动化方面的技能不足。开发人员需要学习的东西更多，代码在几个迭代后快速的腐化，每个迭代都要安排不少时间来重构返工，架构不能支撑业务需求，多次大调整。ScrumMaster仅仅是维护Scrum的流程就很累了。（上面仅是部分问题列举）

结果并不理想，但是Scrum应该没有问题，那么问题在哪里呢？苦苦思索，好像有了答案。如果我们有了优秀的人，他们组成了优秀的自组织团队，使用优秀的工具，采用优秀的实践，那么Scrum应该能够发挥它的作用。

2. 我不信奉Scrum

2.1 Scrum不是解决方案

不少企业或组织根据Scrum重新定义了角色，活动和产物，然后开始工作，然后碰到了困难。于是他们请来教练进行诊断，一番诊断后，教练给出了诊断结果，你们做的不是真正的Scrum，你们做的是Scrum-but。在那一霎那，心都碎了，我们做的不是真正的Scrum。拿出Scrum的定义看看，我们一个也没少啊，怎么就不是真正的Scrum了呢？（文学夸张，请见谅，呵呵。）

按照Scrum创始人对Scrum的定义，Scrum不是一种方法学，而只是一种管理框架。Scrum不能解决问题，只能暴露问题。然而为什么大家都认为它就是解决方案呢？

1. 问：为什么大家都认为Scrum是解决方案？

2. 答：因为我们需要解决方案。

3. 问：可Scrum不是解决方案啊。

4. 答：这不重要，因为我们需要解决方案。

5. 问：我们还需要学习敏捷思想、原则和其他实践。

6. 答：实践可以有，思想就不必了，因为我们已经有了Scrum解决方案。

上面的问答真有爱。“你想要什么，你便得到了什么。”因为我们需要解决方案，我们就有了解决方案，我们也有了无数的网站和人宣传和咨询这个解决方案。

2.2 硬套会死的很难看

Scrum不是解决方案，它甚至不是一种方法学，Scrum可以和其他的方法学一起使用，当然相性不合，死的很难看。

2.3 Scrum配合敏捷

回到敏捷宣言和原则，从以事为中心到以人为本、人事和谐发展，这应该是Scrum可以发挥更大威力的重要方式。（篇幅有限，没有讨论为什么我信奉敏捷。）

本文链接