按照大家的要求进行了整理，内容如下，但是建议大家还是看看讨论内容，那样更容易理解。
***************************************************
通常程序员给人留下的印象就是机械，内向，不善言谈。
其实一个好的程序员最需要具备的能力就是沟通的能力。
只有良好的沟通才能知道客户需要什么，也只有良好的沟通，才能与团队成员合作无间
本次讨论希望带领大家进入一个以沟通为基本原则的软件开发领域，它就是——敏捷开发
一、敏捷开发简介
1、敏捷开发与传统软件工程的比较
传统软件工程：规范化的文档，持续改进的软件过程
敏捷开发：密切的交流与合作，逐步细化的开发过程
两者的区别好比重型武装部队与特种部队的区别
人员变更大，人数较多，成员分数，模块通信量大，耦合性强，维护时间长，开发过程有长期性，社会性的项目不益采取敏捷开发方法
2、4条核心价值观
（1）个体和交互胜过过程和工具
敏捷开发很强调个人能力
它以沟通和个人能力代替了定义死了的过程
（2）可以工作的软件胜过面面俱到的文档
它强调迭代式的开发，以开发的一个个版本形象的说明了需求，便于客户联想，也便于团队沟通演示
（3）客户合作胜过合同谈判
这条有过项目经验的人都能理解，与客户成为朋友比固定死的合同有用得多
（4）响应变化胜过遵循计划
它强调沟通，从而更积极的拥抱变化，并随时调整
3、敏捷开发的基本原则
（1）尽早、持续交付有价值的中间软件
（2）响应变化创造竞争优势
（3）业务人员与开发人员一起工作
它的目的是强调大家建立频繁密切的交流
这是一种帮助大家沟通的方法
这里的业务人员是指需求人员，开发的时候当然需要了
但是肯定不直接参与软件编写过程
（4）团队内部面对面的沟通
（5）根据完成了的功能调整工作进度
这是一种帮助大家沟通的方法
这里的业务人员是指需求人员，开发的时候当然需要了
但是肯定不直接参与软件编写过程
业务人员指的是了解客户需求的人员
熟悉业务的人
（6）重构代码，保持代码健壮
（7）尽快完成目前已知的需求
强调把不了解的需求放到以后，不考虑太多可能性
不考虑太多可能性是指不考虑变化的可能性
先做好已知的，定义好的，持续形成新版本，客户可能会想到需要什么
很多客户并不是一开始就知道自己要什么
你给他一个东西用用，他会觉得好，还需要什么
或者哪里不好，需要改动
很多时候客户有很多需求，我们需要做的是帮他找到重点，理清流程，帮助客户提高主要的工作的效率才是目的
大家要始终知道，敏捷开发是一种开发方法，遵照执行可以对你的工作提供效率，而不是必须遵守的。
4、主要的敏捷方法
（1）极限编程（XP）-后面介绍
（2）水晶方法（Crystal）-个人觉得是XP的复杂版
重点；一种方法学，根据不同类型的项目确定不同的开发方法
（3）动态系统开发方法（DSDM）
重点：迭代式开发，及时并持续获得客户反馈，并对主要功能不断精化
敏捷开发是一种原则，实际的方法很多
是一种哲学的价值观
（4）特征驱动的软件开发（FDD）
自适应软件开发（ASD）
SCRUM方法……
二、极限编程简介
个人觉得极限编程是一系列方法的组合
1、特点：轻量、柔性、充满乐趣
2、XP的价值观
（1）沟通
（2）简单
（3）反馈
（4）勇气
其实前三点刚才敏捷开发方法已经讲了，重点就是勇气
不是重点，是我要讲的重点
勇气其实和拥抱变化是一个意思
勇气还指不断的重构代码
勇气就是甚至引导客户去变化
使之成为一种竞争优势
3、基本原则
（1）快速反馈
（2）简单性假设
（3）逐步修改
（4）提倡更改
（5）优质工作
第（5）点是很多优秀的程序员容易犯的错误
很多优秀的程序员喜欢设计，觉得思路是最重要的，很多时候把思路理顺了，不愿意把问题完全解决好，总是留些小尾巴。但是后面又更不愿意回有修补好
比如很多人写TRY加个CATCH，然后就不写出错处理，想等最后一起写，实际上再不会回头看了
三、重要概念解释
这里的概念实际上很多就是一些小方法，我重点讲解一下，希望能引起大家的兴趣，使大家更详细的研究XP方法
用户故事:
就是面对面的请用户描叙自己工作的步骤，可以用UML，也可一用小卡片
也可以用最平实的语言描叙，当然你一定要记录下来，这个是需求分析的依据
迭代式开发：
迭代方法有没有人不懂？
迭代式开发就是不断的交付新版本，但是不是修改性质的，而是不段精化的
隐喻：
我觉得就是对事物的约定俗成的叫法
比如很多人把DOTNET高手叫大内高手（DOTNET读音和大内读音很近似）
这里的约定俗成是为了更方便的交流，更愉快的沟通，大家把平时这些比喻收集起来，和客户交流，和团队成员交流的时候就可以这样说
就象现在把女朋友叫老婆，难道你会不懂吗？
简单设计：
粗略的设计，不考虑各种可能情况，只设计主要类
测试先行：
测试先行是现在很提倡的开发方法，是很值得研究的
好比砌砖头，先拉一个水平线，每砌一快砖都对比一下
如果你全部砌完了再看对得齐不齐是不是有点晚了
测试先行的方法之一就是写每个模块之前先写测试代码，并且在每次改动之前测试一次
这样是很正确的思路，其实一点也不复杂，就象在学校写程序的时候，要也MIAN（）方法测试一下结果，你写好了以后，再测试就很方便了。而且不用进行很复杂的测试
重构：
我用三个词解释，就是重思考，重设计，重编码。
不断的找时间重构自己的代码是提高自己能力的很重要的方式
结对编程：
结对编程不是结队编程，是2个人，不是更多
有谁亲自试过
我个人不喜欢结对编程，但是建议大家工作不忙的时候可以试试，至少可以提高大家的交流度
结对编程主要目的是让大家更好的交流
敏捷开发的基本原则就是沟通
持续集成：
将所有模块经常性的整合，以及时发现与系统有冲突的问题
典型的就是微软团队的：每日构造
微软的每日构造甚至到了变态的地步，要求每天集成测试，发现问题，就算是凌晨也会找到你，要你立即修改
现场客户：
这是一种夸张的说法，其实就是经常和客户面对面的交流，演示，和现场开发差不多
编码标准：
团队采取统一的编码标准，避免就个人习惯，个人爱好等细节问题产生争论。
总之极限编程就是要求团队与客户密切的沟通，团队最好是长期合作，和客户交朋友。
希望本次讨论能让大家更加热爱编程，更积极的于他人沟通，更热情的拥抱变化。
并预祝大家能利用此方法更充分的发挥自己的潜力，在职业道路上一帆风顺。
***************************************************
通常程序员给人留下的印象就是机械，内向，不善言谈。
其实一个好的程序员最需要具备的能力就是沟通的能力。
只有良好的沟通才能知道客户需要什么，也只有良好的沟通，才能与团队成员合作无间
本次讨论希望带领大家进入一个以沟通为基本原则的软件开发领域，它就是——敏捷开发
一、敏捷开发简介
1、敏捷开发与传统软件工程的比较
传统软件工程：规范化的文档，持续改进的软件过程
敏捷开发：密切的交流与合作，逐步细化的开发过程
两者的区别好比重型武装部队与特种部队的区别
人员变更大，人数较多，成员分数，模块通信量大，耦合性强，维护时间长，开发过程有长期性，社会性的项目不益采取敏捷开发方法
2、4条核心价值观
（1）个体和交互胜过过程和工具
敏捷开发很强调个人能力
它以沟通和个人能力代替了定义死了的过程
（2）可以工作的软件胜过面面俱到的文档
它强调迭代式的开发，以开发的一个个版本形象的说明了需求，便于客户联想，也便于团队沟通演示
（3）客户合作胜过合同谈判
这条有过项目经验的人都能理解，与客户成为朋友比固定死的合同有用得多
（4）响应变化胜过遵循计划
它强调沟通，从而更积极的拥抱变化，并随时调整
3、敏捷开发的基本原则
（1）尽早、持续交付有价值的中间软件
（2）响应变化创造竞争优势
（3）业务人员与开发人员一起工作
它的目的是强调大家建立频繁密切的交流
这是一种帮助大家沟通的方法
这里的业务人员是指需求人员，开发的时候当然需要了
但是肯定不直接参与软件编写过程
（4）团队内部面对面的沟通
（5）根据完成了的功能调整工作进度
这是一种帮助大家沟通的方法
这里的业务人员是指需求人员，开发的时候当然需要了
但是肯定不直接参与软件编写过程
业务人员指的是了解客户需求的人员
熟悉业务的人
（6）重构代码，保持代码健壮
（7）尽快完成目前已知的需求
强调把不了解的需求放到以后，不考虑太多可能性
不考虑太多可能性是指不考虑变化的可能性
先做好已知的，定义好的，持续形成新版本，客户可能会想到需要什么
很多客户并不是一开始就知道自己要什么
你给他一个东西用用，他会觉得好，还需要什么
或者哪里不好，需要改动
很多时候客户有很多需求，我们需要做的是帮他找到重点，理清流程，帮助客户提高主要的工作的效率才是目的
大家要始终知道，敏捷开发是一种开发方法，遵照执行可以对你的工作提供效率，而不是必须遵守的。
4、主要的敏捷方法
（1）极限编程（XP）-后面介绍
（2）水晶方法（Crystal）-个人觉得是XP的复杂版
重点；一种方法学，根据不同类型的项目确定不同的开发方法
（3）动态系统开发方法（DSDM）
重点：迭代式开发，及时并持续获得客户反馈，并对主要功能不断精化
敏捷开发是一种原则，实际的方法很多
是一种哲学的价值观
（4）特征驱动的软件开发（FDD）
自适应软件开发（ASD）
SCRUM方法……
二、极限编程简介
个人觉得极限编程是一系列方法的组合
1、特点：轻量、柔性、充满乐趣
2、XP的价值观
（1）沟通
（2）简单
（3）反馈
（4）勇气
其实前三点刚才敏捷开发方法已经讲了，重点就是勇气
不是重点，是我要讲的重点
勇气其实和拥抱变化是一个意思
勇气还指不断的重构代码
勇气就是甚至引导客户去变化
使之成为一种竞争优势
3、基本原则
（1）快速反馈
（2）简单性假设
（3）逐步修改
（4）提倡更改
（5）优质工作
第（5）点是很多优秀的程序员容易犯的错误
很多优秀的程序员喜欢设计，觉得思路是最重要的，很多时候把思路理顺了，不愿意把问题完全解决好，总是留些小尾巴。但是后面又更不愿意回有修补好
比如很多人写TRY加个CATCH，然后就不写出错处理，想等最后一起写，实际上再不会回头看了
三、重要概念解释
这里的概念实际上很多就是一些小方法，我重点讲解一下，希望能引起大家的兴趣，使大家更详细的研究XP方法
用户故事:
就是面对面的请用户描叙自己工作的步骤，可以用UML，也可一用小卡片
也可以用最平实的语言描叙，当然你一定要记录下来，这个是需求分析的依据
迭代式开发：
迭代方法有没有人不懂？
迭代式开发就是不断的交付新版本，但是不是修改性质的，而是不段精化的
隐喻：
我觉得就是对事物的约定俗成的叫法
比如很多人把DOTNET高手叫大内高手（DOTNET读音和大内读音很近似）
这里的约定俗成是为了更方便的交流，更愉快的沟通，大家把平时这些比喻收集起来，和客户交流，和团队成员交流的时候就可以这样说
就象现在把女朋友叫老婆，难道你会不懂吗？
简单设计：
粗略的设计，不考虑各种可能情况，只设计主要类
测试先行：
测试先行是现在很提倡的开发方法，是很值得研究的
好比砌砖头，先拉一个水平线，每砌一快砖都对比一下
如果你全部砌完了再看对得齐不齐是不是有点晚了
测试先行的方法之一就是写每个模块之前先写测试代码，并且在每次改动之前测试一次
这样是很正确的思路，其实一点也不复杂，就象在学校写程序的时候，要也MIAN（）方法测试一下结果，你写好了以后，再测试就很方便了。而且不用进行很复杂的测试
重构：
我用三个词解释，就是重思考，重设计，重编码。
不断的找时间重构自己的代码是提高自己能力的很重要的方式
结对编程：
结对编程不是结队编程，是2个人，不是更多
有谁亲自试过
我个人不喜欢结对编程，但是建议大家工作不忙的时候可以试试，至少可以提高大家的交流度
结对编程主要目的是让大家更好的交流
敏捷开发的基本原则就是沟通
持续集成：
将所有模块经常性的整合，以及时发现与系统有冲突的问题
典型的就是微软团队的：每日构造
微软的每日构造甚至到了变态的地步，要求每天集成测试，发现问题，就算是凌晨也会找到你，要你立即修改
现场客户：
这是一种夸张的说法，其实就是经常和客户面对面的交流，演示，和现场开发差不多
编码标准：
团队采取统一的编码标准，避免就个人习惯，个人爱好等细节问题产生争论。
总之极限编程就是要求团队与客户密切的沟通，团队最好是长期合作，和客户交朋友。
希望本次讨论能让大家更加热爱编程，更积极的于他人沟通，更热情的拥抱变化。
并预祝大家能利用此方法更充分的发挥自己的潜力，在职业道路上一帆风顺。
