扫码阅读
手机扫码阅读

都知道敏捷开发好,但为什么大多公司都不用呢?

207 2024-02-23

本文1868字,阅读约需3分钟。

知乎上有小伙伴问了这么一个问题“都知道敏捷开发好,但为什么大多公司都不用呢?”。

我从一个不太一样的角度聊聊我的看法。

请把“敏捷”当作形容词

大多数人都在提“用没用敏捷”、“是不是敏捷”、“是不是真敏捷”、“敏捷对人的要求高”、“适不适合敏捷”,这实际上已经默认为“敏捷”是一个名词
但是如果你把“敏捷”看作是一个形容词的时候,你是不是就豁然开朗了?
其实“敏捷”是一个形容词这个说法并不是我说的,敏捷宣言联合作者之一的Dave Thomas在接受我的采访时就已经确认了(具体可参考访谈回放https://www.rongpm.com/talktotheworldvideo/talk-to-dave-thomas-12.html)。
也就是说,我们要问“我们是不是可以比原来更加敏捷?”,“如果我们想要比原来更加敏捷,我们需要做些什么呢?” 这个时候,你就会意识到,我们都需要更加敏捷,而且我们都有能力变得更加敏捷,并且大多数公司也正走在更加敏捷的道路上,并不是题目所说的“大多数都不用”

以下这些都叫“更敏捷”

例子#1

相信大家对瀑布方式已经很熟悉了。比如原来一个大瀑布项目可能需要8个月交付完成,只有在项目非常靠后的时候才能够看到对用户有意义的版本。现在,大家是不是看到很多公司已经尝试将整个大项目分成多个更小的部分了,比如改成2个月发一个版本。
虽然在这两个月之内,大家还是按照瀑布的方式进行工作,即分为设计、开发、测试...等明确的阶段,而且每个阶段都工作在这两个月全量的需求上。我们亲切地管这种方式叫做“小瀑布”。
即使是这样,“小瀑布”的方式是不是比原来的“大瀑布”更加敏捷了呢?一定是的!(可参考我的另一篇文章 我也来聊聊传说中的敏捷和小瀑布

例子#2

在不改变现有工作分配和工作流程的情况下,我们增加一个每日站会,就可以让团队成员更加及时地互通有无,更加及时地识别风险,更加及时地寻求并获得大家的帮助,更及时地排除障碍,为接下来一天的工作做好计划调整。

图片来源:https://netmind.net/en/scrum-fundamentals-infographic-what-is-the-daily-scrum/
也可以通过增加一个双周的回顾会,有规律地进行复盘,寻求改进机会,让我们的工作做得更好。
以上这两个会的增加,是不是让我们的工作变得更加敏捷了呢?会的!

例子#3

有些人非常喜欢做什么事情都发邮件,邮件成了问题讨论的工具,结果一天的时间就用来发邮件了。做得更好的人通过打电话来解决问题,显然效率会提高不少。比打电话更好的方式是找要沟通的人当面谈,那沟通效率提高的可不是一点点儿。正如敏捷12条原则里面提到的“不论团队内外,面对面沟通是效率最高,效果最好的信息传递方式”。
我们可以对照敏捷宣言 的四个价值观和12条原则来看,我们在任何一条上比原来做的更好,我们就做得比原来更敏捷,不是吗

软件研发如何更加敏捷?

所以,我们还是问问自己“我们想要比原来更加敏捷,我们能做些什么呢?”,这个时候是不是我们就不那么纠结了?
#1 让软件架构更加合理,更加清晰,更加模块化,更加高内聚低耦合,是不是我们想要做一个业务功能速度就会更快,就会有更强的能力响应市场的变化。
#2 我们在做需求讨论的时候让产品人员、开发人员、测试人员等各个角色都参与其中,讨论得更加清晰,大家在开发之前就对验收标准达成一致,是不是就可以让各角色对需求有一致的理解,提升软件开发的质量,大幅减少返工。就能够更快交付软件,也能够让大家未来有更充足的时间做新的需求(而不是困于改Bug中)。
#3 将我们的工作透明化,大家能够实时看到各种工作的状态,是不是会降低沟通的成本,是不是提升协作的水平?

图片来源:https://www.wrike.com/blog/scrum-vs-kanban/

不要把敏捷和敏捷实践搞混了

我们在学习敏捷的时候,不要着急学习具体的敏捷实践,我们先停留在下面的敏捷宣言的价值观和原则这里:

图片来源:https://agilemanifesto.org/iso/zhchs/manifesto.html
我们问问自己,在日常的工作中,如果我们向敏捷宣言的价值观和原则的要求靠近的话,我们可以做什么?我相信大家即使在没有学到Scrum, Kanban, XP等各种业界优秀实践之前,我们也能说出个一二三来!
然而,当我们学习了一大堆业界优秀实践(如Scrum, Kanban, XP等)的时候,我们很多人不知不觉把敏捷和这些业界优秀实践划了等号,迷失了!
他们发明了“敏捷团队”这个词。那么你能告诉我满足什么条件我们才能把它叫做“敏捷团队”?使用Scrum框架就叫做敏捷团队,没有使用Scrum框架就不叫敏捷团队吗?用10个敏捷实践的团队叫敏捷团队,就是在用敏捷,用1个敏捷实践的就不叫敏捷团队,也不能说是在用敏捷,是这样吗?这些问题你说的清楚吗?

图片来源:https://www.codeproject.com/articles/1064114/agile-software-development-basics

此时我们需要做的是回归“敏捷”这个形容词本身,把那些业界的优秀实践仅仅作为我们的参考。我们要观察我们团队或者企业的现状,找到真正适合我们当前状况的,能让我们变得更加敏捷一件或者几件事,做起来!
什么是适合我们当前状况的?就是找到大家都想解决的最重要的问题,解决它,一次尝试一点点,千万不要贪多,大家尝到甜头了,并且新的工作方式已经很自然成为大家默认的工作方式了,那么接下来可以再尝试一点点儿。不断前进,持续改进,变得更加敏捷起来!
祝大家在追求更加敏捷的道路上开心,成就满满!
原文链接: http://mp.weixin.qq.com/s?__biz=MzI4NjkwNzE4MA==&mid=2247485000&idx=1&sn=0bcd46b55dd0e72625b422966d8fc9ce&chksm=ebd4880bdca3011dad393019a968eb60a58c59fecf1bf9bea05fa8551221137ba22e0033860c#rd