如何在公司内实施敏捷？

问：公司最近尝试敏捷开发和管理，但是没什么收效，实行了一个多月了，感觉和以前一样，该完成的完成不了，开发没有成就感，都没有一点的积极性了，难道是项目比较大不适合敏捷吗？是新项目，项目比较大，做了几个月后刚开始实行敏捷，每天早上组织 Team Leader 开会半小时，主要回顾昨天的工作中遇到的问题，是否需要决策，以及今天要完成的事情，需要什么支持，开发任务是按照周为单位布置的，每个开发和 Leader 细化，周五开会时间长一点，超过30分钟不能解决的问题就一起讨论。Leader 会在开会前收集各个成员的问题和事情。团队构成：PM->CTO 1 位 ->架构师 1 位 -Team Leaders（兼开发）6 位->Developers，开发和测设人员接近 30 人。

答

从「感觉和以前一样，该完成的完成不了」，我推测你们想用敏捷解决效率的问题，而敏捷并不是为解决效率问题而生的。敏捷盛行的大背景是，基础设施（操作系统，高级语言，开发框架等）不断完善，开源组件日趋成熟，市场竞争愈加激烈，软件开发团队可以把大部分的时间都花在「业务需求」上，而不是相对确定的基础设施开发上。而「需求都是待验证的假设」，所以我们要快速迭代来消除不确定性，避免把精力浪费到没有价值的需求上。从而达到做的更少，却更有价值，降低成本，快速响应市场变化。

把敏捷实践当成一个工具来使用的时候，需要思考我们团队当前遇到了什么问题，哪个工具可以解决。

以站会为例，它解决的是什么问题呢？团队成员间的互相认可和信任是团队协作的前提，团队成立初期，我们可以用站会这个工具来解决信任问题。经典的三问「昨天做了什么，今天准备做什么，遇到了什么问题」就可以起到作用，「昨天做了什么」表明我的能力，我对团队的贡献，「今天准备做什么」表示我的主动性，我会主动思考什么是对团队最重要的事情，「遇到了什么问题」表示我不会隐瞒，我愿意暴露自己的不足，我信任团队成员可以帮助我。这三个问题表面上是更新项目进度信息，实际上背后的情感价值更大。

当项目进展了几个月，团队成员间的信任已经建立，我们的焦点可以从「人」转移到「事」上。我们之前说「需求都是待验证的假设」，那么我们就应该让它得到验证，而许多时候我们分析好的需求长时间等待开发，开发完的需求长时间等待测试，你会发现每个人都很忙，效率都很高，但「事」却没有很好地流动。这时我们可以采用「精益看板」的管理方式，把项目流程可视化出来，只关心一个指标，就是需求流入到流出的时间间隔，我们不再关注谁做了什么，在做什么，而是这个需求还需要做什么才能流入下个环节？谁适合来做？什么时候可以做完？事物都是发展变化的，随着时间推移，团队在变，产品也在变，问题也可能在变，有可能之前的问题已经消失了，有可能出现了新的问题，动态地调整我们所使用的实践，解决当前的问题，就是敏捷性的体现。站会只是一个框框，站着开可以缩短时间，具体怎么开，却是需要自己往里装的。团队实施敏捷不见成效，有很多表现，比如发现大家参与站会的积极性不高，听了别人的发言也没有反馈。这可能和分工有关，开发人员在想：我一个星期的任务都提前确定了，我的任务都没做完，哪有心思去关心「别人」的任务啊，「别人」的任务反正我也不参与，听来又有什么用呢？ 参与计划会议的热情不高，开发人员可能在想：反正开不开会，该做的需求都要做，我干嘛还要去浪费时间开这个会？我们为什么要迭代？是我们期望做了一个迭代后，我们知道哪些是对用户更有价值的需求，哪些是对用户没有价值的需求，从而根据反馈改变我们的产品需求。那你需求压根儿不变，客户说啥就是啥，产品经理说啥就是啥，迭代又有什么价值呢？实施敏捷是对组织和个人导入新的习惯，新习惯导入有学习成本，需要提供环境支持，比如培训，比如绩效评定的方式，是否允许短期的效率掉落等。

说了这么多，总结一下，就是要用逻辑思维，辨证思维，系统思维，用户思维（作为想导入敏捷的管理者，团队成员就是你的用户）来思考，发现并解决问题，至于你用的是什么方法工具，叫不叫敏捷，那都不重要。小平爷爷老早就讲过「管它黑猫白猫，能抓耗子就是好猫」。