无兄弟，不敏捷

不得不说，相当一段时间，我都是传统瀑布模型的粉丝，因为它是自上而下的，职责分明的，规划明确的。
Web前台开发人员不必知道他调用的Web服务的接口是谁写的，任何开发自始至终都依赖于审核后的设计文档，这有利于团队管理。在瀑布模型里，文档就是指南针，就是游戏规则，从需求分析，到概要设计，到详细设计，到测试计划，整个过程限定开发自始至终都要按照规则行事，开发人员不必关心用户的想法，因为上层的产品经理已经将用户的想法写到了需求文档里。然而用户真实的想法可能并不完全，甚至他们自己都不知道需要怎什么样的软件。软件开发最大的问题就是需求不确定，有时候开发正在有条不紊地进行，一个突如其来的变化会让我们措手不及，当然在瀑布模型里是对变化关闭的，然而某些变化是无可厚非的。比如用户突然提出要用Oracle代替SQLServer。
有些时候，某些项目需要通过快速原型模型，不断通过变化的需求改进原型，于是我就想到了敏捷。

敏捷重要的宣言：

• 个体与交互 重于 过程和工具
• 可用的软件 重于 完备的文档
• 客户协作 重于 合同谈判
• 响应变化 重于 遵循计划

我们将分布在公司各个角落的研发部署在一间会议室内，这使得我们交流十分方便，同时作为ScrumMaster可以随时知道人们在交流的过程中发生了什么，可以在每天的例会上提前列举出开发的疑惑，或者当时就能协调解决问题。按照敏捷的思路，参与人是整个过程最重要的，Scrum来自橄榄球比赛的术语，同时也适用于篮球比赛。ScrumMaster是教练，球员是团队。产品负责人则是球队经理。用户则是我们的比赛对手。Backlog很简单：赢球。Sprint则是每一次暂停教练的安排的战术：你去防对方的投手，你找机会投三分，你做好挡拆，你抢篮板球。通过很多Sprint迭代目的是Backlog列举的目的：赢球。在这期间，毫无疑问，变化是一直存在的，所以需要团队中的每个人专注自己的工作，自我管理，自我承诺。
实际上，团队自始至终都一定要有凝聚力，并且为了共同的目标而奋斗。即使个别研发能力有限，但我们在一起就是一个团队，在团队里，任何人都要争取个人能力发挥的最大化，从而弥补特殊原因导致的团队意外的损伤。

在这个团队里，没有领导，没有官僚，完全民主和自由，无关种族，无关年龄，无关性别。
只和我们的信仰有关：无兄弟，不敏捷。