敏捷软件开发宣言
原本这篇应是关于Affinity Designer的，然后在写的过程中，发现关于AD以及UI、UX和原型设计可以专门写一个系列（毕竟还是too young），于是就愉快地跳票了。这篇是关于敏捷软件开发宣言和敏捷软件开发的，也是为之后写用户故事地图作一个开头。
3.1 敏捷软件开发宣言
敏捷软件开发宣言是在2001年，由17位软件开发的先驱在一次聚会中共同提出的。这17个人分别是极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表，还包括了一些希望找到文档驱动、重型软件开发过程替代品的推动者（总之知识水平都很高就是了）。
宣言提出了一种全新的软件开发价值观——敏捷软件开发。敏捷软件开发基于迭代和增量，强调沟通和互动的重要性，注重响应变化。与之相对的是瀑布流开发，是一种老旧的、已然过时的软件开发方法，无法很好地应对日益复杂的情况和响应越来越频繁的变化（见下图）。
瀑布流示意图.png
而敏捷软件开发最核心的价值观，是在17位先驱谈笑风生的过程中，达成的四点共识：
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
// 也就是说，尽管右项有其价值，我们更重视左项的价值。
3.2 敏捷软件开发十二原则
除了上述的四点核心价值观，敏捷软件开发还包含着如下十二条原则：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
3.3 敏捷软件开发的实践
自2001年诞生了敏捷软件开发宣言后，敏捷开发的思想在业界中造成了相当的影响，很多企业自觉或不自觉的按照它的思想和原则进行开发，这其中就了包括我司。
但在实践中，也有一些所谓的“敏捷”，只是学到了敏捷的“形”，而没有学到敏捷的“神”。乍一看，它的流程的确是符合敏捷的原则，还能说出一些诸如Scrum、XP之类的话语，实际上背后的思想却还是传统的那一套。敏捷开发关键在于它的思想，在于个体之间充分而有效的沟通和积极的互动协作，以持续地去调整方法和响应变化，最终达成企业的目标和满足客户（用户）的需要。而不是使用什么样的敏捷开发方法，采取怎么样的流程，过分注重形式，只会违背敏捷软件开发的初衷。
因此，敏捷软件开发需要以适合企业自身的方式开展，企业内部各团队之间、团队各成员之间要能充分地互动和沟通，在工作的过程中保持沟通、定期反思，并持续地改进和调整工作方法。项目一开始时受挫是正常的，项目进行中出现各种各样的变化也是正常的，甚至项目在deadline之前出现问题也是正常的，怎么持续地响应变化和解决问题，以产出能达成目标和满足需求的软件，这才是我们真正需要担心和考虑的。
敏捷开发之道不是一天可以领悟的，它需要在实践中不断地去体会，更重要的，它是需要与团队中的其他成员、以及其他的团队一同实践的。笔者很幸运，可以在工作中遇到一帮很棒的同事，去不断地实践敏捷开发之道，也在这个过程中有了一些心得（包括用户故事地图），并将在接下来的几篇中一一呈现。
下篇预告：积极的碰撞，而不是无谓的撕逼
Designed & bulit with all the love in the world by @GAIUS_YAO
