整理资料，发现很久以前的培训总结，分享之
敏捷不是“银弹”
当前“敏捷”是一个比较流行的词汇，当敏捷不是大家想象的银弹，对人员的培训及方法的掌握仍旧是不可替代的。敏捷开发来自欧美，欧美从事敏捷开发的企业尤其是较大的企业中，其开发人员一般都有十年甚至二十年的开发经验，所以敏捷对他们来说可以不需要写文档，因为关于产品和开发的知识都已经烙印在他们脑子里，某些文档对他们来说可能是一种浪费。当在国内，有经验的开发人员数量有限，不要试图把“敏捷”当做解决一切问题的银弹，如果从事敏捷开发一定要注意风险。但敏捷开发中的“团队开发模式”对员工的成长和培养有较大的帮助，中国人比较不善于“团队”工作，而敏捷在这方面对大家会有所帮助，但也会造成部分困难，比如知识的总结、分析和分享，中国人很可能说不出来，实施敏捷时也需要注意。可以考虑让大家掌握鱼骨图、思维导图等问题分析方法，促进团队内的分享与总结。关于“结对编程”，目前敢于使用的公司不多，比较需要勇气，讲师询问了在场的企业，只有一家公司目前尝试使用“结对编程”。
敏捷开发的范围
该讲师的主要工作经验背景来自IBM软件研发中心，在IBM敏捷开发的范围主要限制在“开发”领域，不包括整个软件开发过程中易变的部分，也就是不包含需求分析和架构设计。不建议将主要的需求开发活动和敏捷开发活动混淆在一起，尤其是产品的早期，产品的概念还不明确，意味着需求可能会有较大的变更，对敏捷迭代的计划的安排有较大的影响。另外，架构设计本身不适合迭代，一个不断变化的架构，对产品开发进度会造成重要的影响。架构的重构也是一件比较慎重的事，一般并不包含在敏捷开发活动中，敏捷开发活动中所指的“重构”通常意味较小范围能的功能组件或模块的变化。
敏捷开发的角色
在开发过程中，一般有几个角色不可以相互兼职，原因是角色之间存在着利益冲突：
- 需求分析人员和开发团队成员不可以兼任——“做成什么”和实现的冲突
- 项目经理和开发团队成员不可以兼任——进度控制和实现时间的冲突
培训的重要性（掌握方法和过程）
仅掌握敏捷实践是不够的，软件开发方法和过程的培训在组织中是不可或缺的。可以想象一个连需求分析、设计都不知道怎么回事的团队，使用敏捷开发实践的场景。RUP将过程维和时间维的分离组成了一个开发架构，了解过程维中的基本活动和方法对敏捷团队是有益的。建议在开发的过程中也要时常去RUP中学习，对大家是有益的。
敏捷的纪律性、节奏与工作环境
敏捷“不写”文档意味着工作量的降低？事实刚好相反，敏捷实践有着更强的纪律性，一个实践得到正确、彻底的实施，需要团队内更多的纪律和努力。例如，Scrum中的sprint，sprint的译文应该是“冲刺”，即全力短跑，需要一个团队全力冲刺。从这里也可以看出，在整个敏捷开发中，掌握开发的节奏非常重要，因为一个人无法一直保持全力冲刺的状态，那么团队开发也是一样，要保持团队的热情和工作能力，也必须掌握好开发节奏，必须做到松弛有度。由此引发的另一个容易被忽视的问题：工作环境！敏捷开发鼓励沟通，因此需要一个“开放”（无隔断、透明公开）的工作空间，需要类似圆桌会议的工作空间没有彼此隔阂，方便及时有效的沟通。“开放”的空间意味着团队中的个人没有“私人空间”，必须全力工作，那么使人在需要放松时能得到放松的工作环境很重要，否则团队的热情和工作能力会持续的降低。综合这些环境的要求，需要“开放”的工作空间和可以得到有效休息的空间（如咖啡室），另外这些休息空间也充当着“沟通”的重要场所，有大量的有用信息往往来源于相关但没有目的的交流。
沟通
沟通有多种手段，如文档、邮件、电话、视频等等，但最有效的沟通手段是“面对面+白板”，而最无效的沟通则是“文档”。所以，敏捷强调使用面对面的沟通，认为这是知识得到传递和分享的最佳手段。中国人在这方面有弱势，因为我们的教育体系中从来没有涉及这些，“沟通”在实施敏捷的团队中既是“机会”也是“风险”，“机会”意味着更有效的员工培养和成长，“风险”意味着一个“僵尸”的团队，仍旧是计划驱动，而不是团队自发。
Scrum中的计划制定
在Scrum中的迭代计划制定过程中，有一点很容易被团队所忽略：用户故事或任务之间的依赖关系。Scrum通过团队制定迭代计划时，除了用户故事的优先级排序以外，需要团队注意用户故事之间的依赖关系，这一点很容易被忽略。这也是为什么需求分析活动（用户或业务需求）不建议和开发混在一起的原因之一，因为业务需求中隐含着用户故事之间的依赖关系。
团队与绩效
敏捷需要改变以前对个人绩效的评估的方式，而是以团队绩效代替。即使存在某个人自认为做的很好或者个人工作任务完成也确实不错的情况，在敏捷开发中，如果团队的绩效不好，对个体成员的继续评估也一样任务不好。因为，敏捷任务如果一个人很“好”或者能力很强那么他应该能够带动整个团队获得成功。敏捷强调的是一个团队。团队的成功才是个人的成功。（具体应该如何评估团队绩效，经过询问，讲师也语焉不详，只是说各个公司可能有自己的模型）
关于工具
在敏捷开发实践中，使用了大量的便签纸，虽然方便，但是过多的便签纸可能对管理造成影响（如团队的年度总结、度量等等），不利于保存，可以使用管理工具。讲师演示了VersionOne工具，当该工具安装比较繁琐，并且目前已经从开源转为商业软件，只有从讲师那Copy一个。
其它
- 需求验证除了静态手段（评审）外，可以使用动态的评审方法，比如Demo和演示
- 测试和开发可以是一个团队也可以不是一个团队，但开发、测试作为一个团队坐在一起，对计划制定以及彼此之间的隔阂都有好处
- 敏捷团队中很重要的一点是团队气氛：分享
- 实现敏捷团队的重点和难点在于“自发”的团队