敏捷开发

软件开发项目的失败使得人们开始思考软件开发的过程，人们希望通过引入严格的过程控制产生软件生命周期中各个阶段的文档和制品来保证软件的质量。比较出名的业界实施方法论有 cmmi （能力成熟度模型）和 rup （瑞理统一过程），这些方法论都是重型的。

当我们在撰写新书Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum中“组织”一章的时候，我们请教了一批大型企业的敏捷开发专家，什么是他们组织在敏捷改进、实施过程中遇到的最大障碍。我们将这些专家的回答汇编成了以下清单，取名为敏捷改进/实施的“十大组织障碍”。

敏捷建模的目的是为建模和文档构建描述一组原则和实践，最好是用于敏捷项目中。但如果它们不是那么敏捷也没有问题。

方法和过程是相对独立的两个概念，例如OO方法既可以用于瀑布式过程也可以用于迭代式过程。《净室软件工程：技术与过程》，分别讲技术(方法的近义词)和过程。讲OO的书很多，一般都不讲过程。本质上Agile是过程。在Agile Software Development一书中，有一个十三个要素的模型，一看便知是个过程“元模型”。

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

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

CMMI和敏捷的一些对比

我经常和别人一起讨论敏捷开发过程的知识，并且我们也会经常争论结合使用敏捷开发过程和CMMI高级别的话题。他们两个是否能够结合使用？或者他们两个只是向相反的方向发展？带着这个疑问，下面我们一起来探讨。

敏捷开发方法所面临的最大的挑战就是开发人员声称自己遵循了这种方法，而实际上他们并没有这么做。当他们运作出了问题的时候，他们就会去责备方法不好，但其实他们根本就没有真正遵循过这些方法。

CMMI环境下，该如何实施Agile？“只要本着‘积极思考，消除浪费’，没有必要把敏捷挂在嘴边，不要对立，而去实践，在实践中不断调整”就是在CMMI环境下实施Agile的要点。

Borland从06年2月开始项目试点，想看看敏捷方法能不能帮助他们达成三个核心目标：缩短交付时间、增强整体生产力、鼓励客户参与开发过程，从而确保产品可以满足市场需要。这个项目非常成功，团队提前十天交付了项目，而且比一开始计划的时候增加了很多新特性。

对于软件开发来说，源于丰田生产管理系统中的“看板系统”是一种用于安排工作的非迭代方法。它并不使用固定时长的迭代和计划会议的工作方式，而是完成先前的工作后才从backlog中取得新的故事来做的工作方式。

微软最近在“模式及实践”分类下发布了一篇文档，名为“如何用敏捷架构进行设计”，为如何使用敏捷方式进行架构提供了详细的指导。

James Shore声称敏捷正在走向衰落。他说，很多团队在用“sprints”和每日例会，但是却不采用那些可以在长期内产出高质量软件的技术实践。在他的估计中，已有无数个Scrum团队将敏捷用的如此之烂，不仅失败已成必然，而且会将敏捷的发展跟他们一起拖入泥潭。

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：个体与交互 重于 过程和工具可用的软件 重于 完备的文档客户协作 重于 合同谈判响应变化 重于 遵循计划在每对比对中，后者并非全无价值，但我们更看重前者。

当谈论敏捷时，大家常常倾向于谈论那些人们每天都在做的有形的事情，比如“敏捷过程”。其实，相对“过程”而言，真正的敏捷更多的是强调“原则”。Travis Birch对敏捷中那些非实体内容之一——“诚实”进行了阐述。

InfoQ的一篇题为“敏捷遭遇实效营销”的新闻指出：敏捷方法不是产品开发中的银弹。当然我们早就知道没有银弹，但仍然有必要强调一遍，尤其是在这个敏捷方法在中国逐渐开始热门的时候。

在这一系列文章中，我们主要看看敏捷生命周期的四个方面：测试和质量管理、应用生命周期管理、IT业务、监测和业绩、IT和SOA治理。但首先，让我们先来看看经常遇到的主要应用过程工具。

本次沙龙希望通过话题讨论和主题演讲，大家共同讨论中小型项目管理的难题是什么，是需求获取、资源获得还是测试管理；专家分享中小型项目在开发实施过程中，应该如何管理项目、整合资源，并最终保障成功交付，其中又有哪些好的工具可以让我们的工作事半功倍？

敏捷软件工程专家Craig Larman最近发文，总结在编写《规模精益&敏捷开发：Scrum中的学习与企业工具》中"企业"一章时，由一组在大型公司工作的敏捷开发专家们列出所遇到的最大困难，并依此整理出以下十大管理障碍。