敏捷开发

在最近的一篇文章中，Martin Fowler尝试探索演进式设计——一种极限编程的常用实践——对于SOA实现的适用性。他从两种常用的设计范型（计划式和演进式）着手开始讨论。

当我们提起工作量估计的时候，我们会碰到同样的问题，我们如何来做估计？有什么方法可以遵循呢？如何估计才更准确？我对某个功能做了估计，但它超出了预计的开发时间，为什么？

Scrum的三个法宝: Product Backlog, Sprint Backlog 和Burndown Chart.

Scrum有三个仪式：Sprint规划会，Sprint评审会，Scrum每日站会

敏捷就是一个团队持续不断的自我改进过程，直到那些优秀的品质成为大家的一种职业习惯——一个自组织的团队。敏捷没有终点，我们一直在路上。

各类大中小型企业所运用的传统软件构建方法，即是众人皆知的“瀑布”型开发方法。此模型存在很多变体，但其典型性是在开发初期制定详细的计划，在计划中最终产品己被仔细研究，设计，并且一切详细资料都记录在案。

在那些最简单也最常谈起的敏捷实践中，每日站立会议（又称作每日例会）就是其一。 Jeff Martin在scrumdevelopment Yahoo!邮件组中问道：我搜索过相关知识却一无所获，我想我一定是用错了词。谁能给我一个每日例会的范本？我们遇到些困难，导致有些团队成员想取消会议，或是一周只开两次会。

scrum不是万灵药，不可能解决所有的问题。但是如果你要使用scrum，在完全领会它之前，最好按部就班的执行scrum要求的每个步骤，遵守每个原则，至少可以少走一些弯路。

Scrum的关键就是确定我们想完成产品或者版本发布的日期、确定功能的优先级、确定可用资源以及做出体系结构方面的主要决定。与更传统的方法学相比，Scrum计划阶段比较短。Scrum使用一种用于开发的经验方法，在此法中不仅允许而且鼓励与环境进行交互。改变范围、技术和功能是在意料之中的，而持续的信息共享和反馈保持了高度的性能和信任。Scrum的应用同样也产生了一种具有良好定义的角色和关系的浓厚文化。

毫无疑问，敏捷开发方法正在大举进军今天的企业，但是通往敏捷的道路却是崎岖的。它更像是一条多车道的高速公路，各种类型的司机们都在选择各自适合的路线向目的地进发。最近，某网站组织了2008年敏捷趋势调查，结果数据显示，瀑布式开发方法并非总是到达目标的捷径。

Borland公司正在采用敏捷开发作为其软件交付策略的核心原则，以加快应用开发及成本节省。

SOA不仅仅只是一套构架，其更像是一套设计思想、方法。为解决客户所面临的业务敏捷性问题提供了一套新的解决方法。

近日，市场研究机构Forrester发布对ThoughtWorks敏捷开发方法的总体经济影响的研究报告。研究结果表明，ThoughtWorks的敏捷开发方法能够有效为客户降低项目成本，提高IT效率。

全球性IT咨询和软件公司ThoughtWorks近日正式发布Cruise通用版。该产品是一款持续集成和发布管理的工具， 让用户可以监控某个应用从最初的代码检入到功能测试、性能测试、用户验收测试、上线试运行与正式发布运行整个过程的变化，从而帮助敏捷开发团队更加自信地发布软件。

关于敏捷开发的文章很容易给人留下这样的印象：构架并不重要，它只是偶然形成的一个晦涩的词语而已。本文则要解释的正是架构的重要作用、它在开发周期中的意义、它与开发人员的关系，以及对系统成本消耗的影响。

一个有实际应用价值的敏捷过程并不是简单地照章办事就可以实现。敏捷方法的采用，既要使敏捷方法适应一个环境，也要调整环境使其有更好的敏捷性和响应性。

希望尝试XP的团队经常不知道从何开始。通常他们有太多关于XP的问题。但技术之后将是什么呢？这个月，Roy Miller结合理论和实践来讨论您应使用什么工具以及如何使用它们。

CMM 基本上是 15 年之前比较传统、陈旧的东西，现在我们更多地应该拿 CMMI-SW 与 Agile 进行比较。目前有关 CMM/CMMI 与 Agile 比较的最权威的一本名著是：Barry Boehm 与 Richard Turner 大师的 Balancing Agility and Discipline: A Guide for the Perplexed（BAND）。CMMI 到底与 Agile 有何不同？我向国内每一位软件项目经理、架构师和过程改进相关负责、研究人员推荐这本必读之作。

Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。

方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。