敏捷开发

敏捷开发不是信仰，团队成员并不关心什么是敏捷，他们只关注把工作搞定，。同样他们不关心什么是敏捷，他们仅仅关心那些能帮助他们解决当前问题的事情。

敏捷开发被越来越多的开发企业和团队所接受。本文讨论了敏捷开发的优点以及敏捷外包的可行性。

敏捷开发是一个使公司能够更快速地提交软件产品的开发过程方法。它是一个渐进的，协作的方法，其目标是有效及时地生产出高质量的软件。

这里将讨论的话题是敏捷开发真的对架构设计不利吗？增量迭代开发本是提高效率的做法，希望本文能对大家有所帮助。

人们对敏捷开发和精益开发的关注兴趣越来越强。仅仅在IBM一家，过去的两年中，敏捷项目的数量从5个增加到了200多个。本文向您介绍使用敏捷开发在成本和效益方面的优势。

敏捷开发现在在欧美已经有了相当的普及，在国内也已经流传实践了几年，现在正逐渐进入到越来越多的项目中。这个过程将使每一位程序员面临更高的挑战。

本文对最小可行产品的概念和优点进行了一些介绍。最小可行产品，就是只是“刚刚好”满足客户的需求，这样的产品人们乐意付费，而且可以尽快推向市场。

本文先介绍了使用传统项目管理技术管理软件开发项目的方法，然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷项目管理进行软件开发的方法。

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

在敏捷开发过程中，软件构建周期以及自动化程度直接影响开发的速度和质量。本文结合具体的软件开发项目，描述如何利用 IBM Rational Build Forge 在敏捷开发过程中实现完全自动化的软件构建，产品安装以及单元测试，进行每天持续快速构建，提高开发团队的效率，改进产品和开发质量。

我们希望一个好的架构能够：重用、透明、延展、简明、高效、安全。为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则。

评判软件成功的标准有很多，对于敏捷方法论来说，成功的标准首先在于交付可用的软件。为了保证软件的可用性，最重要的就是做好需求。做好需求的方法有很多（参见拙作需求的实践），但这并不是我们讨论的主题。对于我们要开始的架构设计的工作来说，从需求出发来设计架构，这就是保证软件可用性的一个基本的保证。

本文将争辩一下敏捷开发不是XP，在这篇文章里面，笔者首先打算分清楚这两个概念，然后谈谈笔者的非极限编程敏捷实践。

对于一个已经初步建立好的模型（分析模型或是设计模型）来说，对其进行精化和合并是必要的步骤。

极限编程中有一条著名的懒汉原则，称之为KISS原则，KISS是Keep it simple and stupid的缩写。简略地说，就是设计尽量保证简单。这里我们将谈到敏捷开发思想中的简单最好原则。

本文向您介绍WebWork框架在敏捷开发方面的一些优势，通过其自带的一些工具可以使初学者快速入门，从而进行WebWork敏捷开发。

令架构趋于稳定的因素包括令需求冻结和架构改进两个方面。需求冻结是前提，架构改进是必然的步骤。在面向对象领域，我们可以通过一些实践技巧来保持一个稳定的架构。这些实践技巧体现在从需求分析到编码的过程中。

作为国内首位也是唯一一位具有资格认证的Scrum培训师（Certified Scrum Trainer，CST），吕毅的传奇是从“会讲中文的Trainer”开始的。

敏捷开发过程中，由开发人员自己来估算完成该任务所需要的时间。然，每个人的能力不同，关键还是靠迭代来逐步求精。

在本文中，笔者探究了当今敏捷项目中广泛使用的各种可视化方法，并提出用看板图（Kanban Board）来组织三种视角（时间、任务和团队），目的是使整个团队都能理解项目的当前状态，并以一种自发、有动力且互相合作的方式来工作。笔者还介绍“TRICHORD”这个软件工具，它用看板方法来实现这三个视角的项目可视化。