- 用了敏捷实践就是敏捷项目吗？
- 采用敏捷方法学的人正在逐渐增多，最近调查中显示，XP，Scrum和FDD这些方法被广泛使用，已经达到前所未有的程度。但其中也有反面教材，不幸的是，随着敏捷的进一步流行，这种“坏敏捷”就有可能成为一种副
- 敏捷是否已跨越“鸿沟”？
- 渐进式敏捷：由下而上的敏捷推行策略
- 敏捷的效果需要在合作各方都采用敏捷方法时才能得以充分发挥。正因为如此，一种广泛存在的看法认为：敏捷的推行必须由组织高层由上而下地进行。在“敏捷中国”用户组的一个讨论中，网名photoman的网友这样说
- 文章：敏捷、架构和凌晨5点的产品问题
- Michael Nygard把自己列为那些仍然相信有架构这种东西存在的人之一。他在InfoQ发表的文章敏捷、架构和凌晨5点的产品问题中抛出了一个神秘的问题，并引导读者走完了从发现到解决的全过程。他在文
- 自动化敏捷工具太冷冰冰了？
- 很多人相信技术创新是提高生产力的主要因素，并假定如果累计投入到计算机系统的金融资本足够大，在信息技术上的投资会反映在国民统计上，其结果将是生产力统计上的增长。敏捷团队通过社会性反馈的主要机制将焦点维持
- 为敏捷项目招聘
- 如果你的敏捷项目是像我碰到过的大部分项目一样，一些已经在组织中的人决定开始使用敏捷方法。那些项目已经成功了，现在是时候招聘更多的人。那么现在有更重要的问题：你怎么确定你正在面试的人是适合你的敏捷项目组
- 敏捷开发中要慎用继承(2)
- 对于ParticipantsInDB来讲，clear这个方法的确是有用的：清空所有的参会者。但getCount就造成了一点点小意外了：通过ParticipantsInDB调用getCount这个方法时
- 项目中如何进行敏捷建模(1)
- Scott Ambler：敏捷建模的目的是为建模和文档构建描述一组原则和实践，最好是用于敏捷项目中。但如果它们不是那么敏捷也没有问题。
- 兴工具之利 善敏捷之事
- 虽然在敏捷开发过程中，工具的使用已经不会再被反复地强调，但是实践证明，我们仍然无法忽视工具对敏捷开发项目的重要意义。合理的选择和使用工具，将使敏捷开发真正受益于工具，而不是受工具所累。
- UP还是敏捷方法？
- 目前UP或RUP软件开发过程已经被很多企业所采用，敏捷方法也逐渐被很多公司使用，究竟是采用UP(RUP)还是敏捷方法呢？哪个更有效呢？
- 乱弹SOA 之业务敏捷
- SOA如何支持的思路探讨SOA之业务敏捷，如有不妥之处请同仁手下留情，慢慢拍来。
- 简析敏捷在分布式团队中的实践
- 与传统的软件开发相比，敏捷强调人与人之间的沟通，而不是通过文档。这儿可以用Kent Beck、Martin Fowler等16位业内权威的软件人士在几年前所做的一个敏捷宣言来解释：
- 敏捷首先要“看得见”
- 在项目之初，曾想到在项目里面导入敏捷开发的一些好的实践，但是仔细分析了一下，项目组的成员大多在经验上还不是很丰富，硬要上敏捷的话，会得不偿失。先从“看得见”做起。
- 敏捷与质量
- 对于什么是“质量”有很多的定义，敏捷方法就是让产品的质量由顾客塑造。他们承认不同的人会用不同的观点看问题，所以对于项目来说谁的观点最能说了算（最终顾客）就是敏捷方法要追求的。
- 如何对敏捷实践相关的实验性数据进行分析利用
- 大多数进行并公布的试验，其结果都不应该被当作是真实世界中的开发项目的产出。 而幸运的是，要判断出你对实验性的结果（不）应该抱有多大的信心还不算太难。
- 敏捷社区需要成熟度模型么?
- 随着时间的推移，在人们的视野中慢慢出现了叫做敏捷成熟度模型或是敏捷实施框架的东西。现在还颇有一些咨询公司在使用敏捷“执行能力评估 （readiness assessments）”来帮助客户“变得”敏捷
- 敏捷联盟——功能测试工具
- 软件开发和测试混杂了人的问题和技术的问题。“人与人”以及“人与技术”的接口一般说来要比“技术与技术”的接口难。大多数问题本身及其解决方案都存在“技术”及“人”两方面的因素。
- 敏捷开发简介
- 本文介绍了敏捷开发中的11个重要理念。
- 为敏捷团队准备的Lisp
- Paragent是一个基于web的、开源的IT管理系统，它的开发语言是，是……Common Lisp？在他们最新的blog里面，Paragent的开发人员描述了他们使用Lisp的经验：
- 敏捷开发的另一种方式--Scrum