再谈scrum

从上一次写“scrum“到现在,已经有一年多的时间了,期间碰到很多问题,也有不少收获。目前离开了原来的项目,回到了“瀑布”的怀抱,但对于scrum,还是有不少体会可以分享。

scrum和GTD

scrum和GTD有很多相同的地方。首先,他们的问题域就很相似,都是为了应对变化的复杂的任务。如果你可以确切的定义(define)你的任务,比如耕一块地,或者使用限定技术针对一个明确且不会变更的需求完成一个软件,你即不需要GTD也不需要scrum。
scrum有着和GTD几乎完全一致的流程。GTD中的“collection”对应scrum中整理Product Backlog的过程,GTD中确定“Next Actin”对应scrum中团队确定“Sprint Backlog”。它们又都存在回顾(review)的过程,且都讲究流程的回归反复(iteration)。
可以说,如果你理解GTD的精髓,scrum对你来说就是水到渠成,反之亦然。从另一方面,也能说明GTD和scrum都不是石缝中蹦出的猴子,都来源于现实,都为了解决现实的问题。

影响scrum不能正常实施的因素

scrum的失败或者效果不理想通常由以下因素造成:

  1. 对未知结果的恐惧心理。出于习惯,大多数人更愿意事先得到一个固定的最终发布日期和一个承诺的结果,哪怕到了日期无法得到结果再延期。我们常常都需要这样的心理安慰,宁愿把苦头放在后面而不愿正视软件开发的规律。
  2. 在sprint过程中加入新需求的诱惑。很难很难抵御这样的诱惑,scrum第一杀手。
  3. 不愿意调整目标而任意延长sprint的时间。不知不觉你就又回到了老路上。
  4. 急于看到结果而压缩sprint的时间。能得到一定的效果,但总体上消耗的更多的资源。我们曾经一度这样做,每周末完成一个可以审查的结果,很有效,但很累人,在整合上花了太多的力气。

scrum的实施

除了按照scrum的流程按部就班的执行,需要理解scrum的几个要点,否则很难达到效果。

  1. 理解软件开发过程中的几个变量:成本、期限、质量和功能。如果这四个变量都能确定,我们就在家数钱就可以了。有时候我们有机会尽量确定期限和功能,CMM之类的软件方法就是着重于在这种情况下如何尽可能保证质量。有时候我们希望通过加人手,提高成本来保证期限、功能和质量不受影响,《人月传说》有不少关于这样是否可行的讨论。也有的时候,频繁的需求变化导致功能无法确定,期限一拖再拖,成本不断增加,质量无从保证,一片混乱(chaos),这时候我们就可以通过scrum,先确定期限和成本,在短期内一定程度上确定需求,让这个四元方程式好解一些。
  2. 确保开发团队在sprint中不受干扰,不被分心。如果能理解上一条,你就能理解为什么在sprint中不随意添加修改需求对团队开发很重要。永远变化的需求只能导致永远不能发布的产品。scrum同时保证了你有足够的机会在下一个sprint实现新的需求,隔这样一段时间,你会对新需求有更多的了解,很有可能它并没有你想像得那么重要。
  3. 注意任务划分的粒度。任务划分的粒度越小,团队对任务的理解也越透彻,对时间的估计也会越准确。
  4. 彼此信任。特别是老板,应该信任他的团队,有能力使用正确的方法完成应该完成的工作,不然你雇他们干什么?

scrum不是万灵药,不可能解决所有的问题。但是如果你要使用scrum,在完全领会它之前,最好按部就班的执行scrum要求的每个步骤,遵守每个原则,至少可以少走一些弯路。InfoQ上有一个Scrum Checklists,或许有帮助。

最后推荐一本书:
Scrum
相比微软出版社的Agile Project Management with Scrum,我更喜欢这本,基本上是从实例出发,让你很快能了解scrum所针对的问题以及如何通过scrum来解决这些问题,读起来很流畅,不费力气。读完这本,再读微软那本效果会比较好。

6 条评论

软件公司是怎么死掉的

这里看到一篇有趣的文章,叫“How Software Companies die”,是Orson Scott Card 1995年发表在Windows Sources上。Orson Scott Card是科幻小说作家,星云雨果都得过,我看过他的《安德的游戏》和《死者代言人》,可没想到他对软件开发也这么一针见血,顶得上一本The art of program management了。
节译转载:

软件公司怎么失控的和完蛋的?通常是来了一个有个性的管理人员,这老兄一看,这帮程序员怎么这么……不顺眼啊?脏兮兮,乱糟糟,不配合,他们看起来是多无趣的一群人啊!最糟糕的是,他们还笑话你!于是对他们进行管理……这下规范了,但是,程序员们被伤害了,他们被要求要参加会议,做计划,写报告,严格按照流程,千万千万不要去动别人的代码!程序员觉得自己就象过起了外星人的生活……于是,最好的程序员走了,有的开始怠工,甚至破坏……蜂房毁了。管理者舒服了,因为好像事情开始受控了,大家开始打领带了;但是Bug开始成堆出现,市场丢失,最后,关门大吉。

原文:

How Software Companies Die

By Orson Scott Card
The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you’re caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you’re a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don’t care, because your program runs, and the code is fast and clever and tight. You won. You’re aware that some people think you’re a nerd. So what? They’re not players. They’ve never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don’t care about the opinions of civilians. You’re building something intricate and fine. They’ll never understand it.

BEEKEEPING

Here’s the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can’t exactly communicate with them, but you can get them to swarm in one place and when they’re not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that’s less than you might think. You see, all these programmers keep hearing their parents’ voices in their heads saying “When are you going to join the real world?” All you have to pay them is enough money that they can answer (also in their heads) “Geez, Dad, I’m making more than you.” On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people’s code only long enough to sneer at it. He’s a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money.

OUT OF CONTROL

Here’s the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But…control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say.

SMOKED OUT

The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team’s code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they’re surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that’s it.

发表评论

不要伪装最后期限

总有一些自作聪明的项目管理认为把最后期限打个折告诉开发人员会让项目按期完成。这里有篇文章告诉大家,这么做除了搞糊涂大家,可能的结果就是:

  • 大家发现你在撒谎
  • 大家不会再信任你
  • 大家会用同样不真实的话敷衍你
  • 大家会认为你每次提出的最后期限都是假的

发表评论

Recent Posts:

Recent Comments:

Archive:

Tags:

Bookmarks:

My music:

About Me:

I am a software engineer in Beijing, China. I write code for work and for fun. I am interested in web technology, life hacking and console games. This blog is dumped from my left brain.
View Robin Lu's profile on LinkedIn

My Flickr:

    scribbleAt Modern Sky Music FestivalIMG_0389IMG_0312urumqi panaramaIMG_9664

Friends: