我们的敏捷之路——故事篇

*今天出于机缘巧合参加一个敏捷的研讨会，虽然在现在这个敏捷已经烂大街的年代，再一次听到各种熟悉的名词还是能让人再次心潮澎湃。正好趁此机会我把之前在为了奇怪目的根据真实经历写的论文拿出来作为本周的博客。
本文记录了我们的敏捷实践过程以及团队的成长历程，欢迎各位对号入座。*
小伙伴们准好了么？下周开始敏捷再落地。

什么是敏捷开发

定义

敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。核心在于通过不断试错的形式向用户交付有意义的产品。关键词:用户，产品，迭代，改进，简单。

宣言

2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development）。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。
由全体参会者签署的《敏捷软件开发宣言》（Manifesto for Agile Software Development）成为了重要标志，因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心，他认为多数美国人都不知道“敏捷”这个词如何发音。
Alistair Cockburn和很多参会者一样，最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后，他再次分享了自己的感受。“对我来说，很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心，因此我们的确达成了某种实质性共识。”
这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站（http://www.agilemanifesto.org/）首页的《敏捷软件开发宣言》，他们称自己为“敏捷联盟”。
敏捷宣言的内容：

---

• 个体和交互 胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档；
• 客户合作 胜过 合同谈判；
• 响应变化 胜过 遵循计划。
  虽然右项也有价值，但是我们认为左项具有更大的价值。

---

对宣言的诠释：
1) 最重要的是通过尽早和不断交付有价值的软件满足客户需要。
2) 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
3) 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
4) 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
5) 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
6) 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
7) 可以工作的软件是进度的主要度量标准。
8) 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
9) 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
10) 简单——尽可能减少工作量的艺术至关重要。
11) 最好的架构、需求和设计都源自自我组织的团队。
12) 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
1.3 原则
1) 通过早期和连续型的高价值工作交付满足“客户”。
2) 大工作分成可以迅速完成的较小组成部门。
3) 识别最好的工作是从自我组织的团队中出现的，
4) 为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。
5) 创建可以改善可持续工作的流程。
6) 维持完整工作的不变的步调。
7) 欢迎改变的需求，即时是在项目后期。
8) 在项目期间每天与项目团队和业务所有者开会。
9) 在定期修正期，