如何在公司内实施敏捷?

一帆问:如何在公司内实施敏捷开发?

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

「小波老嬉」回答

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

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

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


当项目进展了几个月,团队成员间的信任已经建立,我们的焦点可以从「人」转移到「事」上。我们之前说「需求都是待验证的假设」,那么我们就应该让它得到验证,而许多时候我们分析好的需求长时间等待开发,开发完的需求长时间等待测试,你会发现每个人都很忙,效率都很高,但「事」却没有很好地流动。这时我们可以采用「精益看板」的管理方式,把项目流程可视化出来,只关心一个指标,就是需求流入到流出的时间间隔,我们不再关注谁做了什么,在做什么,而是这个需求还需要做什么才能流入下个环节?谁适合来做?什么时候可以做完?
事物都是发展变化的,随着时间推移,团队在变,产品也在变,问题也可能在变,有可能之前的问题已经消失了,有可能出现了新的问题,动态地调整我们所使用的实践,解决当前的问题,就是敏捷性的体现。站会只是一个框框,站着开可以缩短时间,具体怎么开,却是需要自己往里装的。

团队实施敏捷不见成效,有很多表现,比如发现大家参与站会的积极性不高,听了别人的发言也没有反馈。这可能和分工有关,开发人员在想:我一个星期的任务都提前确定了,我的任务都没做完,哪有心思去关心「别人」的任务啊,「别人」的任务反正我也不参与,听来又有什么用呢?
参与计划会议的热情不高,开发人员可能在想:反正开不开会,该做的需求都要做,我干嘛还要去浪费时间开这个会?
我们为什么要迭代?是我们期望做了一个迭代后,我们知道哪些是对用户更有价值的需求,哪些是对用户没有价值的需求,从而根据反馈改变我们的产品需求。那你需求压根儿不变,客户说啥就是啥,产品经理说啥就是啥,迭代又有什么价值呢?
实施敏捷是对组织和个人导入新的习惯,新习惯导入有学习成本,需要提供环境支持,比如培训,比如绩效评定的方式,是否允许短期的效率掉落等。

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