敏捷开发

每个组织都喜欢吹捧其敏捷性，尽管事态并没有很快发生。当组织宣称是敏捷的，但实际上并非如此时，架构师就陷入了两难的境地。可以使用五个关键预测指标发现组织是否缺乏真正的敏捷性。了解这些预测指标，并获得帮助组织往更敏捷的方向推进的技巧。

复杂用户界面开发（本文用作UI开发），为敏捷开发提供了某些独特的挑战。与那些功能大部分是自动运行业务规则或计算薪水的项目不同，因为由用户培训或生产力缺失引起的各种问题，UI开发项目往往不能承受剧烈的变动，尤其是那些经常被使用的应用程序（如呼叫中心、E-mail阅读器或数据登记系统等）。

中国市场是目前世界上变化最快、增长最快的市场。在这种情况下，企业级软件自然也要应对适应迅速变化的要求，于是，在中国，软件开发所面临的挑战不是比别人低，而是更高：开发成本太高，需求变化又频繁，如何在这种情况下保证软件的质量？为了解答这一问题，以及由此而来的一系列人才培养、方法论、工具选择等困惑，中国计算机报执行总编卢山与世界软件开发领域的教父马丁.福勒，进行了一次促膝长谈。

如何从软件工程的角度，通过采用适当系统设计方法和加强项目管理来解决需求不断变化的问题，是各个软件开发商的一个重要课题。通过实践，感到采用敏捷方法的基本思想和原则来设计系统和处理需求变化问题，能够产生较好的效果。

瀑布模型、极限编程、敏捷开发是有代表性的开发模式，在对开发者、客户、最终的产品的关注上的变化，体现了软件开发管理者在管理模式上的变化。

近年来软件过程改进在国内日益得到重视，一度出现了许多组织纷纷开展 SW-CMM 商业评估的热潮。迄今全国已有近两百家软件企业通过了 SW-CMM、CMMI 各级评估（1 2 3）。这一方面说明原本作为美国军方标准（如今已成为全球通行的国际标准）的 SW-CMM、CMMI 并非高不可攀，另一方面也说明加强软件开发规范化管理、提高过程成熟度已经得到了业界的广泛认同。

一些IT人在畏惧敏捷，但管理阶层应该去调研敏捷的真相。

由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM方法最初实践于Easel公司(1993年)，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。

1991年秋，在美国勒海大学亚科卡学院的一份研究报告《21世纪美国制造业的战略：一个工业主导的观点》中，首次提出了敏捷竞争的概念.而今天，我们似乎已经看到，敏捷已经在我们身边，形影不离。

关于敏捷和CMM，以及怎样在CMMI的框架下有效的引入敏捷的开发，是我所一直关注的话题，最近在网上闲逛，看到ThoughtWorks总经理郭晓在软博会上的演讲，觉得讲得不错。

AM的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

敏捷建模（AM）在AM原则的基础上定义了一组核心实践（practice）和补充实践，其中的某些实践已经是极限编程（XP）中采用了的，并在Extreme Programming Explained一书中有详细的论述，和AM的原则一样，我们在描述这组实践时，将会注重于建模的过程，这样你可以从另外一个角度来观察这些已或XP采用的素材。

敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模a href="practices.htm">实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。

我坚信当在描述事物的范围时，你需要说明它是什么，它不是什么。不管你谈论的是系统还是案例中的AM都一样。

用白板解决项目管理和团队沟通

软件项目开发的核心资源就是人，在一定的项目规模和资本规模下，人的资源是受限的。项目中考虑人的资源常常以人数来计，但是实际中我们都清楚，工作量是以任务来分解和总和的。这就说明人和任务之间存在一个关系，这个关系就是角色。

项目计划告诉了我们要如何去完成项目，但是项目计划的执行并非总能够沿着预定的轨道前进。可以肯定地说，如果没有健全的反馈机制，计划的执行定然会偏离预定的轨道，而唯一能够确避免的措施就——追求项目计划执行中最细致的项目跟踪，在计划的执行稍有偏离的时候就纠正其方向，这在控制理论中，就是基于反馈的控制。

对于什么是&ldquo质量&rdquo有很多的定义，&ldquo质量是由旁观者定义的&rdquo，有些人会说这是不可能使用的定义，因为它很难在真正的业务场景中工作。但是敏捷方法不同意。敏捷方法就是用这种方法让产品的质量由顾客塑造。他们承认不同的人会用不同的观点看问题，所以对于项目来说谁的观点最能说了算（最终顾客）就是敏捷方法要追求的。

要想了解AM，你需要了解模型和敏捷模型之间的区别。模型是一个抽象的概念，它描述了一个的问题的一个或多个方面，或是处理这个问题可能的解决方案。传统意义上，模型被认为是图表加上相应的文档。然而那不够直观的artifact，也可以被视为模型，例如CRC卡片集，单条或多条业务规则的文字描述，或是业务流程的一段结构化英文描述。

敏捷建模不是万能的，它并不适合于每一个人、每一种情况。即使是你的条件非常适合于AM，也不能保证它就能良好的运行——你在组织内实施AM时还是有可能犯下错误。