在我不长的职业生涯中，呆过两个团队：一个团队想做敏捷，但不知从何下手，欲试而不能；另一个团队：已经使用了敏捷开发，有SQA，有完善的CI，有了一些指标，推行TDD，有完整的理论指导。
两个团队各有特点，有相同和不同的痛点，大家的开发模式和组织方式有极大不同：第一个团队里，一个人要负责多个项目，开发目标来自于需求团队，是一种比较混乱的组织方式，既不是瀑布，也不是敏捷。我想绝大多数的软件开发公司都是这样的模式，这是小团队必然选择的模式。标准的敏捷不适合他们，敏捷要求一个项目至少有三个人参与开发，而这样的团队里，一个开发开发三个项目不嫌多。在整个开发团队规模较小的情况下，这种模式提供了极高的开发效率。而问题也显而易见，当团队规模大了以后，沟通成本将直线上升，团队容错性很低，往往一个开发人员离职，整个团队都会伤筋动骨…
第二个团队里：大家使用敏捷开发，管理更规范，容错性高，团队有个别人员离开也能快速作出反应，优点很多，而问题也不少，第一个问题就是：开会太多了，计划会，总结会，迭代中需求变更要开会，遇到意见不同要开会…… 标准太多并且容易出现标准固化，一个纯插入操作也需要测试覆盖…还有一个很严重但我不知道是否是我们团队的独特问题：对迭代的关注导致对整体战略的忽略，我始终觉得敏捷的指导思想里一直在回避这个问题。而战略既有业务层面的战略，也有软件整体架构层面的战略。
必须承认，敏捷带来了新理念，带来了好东西，我认为，在思想上它最大的贡献在于指出了软件开发的工程模式和传统工程模式的不同，必需正视这种不同。在方法论上我十分欣赏敏捷提出的迭代和看板。但也必需看到，敏捷不是银弹，他也带来了诸多问题，君不见IOS和Windows稳定性下滑了多少？再看他们的大版本升级周期缩短了多少？
所有方法论的提出必须要基于解决问题的目的来提出，那么对于软件工程而言，最大的矛盾在哪呢？我想最大的矛盾就是在于需求经常变更的现实和不可忽视的修改成本。开发往往很容易和需求成为对立面，在开发看来，你需求只需要听几句话然后转过头和我说一下就好了，而我却面临着大量的修改变更，而很多中小型开发团队是无法提供开发对需求的制衡力量，而制衡力量的缺失又会造成需求变更的肆无忌惮。
敏捷的理论一出，首先掐死了瀑布那样的一锤子买卖模式，之后引入了更容易操作的需求变更管理方式：看板和迭代！
迭代首先明确了开发时间，避免了时间衡量纬度的缺失导致的任务量评估的缺失。之后引入了看板，我认为这是敏捷中最核心的东西，他打破了沟通边界，达到了对所有人“有交”代这一目的，他也赋予了开发制衡需求的力量，很多时候，看见本身就是一种力量。
当需求变更时，我们需要评估影响的时间，并将需求变更记录在案。燃尽图，看板上的标签都能直观反映工作进度，领导绕场一圈就能快速知道所有团队的进度，当最终任务不能按期完成时，大家也能根据看板明确的划分责任。这样就形成了一个互相能够制衡，健康的工作环境。
而敏捷所存在的问题在于：随着使用场景的增多，难以根据团队/项目的特点进行适当修正，过多的形式化使得开发团队效率降低。而此时总要有人站出来，回归他的本源，再根据团队情况进行定制，而非简单地指标约束，拿来就用。敏捷所引导的战略的缺失我看只能寄托于团队负责人的大局观了吧……
网友评论