敏捷开发大会总结
敏捷开发大会总结
201*年9月18日星期二
9月份的12日下午、13、14两天，参加了第七届敏捷开发大会，虽然自己没有做过敏捷项目，但因为现在“敏捷”是流行词，想看看自己公司的项目能不能用，所以就拿着领导的大洋，风风火火的参会去了，接受各位牛人的轮番知识轰炸。
NealFord：AgileArchitecture&Design
总觉得演讲的内容与题目不太相符，在讲主要内容之前，引用了很多名人名言，比如戴明的“坏的流程会打击好员工的积极性”，泰勒的科学管理理论等，之后，主要讲了4部分内容：
1、
沟通的重要性，每个团队都要找到适合自己的沟通方式，面对面的沟通时，站在白板前，语言+文字的沟通可能是最好的。
沟通一定要有反馈，比如敏捷中可能有即时的反馈，每天的反馈，每周的反馈等等。
2、
为什么结对编程有效
这个最主要的论据是一个人很难同时使用左大脑和右大脑，而结对编程则可以分工，达到同时使用的目的。
3、
反馈与沟通如何结合
这部分，讲的是具体的实践，比如在构建的时候放一点歌，在办公室里边放玩偶，在工作中创造乐趣等。
4、
为什么敏捷开发是有效的
因为沟通是闭环的，沟通是高效的，工作是快乐的，所以敏捷开发是有效的。
回答的提问：
Q1：结对编程时，对人员水平有要求吗？A1：要尽可能水平相近，以提高生产力为目标
Q2：是否要保持结对的稳定？
A2：最好1~2天换一次，以保持信息的可传承行
Q3：如果是异地，可以形成结对吗？
A3：尽可能在本地，可以以互相出差的方式形成本地结对。
王红超：大规模敏捷转型
主要讲的是华为如何开展敏捷转型工作的，听完之后的第一感觉是：“有钱
真好”！
华为是以“业务目标达成”为导向推荐的敏捷，并且把敏捷提高到了战略的高度，在这过程中请了很多业界的牛人做自诩和辅导。
华为的敏捷转型，简单来说可以分为两步：第一步：统一对敏捷的认识
敏捷=理念+优秀实践+具体应用，其中，理念指的是敏捷的核心思想，优秀实践指的是经验的积累，而具体应用，指的是能够结合自身灵活应用才是真正的敏捷。
在敏捷中，领导的作用是“激发”团队，而成员是全方位的积极参与者。第二步：建立敏捷开展辅导队伍
建立公司级和产品线级两级敏捷教练体系，引进几乎业界所有的顾问。采用开展日常培训、讲座等等；每年组织年度软件工程大会进行优秀实践的分享；建立内部交流社区等方式促进内部沟通。
华为在引入敏捷的过程中，也遇到的很多问题，比如新员工大量进入对原来团队的冲击，能力的稀释；研发过载，需要面对交付压力、能力不足、沉重的技术债务等。
最后的总结是，引入敏捷，一定要务实、理性。
RitchardMarkelz：GlobalAgileStrategy
主要讲了敏捷中的领导力及创新，还有为什么要用敏捷。
敏捷中的领导力主要体现在，把团队看成整体而不是层级，在组织中创建授权，把优秀领导从合格领导中区分出来。讲焦点集中在优秀实践和成功模式上，采用激励式询问方式，如什么事我们做的好的，什么是有效的。
使用敏捷的一个很重要的原因是：客户时敏捷的，客户关心的是如何快速解决问题，因此灵活性和适应性才是其中的关键。回答的提问：
Q：敏捷方式中，计划怎么做？
A：分层，更高层的做传统的计划，不具体到细节。
荣浩：百年历史看管理
不得不说，荣浩真的是才子，将管理的历史帮我们梳理的简单而清楚，把这些人和事都按照顺序列出来的话，应该就能理清大概的思路了。
亚当斯密、泰勒、亨利福特、法约尔、韦伯；摩登时代、霍桑实验；休
哈特、PDCA；彼得德鲁克、列维特、钱德勒；权变理论。
80年代的日本制造、PDCA、TDD、精益；90年代的组织瘫痪、流程再造，哈默和钱皮、彼得圣吉。
21世纪以来，扁平化的组织结构、全球供应链的挑战及国内最严重的管理的道德问题等等。
所有的这些都说明了，管理只有恒久的问题，没有终结的答案。
乔梁：组织转型的十个要点
主持人介绍时说，这位是传说中的乔帮主，无奈本人孤陋寡闻，愣是没听说过。
乔帮主说，敏捷实践中，大约有75%的失败率，其中文化变革的范围是其中的原因之一。
乔帮主还说，因为用英文表达比用中文更好理解一点，所以用英文表了。组织文化变革中，只变革需要变革的部分，因为人天性是害怕变革的，只有不满意程度达到一定程度时，才会变革，而变革时，应该先unfreezing再unfrozenandmovingtoanewstate之后再refreezing。
1、2、3、4、5、6、7、8、9、10、
钱安川：可视化敏捷项目管理
钱老师其实就讲了一个故事，怎么把项目管理用数字表达出来，设计问卷的过程中和问卷的使用过程中遇到的问题，其实跟敏捷不敏捷没有太大的关系。3Alignwithbusinessurgency。只解决TOP3的问题，不要去做那些Truebutuseless的事情。
Properleadingteam。结论性的东西才能推出。Quickassessment。谁执行谁做决定。Definetheroadmapandspecificactions。
Pilotteamcarefully。因为这个与信心有关，一定要考虑人的积极性和能动性。敏捷中最主要的是开放的心态。
Beawareofantibodyeducation。注意生产率与team的motivation之间的关系。
Workasawhole。把团队所有成员弄到一起，坐在一起，对所有的实践，都要体验而不是判断。Visualizeeverything
Metricsisimportant。结果和过程的数据一定要有，这样才能知道底细和过程。
Justgiveitatry。敏捷都是经验主义者，所有的事情都需要试一下并给出反馈。仝健：共识、乌合之众和可视化
仝老师主要通过一个经典的博弈“协同谬误”来说明信息共有的重要性，讲在项目中，信息不共有会产生的问题及信息共有会带来的收益。
常见的信息共有的方法包括发布信息、公布标准、设定目标和制定规则。在项目中，把权限放给每个人，会更有自主性和责任感。
如果不能解决问题，就把问题暴露出来，让能解决问题的人看到它。
杜伟忠：利用可视化的工作方式打破部门壁垒
可视化主要解决部门之间沟通成本高、管理层因为项目过程不透明而对项目组不信任的问题、每个部门都想着自己部门利益的问题。
张忠：以客户价值为中心的公司级敏捷开发
张老师主要讲了用友是如何推进敏捷的。在软件行业，研发人员总是很被动的，而敏捷让大家的参与度提高了。而要推进敏捷，必须把敏捷变成一种公司级的价值观。
用友从201*年开始推进敏捷，已经有3年的时间，201*年的主题是“快速响应”，因为市场与客户都希望能快速响应；201*年的主题是“效益化研发”，公司内技术人员感觉可能不是很明显；201*年的主题是“全面推进”，重在吸引大家，建立内部俱乐部，专题推进等，转变研发视角，更关注市场价值，这时候要站在巨人的肩膀上而不是站在腰眼儿上。
用友在敏捷的过程中，也遇到了很多问题，如开发人员压力大（负面反馈具体而大量，实现价值与研发交付无关联等）；交付物难以进行实际客户交付；多角色间协调一致的耗费比较大；保证持续发布能力的敏捷工程方法支撑不足；缺少全面支持的研发管理平台等。
敏捷应该采用阿米巴的方式，自我生长，自我分裂，自主经营。
如果敏捷最后能做成有趣的研发、与客户紧密关联的研发、幸福的研发就算成是成功了。
王宇：如何引导团队快速建立信念
王老师教会我的第一句话是“当学生准备好了，老师自然会出现”，以前总觉得自己是幸运，总是能够在希望学到什么的时候及时出现可以教会自己的人，看到这句话之后突然发现，原来在这件事上，大家都是一样幸运的。同理，当自己没有准备好的时候，即便老师在眼前晃来晃去，在耳边喊来喊去，仍然不可能有收获一样。
亨利福特曾经说过，我需要的是一双手，但他带给我一个脑袋。而在我们现在，员工带来的不仅是一个脑袋，更包括了他们的家人、他们的经历、他们的
懊恼和忧愁。
作为敏捷项目的领导，要有能激发出团队信念的信念。而团队最基本的信念，在Scrum里边是：开放、专注、勇气、承诺、尊重，XP中则是：简单、沟通、有序。
要记住，每个人都是部分正确。教练的作用是在舒适的区域外迈一步。
阳陆育：做减法的艺术
Louis主要讲的是CMMI3及以上团队中，如何实现敏捷转型，主要讲了几个公式：
1、自适应流程=选择团队熟悉的流程+不断修正2、PMO如何管理=敏捷项目管理≠监管
=提供暴露问题的环境+专业的流程优化服务3、质量成本≠测试成本
=沟通成本+团队的学习成本
4、成功的项目≠做完了的项目
=客户需要的产品+用户可接受的方案+团队可接受的质量
5、协作≠消除分工
=各司其职+紧密沟通6、开发≠编码
=正确的理解问题+提出可接受的设计+完成可交付的代码在CMMI3及以上团队中做敏捷，要使用做减法的艺术，要提取现有流程资产引入敏捷基础实践逐步剔除控制式监管+构建学习型组织+引入更多工程实践，其中学习型组织是关键，敏捷之所以能敏捷，就是因为每个人的能力都在提高，而所谓的学习型，则是指把某些人的知识传递给别人并固化下来。把现有流程当成资产对待，按照以下方式处理：
1、文档：有区分的对待，有计划的简化。尽量避免writeonly的文档。2、检查点：权力下放，减少或者延迟检查。让每个做事情的人成为检查的执行人。
3、测量域：明确目标，服务导向。根据团队的实际情况制定测量域，测量结果要纵向对比而不是横向对比。
4、测试：是开发协助型测试还是验收型（放行性）测试？前者的作用是改进生产的正确率，测试人员是开发人员的助手。
扩展阅读：修炼敏捷开发总结
从公司拿的第一本书《搞笑程序员的45个习惯敏捷开发修炼之道》，急急忙忙的看完了，写的是什么呢？大概清楚，但具体来说不是很清楚，所以现在总结一下下，里面虽说说的不是很具体，很多是大家都在做的，但是还是总结出来的好，把它养成自己的习惯，符合的继续发扬，不符合的改善，如此而已。
现在我的功力尚浅，读这些习惯的书，应该不算早也不算晚，看看吧，反正不管怎么样，我翻完了，总结一下吧，总结其实就是摘抄里面的内容，自己的感受呢，项目经验太少，应该不是很多，但敲一遍应该能记住一些吧。好吧，开始了。
糟糕的代码需要重构！
需求一直是变化的，不要畏惧变化，但也不要频繁的变更需求，需要在一小段时间内，保持需求的稳定性！
需求是用户决定的，不是编码人员决定的！
测试先行，有时可以让测试牵引着编码工作的进行！
团队内部的协作，资源共享，代码共享，相互帮助，降低每个人垄断的面，使得危险性降为最低，使得每个人都不是不可替代的！
编码：先难后易！这样利于工作的进行，容易的都做完了，难得做的时候遇到问题，有时不得不修改或者重写已经做完的部分。
一、态度决定一切
1、做事
遇到bug，应该做的是解决问题，而不是找出凶手！！！2、欲速则不达
该重构的重构，该修改的修改，有时这会让我们工作的更快。绕过这些，没准我们会走更多弯路！3、对事不对人
我们是来工作的，又不是找茬的，是吧，每个人都有自己出色的一方面，当然也会有自己不出色一方面，给每一个人一个表达自己看法的机会。4、排除万难、奋勇前进
勇气会让人觉得不自在，提前鼓起勇气更需要魄力。但有些时候，它是扫除障碍的唯一途径，否则问题就会进一步恶化下去。鼓起勇气，这能让你从恐惧中解脱出来。
二、学无止境
1、跟踪变化
每天学习下新的技术，新的思路，逆水行舟，不进则退，难呀！2、对团队投资
与团队的人进行分享，大家强才是真的强大，让讲座穿插在我们的生活中，午饭时间大家都可以交流自己学习的心得，你有苹果我有梨，一共享，咱俩就都有苹果和梨了，何乐而不为呢？3、懂得丢弃
有时我们学习了新的技术，新的开发方法和习惯，但也不忍心丢弃旧的不好或者叫不合时宜的技术和习惯，我们应该适应社会的发展，适应技术的创新，我们已经学习了新的技术了，又有什么不忍心废弃掉原来那些不好的耽误事的技术呢？舍得舍得，有舍才有得嘛！4、打破沙锅问到底
很好的提问，可以给你带来答案！用一下5H1W什么的方法吧，它确实能给你带来答案，即便带不来答案，也能告诉你你该怎么做了5、把握开发节奏
开发节奏不能太慢，那样会让人变得更懒惰，更没有斗志；同样开发节奏太快也是，经常性的加班，也会让人们绝望。就像减肥一样，一点点的成功也是一个很大的激励，小而可以达到的目标可以让人们全速前进，庆祝每一次难忘的成功
三、交付用户想要的软件
在模电上面学到一个词反馈！他会帮助你开发出很接近用户需求的产品！不断地发布，然后不断地与用户交流，不断地修正需求，这就是反馈带给你的1、让客户做决定
产品最后谁用？废话，当然是用户了，所以产品做成什么样子，只有用户才能决定，我们做什么？只能建议！2、让设计指导而不是操纵开发
很简答，计划赶不上变化！开始时有一个宏观的设计就好了，不要面面俱到，因为你开始并不是很清楚这个项目，需要在编码过程中慢慢了解，慢慢根据实际情况再进行更详细的设计，开始时就用大量时间做没有实际价值的文档，浪费生命啊，而且自己以后也可能要按照原来的不合适的文档编码，因为那是你费尽九牛二虎之力才弄出来的文档啊，不用的话不是白做了吗？？何苦呢啊3、合理的使用技术
技术没有好与不好，只有合适不合适！选择慎重，不是看起来困难的就好，相反，越简单的说明越有功底，就像篮球场上，最牛叉的得分不是什么空中转体360再拉杆…..，一系列花哨的动作得分才是最美的，不可否认，这些可以证明你的实力，但是这样也同时带来更多的体能消耗，也可能带来更多的伤病，相反，一个简单的上空篮得分，一次简单的篮下空位跳投，都是很省体力，很巧妙，而且不会受伤的优雅的得分，能摆脱5个人的防守，证明你的功力更加深厚啊。代码也如此，简单的代码，自己看着清晰，用着简单，别人看着也清晰，维护起来越简单，而且越简单的事物越不容易坏4、保持可以发布
随时都保证你的项目能展示给任何人看，给客户，给老板，这样对大家都有好处，对代码的健壮性，对进度的安排，对客户的需求。。。。。。5、提早集成，频繁集成
越早集成，越早发现模块间的问题，修改的成本越低6、提早实现自动化部署
7、使用演示获得频繁反馈
他会帮助你开发出很接近用户需求的产品！8、使用短迭代，增量发布
9、固定的价格就意味着背叛承诺
软件项目有很多不确定性，很多东西做之前是没办法评估的
四、敏捷反馈
1、守护天使
自动化单元测试2、先用它再实现它
编程之前，先写测试。先写测试，你就会站在代码用户的角度来思考，而不仅仅是一个单纯的实现着。这样做有很大的区别，你会发现因为你要使用它们，所以能设计一个更有用、更一致的接口。3、不同环境，就有不同问题
多平台测试不是增加麻烦，而是减少以后的麻烦的不同环境下，问题也不同的4、自动验收测试5、度量真实进度
有时候做一个任务列表真的会很不错，而不是时间性质的，是任务性质的，将一个项目拆分成若干任务，列出来，然后自己做完一个就标记上，没做的就空在那里，等着继续完成6、倾听用户的声音
每一个抱怨的背后都隐藏了一个事实，找出真相，修复真正的问题
对客户的那些愚蠢抱怨，你既不会生气，也不会轻视。你会查看一下，找出背后的真正的问题
五、敏捷编码
1、代码要清晰的表达意图
它说，代码重读的次数远远超过编写的次数，所以还是把代码写的清晰，简洁些吧，有时甚至可以牺牲性能，因为你要让后期升级，维护的人容易做事，因为你也有可能是一个升级别人代码，维护别人代码的人，己所不欲勿施于人嘛。那就把代码写的像英语一样，通俗易懂吧，哪怕借助词典查一下呢2、用代码沟通
恰当的注释可以帮助人们阅读代码。不光要写这代码是做什么的，而且也要注明为什么这样做，当时自己的想法。
先阅读注释，然后快速浏览代码，从而完全理解它做了什么，以及为什么这样做。
3、动态评估取舍
东西没有绝对的好坏，只有适不适合你的客户，面面俱到不太现实，所以还是舍弃一些东西吧，因为你有更重要的东西要做呢4、增量式编程
在写了几行代码之后，你会迫切的希望进行依稀构建/测试循环，在没有得到反馈时，你不想走的太远。5、保持简单
简单不是简陋。简洁，实用，就好了，不必整一堆花里胡哨的高技术，没用的。6、编写内聚的代码
模块自己做自己的事，相互之间耦合度应该低一些，独立性强一点，不能离了谁，谁都玩不转，一个错就都出问题了，这个要特别注意啊！怎么才能做得到呢？？？？？？？？？？？？？？？？？？？？7、告知，但不要询问
命令与查询分开。命令可以做很多事，可以修改很多量，但是查询就是去看一下，而不能做出任何修改，也应该不要做任何修改8、根据契约进行替换六、敏捷调试
1、记录问题解决日志
这个就像高中时期的错题本，2个月2个本子，让我的数学成绩从90多分提至了130多分甚至更高，这说明了什么？说明了人们会经常跌倒在同一个地方，是很不长记性的，所以我们怎么办？脑子记不住，笔头总可以吧，写上啊，以后再查啊，没事就瞅瞅啊，笑话下自己嘛，是吧！2、警告就是错误
没事也应该多注意下警告，争取都给改了，完美主义者有什么不好呢？不过我的实际经验告诉我，有些警告是不可以避免的，是不用去搭理的，这个看你自己了，看具体情况了。3、对问题各个击破
没啥可说的，调试时基本的原则，单一变量原则，我们要确保周围其他的一定是好的，方能去判断这个事物是不是好的，所以，尽可能的拆开他们吧，那样你的思路会更清晰，做事情也越轻松4、报告所有的异常
报告异常情况，利于你的调试要传播不能处理的异常
有些东西隐藏起来终究会出来祸害人的，只能将其消灭掉，消灭不了的，也要将其示之于众，让大家来看清楚他，消灭它吧5、提供有用的错误信息
不是什么丢人的事，利己利人！
七、敏捷协作
双拳难敌四手，一个人干不过一群人的，所以团队是一个很重要的玩意儿，团队中不能只有一个人发挥，其他人抑制，因为那样还是一个人，我更倾向于抑制一个人激活全队的人，当然最好的结果是，激活所有的人，但是也有偶尔嘛，哈哈，大家的利益高于一切，在哪都是这样的，没啥可说的，除非你是牛人，但世界上牛人不是很多，我看还是老老实实混团队吧。1、定期安排会面时间
当然会议的交流很重要，相互了解，相互帮助。2、架构师必须写代码
只有深入进去了，才能了解，了解了才能架构啊3、实行代码集体所有制
让开发人员轮换完成系统不同领域中的不同模块的不同任务4、成为领导者
你会感到给予别人教导，也是提升自己学识的一种方式，并且其他人亦可以开始相信你可以帮助他们5、允许大家自己想办法
用问题来回答问题，可以引导提问的人走向正确的道路
如果有人真的陷入胶着状态，就不要折磨他们了，告诉他们答案，再解释为什么是这样的
6、准备好后再共享代码
自己对自己负责嘛，没啥说的7、做代码复查
人都是会犯错的，相互之间做代码复查是很好的，一起提高8、及时通报进展与问题
发布进展情况，新的想法和目前正在关注的主题，不要等着别人来问项目状态如何了。当经理或同事来询问工作进展、最新设计或研究状况的时候，不会感到头痛。
友情提示：本文中关于《敏捷开发大会总结》给出的范例仅供您参考拓展思维使用，敏捷开发大会总结：该篇文章建议您自主创作。
来源：网络整理 免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。
《敏捷开发大会总结》
由互联网用户整理提供,转载分享请保留原作者信息,谢谢!
http://m.bsmz.net/gongwen/747772.html