敏捷开发

面向对象开发方法无疑是当前最流行的软件开发方法。这归功于面向对象开发的众多优点：可靠性高，所开发的程序更健壮;由于面向对象编程的可重用性，可以在应用程序中大量采用成熟的类库，从而缩短了开发时间;继承和封装使得应用程序的修改带来的影响更加局部化，应用程序更易于维护、更新和升级。另外，UML建模语言和Rosc等CASE工具为面向对象的流行也起了很太作用，这些工具允许应用规范的面向对象分析和设计的方法与理论，远离纠缠不清的源代码，使得构建和设计变得更直观、更容易理解与修改，从而大大提高开发效率。

“天下事头绪纠缠，兴一利必也生一弊。” 　　一句话，道破了改进难点所在。最近在项目中围绕持续集成做改进的时候，对这一点感受颇深。跌跌撞撞的一路走来。我们的持续集成的过程已经变得有些“个性化”，反过头来看我们一路的变化，非常有意思。

SaaS已经成为软件业发展的新趋势，甚至将成为未来10年软件业的制高点。有分析指出，2009年将有半数开发者将转向SaaS平台的应用开发。开发者该如何转向SaaS平台？SaaS应用与传统软件开发有那些区别？

维护代码是程序员的日常工作，这个工作做得好坏与否直接关系到一段代码的生命周期。本文列举了程序员在维护代码时常犯的六大错误，以便大家参考学习。

在实施敏捷项目的组织中，人们要想在项目间分配人力，经常面临这方面的挑战；本文提供一些敏捷项目中高效资源管理的方法。

S.M. Kripanidhi感到现有的敏捷认证体系差强人意，给出了“社区认证敏捷实践者”的提议。这样的认证价值何在？Kripanidhi列举出一堆理由,让我们详细来看一下。

敏捷软件开发，实际上，也是一种开发方法。我知道，大家一听到开发方法，都会感觉头痛的。一方面，作为学生，开发方法这种东西，只是在软件工程的课程上听说过，-而自己实际的经验又不多，另一方面，提起方法学，本身显得很抽象，比较理论化。但实际上，所谓开发方法，其实就是一个解决问题的过程。比如说，遇到一个问题，我-们要分析问题，然后动手解决，最后还要检查一下解决得是否正确，对应到软件开发中，这就是需求分析、开发和测试等阶段。

敏捷开发中的成效评估模型可以使敏捷团队将关注点放在可发布的产品上，而不是被传统铁三角限制住。在敏捷开发中，价值、质量、约束构成新的“敏捷三角形”。

S.M. Kripanidhi感到现有的敏捷认证体系差强人意，给出了“社区认证敏捷实践者”的提议。这样的认证价值何在？Kripanidhi列举出一堆理由,让我们详细来看一下。

本文作者和大家分享了如何使用敏捷教条对管理方面的问题进行分析，如何采取合适策略来解决对下属的工作处理问题。

架构师象牙塔的根基已经被动摇了。新一类的“敏捷架构师”正在逐步涌现出来，并与团队一起工作，为团队做贡献。

SOA是用来描述一种特定的软件结构的词汇。更多的是为了让市场上大家明白这种软件结构，而敏捷方法是一种方法学，是用来构造软件的一种方法。

本文分析了选择敏捷方法时应该考虑的事宜。选择敏捷应该是有目的性的，旨在解决项目中一些现存的问题。现在可选择的敏捷方法很多，要分析需求之后再选择合适自己项目的。

敏捷开发本质上是一种开发理念与开发方式，它对开发工具没有任何强制性的要求。但工欲善其事，必先利其器，好的开发工具对于敏捷开发会起到事半功倍的效果。本文介绍了Jazz这个很好的支持敏捷开发的工具。

敏捷原理其实不复杂，但实践起来比较难。Scrum作为敏捷方法中的一个重视主流，它的流程简单，但是想真正实践好确很复杂。本文将简单介绍敏捷开发中的Scrum流程和术语 。

敏捷思想就是那四条敏捷宣言和十二条基本原则，很抽象也很乏味。本文将给出作者自己的一些独到见解。希望能对大家理解敏捷有所帮助。

合同是不同机构间的粘合剂，但传统的合同是基于“不信任”和“自保”哲学，而且定额合同也未考虑软件开发的不确定因素。在工作中，你是用敏捷合同还是传统合同？那又该如何运用它？是感觉还行呢，还是感觉哪里有点不对味？

本文通过简单通俗的例子，告诉我们如何判断代码的稳定性和代码中的异类，并且如何重构此类代码。

设计者-开发者工作流（designer-developer workflow）这个词已经流行了好几年。它描述了设计人员、开发人员在为Web或桌面应用创造交互体验过程中的关系，而没有表达出设计者、开发者之间的交互和协作。工作流这个术语让我们觉得这种关系是线性的，但实际上它不是。

极限编程是敏捷开发过程的重要方法之一。这个概念于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导，由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。