敏捷开发大会总结
9月份的12日下午、13、14两天，参加了第七届敏捷开发大会，虽然自己没有做过敏捷项目，但因为现在“敏捷”是流行词，想看看自己公司的项目能不能用，所以就拿着领导的大洋，风风火火的参会去了，接受各位牛人的轮番知识轰炸。
Neal Ford ：Agile Architecture& Design
总觉得演讲的内容与题目不太相符，在讲主要内容之前，引用了很多名人名言，比如戴明的“坏的流程会打击好员工的积极性”，泰勒的科学管理理论等，之后，主要讲了4部分内容：
1、沟通的重要性，每个团队都要找到适合自己的沟通方式，面对面的沟通时，站在白板前，语言+文字的沟通可能是最好的。
沟通一定要有反馈，比如敏捷中可能有即时的反馈，每天的反馈，每周的反馈等等。
2、为什么结对编程有效
这个最主要的论据是一个人很难同时使用左大脑和右大脑，而结对编程则可以分工，达到同时使用的目的。
3、反馈与沟通如何结合
这部分，讲的是具体的实践，比如在构建的时候放一点歌，在办公室里边放玩偶，在工作中创造乐趣等。
4、为什么敏捷开发是有效的
因为沟通是闭环的，沟通是高效的，工作是快乐的，所以敏捷开发是有效的。
回答的问题：
Q1：结对编程时，对人员水平有要求吗？
A1：要尽可能水平相近，以提高生产力为目标
Q2：是否要保持结对的稳定？
A2：最好1~2天换一次，以保持信息的可传承行
Q3：如果是异地，可以形成结对吗？
A3：尽可能在本地，可以以互相出差的方式形成本地结对。
王红超：大规模敏捷转型
主要讲的是华为如何开展敏捷转型工作的，听完之后的第一感觉是：“有钱真好”！
华为是以“业务目标达成”为导向推荐的敏捷，并且把敏捷提高到了战略的高度，在这过程中请了很多业界的牛人做咨询和辅导。
华为的敏捷转型，简单来说可以分为两步：
第一步：统一对敏捷的认识
敏捷 = 理念 + 优秀实践 + 具体应用
其中，理念指的是敏捷的核心思想，优秀实践指的是经验的积累，而具体应用，指的是能够结合自身灵活应用才是真正的敏捷。
在敏捷中，领导的作用是“激发”团队，而成员是全方位的积极参与者。
第二步：建立敏捷开展辅导队伍
建立公司级和产品线级两级敏捷教练体系，引进几乎业界所有的顾问。采用开展日常培训、讲座等等；每年组织年度软件工程大会进行优秀实践的分享；建立内部交流社区等方式促进内部沟通。
华为在引入敏捷的过程中，也遇到的很多问题，比如新员工大量进入对原来团队的冲击，能力的稀释；研发过载，需要面对交付压力、能力不足、沉重的技术债务等。
最后的总结是，引入敏捷，一定要务实、理性。
Ritchard Markelz ：Global AgileStrategy
主要讲了敏捷中的领导力及创新，还有为什么要用敏捷。
敏捷中的领导力主要体现在，把团队看成整体而不是层级，在组织中创建授权，把优秀领导从合格领导中区分出来。将焦点集中在优秀实践和成功模式上，采用激励式询问方式，如什么事我们做的好的，什么是有效的。
使用敏捷的一个很重要的原因是：客户时敏捷的，客户关心的是如何快速解决问题，因此灵活性和适应性才是其中的关键。
回答的提问：
Q：敏捷方式中，计划怎么做？
A：分层，更高层的做传统的计划，不具体到细节。
荣浩：百年历史看管理
不得不说，荣浩真的是才子，将管理的历史帮我们梳理的简单而清楚，把这些人和事都按照顺序列出来的话，应该就能理清大概的思路了。（理不清楚的，去了解一下这些名字代表的具体事情和理念就知道了）
亚当·斯密、泰勒、亨利·福特、法约尔、韦伯；摩登时代、霍桑实验；休哈特、PDCA；彼得·德鲁克、列维特、钱德勒；权变理论。
80年代的日本制造、PDCA、TDD、精益；90年代的组织瘫痪、流程再造，哈默和钱皮、彼得·圣吉。
21世纪以来，扁平化的组织结构、全球供应链的挑战及国内最严重的管理的道德问题等等。
所有的这些都说明了，管理只有恒久的问题，没有终结的答案， 敏捷也不过是解决现在遇到的问题的一个方法而已。
乔梁：组织转型的十个要点
主持人介绍时说，这位是传说中的乔帮主，无奈本人孤陋寡闻，愣是没听说过。
乔帮主说，敏捷实践中，大约有75%的失败率，其中文化变革的范围是其中的原因之一。
乔帮主还说，因为用英文表达比用中文更好理解一点，所以用英文表了。
组织文化变革中，只变革需要变革的部分，因为人天性是害怕变革的，只有不满意程度达到一定程度时，才会变革，而变革时，应该先unfreezing再unfrozen and moving to a new state 之后再 refreezing。
1、Align with business urgency。只解决TOP3的问题，不要去做那些True but useless的事情。
2、Proper leading team。结论性的东西才能推出。
3、Quick assessment。谁执行谁做决定。
4、Define the roadmap and specificactions。
5、Pilot team carefully。因为这个与信心有关，一定要考虑人的积极性和能动性。敏捷中最主要的是开放的心态。
6、Be aware of antibody education。注意生产率与team的motivation 之间的关系。
7、Work as a whole。把团队所有成员弄到一起，坐在一起，对所有的实践，都要体验而不是判断。
8、Visualize everything
9、Metrics is important。结果和过程的数据一定要有，这样才能知道底细和过程。
10、Just give it a try。敏捷都是经验主义者，所有的事情都需要试一下并给出反馈。
钱安川：可视化——敏捷项目管理
钱老师其实就讲了一个故事，怎么把项目管理用数字表达出来，设计问卷的过程中和问卷的使用过程中遇到的问题，其实跟敏捷不敏捷没有太大的关系。
仝健：共识、乌合之众和可视化
仝老师主要通过一个经典的博弈“协同谬误”来说明信息共有的重要性，讲在项目中，信息不共有会产生的问题及信息共有会带来的收益。
常见的信息共有的方法包括发布信息、公布标准、设定目标和制定规则。
在项目中，把权限放给每个人，会更有自主性和责任感。
如果不能解决问题，就把问题暴露出来，让能解决问题的人看到它。
杜伟忠：利用可视化的工作方式打破部门壁垒
可视化主要解决部门之间沟通成本高、管理层因为项目过程不透明而对项目组不信任的问题、每个部门都想着自己部门利益的问题。
张忠：以客户价值为中心的公司级敏捷开发
张老师主要讲了用友是如何推进敏捷的。在软件行业，研发人员总是很被动的，而敏捷让大家的参与度提高了。而要推进敏捷，必须把敏捷变成一种公司级的价值观。
用友从2009年开始推进敏捷，已经有3年的时间，2009年的主题是“快速响应”，因为市场与客户都希望能快速响应；2011年的主题是“效益化研发”，公司内技术人员感觉可能不是很明显；2012年的主题是“全面推进”，重在吸引大家，建立内部俱乐部，专题推进等，转变研发视角，更关注市场价值，这时候要站在巨人的肩膀上而不是站在腰眼儿 上。
用友在敏捷的过程中，也遇到了很多问题，如开发人员压力大（负面反馈具体而大量，实现价值与研发交付无关联等）；交付物难以进行实际客户交付；多角色间协调一致的耗费比较大；保证持续发布能力的敏捷工程方法支撑不足；缺少全面支持的研发管理平台等。
敏捷应该采用阿米巴的方式，自我生长，自我分裂，自主经营。
如果敏捷最后能做成有趣的研发、与客户紧密关联的研发、幸福的研发就算成是成功了。
王宇：如何引导团队快速建立信念
王老师教会我的第一句话是“当学生准备好了，老师自然会出现”，以前总觉得自己是幸运，总是能够在希望学到什么的时候及时出现可以教会自己的人，看到这句话之后突然发现，原来在这件事上，大家都是一样幸运的。同理，当自己没有准备好的时候，即便老师在眼前晃来晃去，在耳边喊来喊去，仍然不可能有收获一样。
亨利·福特曾经说过，我需要的是一双手，但他带给我一个脑袋。而在我们现在，员工带来的不仅是一个脑袋，更包括了他们的家人、他们的经历、他们的懊恼和忧愁。
作为敏捷项目的领导，要有能激发出团队信念的信念。而团队最基本的信念，在Scrum里边是：开放、专注、勇气、承诺、尊重，XP中则是：简单、沟通、有序。
要记住，每个人都是部分正确。教练的作用是在舒适的区域外迈一步。
阳陆育：做减法的艺术
Louis 主要讲的是CMMI3及以上团队中，如何实现敏捷转型，主要讲了几个公式：
1、自适应流程 = 选择团队熟悉的流程 + 不断修正
2、PMO如何管理 = 敏捷项目管理≠监管
= 提供暴露问题的环境 + 专业的流程优化服务
3、质量成本 ≠ 测试成本
= 沟通成本 + 团队的学习成本
4、成功的项目 ≠ 做完了的项目
= 客户需要的产品 + 用户可接受的方案 + 团队可接受的质量
5、协作 ≠ 消除分工
= 各司其职 + 紧密沟通
6、开发 ≠ 编码
= 正确的理解问题 + 提出可接受的设计 + 完成可交付的代码
在CMMI3及以上团队中做敏捷，要使用做减法的艺术，要提取现有流程资产– 引入敏捷基础实践– 逐步剔除控制式监管 + 构建学习型组织 + 引入更多工程实践，其中学习型组织是关键，敏捷之所以能敏捷，就是因为每个人的能力都在提高，而所谓的学习型，则是指把某些人的知识传递给别人并固化下来。
把现有流程当成资产对待，按照以下方式处理：
1、文档：有区分的对待，有计划的简化。尽量避免write only的文档。
2、检查点：权力下放，减少或者延迟检查。让每个做事情的人成为检查的执行人。
3、测量域：明确目标，服务导向。根据团队的实际情况制定测量域，测量结果要纵向对比而不是横向对比。
4、测试：是开发协助型测试还是验收型（放行性）测试？前者的作用是改进生产的正确率，测试人员是开发人员的助手。