前沿讲座心得体会

北京邮电大学软件学院。

前沿课题讲座心得体会。

报告人：学号：

导师：日期：2015 年 1月20日）

在北京邮电大学软件学院学习期间，我积极参加学校组织的前沿课题讲座和各大企业举办的新技术讲座，下边分几个方面谈一谈对敏捷开发、自动化测试、大数据讲座的体会：

一、敏捷开发。

最近一段时间以来，很多人开始谈论敏捷开发、研究敏捷开发，那么究竟什么才是敏捷开发呢？

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。

敏捷开发(agile development)概念从2023年初开始广为流行。bailar非常支持这一理论，他采取了"敏捷方式"组建团队：capital one的"敏捷团队"包括3名业务人员、两名操作人员和5～7名it人员，其中包括1个业务信息指导(实际上是业务部门和it部门之间的"翻译者");另外，还有一个由项目经理和至少80名开发人员组成的团队。

这些开发人员都曾被bailar送去参加过"敏捷开发"的培训，具备相关的技能。

每个团队都有自己的敏捷指导(bailar聘用了20个敏捷指导)，他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3～4次，以评估过程及决定需求变更是否必要。

在capital one，大的it项目会被拆分成多个子项目，安排给各"敏捷团队"，这种方式在"敏捷开发"中叫"蜂巢式(swarming)"，所有过程由一名项目经理控制。

为了检验这个系统的效果，bailar将项目拆分，从旧的"瀑布式"开发转变为"并列式"开发，形成了"敏捷开发"所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行"冲刺"--每个冲刺始于一个启动会议，到下个冲刺前结束。

在bailar将其与传统的开发方式做了对比后，他感到非常兴奋--"敏捷开发"使开发时间减少了30%～40%，有时甚至接近50%，提高了交付产品的质量。"不过，有些需求不能用敏捷开发来处理。" bailar承认，"敏捷开发"也有局限性，比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构中却不能排列出三者优先级的需求。

此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让cio受益匪浅。

二、敏捷开发模式内容。

test-driven development，测试驱动开发，它是敏捷开发的最重要的部分。在thoughtworks，实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的story，记录在story card上。然后两个人同时坐在电脑前面，一个人依照story，从业务需求的角度来编写测试**，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试**就真实反映了业务功能需求。

接着由另一个人控制键盘，编写该测试**的实现。如果没有测试**，就不能编写功能的实现**。先写测试**，能够让开发人员明确目标，就是让测试通过。

continuous integration，持续集成。在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。

一次集成要做哪些事情呢？它至少包括：获得所有源**；编译源**；运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。

当然也会做一些其它的任务，比如说**分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的**是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。

有很多很多的书用来介绍重构，最著名的是martin的《重构》，joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得**尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在**进行重构整理。

但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in**之前，都要对所写**进行重构，让**达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现**进行重构，如果测试**中有重复，也要对它进行重构。

pair-programming，结对编程。在敏捷开发中，做任何事情都是pair的，包括分析、写测试、写实现**或者重构。pair做事有很多好处，两个人在一起**很容易产生思想的火花，也不容易走上偏路。

stand up，站立会议。每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：

1. 你昨天做了什么？2.

你今天要做什么？ 3. 你遇到了哪些困难？

站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。

frequent releases，小版本发布。在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。

正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。

minimal documentation，较少的文档。其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试**真实的反应了客户的需求以及系统api的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试**，而比一边看着文档一边进行debug要高效。

如果用书面文档或者注释，某天**变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现**和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，**才会变化，测试是真实反应**的。

这时有人会问：**不写注释行吗？一般来说好的**不是需要大量的注释吗？

其实简单可读的**才是好的**，既然简单可读了，别人一看就能够看懂，这时候根本不需要对**进行任何注释。若你觉得这段**不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。

collaborative focus，以合作为中心，表现为**共享。在敏捷开发中，**是归团队所有而不是哪些模块的**属于哪些人，每个人都有权利获得系统任何一部分的**然后修改它，每个人都能够对这部分**重构而不需要征求**作者的同意。这样每个人都能熟悉系统的**，即使团队的人员变动，也没有风险。

customer engagement ，现场客户。敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。

敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。

三、自动化测试。

automated testing ，自动化测试。为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对qa人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。

在自动化测试过程中，ui的自动化测试实施难度比后台程序的自动化要大，那么ui自动化测试是怎么做的呢？首先需要用一个持续集成的工具hudson作为一个颗粒度比较粗的测试用例管理工具，hudson作为自动化测试的主心骨，qa们可以在hudson上触发自动化测试的运行，运行完了以后可以看到测试结果，并且，利用了hudson的分布式结构，由多个测试机来执行测试，达到了很好的资源调配。对浏览器的控制方面，用了selenium，会上没有问ui是否利用了selenium的多浏览器支持，从演示上来看应该只做的firefox的。

他们的分工很明确，分了专门做功能测试的qa和专门做自动化测试工具开发的sdet，sdet主要是负责写ruby**，封装并且暴露了一些通用的方法给qa使用，并且同时使用了cucumber作为一个dsl，qa是用cucumber来做自动化测试的一些描述，cucumber的作用就是对功能测试的qa屏蔽了底层ruby脚本，对上就是“翻译”功能测试qa的意图，“翻译”成ruby。优点在于：分开了自动化测试工具开发和自动化测试实施；使用了大量开源工具，提高效率；在测试过程中我将这个方式加以运用，提高了测试技术。

自动化测试是软件测试发展的一个方向。很多人都认为做测试，懂得自动化测试是很重要的。我之前用qtp的时候，给自己最大的感触就是录制脚本和调试脚本的时间太长了。

通过一些讲座和交流，我对自动化测试和脚本的录制修改技巧慢慢熟知，大大提高了自动化测试设计的效率。测试是一个思考的过程，自动化测试是测试发展的必然趋势，所以在自动化测试的运用之中我还是有很多需要学习的内容。

四、大数据。

现在，当数据的积累量足够大的时候，量变引起了质变，“大数据”通过对海量数据有针对性的分析，赋予了互联网“智商”，这使得互联网的作用，从简单的数据交流和信息传递，上升到基于海量数据的分析，一句话“他开始思考了”。简言之，大数据就是将碎片化的海量数据在一定的时间内完成筛选、分析，并整理成为有用的资讯，帮助用户完成决策。借助大数据企业的决策者可以迅速感知市场需求变化，从而促使他们作出对企业更有利的决策，使得这些企业拥有更强的创新力和竞争力。

这是继云计算、物联网之后it产业又一次颠覆性的技术变革，对国家治理模式、对企业的决策、组织和业务流程、对个人生活方式都将产生巨大的影响。后工业社会时代，随着新兴技术的发展与互联网底层技术的革新，数据正在呈指数级增长，所有数据的产生形式，都是数字化。如何收集、管理和分析海量数据对于企业从事的一切商业活动都显得尤为重要。

前沿讲座心得体会

交通前沿讲座心得体会03前沿讲座心得体会王兴华

交通前沿讲座心得体会专业前沿讲座心得体会

交通前沿讲座心得体会学科前沿讲座心得体会报告田骄

其他用户还读了