一、相识敏捷开发
敏捷之旅 203年深圳站，活动组织130人左右，大家来自不同的公司，来自不同的职能岗位，来自不同的人生阅历背景，来自对敏捷开发的不同认知，来自对敏捷开发的不同实践，大家坐在一起学习、探讨敏捷，把大家很好的融合在一起，很好的合作。
最初接触敏捷是在博客园关注周老师(周金根)的博客，通过周老师的一些博客对敏捷多多少少了解些，加入敏捷交流群，关注群里的活动。简单收录一些敏捷开发的相关书籍，一直没去深入了解学习，在广联达济南时，公司使用敏捷开发的相关方式，进行项目的管理，确实也体会到很多益处，大家都在尝试执行到位，并体会其中的快乐，还是蛮不错的。 在山东济南的时候，是很少有机会，也没可能接触到一些线下技术分享活动。这是来深圳的第一年，正巧赶到深圳敏捷部落组织的敏捷活动，整个活动感觉还是不错的，对敏捷又有了不一样的理解。
二、参加活动思考
为了很好的参加线下敏捷活动，简单设定几个问题，数据收集分析：
1.你对这个活动的主题了解多少？
用于了解你的用户，参会者对敏捷开发的认识程度，根据认识程度的不同安排不同的培训，可能培训效果会更好些。
2.你对这个活动的期望有多少？
用于了解用户的需求，参会者想在这次培训中获取什么，即用户的需求是什么，可以很好的改进培训。
3.参加活动后，你的总结是什么？
用于巩固培训成果，培训的成果需要巩固，培训的价值才能真正的的体现，可以衡量投入产出比。
4.参加活动后，你的反馈是什么？
用于了解用户的反馈，参会者的会后体验，期望与落差的反应，用户满意度调查，可以很好改进培训。
无论是公司组织的内部培训还是参加一些技术分享交流会，活动组织者可以对活动的参与者进行简单问卷调查，设定简单的问题点，帮助改进活动。活动前的用户调研，活动中的用户互动，活动后的用户反馈，可能会达到很好的培训效果，这次组织的活动也是成功的。了解参会受众、了解大家的关注点、了解这个地区的敏捷成熟度，了解大家的疑难点。可能都需要对活动的主题有所了解。
如果你是初学者，参与活动只是兴趣使然，更多的是倾听学习，那参加活动后是不是对这个知识有更多的了解；如果你是践行者，那么参加活动大家一起探讨，对于其中的盲点是不是有更清晰的认识；如果你是讲师，是不是应该好好的充分准备，根据你的听众探讨其中的知识点，如何很好的引导你的听众，让他们真的可以学到知识，结合他们实际情况给他们更多的建议和改进方案。
根据上面的提问点，简单的说一下，对于敏捷的了解还是在学习摸索阶段；对于这次敏捷活动期望，可以结识一些新朋友，对于敏捷开发的认识更充分；参加活动的总结，就是这篇文章的产出；参加活动的反馈，针对这次活动，如果能把最后的抛球游戏放在上午最后一场，大家可以互动的更好，中午吃饭大家就有更多机会多聊聊了。可能这次活动组织者，之所以把抛球游戏放到最后，可能就是通过这个活动让大家体会敏捷的最佳实践，那如果是这样的话，看看可不可以安排两个活动，大家在有对敏捷开发有认识提高的需求或许还会有结识新朋友的需求，如何验证，问卷调查，你的期望是什么就可以找到答案。
作为组织者，做不到满足每个人的个性化需求，更多考虑的是大家普遍关注点，给大家一个很好的互动交流的平台，更好的服务大家，给大家带来更多的益处。
或许引伸出话题是如何组织一次很好的培训？如何做一个很好的讲师？如何做一个很好的参与者？如何很好的践行敏捷开发？（问题：知易行难,倡导最佳实践）
三、参加活动准备
为了很好的参加这个活动，能很好的跟大家交流，很好的跟上讲师的思维，做了一些敏捷开发的补习和准备。
收录的一些书籍，如《敏捷开发最佳实践》、《敏捷落地路线图》、《敏捷软件开发：原则、模式与实践》、《高效程序员的45个习惯:敏捷开发修炼之道》等，但是看书是需要时间、也是需要好好的消化吸收的，成效比较慢，参加培训成效比较快不深入。时间的不允许，只能通过一些简短的博客、PPT、文档、PDF来了解，参见他人提炼的片面知识。所以就在网上收集了一些相关资料，让我们去看他人如何做敏捷的：
腾讯如何做敏捷？《敏捷开发基础》
华为如何做敏捷？ 《敏捷开发》
易杰如何做敏捷？ 《什么是敏捷》
其他资料：
《敏捷开发基础概念》、《什么是敏捷开发》、《敏捷开发推行》、《经典入门-敏捷开发》、《为什么敏捷开发不行》
敏捷是一套很好的项目管理工具，其中很多优秀的思想是值得学习和推广的，是不是要一定按照常规的敏捷推行方法，Scrum、XP、精益开发的"流程"执行，如果适合于你的团队完全可以很好的推行，如果不是很适合你的团队，可能其中的某些很好的方式方法值得很好借鉴使用。
Scrum流程图：
四、参加活动分享
活动安排：
吴穹博士，Agilean首席敏捷咨询师
分享主题：自动化测试困难及测试DSL
听吴穹老师讲自动化测试，主要从自动化测试存在的问题，到理清自动化测试方向，到避开自动化沼泽，到自动化测试七武器。
1.自动化测试问题：
编写、维护成本太高；效果不明显，没找到多少缺陷；没起到节省测试人力的作用
2.理清自动化测试方向
1).自动化测试是防弹衣： 守护核心功能；不要因为自动化测试没能发现许多缺陷而苦恼
2).自动化测试是放大镜：
自动化测试的目的不是节省测试人力，而是加快测试反馈,提升质量，减少研发浪费； 自动化测试案例是需要人来维护的，而且建设初期需要更多的测试人力
3.自动化测试沼泽
1).全面自动化 2).录制回放神话 3).不稳定环境下的半自动化测试
4.自动化测试七武器
1).分层测试规划 2).正确的质量观-内建质量 3).稳定的测试环境及测试数据 4).开源测试工具 5).测试SDL 6).持续集成驱动 7).开发测试融合工作流程
对于自动化测试，了解不是很多，简单分享一下。
测试系统支持。自动化测试需要一整套系统来推动自动化测试的践行，同样又是很大的成本投入，有了投入就需要考虑产出问题，这需要高层对自动化测试有很好的认识，通过整体团队的投资回报率来衡量自动化测试所带来的效益，而不是通过某些具体的数据参数就单一的作为衡量的指标，这样下去即慢慢的偏离推行自动化测试的初衷。
开发测试协同。多次强调开发和测试的紧密合作，按敏捷的思想是测试部门就是机动部队被分派到不同的开发组，阶段性的跟踪这期项目进行测试，自动化测试环境的搭建、以及后续对于质量的把握都需要开发和测试共同参与，要求开发和测试协同更加紧密吧。
持续集成驱动。对于测试来说，可能敏捷推行的自动化测试，测试先行或测试和开发并行，持续集成可以把项目中很多潜在的风险降低，成本最小，但持续集成环境的搭建确实又是很大的投入，自动化测试环境的搭建，以及对于测试粒度如何拆分才是最好的，分层测试规则的保障。
胡伟，华为高级项目经理
分享主题：打造自组织的敏捷团队
主要从我们理想中的团队、现实中团队的差异思考我们的如何建立自组织的独立团；借助场景小华的烦恼，分析践行敏捷中的困惑，没有达到敏捷的效果；引出打造自组织团队的几个要点；分享椰子型团队的特点。
1.华为对敏捷的统一认识
理念(敏捷核心思想)、优秀实践(敏捷经验的积累)、具体应用(能够结合自身灵活应用才是真正敏捷)
2.团队差异
1).我的独立团
超强的执行力、初验前的冲锋 、无人打破的记录、救火队 、严格要求下属、长期加班
2).W的独立团
“专家”才能改的代码 、提升？、两年累计离职率50% 、骨干不愿加入 、春节值守 、午夜“红牛”讲到自组织团队的几个要素：目标、承诺、可视化、团队、辅导、授权
3.小华的烦恼
1).接受了正规的Scrum培训；组建了跨职能的特性团队；严格遵循Scrum流程
2).晨会成了汇报会；状态墙成了“年画”；CI红了没人关注 ；回顾会议形式化
3).没有达到敏捷的预期效果
4.打造自组织敏捷团队的要点
目标、承诺、可视化、团队、辅导、授权
5.椰子型组织
其中比较感兴趣的是：
目标谈的更多的是用户故事的确定和Sprint的范围、商业价值、完成标准。
对用户的需求的探讨挖掘，我们要对产品负责，做好产品规划，确定那些是客户真正想要的，客户真正的需求是什么，强调用户需求的挖掘的深度；
承诺谈的更多的是Team对PO的承诺；PO对Team的承诺；ScrumMaster对Team的承诺；成员对Team的承诺。
承诺更多的是保障软件的质量，Team对PO承诺，需要Team有很强的执行力，确保项目准时上线；PO对Team承诺，确保本次Sprint周期内的需求是稳定的不会发生变化的，或80%的需求都是确认不会改变的；ScrumMaster对Team承诺，为Team提供更好的辅导和支持，并保障Team在这个Sprint的专注度，不要并行项目；Team之间的承诺，确保团队成员之间很好的合作配合，我们彼此之间是为对方服务的，都对彼此负责。
可视化谈的更多的是任务卡、任务墙、燃烧图、燃尽图、投入产出，尽量一切透明可视化。
可视化是让团队中每一个人都明白懂得知道我们要做的是什么，我们要到达的地方是哪里，让团队中每一个人了解项目的进度以及其中存在的问题，我们该如何解决这个拖延团队开发进度的问题，一切大家了然于心，更知道我们每天在奋斗什么。
团队谈的更多的是敏捷对人的要求，团队对团队成员的要求，很好的敏捷推行、自组织的建立都需要拥有一批良好素质的团队成员支持，强调人的因素。
需要团队中每个人都有很大的责任心，并能很好的保持开放、保持很好的交流沟通状态，很好的学习分享精神，坐在一起就是自己人，对团队成员的素质有一定要求的，很好的团队沟通氛围，提高大家的参与度，主人公的精神；
辅导谈的更多的是敏捷推行中敏捷教练的辅导支持，以及团队成员之间的辅导，新老员工的辅导，对团队成员成长的辅导，知识的辅导；
授权谈的更多的是在团队中很好的进行不同个性的人员管理中的对大家授权的支撑，给大家更多的权利，每个人都是项目的主人，每个人都有责任对我们的产品负责。
其中分享了对于在推行敏捷初期，照搬"流程"的困苦，以及后续为了看到成效的调整。如Scrum每日站立会，不再是居于形式，而是真的让大家关注项目，关注项目进度。昨天做了什么？有什么问题？今天做什么？提高大家的关注度的方法一个是通过抛球的形式，随机的指定会议纪要人，随机指定下一个阐述者，大家都会投入这个小小的游戏中，参与度、关注度提升，每个人就更能关心项目中状态。
王威，BoostAgile敏捷教练
分享主题：产品决定成本
1.分享人的心灵状态责备、开脱、羞愧(退出)、义务、责任，你在面对一些事情的时候是处于那种状态，就能很好的检视自己、审视自己；
分享精益开发，可能更多的对于新功能、新产品的孵化，对于用户需求的挖掘，以及挖掘的透彻度，是不是真的给客户带来效益。分享产品的功能的快速迭代、客户的尽早验证可以降低软件开发中的风险。
2.Scrum中的盲点：
Scrum要求人都是有责任心的；Srum要求人都是有能力的；Scrum要求PO对产品有一个很好的产品愿景。
但这三个在现实中推行，都是有很多阻力，而且大多数的团队都不是这种状态，这个也是真的要推行敏捷看看我们所在的团队可否推行敏捷，以及推行敏捷处在的状态，敏捷团队的成熟度。或者如何改进团队更加切合这三种假设，让团队的成熟度很大提高。
3.意启部落
其中的一些观点跟下午Daniel老师(滕振宇)的原型设计中谈论点有很多的相识处，需求调研、需求挖掘、低成本的验证需求、低成本的功能分析、原型的反复确认，是否客户真的需要这个功能，理性的、数据性的证明假设的成立。
如果调研成本、需求验证成本、功能成本大于功能开发成本，就可以直接去开发该功能，用户用于不用都不会造成影响。如果前期投入很大的成本去验证，最后发现不用做了，客户不需要了，而开发的成本只有很小的一部分，那么这个需求调研和验证的成本就可以省掉直接进入开发。之所以有需求调研、验证成本，更多是确定用户需要该功能，也是为了降低开发无用功能的成本，改动的成本。当然，需求调研方法和需求验证方法不一，可能各个方法都有其益处和弊端。如原型就是一种验证手段有时间好好学习一下
佘作传，OPPO项目经理
分享主题：让用户需求清晰起来
1.标准的用户故事
1).标准化格式 作为……，我希望……，以便…… 2).用户故事三要素 用户角色、用户需求、用户价值
2.用户故事分解
1).单一价值 2).规范适中
3.小规模用户故事拆分
1).设计、计划、架构、依赖
单超，中国平安版本经理
分享主题：金融行业后援系统敏捷实践
1.特殊的团队特点
1).金融行业，金融业典型开发团队，从事平安人寿相关业务系统开发和维护工作；
2).后援系统，后援类核心系统，业务复杂，业务关联紧密
3).团队稳健，团队以5年工作经验为主，8-10年老员工5个
2.特殊的系统特点
大型、复杂、老古董
3.实践分享
看板、测试前置、专注、拥抱变化、回顾会议
佘作传老师和单超老师，结合他们在企业的实际项目、实际践行敏捷做了分享，走出不一样的敏捷路线，适合才是最好的。 还有腾讯的王洪涛、陈军组织的抛球游戏，集合大家130人一起做这个游戏，一个简单的敏捷实践的小游戏，以及游戏后的大家体会分享。由最初的预估迭代1的0个球到最后5迭代后的84个，里面有对需求的理解的深入、有计算方法的优化、有自组织团队的雏形、有站立会讨论、有回顾会议等，大家玩的都很高兴。或许一些拓展活动将成为众多企业文化形成、员工凝结力很好的推动形式。
这些分享基于讲师的引导的个人观点，可能对讲师要表达的理解有误，可能存在片面性，希望大牛批评指正。一千个人有一千种思想，一千个听众对主讲内容有一千个理解，每个人的学习、消化、理解能力不一样，如何统一，兼容并包。
五、敏捷思考
用正确的方法做正确的事情；没有最好的，适合才是好的。
使用敏捷思想所倡导的指导性方法，做有价值的事情，真的可以为客户创造价值的事情；在践行敏捷中，吸收其中使用本项目、本团队的使用的方法，改进团队建设，控制软件管理的诟病。
敏捷所倡导的思想是很好的，值得推崇的，敏捷落地实践中有很多不错的方法，是值得学习借鉴的，不要照搬执行，或执行中更多激发团队力量，敏捷更多强调人的因素，需要很好的氛围和环境。敏捷自上而下推广，而又自下而上践行，每个人主人公的精神。
或许敏捷中提供的诸多方法中去很好做好项目管理的“流程”是很好的保障，但并不是所有的都可以推行的，也并不是所有的都可以适合于你目前的团队状态，你的团队敏捷的成熟度，团队的考评，团队的产能。针对不同的团队、不同的项目、不同的公司，践行敏捷的形式不一样，其中的适用性方面也是不一样，或许就是没有最好的，适合的就是好的。
敏捷开发有很多好的思想，有很多优秀的方法实践，还需要好好的学习，简单的敏捷初探，前面还有好长的路子要走，简单记录一下。