谈敏捷开发

这年头不做敏捷开发都不好意思说自己是做软件开发的。很多人都知道敏捷开发或者项目就在敏捷开发中,但是越来越多的人对敏捷开发表示不理解了。我经常听身边的人问:敏捷是什么?究竟什么才是敏捷开发?难道敏捷开发就是这样吗?

这就跟早上正常点上个班,周末加个班就喊“狼性”是一个道理:很多人认为早上开站立会就是敏捷了!

敏捷开发和每日站会的关系

如果要问:敏捷开发和站会是什么关系?我想说:的确有关系,但要知道不是你把敏捷的流程都走一遍就真的敏捷了。

scrum会议可以分为:sprint计划会,每日站会,评审会和回顾会。

个人认为:敏捷提到的站会只是一天固定时间沟通的会议,主要目的还是跟进进度、暴漏问题,PO和SM意图通过站会来完成自己的职责:

  • 协调资源,解决项目的障碍
  • 保证项目进度
  • 保证团队内角色之间的协作
  • 团队跟其他团队的接口人,协调沟通

而现实中的站会可能是下面的样子:

  • PM忙着改需求
  • RD讨论解决方案
  • UE听不懂,在打哈欠
  • QA在报bug

敏捷开发究竟是怎样的

敏捷开发是一套经过多年实践而总结出来的一套方法论。所以不要神化,更不要跟风,适合自己的team就好。

敏捷总结了一些项目中常常遇见的问题,并且想通过敏捷的流程来避免这些问题。而现在很多公司很多项目用了敏捷(或者敏捷扩展版),实际参加敏捷的童鞋并没有“敏捷”,而是在抱怨:为什么这么多流程?为什么这么多会议?

究竟错在哪里??!

往往大公司一个项目需要牵扯太多人,一次(预)发布会可以开5个小时,涉及到的人都参加,前面的人七嘴八舌各抒己见,后面的人各干个事。PO都不知道自己想要的是怎样的一个产品,最多的情况是在听取了意见后做了妥协。

团队太大,还会出现一些鸡同鸭讲的会议,比如每日站会:先是UE,然后RD,后是QA,再。。。

这样前面讲的事情,根本自己都不知道干啥,听不懂,那为啥还要非拉在一起开会呢?

team太大

最大的错误是team太大,忽略了个体。敏捷有个说法:2个披萨。也就说团队人数要控制在两个披萨够吃内。

敏捷提倡对团队人的信任,充分调动团队中每个人的积极性,发挥最大的效率。

当一个项目team太大的时候,可以考虑拆成几个敏捷团队来执行,团队之间共享角色,来实现沟通。比如:UE开UE的会,而参加RD的会就会昏昏欲睡;何必呢~当涉及到其他团队角色的时候可以叫上一起啊。

其实这在scrum里面有个专业术语:scrum of scrums。我的想得到,大佬想不到吗?当然我相信他们也想得到,不过没有什么比成功更具有说服力。所以也许坚持经验更重要。

太看重流程和工具

比如说燃起图(燃尽图)这件事,就是为了大家看到每天的进度,而老一些“敏捷er”往往对新“敏捷er”说:task要拆的够细,每天都有事情做,每天都有事情完成,要燃起图好看。

你是知道的中国人都是很聪明的,于是会想尽办法“造”task,因为我要保证第二天我的燃起图正常,不然会被点名批评的,被批评了KPI怎么办?

对于流程来说,当流程太复杂的时候,我们应该勇于提出来,去精简。当一个新的SM接棒的时候,应该审视之前的流程,是否合理,是否需要调整。

现在往往是大家觉得项目做成了,leader升级了,留下的就是宝贵的经验,下一个leader就会按照这个流程来做,尽快他也深受其害,但是这是“宝贵经验”,之前的leader就是这样成功的,为什么我们要颠覆呢?

并行还是串行

也许好几个项目并行,一个角色穿梭于多个项目中,这样貌似在并行,其实人还是那个人,他不可能同时做两件事情,这不是一种提高效率的事情。人只有在专注一件事情上,才能发挥最大的效率。多个事情并行会分散精力。这就像番茄钟要25分钟专注一件事情的道理一样的。

穷则变,变则通

为啥大家都怨声载道还要摸黑走下去呢?该变就变!

SM需要做的是:要每个角色效率都最大化利用,为角色提供更舒适的工作环境(包括流程)。

个体和互动高于流程和工具
工作的软件 高于详尽的文档
客户合作 高于合同谈判
响应变化 高于遵循计划

甚至我想应不应该把敏捷开发跟KPI和个人职业发展更好的结合呢?