敏捷开发

在08年的STP第6期杂志，Glenn Jones在《Fly into agile development with agile testing》一文中把敏捷开发中的测试分为7种类型

这是一个真实的故事。故事中，作者作为一个项目的负责人，因为初期过于迎合客户，而放弃了对一些基本原则的坚持，最终导致项目进行中被迫进行大改动。而改动过程中，通过引入敏捷开发而将损失降到了最低。

在08年的STP第6期杂志，Glenn Jones在《Fly into agile development with agile testing》一文中与我们分享了他们的敏捷项目中的持续构建的做法

敏捷建模思想，是由以下一系列文章组成：敏捷建模的价值观、敏捷建模的原则、敏捷建模的实践等

Michele Sliger是《软件项目经理的敏捷之路》一书的编者和顾问，本文总结了她对如何做好敏捷项目经理的一些观点和建议。

Ryan Martens是Rally公司的创建人和CTO。他在帮助企业从传统开发过程转向敏捷开发方面有着丰富的经验。面对影响到每个企业的经济危机，他从敏捷开发的角度对正在为预算发愁的公司经理和企业主管们提出如下建议。

在要求项目要尽量快地实现的时候，质量与开发进度上会出现一定的矛盾，最突出的就是单元测试代码与逻辑实现代码。

本节是如何构建敏捷性SOA的第四部分，在这一节里，我们将主要研究一下IT运营、监测和性能。

如著名市场研究机构Forrester的Cary Schwaber所说的那样，最新的ALM平台将会改善开发过程，向应用工具提供普通服务。这一代的ALM软件在将需求、测试案例、bug跟踪和问题解决方案整合到一个应用套件中做了更多的工作。下图就简单说明了共享测试过程并把它作为协作资产。

在过去，TM（测试管理）工具中使用的测试“脚本”实际上主要是一步一步的指令（保存在Word或Excel文档中），手工测试人员通过按照这些指令点击一个已经完成的界面完成测试。当测试工作完成以后，测试人员需要检查测试管理用户界面的“检查框”，从而确认测试是成功还是失败了。

一直以来，测试是都是应用生命周期的一个单独活动，使用不同并且没有关联的工具。首先，开发团队会运行一套JUnit测试套件，作为建设过程的一部分。然后，质量保证团队会手动创建并运行了一套针对用户界面的功能测试。

最近听到了很多关于软件质量的话题，自己前段时间也参加个PMP(项目管理)的培训，所以一时对于质量控制特别感兴趣，在这里想和大家共同讨论下！软件质量，是所有人都很关心的东西。我们在开发过程中为了保证质量，从中引进了软件测试。它在整个的过程中起到的作用不言而预，但是它也存在一些问题。

在这篇文章里，我们将同时使用敏捷教练（Agile Coach）作为协作主管（ScrumMaster）的同义词。因为要提高团队的效率，协作主管和敏捷教练都必须深入团队、传授实践并体现教练的作用，所以在本文中我们只使用敏捷教练这一术语。请注意：本文中提及的失败（及修复）模式对协作主管和敏捷教练都适应。

并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。

谈到敏捷，人们往往都非常高调地打探TDD与持续集成。同时很多实践，非常低调。比如，估算。学习TDD，你有很多具体例子可以学习。但是学习估算，却无从下手。在“搞砸”了几个项目之后，貌似我摸着了一些门道了。

除了命令行接口、单元测试工具和3×5的索引卡片，敏捷软件开发人员通常还会使用其它各种各样的专业工具。根据某网站发布的2008年敏捷趋势调查报告，按“重要级”排列依次是需求管理工具（56%）、Bug追踪工具（51%）、项目管理工具与单元测试工具（各占45%）。此外，常用工具还包括功能测试、持续集成构建、协作、配置管理和文档管理工具等。

敏捷开发关键在于，能够“敏捷”地适应项目的变化，而不是在开发阶段去适应需求变化。

有人强调敏捷的要素是迭代，那是完全错误的，迭代式开发是RUP的核心实践，而且它远在RUP出现以前就已经存在了。

Scrum作为敏捷方法之一，在十多年前由Ken Schwaber和Jeff Sutherland共同提出，名称来自英式橄榄球，用Scrum来类比软件团队在软件开发所展示出来的速度和灵活性。

ThoughtWorks近日推出了其测试资源共享社区testing.thoughtworks.com网站。testing.thoughtworks.com网站提供流程、实践、测试理念、以及如何在项目中实施高效测试等方面的经验分享，使人们了解测试的重要性，并为知识的共享搭建平台。