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

本文是团队管理系列的第五篇，也是“松结对编程”系列的第九篇。（团队管理栏目目录，松结对编程栏目目录）抱歉在这次MPD上不知道中间的20分钟茶歇也在3小时内，所以最后有10分钟左右的内容没有讲，这里补充一下。大型团队的切分如果团队大到一定程度，比如40人，那么怎样切分团队最好呢？答案是纵向切分，就是按产品而非按职能切分，也就是事业部化，而非开发-测试-支持这样划分。原因大致如此：1. 纵向切分的团队

本文是“松结对编程”系列的第十三篇。（松结对编程栏目目录）松结对编程包括L型代码结构的一个很大的问题，是在于由于人们复用了太多的代码，以至于所有代码牵一发而动全身。这很容易导致一个底层库改动后，很多地方编译不通过，或编译通过但运行不通过。本人曾经担任过底层库的编写者，在修改和维护底层库的过程中遇到了很多问题，也发现了一些诀窍，下面是一些编码级别的处理诀窍。这些诀窍其实都写在教科书上，学习和使用起来

本文是“松结对编程”系列的第十五篇。（松结对编程栏目目录）之前的L型代码结构的前三篇提到过，L型代码结构的微观计划和估算过程会与一般的编程方法不同，今天正好要编写一些新代码，边写边记录整个过程。如果中间卡壳了，我也会尽量记录下来。业务需求这是《火星人》中的一个功能，以往用户故事是使用故事树来展示的（就是有父子关系的用户故事），故事树隶属于一个产品Product。但是最近要发版了，感觉一个以前认为暂

本文是“松结对编程”系列的第十六篇。（松结对编程栏目目录）今天正好要复用一段框架（asp.net MVC3，服用范围包括Controller和View），把过程记录一下。与复用一般的过程相比，L型代码结构有这么几个特点：1. 如果复用有难度，在复用之前，一般不刻意形成“可复用代码”。顺便就能写成函数的例外。2. 从第二次复用的时候，就形成复用代码。这个听起来很容易，但要求：编写复用代码的人，就是调

续前文。本文是“松结对编程”系列的第十七篇。（松结对编程栏目目录）上一篇文章基本上把Controller中Action和与Action直接相关的复用讲到了，下面讲讲比较困难的部分。几个关键问题1. 如何实现整体结构相同，而局部不同的复用比如我们的业务需求中，整体上都是一个横向的结构（请参考下图），每个单元上面都是标题，下面都是增删改查之类的按钮，唯独中间的部分不同。如果是团队，要显示成员，如果是产

这是IT职场人生系列的第二十五篇（序言，专栏目录），也是松结对编程的第十八篇（专栏目录）。向高手学习是每个新手的心愿，但遇到的最大的问题是没有高手愿意教，这篇文章主要是解决这个问题。向高手学习有以下诀窍：善于观察不需要高手说话，也可以从高手那里学到东西，那就是靠多观察。1. 观察代码不是所有高手都愿意或都有时间来指导新手，所以如果能拿到高手的代码，就要多学习借鉴。先从比较好学的部分入手，比如命名方

通过一个案例，演示代码复用的一般原则和步骤。结论是：1. 任何相似代码都是坏味道2. 调用代码的信息量应该与自然语言相同3. 重构时做对比测试。

本文探讨Link访问权限的最佳实现方法，力求外观干净且封装良好。这些代码将位于L型代码结构（参见松结对编程系列中的定义）的下层，调用者无需理解其原理。

本文以一个完整案例展示代码分层及在松结对编程组中师傅与徒弟的分工。松结对编程（以及结对编程、代码审查……等）是最末级的管理实践，其实施过程必须与工程实践相结合。比如代码怎么分层，函数怎么写，都是这种管理实践的一部分。

本文以一个完整案例展示代码分层及在松结对编程组中师傅与徒弟的分工。松结对编程（以及结对编程、代码审查……等）是最末级的管理实践，其实施过程必须与工程实践相结合。比如代码怎么分层，函数怎么写，都是这种管理实践的一部分。

一期：活动描述，之一，之二，之三，之四，之五二期：活动描述，之一，之二，之三，之四，之五，之六三期：活动描述，之一，之二，之三，之四，之五之二：用户故事树与MVC中Area的关联陈勇-创业-北京(**9107533) 13:15:15下面的话题，是用户故事和设计的关系。设计整体上包含纵向和横向两种设计。比如MVC，可以理解为解决纵向设计问题的，他说：任何编码，应该包含表现业务逻辑的M，和表现界面展

