敏捷开发

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

敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观： 沟通、 简单、 反馈、勇气，此外，还扩展了第五个价值观：谦逊。

敏捷开发是针对传统的 瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

沟通

建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。

简单

画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。

反馈

Kent Beck在Extreme Programming Explained中有句话讲得非常好：“过度自信是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。

谦逊

最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。

------------

核心原则

◆主张简单

当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建

敏捷开发

（overbuild）你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的 建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。

◆拥抱变化

需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

◆你的第二个目标是可持续性

即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现Project stakeholder的需求，其中就包括你的系统应该要有足够的 鲁棒性（robust ），能够适应日后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到未来。

◆递增的变化

和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。

◆令Stakeholder投资最大化

你的project stakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。

◆有目的的建模

对于自己的artifact，例如模型、 源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。你不应该毫无意义的建模，应该先问问，为什么要建立这个artifact，为谁建立它。和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你需要和高级经理交流你的方法，也许你需要创建描述系统的文档，使其他人能够操作、维护、改进系统。如果你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。一旦一个模型实现了目标，你就可以结束工作，把精力转移到其它的工作上去，例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型：如果你要做一些改变，也许是一个熟知的模式，你应该有做出变化的正确理由（可能是为了支持一项新的需求，或是为了重构以保证简洁）。关于该项原则的一个重要暗示是你应该要了解你的受众，即便受众是你自己也一样。例如，如果你是为维护人员建立模型，他们到底需要些什么？是厚达500页的详细文档才够呢，还是10页的工作总览就够了？你不清楚？去和他们谈谈，找出你想要的。

◆多种模型

开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应

敏捷开发

用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，你的建模 工具箱应该要包容大量有用的技术（关于artifact的清单，可以参阅AM的建模artifact）。有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型。不同的系统使用不同部分的模型。比如，和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具。又比如，你可能会比较喜欢某些工具，同样，你可会偏爱某一种模型。有多少的建模 artifact可供使用呢，如果你想要了解这方面的更多细节，我在Be Realistic About the UML中列出了UML的相关部分，如果你希望做进一步的了解，可以参阅 白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。

◆高质量的工作

没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。

◆快速反馈

从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。

◆软件是你的主要目标

软件开发的主要目标是以有效的方式，制造出满足project stakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。

◆轻装前进

你建立一个artifact，然后决定要保留它，随着时间的流逝，这些artifact都需要维护。如果你决定保留7个模型，不论何时，一旦有变化发生（新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术...），你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型，很明显，你实现同样的改变要花费的功夫就少多了，你的灵活性就增强了，因为你是在轻装前进。类似的，你的模型越复杂，越详细，发生的改变极可能就越难实现（每个模型都更“沉重”了些，因此维护的负担也就大了）。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处（所以才需要加强团队之间，团队和project stakeholder之间的沟通）。千万不要小看权衡的严重性。一个人要想过沙漠，他一定会携带地图，帽子，质地优良的鞋子，水壶。如果他带了几百加仑的水，能够想象的到的所有求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？同样的道理，一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。

-----------

工具

Visual Studio Team Foundation Server

TFS，即团队基础服务器是微软应用程序生命周期管理服务器，用于帮助团队在Visual Studio的协作开发。最近，它进有了升级包括工作项目执行改进、富文本编辑器的改进，以及富文本编辑器中改善的超链接体验。 TFS中的Kanban面板也做了改善，提升了可以录入和跟踪的项目数量，该服务器现在有一个“利益相关者”许可，来规范服务器的访问权限。

Atlassian Jira

Atlassian的是一个很流行的工具，主要用于跟踪产品开发、帮助团队整理问题、安排工具，以及记录团队行为。它Jira Agile插件使开发人员更容易部署关键敏捷策略，这包括用户故事开发、冲刺模块构建，以及可视化的团队活动。

Axosoft

Axosoft以前被称为Axosoft OnTime Scrum，这一软件套件有四个功能模块：Scrum、Bug追踪器、帮助台和Wiki。它是基于HTML5构建的，帮助开发团队管理待办事项列表、发布和冲刺，带有燃尽图功能，有一个 管理仪表板用于跟踪编码和修改BUG的时间。

LeanKit

使用 LeanKit的团队可以看到工作负载的分布并导出历史数据。最近 LeanKit 进行了一次升级，包含单点登录功能 和附加报告功能，从而提供更细粒度的数据详细信息。

Planbox

Planbox 敏捷管理工具通过燃尽图跟踪进程，集成客户反馈，它的目标人群很广泛。最近它对应用的前端和后端都做的升级，添加了更强大的报告功能和新仪表盘，来提升项目速度。时间跟踪特性和工具允许用户得到所有他们在Planbox产生的数据。

-----------

