摘要： 2012-02-24：新版本发布，新增敏捷计划5页由于原定发布时日期2012-02-29在外地培训，提前发布；本期内容由原定的产品管理改为较为基础的敏捷计划，建议下载。预告：下一更新日期：2012-04-30。您可以在非商业场合免费使用（详见文档最后的授权页面）：作为培训前的预习阅读。打印并张贴在公司走廊上。作为企业内部小组培训教材使用。请大家跟帖多提意见和要求，以便及时更新。下载请点击（无需积分）：2012-02-24版：CSDN下载，无需积分，需要注册：http://download.csdn.net/detail/cheny_com/4086672115网盘，不用注册：http://11 阅读全文

摘要： 已经正式发布，请转至：http://blog.csdn.net/cheny_com/article/details/6616794最近几天没写博客，一方面因为有几次培训和会议占用了时间，另一方面在编写一个免费敏捷教材及宣传材料。最后有几张已经完成的草图。编写到初衷有两个：1. 希望每次培训课前，大家已经对基本概念有所了解，而不是从头听，这样有限的时间就可以用来解决真正的“敏捷如何应用”的问题而不是“敏捷是什么”的问题。花钱去听基本概念是很亏的一件事情，但要找一本书（尤其是2小时就能看完的）来了解敏捷基本概念还挺难。国外如goodaigle有一些类似材料，但是不完全对外公开。2. 去过几家企业， 阅读全文

摘要： 本文是“松结对编程”系列的第六篇。（之一，之二，之三，之四，之五，之六，之七，之八）松结对编程是小型团队的实践，大约运行在1个师傅+1～3个徒弟的尺度上，当面临更大尺度的时候，就需要大型团队模型。这里推荐139团队模型，因为它不但可以让松结对编程运转顺利，还解决了大团队沟通、绩效考核、师傅的出路等问题。139团队的整体情况相当复杂，将另有系列博文描述，这里只描述与“松结对编程”相关的内容，以保证本系列博文的完整性。基本概念139团队就是1个项目经理，3个师傅，9个徒弟的简称，当然实际上未必正好凑够13个人，也未必正好每个师傅都有3个徒弟。在第一篇里边已经提到过三个层级的工作关系，下面是一些深入 阅读全文

摘要： 本文是“松结对编程”系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八）松结对和紧结对不一样，两个人不是总坐在一起随时发现问题解决问题，而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个：一是看结果是否符合需求（做什么），而是看代码是否存在问题（怎么做），后者就是代码检查。代码检查（也称代码审查Code Inspection）是一种由来已久但是很神秘的东西，最初引入是在一些生命攸关、重大财产相关的软件开发中，典型的就是SSOS（美国航天飞机的软件），其每段代码都交由6个人审阅，方可入库。成果就是在1989年之前（之后笔者没有数据），SSOS在太空中失效次数只有一次。笔者亲身 阅读全文

摘要： 各种思路和顺序都试过。最开始时先编写Model，毕竟Model是所有一切的基础，再说没有Model，Controller里边用到该怎么办。后来改成先编写View，View才是用户能看到的东西啊，不知道用户看什么，怎么知道应该提供什么Model。现在先编写Controller。在讨论哪种次序最好之前，必须弄清楚“好与不好”的标准。开发次序好与不好的标准1. 顺畅比如编完Model的10个方法，再编Controller的10个方法，再编10个View是不顺畅的。从敏捷的角度看，就是同时开启了多个故事，而这些故事要等到最后才能同时完成，属于不好的实践。而先编controller中的1个方法，然后马上 阅读全文

摘要： 本文是“松结对编程”系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八）团队中常见的一种情况计划、估算、设计的时候大家还在一起，但编程的时候就会分开。分开看似是安全的，但是却充满隐患。2001年，一位招聘考试前三名（一共120员工）的程序员的两个月的成果被彻底放弃重写，原因是里边包含3000多个常数，而且很难修改（码流参数），重写的人座位距离他只有4米，重写也只花费了2周；2002年，一位月薪7000（那时候北京房价才3000多）的程序员编写了一个月的4000多行代码，在一个下午被重写为50多行，座位距离他只有5米的项目经理疑惑加惊讶地问：“你真的没学过c++ template？” 阅读全文

摘要： 本文是“松结对编程”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八）估算是经久不衰的管理话题，大致分为两种流派。第一种是领导指派，领导说这是10天的活，就必须当是10天的活来干，如果干不完，可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算，但是交给领导审批；领导审批其实就是砍一半的过程，还好大家之前就已经加了一倍，所以不怕。第二种是自我管理派（偏敏捷），就是由具体开发的人员自己说开发工作量，领导和他人不干预。尽管“自组织”了，但是领导深以为这种方法留下了偷懒的种子，而队员也觉得某人的估算很不靠谱（太长或太短），到底怎么办呢？共同估算吧。-------- 阅读全文

摘要： 本文是“松结对编程”系列的第二篇。（之一，之二，之三，之四，之五，之六，之七，之八）新人其实很少偷懒，因为一方面正处于入门学习的高峰期，另一方面工作时间不长需要得到企业和团队的认可。可为何他们工作总是不得力呢？新人的真正问题在于无心办错事和好心办错事。无心办错事包括没学过某种好的方法、不知道企业已经有某些可用代码或库、不懂业务等种种问题。好心办错事包括想做一个比领导想想的更好的功能、过度思考了可复用性可维护性等。这两个问题笔者都经历过（作为新人和老人），“避免”是最好的方法，而不是事后改正，这就需要在设计阶段和计划阶段从技术、管理两个方面来提前预防。---------------------- 阅读全文

摘要： 只要不是白痴，每个小的个体商业机构的老板都渴望有更多的人知道自己的产品，一般都会想到要利用网络资源来宣传自己的产品，于是产生了各种五花八门的网络营销手段。由于本人长期深处软件培训领域，自然会关注和分析一些同行在网络上的各种宣传方式，时间一长，我也从中慢慢地看明白和学到了一些网络营销手段，现在全部公之于众，全当给各位网友增加一些见识，丰富一下人生经验。如果这些披露不小心触动了某些人的利益，还请口下积德，多多担待。如果有网络营销高手看到了，还请多多指教，为大伙补充一些更多的网络营销秘密。由于各位网友的生活已经离不开网络，了解了这些网络营销手段，随时都可能会给我们的生活带来帮助，例如，我曾经因看病. 阅读全文

摘要： 本文是“松结对编程”系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八）传说中的结对编程，大致结构是两个人共用一台电脑，一个开发，一个测试，以随时评审来抵消返工时间损失。传说归传说，谁也没有见过。问题出在哪里？有两种主要原因。一是来自高层的，高层感觉两个人只有一个人干活，实在是有点浪费。“评审抵消返工时间”虚无缥缈，但每天只有一个人干活却是现实情况。二是来自基层的，两人若有高低，高手肯定觉得还不如我一个人干的快；两人若旗鼓相当，难免产生争执。其实在我们身边一直有一种方法很像结对编程：“师徒制度”，就是每个新人来到公司，都指派一个师傅带着，在技术与业务方面提供指导。他们既不用一台电脑 阅读全文