本文是“松结对编程”系列的第十二篇。（松结对编程栏目目录）有没有一种管理方法，无需额外的测试活动，就能大幅度提高产品质量？L型代码结构就是其中一种候选方案。缺陷的来源要减少缺陷，就要先弄清楚到底缺陷是从哪里来的？就我自己的经验而言，大概20%的新手，制造了系统中50%以上的缺陷；而若将人群扩大到80%的新手+中等水平的人，估计他们能制造95%的缺陷；而剩下的20%的高手，可能只制造了5%的缺陷，甚

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

本文是“松结对编程”系列的第八篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。） 好像微软自己也有一个无纸下载处，但是手册不在身边没搜到，这里补充一个下载链接。 无需积分，但需要注册CSDN帐号。http://download.csdn.net/detail/cheny_com/3678487  ppt无法单独阅读，请参考以下相关的系列博客：松结对编程的起

本文是“松结对编程”系列的第七篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。） 刚刚参加完MPD 2011深圳站，在演讲中间及后来媒体采访，被问到了一些问题，也给出了答案，这里做一总结。 我自问自答到一半，才发现这里边的很多问题的答案，都用到了火星人谚语系列之一：有问题的地方无答案、火星人谚语系列之三：正确的答案一定简单。如果您觉得答案和自己的情况不完全

本文是“松结对编程”系列的第六篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）松结对编程是小型团队的实践，大约运行在1个师傅+1～3个徒弟的尺度上，当面临更大尺度的时候，就需要大型团队模型。这里推荐139团队模型，因为它不但可以让松结对编程运转顺利，还解决了大团队沟通、绩效考核、师傅的出路等问题。139团队的整体情况相当复杂，将另有系列博文描述，这里只描

本文是“松结对编程”系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）松结对和紧结对不一样，两个人不是总坐在一起随时发现问题解决问题，而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个：一是看结果是否符合需求（做什么），而是看代码是否存在问题（怎么做），后者就是代码检查。代码检查（也称代码审查Code Inspection）是一种由来已久

本文是“松结对编程”系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）团队中常见的一种情况计划、估算、设计的时候大家还在一起，但编程的时候就会分开。分开看似是安全的，但是却充满隐患。2001年，一位招聘考试前三名（一共120员工）的程序员的两个月的成果被彻底放弃重写，原因是里边包含3000多个常数，而且很难修改（码流参数），重写的人座位距离他只有

本文是“松结对编程”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）估算是经久不衰的管理话题，大致分为两种流派。第一种是领导指派，领导说这是10天的活，就必须当是10天的活来干，如果干不完，可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算，但是交给领导审批；领导审批其实就是砍一半的过程，还好大家之前就已经加了一倍，所以

本文是“松结对编程”系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况

这是敏捷开发松结对编程系列的第十篇（栏目总目录）。以下是本人自己及各企业所采用的代码审查的最佳实践，有些数据做了归纳，以使其“更佳”。请特别注意每个实践最后简单总结的价值观。如果想采用这些实践，则要认同并实现这些价值观；若想采用不同的实践，则要找到自己的合理的价值观。由于下面的价值观多数都是很有价值的，所以即使采用不同的实践，也要考虑到兼顾这些价值观。1. 每天进行代码审查能坚持做代码审查的企业，

本文是“松结对编程”系列的第二篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）新人其实很少偷懒，因为一方面正处于入门学习的高峰期，另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢？新人的真正问题在于无心办错事和好心办错事。无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。好心办错事包括想做一个

本文是“松结对编程”系列的第十篇。（松结对编程栏目目录）主题：如何用更少的代码写相同的功能，怎样的团队结构可以推进这一点。如果你也希望只用国际先进水平的1/4代码量，就实现相同的功能，欢迎阅读本文。本文会多次切换技术和管理两个平行线，所以结构会复杂一些。前言一直对代码有效性比较感兴趣，所以今天早上重新排布了功能树后，仔细计数了功能点和代码行，大致如下：代码9883行，来自VS的统计数据（只计算CS

本文以一个完整案例展示代码分层及在松结对编程组中师傅与徒弟的分工。松结对编程（以及结对编程、代码审查……等）是最末级的管理实践，其实施过程必须与工程实践相结合。比如代码怎么分层，函数怎么写，都是这种管理实践的一部分。