敏捷开发大会总结

网站：公文素材库　|　时间：2019-05-29 22:33:39　|　移动端：敏捷开发大会总结

敏捷开发大会总结

敏捷开发大会总结

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、及时通报进展与问题

发布进展情况，新的想法和目前正在关注的主题，不要等着别人来问项目状态如何了。当经理或同事来询问工作进展、最新设计或研究状况的时候，不会感到头痛。

友情提示：本文中关于《敏捷开发大会总结》给出的范例仅供您参考拓展思维使用，敏捷开发大会总结：该篇文章建议您自主创作。

来源：网络整理免责声明：本文仅限学习分享，如产生版权问题，请联系我们及时删除。