引子

敏捷开发总是一个充满话题与争议的东西，加上日常工作中经常会遇到有各种各样的场景。要不要TDD? 要不要Pair? 要不要每张卡上线？要不要团队每个开发都是全栈？要不要每个人都是全功能? 流程是否过重？会议是否过多？日常沟通是否太费时？这个来源于十几年前的开发方法论，是否依然适应于这个一日千里的开发领域？要不要写文档？等等。。。

关于这些争论了无数次的东西，嗓子大是没有用的。于是基于个人浅薄的经验，梳理了以下思考的过程，以及欢迎大家拍砖。

思考逻辑

明确首要目标 --> 确定原则 --> 结合场景 && 提出实践

明确首要目标

首先就是要明确我们最重要的目标：持续不断地及早交付有价值的软件使客户满意。“持续不断的及早交付有价值的软件”，是为了能够及早的推出产品，从而快速的验证想法、快速的试错，进而更快的适应市场的需求，降低错误成本，快速抢占市场；“客户满意”，则强调了软件作为产品，用户体验的重要性。
我们所做的事情，应该都是为了达成这个首要目标而努力。当我们有件事情不确定了的时候，不妨问下自己，是否有利于自己达成首要目标。

确定原则

其次确定原则。原则与实践是两种不同的东西，类似于数学中的公理与定理。原则是大家公认的绝对不可轻易违背的东西，通常描述的会比较大一些，在这里面，就是为了实现上述目标，我们必须得遵守的东西；而实践则是由原则衍生出来的一些具体的操作，是可以由原则推导出来的。
原则比首要目标要更具体，有利于我们在有些讨论中快速达成一致，减少沟通成本。当多条原则互相冲突时候，可以参考我们实际的首要目标；
参考当年敏捷宣言的具体内容提到的东西：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

以及敏捷十二原则, 太长这里就不列了。个人总结，就是强调：

• 及早以及持续的交付价值。能快速上线，快速验证，低成本试错……
• 及时的响应需求变化。市场&社会是个复杂巨系统，变化很快，及时响应保证产品价值最大。并且敏捷这个词，在系统学中，本身就有指代快速响应变化的能力。
• 重视沟通，流程简洁。团队内外，业务、开发、客户、责任人等。保证大家对于需求的理解是一致的，保证大家能及时获取用户真正的需求
• 及时反思。三省吾身
• 追求技术卓越与良好设计。 好的可读的代码，有利于持续的开发与演进
• 激发个体斗志，提供环境、资源，团队自组织。 团队中人的重要性，大家很嗨皮，自主意愿&斗志强的时候，才能做出最好的产品。

结合场景 && 提出实践

实践是我们项目上具体采取的一些操作，是一些很具体的事务。这些操作的目的是为了完成上面说的首要目标。而原则则给我们提供了一些思考方向，帮助我们快速的从一些维度来思考并达成一致，而在这个过程中，项目的实际背景不可忽视。

因此，在我看来，上面疑问里面的很多实践，之所以会有这么大争议，也是因为他们大都符合大部分的原则，但是又在一些背景里面多少有些冲突。
比如说，要不要TDD? 要不要pair? 这些实践固然很好，它“追求技术卓越与良好设计”，他“促进团队内部沟通”，能帮助我们少写bug。但是很多产品，尤其是一些创业团队而言，在早期MVP阶段，几乎不可能以这种方式去工作，他们需要快速上线快速测试，更愿意使用最简单甚至很潦草的方式去实现，比如江湖传言某滴早期的代码烂，做大以后开始各种重构；团购鼻祖Groupon早期就是基于开源框架Wordexpress搭建了一个相当粗糙的模板；
其他比如要不要团队每个开发都是全栈？这在一个平稳的项目中当然很好，有利于大家的沟通，以及减少对个体的依赖；但是在一个项目初期，本身有很多坑要趟，或者有很多领域的技术难题需要解决，那么过度追求全栈的结果就是多而不精，某一块的技术卓越与良好设计很难实现；尤其是如果那个人对领域本身的偏好也比较强的时候，个体斗志，团队自组织性，都会有影响。
一言蔽之，实践是需要跟实际背景相结合来看的。完全脱离背景谈必须follow什么实践，就跟脱离剂量谈毒性一样，都是耍流氓。

小结

简单的说，敏捷开发发展这么多年，给出了很多非常好的实践，可以解决开发中很多代码、流程、管理上的问题。但是我们在完全follow时候，不妨先看下项目的实际情况，是否真的可以帮助我们“持续不断地及早交付有价值的软件使客户满意”。