敏捷软件开发原则

我们最优先要做的是通过连续不断的及早的交付有价值的软件使客户满意

《Product-Development Practices That Work: How Internet Companies Build Software》论文分析了对于公司构建高质量产品方面有帮助的软件开发实践, 发现尽早交付具有部分功能的系统和系统质量之间具有很强的相关性, 论文指出 初期交付的系统中所包含的功能越少, 最终交付的系统质量就会越高. 该论文的另一项发现是, 以逐渐增加功能的方式经常性的交付系统和最终质量之间有着非常强的相关性, 交付的越频繁, 最终产品的质量就越高.

敏捷实践会尽早、经常的进行交付, 我们努力在项目刚开始的几周内交付一个具有基本功能的系统, 然后努力坚持每两周就交付一个功能渐增的系统.

欣然面对需求变化, 即使到了开发后期也一样. 敏捷过程利用变化来为客户创造竞争优势

敏捷过程的参与者不惧怕变化, 他们认为改变需求是好的事情. 敏捷团队会非常努力的保持软件结构的灵活性, 这样当需求变化时, 对于系统造成的影响是最小的.

经常性的交付可以工作的软件, 交付的间隔可以从几周到几个月, 倾向于采取较短的周期

我们交付可以工作的软件, 并且尽早的(项目刚开始的几周后)、 经常性的(此后每隔几周)交付它. 我们不赞成交付大量的文档或者计划, 我们认为那不是真正要交付的东西, 我们关注的目标是交付满足客户需要的软件.

业务人员和开发人员必须相互合作, 项目的每一天都不例外

为了能够以敏捷的方式进行项目的开发, 客户、 开发人员以及涉众之间就必须要进行有意义的频繁的交互

激发个体的斗志, 以他们为核心搭建项目. 提供所需的环境和支持，并且信任他们能够完成工作

敏捷项目中, 人被认为是项目取得成功的最重要的因素. 所有其他因素—过程、环境、管理等等—都被认为是次要的, 并且当它们对于人有负面的影响时, 就要对它们进行改变. 例如如果办公环境对阮对的工作造成阻碍, 就必须对办公环境进行改变; 如果某些过程步骤对团队的工作造成阻碍, 就必须对那些过程和步骤进行改变.

不论团队内外, 最有效果并且富有效率的传递信息的方法, 就是面对面交谈

敏捷项目中, 人们之间相互沟通, 首要的方式就是交谈. 团队可能会编写文档, 但文档不是默认的沟通方式, 团队成员进党迫切需要并意义重大的情况下才去编写文档, 默认的沟通方式是交谈

可工作的软件是进度的首要度量标准

敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度.

敏捷过程倡导可持续的开发速度. 责任人、开发者和用户应该保持一个长期的、 恒定的开发速度

敏捷项目不是50m短跑, 而是马拉松长跑. 跑的过快会导致团队精力耗尽. 敏捷团队不允许自己过于疲惫, 不会借用明天的精力来在今天多完成一点工作. 他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上.

不断关注优秀的技能和好的设计会增强敏捷能力

快速开发的关键是高的产品质量, 保持软件尽可能的简洁、健壮才能做到快速开发. 因此所有团队成员都致力于只编写他们能够编写的最高质量的代码. 他们不会编写混乱的代码然后告诉自己等有更多的实践再来清理他们.

以简洁为本,是极力减少不必要工作量的艺术

敏捷团队不会试图构建华而不实的系统, 他们更愿意采用和目标一致的最简单的方法. 他们不会看重明天会不会出现问题, 也不会在今天就对那些可能出现的问题进行防卫. 相反, 他们在今天以最高质量完成最简单的工作, 身心如果明天发生了问题, 也会很容易处理.

最好的架构、 需求和设计出自于自组织的团队

敏捷团队是自组织的团队, 任务不是从外部分配给单个团队成员, 而是分配给整个团队, 然后再有团队来确定完成任务的最好方法. 敏捷团队的成员共同解决项目中所有的问题. 每一个成员都具有项目中所有方面的参与权利. 不存在单一的团队成员对系统的架构、需求或者测试负责的情况, 整个团队共同承担那些责任, 每一个团队成员都能够影响它们

团队定期的反思如何能提高成效, 并以此调整自身的举止表现

敏捷团队会不断的对团队的组织方式、规则、规范、关系等进行调整, 敏捷团队直到团队所处的环境在不断变化, 并且直到为了保持团队的敏捷性, 团队需要随着环境一起变化.

总结

每一位软件开发人员、每一个开发团队的职业目标都是给客户交付最大可能的价值. 可是, 我们的项目以令人沮丧的速度失败, 或者未能交付任何价值. 虽然在项目中采用过程方法是出于好意, 但是膨胀的过程对与项目的失败或多或少的应该负一些责任. 敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法, 这个方法关注的是可以达到团队目标的一些简单技术。