敏捷软件开发：原则、模式和实践

1，敏捷宣言和原则

1.1 敏捷宣言

敏捷联盟在敏捷大会上发布了他们最主要的主张，称之为敏捷宣言。其主要表述如下：

1，个人和交互胜过过程与工具

2，可以工作的软件胜过面面俱到的文档

3，客户合作胜过合同谈判

4，响应变化胜过遵循计划

虽然后者在软件开发中也具有其价值，但敏捷联盟认为，前者比后者更具有价值。这四点构成了敏捷最核心的要素，但我个人认为就这4点而言，最根本的还是“个人和交互”，这是敏捷方法区别与其他方法和流程的根本性原则。它体现的是一种很朴素的哲学原理--“以人为本”。其潜台词就是：人，才是获得成功的最重要的因素。由此，由生发出另一个关键的问题：既然人这么重要，那么什么样的人组成的团队才能获得成功呢？就像敏捷宣言主张的一样，“人和交互胜过过程和工具”，这就意味着，我们需要的人不是孤立的个体，而是一个融进组织的具有很好的交互能力的团队成员。所以我比较认同作者提出的一个观点：合作、沟通和交互能力要比单纯的编程能力更为重要。同时我认为，最好的团队是有那些技术还过得去，但能够很好的沟通、合作的人组成的，而不是许多技术超一流但不会沟通合作的人组成的。

很多事实都表明，构建一个好的团队是成功的基石之一，而构建一个好的团队的难度远比去构建一个开发环境这类的事情要大得多。因为他很多属于社会科学、属于管理学、心理学以及其他学科的范畴，而开发环境的构建纯粹就是自然科学范围内的事情。

强调人的作用，比不意味着不重视工具的作用。经验告诉我们，很多时候，工具可以大大提高我们的生产率，使我们做起事情来事半功倍。但是我个人觉得，现代社会的趋向是太过依赖于工具，所以工具的应用上，主要还是要防止滥用，应该使用适度的工具。

关于文档，我向来认为，陷入成篇累牍的文案中，是一种吃力不讨好的行为，但我觉得，又必须有一定的文档，以便在维护的时候、在培训新人的时候能够有所帮助。我认为敏捷其实不是放弃文档，而是减少文档在日常工作中的占比，减少文档的量，最重要的是使软件成为一种自组织的、更形象化的文档。是的，我们不需要面面俱到的文档，但是一份记录我们如何决策、设计的详细架构文档还是需要的。

软件开发的根本目的是满足客户的需求，因此让客户加入团队合作，能使产品长的更像它应该像的样子。我们都知道，当客户说“我想要天上的月亮”的时候，其实他想要的只是一个月饼而已。所以需要技术人员循循善诱的让客户和自己清楚客户真正的需求。如果，只有合同谈判，也许费劲心力，都做不出用户满意的产品来。在我的职业生涯中，我所面临的客户一直是公司内部的产品人员，所以大部分时候都采用的是客户合作的方式来。

敏捷为客户创造最大价值的一个手段是，对变化的快速响应。当产品的生产可以快速变化而适应市场的变化，我们为客户赢得的就是机会。“响应变化胜过遵循计划”，对这句话的理解包含两方面，首先是响应变化，我们可以很快的做出改变，去优先完成那些新加入的、对客户有更大价值的事情。这种改变的前提是，在某小一段时间内（比如一个Sprint），我们的需求是稳定的，从而可以专注的做事情。应用到Scrum中，就是下一个个Sprint里要做的事情，是可以改变的，但当前Sprint的需求是不能被改变的。另以方面就是遵循计划。由此引申开来就是，怎么样去做计划，使得计划既可以被遵循，也可以响应变化，作者给出了一个他认为合理的方法：为以后两周做详细计划、为下3个月做粗略计划、再以后就做粗糙的计划。既我们需要详尽的了解这两周我们要做的事情，对以后的3个月有个粗略的任务计划，至于接下来的一年里做什么，有个模糊的想法就行。

1.2 敏捷原则

敏捷联盟在发布四条宣言的同时，也发布了12大原则，进一步阐述他们的主张。下面，我们一一的来解析这12