Scrum 缺点

Uncle Bob在二月时提出对Scrum的批评, 每点都直击要害, 我自己是十分认同. 不过令人兴慰的, 到目前为止, 有不少先知对这些缺点, 提出不少解法。
Scrum/Agile Failings or the Theses of Uncle Bob Martin
http://www.infoq.com/news/2010/02/scrum-failings

1. No technical practices
– Scrum只给了管理上的建议, 但是没有给开发人员技术上的建言
– Scrum必须借助XP的practices, 像是:TDD, Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.

2. 30 day sprints are too long
– 很多团队认为2 weeks比较合适, 会比较快得到feedback

3. The tendency of the scrum master to arrogate project management powers.
– 有很多Scrum Master把Scrum搞成micro management
– 也许是不应该用master这个字, 改成用coach也许比较不会让Scrum被误用

4. The Certification in CSM is unfortunate
– 在Scrum中常把这个role搞成变成一个person.常常都是同一个人当scrum master
– 应该要学XP的coach观念, 要轮替到不同的团队, 而不是都是同一个scrum master

5. Scrum provides insufficient guidance regarding the structure of the backlog.
– Scrum对backlog的structure着墨很少
– 经过一段时间的学习, 我们了解到要对backlog做拆解: Epics->Themes->Stories->Tasks

6. Scrum carries an anti-management undercurrent that is counter-productive.
– Scrum过度强调团队自我管理. 自我管理的团队固然很好, 但是有其局限性.
– 仍然需要管理团队适时辅助

7. Automated Testing.
– 没有高品质的test automation, 很难缩短iteration的时间, 并且也不知道什么时候会做完

8. Multiple teams
– Scrum 和agile都对于scalability没有很好的处理.
– 虽然很多实践者都有一套做法, 但是并没有一致的结论

也有另外网友对敏捷开发提出了一些疑问:

Scrum的基石是相信人。创造一个安全的环境,这样每个人都能相互学习,相互直言。但是,这是不行的,这世上有很多人并不关心这些,而且政治和竞争到处都是,办公室里无小事,你和别人交心,你相信他们,最终受伤的你自己。你真的以为那里有空间让你可以去犯错,去冒险吗?别天真了!你啊,too young, too simple, sometimes naive!

Scrum认为只要给员工足够多的自由员工就能做得最好。这该死是理论是基于什么玩意?不可能,人的天性是懒惰的,他们才不会把事做好的,他们只会做相应报酬的工作量,还可能基本还达不到其相应的报酬,大多数人都在混日子啊。尤其是和经理比起来,谁不想能尽快地成为经理或Team leader啊,因为那样他们就可以即不干活,又挣得多。另外,你给他们自由,你就会发现,他们会只会做他们感兴趣的事,要么聊QQ,要么打游戏,看闲书,反正不干正事。直到你催了,他们才动一动。

因为前面的原因,所以,我们仍然要把一个PM放在Scrum团队的上面做管理,这样才会有产出。于是,PM给团队分配任何,管得细枝末节,事无巨细,天天让你做进度汇报,等等。直至把团队拖垮。

Scrum只不过是一个流程。这世上有太多的流程,尤其是那那些操CMMi的公司。几乎所有玩CMMi流程的公司,你都能看到的是员工都是那一副副苦逼的脸。所以,Scrum的流程同样会这样。因为这些都不是开发团队自发出来的,而是上面管你喜欢不喜欢按给你的。 Scrum 根本不可能增进你的软件质量和技术,只能是优秀的人才才可能!使用Scrum的公司都是些吝啬鬼,他们不愿花大钱招优秀的人,他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率,Scrum成了push程序员最有用的工具。

Scrum delivers ‘business value’。不是这样的,实际上,Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队,那些人谁TMD愿意和苦逼的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝,花天酒地的,根本不会和你们那些奇怪的东西(如:backlog)或是那堆ugly的内向古怪的技术人员打交道,更别说什么技术了。所以,你的团队就像一个客服团队或救火队一样疲于奔命。

一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好,什么需要改进,并定义行动方案。你真的以为员工想进步吗?让他们不得不去想想自己和团队怎么进步,然后他们还不得不去执行行动方案。别天真了,人的天性是不喜欢改变的,人的天性是习惯于一些按部就般的事的,也许那样做令人讨厌,但是人家还是能干点东西出来。如果你逼着人家改变,你就是在压迫人家,人家自然会反抗。

Product Owner 专注于 ‘what’ 和 ‘why’ 的问题,开发团队决定 ‘how’。很不错的分工,于是可以造就一个即高速有重质量的团队。然而,这根本不行。你的Product Owner马上就想要这个功能,他才不管你的软件开发的技术难题,人家只要快,要你meet deadline,要你给我们重要的客户做出承诺。另外,你千万不要以为你们可以哄走这个初级的product owner,因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰,或者只是外包公司,你觉得可能吗?你觉得建立信任可能吗?

软件质量和生产率成正比。也就是说,质量越高,生产率越高。如果质量不高,你开发效率就会低下,但是谁管呢?我们朝九晚五的上班,质量好了也是做8小时,质量差了也是做8小时,无所为嘛。另外,我们的 project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以,这根本 不可能。

“是的,如果我们只做需要的功能,那么我们就会最低的成本,对吗?”,为什么这世上总是会有这些幼稚的人?这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格(可能还会有回扣),为了打单子,销售什么都干得出来,让你去做项目是因为你是廉价劳动力,而且,他们会不断地加需求,因为软件合同谈好的价格时候,连需求都没有,你去做了才有,还是模糊和不确定或根本就是错的,然后需求是越来越多,越改越多。等你精疲力尽的时候,你才意识到,销售早就把你卖了。