敏捷模式真的是灵丹妙药吗？

作为一个IT人，我想每个管理角色，不管是一个小组leader，抑或部门经理，都会对如下场景非常熟悉。

设定前提：该公司是一个相对有一定规模的公司，比如同时有一个几百人的团队在从事某个方向的业务拓展，包含开发、产品、市场、销售、售前、运营等。

产品的需求通常以一个月或者两个星期的周期进行开发测试发布，中间可能参杂着不得不加入的小需求周期。

如此各司其职的一个周期下来，产品十有八九会正常交付，只是管理者心里常常有个心结：每次发版就像是一次赌博，运气好也许发版的数据很好看，运气稍差，往往大家都搞的身心俱疲但是却结果很勉强。

笔者所在的公司直接参与该软件项目的开发大概100个人，使用的是传统的瀑布模型，大版本的开发周期为一个月，里面参杂3个左右小版本，用禅道进行流程的管理。由于用户群体一部分为B端群体，一部分为C端群体，对错误的容忍程度相对较低，所以一直都是在需求评审阶段花费四天时间，尽量确保需求的合理性和可靠性，测试人员最终的测试依据也是严格依照该阶段所产出的交互文档和需求文档。

但是，如上所说，结果数据并不稳定。也曾开过N个会来强调质量意识，强调过需求评估时间的重要性，强调过没处理完当天的事情自行加班。也用KPI进行约束，but，部分人总是对自己剩余任务时间进度的把控、需求可行性的把控存在偏差，导致提测质量不稳定。于是乎，领导提出来用敏捷模式替代当前的模式，以达到解决问题。

对笔者而言，敏捷模式不是什么新鲜的事物，早在开发手机方案的年代，由于客户的时效性要求高，需求随着市场的变动而快速更新，且对交付质量的要求并没有那么高，通常以抢占市场为第一要素，所以往往一个10个人左右的Team来不断推进一个项目的迭代。轻文档，重成果，重沟通，重进度。也许那个时代大家只是潜意识里觉得这样是很正常的工作方式，只是并没有冠以所谓的敏捷之名。

那么敏捷到底能不能用在当前的公司项目？

思虑再三，觉得如下几点还是有待商榷

其一，敏捷区别与瀑布的一点，前者是拥抱变化的，并鼓励变化，那么会有两种“变化”，

一、由于客户需求中途变动导致的变化，这是应该所有人去拥抱的，但是这种情况目前看来并不多。

二、由于产品能力不足或者开发评审能力不足，导致需求具体实现有坑，不得不改动。当前的瀑布模式对此有绩效约束，如果改成敏捷，那么这种更改将相对“正常”，显然，这不是项目经理或者小组成员希望看到的。

其二，敏捷的开发要求交流重于文档，那么质量怎么保证，如果文档针对某个需求点并没有详尽的说明，那么如何保证细致到文案的颗粒度要求。长此以往，开发人员会觉得质量细节并不重要。当然这也符合敏捷鼓励“不断试错不断进化”的初衷。

其三，由于业务模块之间的协同关系，A模块的开发通常会需要B模块的配合，即使他们之间的代码层面是解耦的，那么当B同时要面对A、C甚至D的配合要求时，B的冲刺周期就会变得无比复杂。反之，ACD如果之间又有关联的话，那更是一件灾难性的事情。

其四，敏捷要求成员每天都能持续集成，通过早站会的方式同步一天遇到的问题，并解决问题，同时，每天集成的成果是由项目经理或者开发组长进行review的。这个确实能部分解决当前存在的痛点，但是前提是任务颗粒度是相对高内聚低耦合的，否则他人的进度往往会影响自己的进度，最终导致名存实亡。同时这也需要开发组长的全力配合。但是不可否认，对于提高员工的紧迫感，是很有好处的。

如上四点，其中三点是必须解决的，第四点是在理想状态能改变现状的，but，如果前三点都解决了，那么其实所谓的敏捷无非是更小时间粒度的瀑布模型。

最后，所有的过程控制方法，都是为了求更高的产出率，如果为了方法而方法，无疑是不明智的。基于以上各点，也许我们可以将此作为一种尝试，总结出一个适用于当前公司的方案。