@Lenciel

敏捷开发的成本

软件工程发展到今天,一共产生了两个比较经典的流程:瀑布和敏捷。

瀑布是一个现实生活里面有的东西,这个类比就变得很好理解。

Vhost threshold

敏捷究竟是什么?如果我们忘记那些story point,站会,sprint,scrum,想一想,“敏捷”这两个字代表什么?

我觉得无非是代表当变化发生的时候,有足够的灵活性。

如果我们以做一双鞋举例。

瀑布可以对应到标准化工厂,每个阶段的专业人士(或者机器)可以用最高的效率进行生产,达到极高的吞吐量。

但是量产的鞋没法满足所有人的需要。比如有的人喜欢脚面宽一点,有的人喜欢鞋带或者鞋帮有一些变化。这个时候如果做鞋的说,都可以满足,那么它就很敏捷。

这通常是一个制鞋的工匠可以做到的:他有大量的工具,足够的技巧,只要多给点时间,可以满足你的各种需求。

工厂的优点很明显是量产的吞吐量,缺点则是生产不同的东西需要花费大量时间来重建机器。 工匠的缺点也很明显,就是生产效率低下,产量低,同时标准化程度低,不能水平扩展。

所以敏捷和效率其实就是跷跷板的两头,因此瀑布和敏捷作为两种侧重点不同的方法论,并没有好坏,也无所谓新旧,两种方法在项目管理的三角形里,一个优化了时间,一个优化了成本。如何选择,其实和软件开发里面大多数时候一样:你得判断做什么样的tradeoff。在最近的十年,只不过因为软件的发布成本不断降低,复杂度却不断提高,且需求常常不确定,因此程序员倾向于支持更有柔性的敏捷。

理解了敏捷流程的成本有什么意义?

首先要时刻想到,你是牺牲了效率的。要把对效率的影响减小,就要控制项目参与人数,而不是加人。要为这些小团队提供更好的工具和服务,而不是把流程弄得复杂。

其次,要明白即便是推敏捷流程,根据不同项目细节上也可以不同:如果你的团队创建的产品或工具有内外部的用户,使用 Scrum,让他们看到交付的节奏,不要一直干扰开发。相反,如果是提供基础设施或者基础服务,使用Kanban等流程来提高lead time,因为这种情况下用户最在乎的就是效率。

再次,因为敏捷牺牲了效率,光从团队组织架构上做动作,比如把团队规模减小,服务化等等,很难完全把这部分损耗找回来。怎么办?要不断地为更好的工具投资,来对抗复杂度,提高效率。好的工具通常是对问题进行了抽象之后,让关键的信息流动的同时,让关键的步骤被自动化,这其实解决的就是复杂度。

最后,当通过工具提高效率进入瓶颈期时,你可以再尝试从人这方面入手:改进流程,将整个系统或者任务分成更小的部分,让员工成为专家中的专家。同时,良好的流程还有助于并行化工作以提高整体的吞吐量。