敏捷开发的4个中心思想
敏捷开发的4个中心思想 如下：
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
翻译成中文如下：
1. 个体与交互比过程与工具更加有效
2. 能够满足用户的软件比综合的文档更加有效
3. 客户协作比守住合同条款更加重要
4. 响应变化比遵守计划更加有用
其中按照不同的协作模式又分为:
1. XP(Extreme programming) 极限编程
2. Scrum (Cohn, 2009; Schwaber, 2004; Schwaber and Beedle, 2001),
3. Crystal(Cockburn, 2001; Cockburn, 2004),
5. Adaptive Software Development (Highsmith,2000),
6. DSDM (Stapleton, 1997; Stapleton, 2003)
7. Feature Driven Development (Palmer and Felsing, 2002)
其中的中心思想是注重最终的可用交付，注重人的沟通协作，注重满意度而非文档、工具与过程，但坦率地讲，在国内的项目型开发中，需要积极地探索如何坚持这个敏捷的思路与需求变更的欲望控制相结合，实现一个最佳的融合，依照笔者个人近20年的从业经验来看，还是存在相当的难度。
相比较于经典的RUP与Waterfall模型而言，由于没有了经典的步骤与过程切割，没有了需求的采集与分析定稿、设计的定稿以及必要的原型开发与验证，其实对于团队的每个成员的要求比起上述的2个经典模型要高出不少，其实要求大部分成员都能够准确、快速分析需求，并且能够转化为具体的代码，还要考虑必要的系统完整度与扩展性，因此对于成员的单兵能力要求非常高，很多国内的公司对于Agile的理解非常片面，笔者曾经碰到很多公司与小组，其中的普遍误区是Agile是不需要写文档的、不需要做计划的，而忽略了对于团队的单兵技能要求与沟通方面的要求，很多初级技术人员很多的团队都使用了Agile的方式来生产软件，最终的结果想必大家也是知道的。
总结一下Agile的应用场景：需求变化可能性非常大，团队的单兵实力很强、团队磨合了一定的时间了，能够紧密配合工作；
总结一下RUP与Waterfall的应用场景：需求变化可能性比较小，团队的单兵实力不太强，团队的磨合时间很短，尚不能紧密配合工作；
那么大家就有个疑问，如果团队单兵能力差距比较大，磨合不太好，而需求变化又很大的时候怎么办呢？ 这个时候在整体交付上的需求实现上使用交替使用递归式分阶段枚举实施，而每个阶段内的管理还是建议采用经典的Waterfall模型来实现，如此来控制整体的交付质量与用户的交付满意度。
附录：Agile的关键工程实践
翻译为中文，大体如下：
1.持续递增的工程计划
2.基于短小有用的功能集所做的发布
3.基于目前功能集的简单设计
4.测试优先驱动开发
5.基于需求驱动的持续重构
6.结对编程
7.集体负责体系
8.持续的集成
9.与客户的持续沟通交付
10.专职的客户代表参与开发
Scrum的实施步骤：
1. Sprints are fixed length, normally 2–4 weeks. They correspond to the development of a release of the system in XP.
2. The starting point for planning is the product backlog, which is the list of work to be done on the project. During the assessment phase of the sprint, this is reviewed, and priorities and risks are assigned. The customer is closely involved in this process and can introduce new requirements or tasks at the beginning of each sprint.
3. The selection phase involves all of the project team who work with the customer to select the features and functionality to be developed during the sprint.
4. Once these are agreed, the team organizes themselves to develop the software. Short daily meetings involving all team members are held to review progress and if necessary, reprioritize work. During this stage the team is isolated from the customer and the organization, with all communications channelled through the so-called ‘Scrum master’. The role of the Scrum master is to protect the development team from external distractions. The way in which the work is done depends on the problem and the team. Unlike XP, Scrum does not make specific suggestions on how to write requirements, test-first development, etc. However, these XP practices can be used if the team thinks they are appropriate.
5. At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint cycle then begins.