敏捷模型是足够正确的。模型通常都不需要100%正确，只要足够正确就行了。举个例子，如果一张街道地图漏画了一条街道，或是它标示某条街道是通行的，但你发现它已经关闭维修了，那你会不会扔掉你的地图开始在城里飙车犯罪呢？不太可能。你会考虑更新你的地图，你可能会拿出笔来自己做修改或是去当地的商店买一张最新版的地图（你原来的那张过期了）。也许你还是会接受那张虽不完美仍可使用的地图，因为它对你来说已经足够好了。你还是可以用这张地图四处转转，因为它还是个正确的模型，标记出了大部分街道的位置。你在发现这张地图不正确的时候，你没有立刻扔掉它，原因是你根本不在乎它是否完美。类似的，当你在需求模型、数据模型中发现错误的时候，你也会选择更新或是接受－－虽不完美但已经足够好了。有些项目成员能够容忍这种不正确而有些则不能：这取决于项目的特性，每个团队成员的特性，组织的特性。充分正确性既和模型的听众有关，也和你要处理的问题有关。

----

误区一

建模就等于是写文档

这很可能是其中最具破坏力的一条，因为开发人员可以此为借口而完全放弃建模。许多优秀的软件开发人员会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中，制造着一些脆弱而劣质的系统。

事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的—你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型，而不论是被画在 餐巾纸的背面，或写在一块白板上，或在Class Responsibility Collaboration(CRC)卡片中，还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档，但他们却都是有价值的模型。

建模很象是作计划：作计划的价值在于计划编制的过程中，而非计划本身；价值体现在建模的活动中，而非模型本身。实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常完美。

误区二

从开始阶段你可以考虑到所有的一切

这种说法流行于二十世纪七十年代到八十年代早期，现今的许多经理都是在那个时候学习的软件开发。对这一点的迷信会导致在前期投入可观的时间去对所有的一切建模以期把所有一切都弄正确，试图在编码开始前就“冻结”所有的需求（见误区四），以致于患上“分析期麻痹症” – 要等到模型非常完美之后才敢向前进。基于这个观点，项目组开发了大量的文档，而不是他们真正想要得到的—开发满足需要的软件。

事实分析：怎么才能走出这个误区呢？首先，你必须认识到你不能考虑到所有的细枝末节。第二，认识到编码员可能会对建模者的工作不以为然（这是可能的，事实上建模者所作的工作在实际价值中只占很少的部分），他们或许会说模型没有反应出真实的情况。第三，认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己建模自己编码。一个基本的道理就是代码永远只会和代码保持一致。第四，认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过程（如EUP），以及轻量级（如XP）的基本原理。

误区三

建模意味着需要一个重量级的软件开发过程

走入这个误区（经常与误区一有联系）的项目组常常是连建模都彻底地放弃了，因为这样的软件开发过程对他们来说太复杂太沉重了。这不亚于一场天灾。

事实分析：你可以用一种敏捷的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM）。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行建模（比如，从办公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地建模。

误区四

必须“冻结”需求

这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上所需要的。

事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。

误区五

设计是不可更改的

如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。

事实分析：事实上，设计会经常根据开发人员和 数据库管理员的反馈进行修改，因为他们是最接近实际应用的人，通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实：人无完人，他们所作的工作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确的态度是：只要你的代码还在改动，设计就没完。

误区六

必须使用CASE工具

建模常常被认为是一项复杂的工作，因此需要大量地使用CASE工具辅助进行。

事实分析：是的，建模可以是很复杂的。但你完全可以建立一个有效而简单的模型表述其中关键的信息，而不是将一些无关紧要的细节包括进来。

误区七

建模是在浪费时间

许多新手都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。

事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的理解，涉及到该项目中的每个成员也可得到对该项目有一个充分的了解。

误区八

数据模型（Data Model）就是一切

许多组织基于数据模型就蹒跚启动新的开发工作，也许正如你所在的组织：IT部门对于数据有非常严格的规定，控制着你的开发项目；或者你以前的数据库是一团糟，别无选择。

事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。（参见“Extreme Modeling”，Thinking Objectively，Nov.2000）。这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的（在数据模型中没有表示出来），这些项目经常是以可悲的失败而告终。你可以使用的模型有很多 – 使用案例（use cases）， 业务规则（business rules），activity diagrams，类图（class diagrams），component diagrams，用户界面流程图（user interface flow diagrams）和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。

误区九

所有的开发人员都知道如何建模

面临这样一个严重的问题：许多不是开发人员的人，不知道软件是如何建成的。其结果，他们不能够区分开熟练的开发者和一般的程序员（当然也分不清高级程序员和一般程序员），他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。

事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，毕竟他们终究只是程序员。正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发者应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短，建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。我个人认为所有的人，包括我自己，都是新手。

-----