Leon's blog

每天活的有趣一点

正在浏览标签为 scrum 的文章

软件项目的任务积压管理

抢沙发

这是一篇关于如何管理软件项目需求、任务、缺陷的文章,来自大名鼎鼎的Joel Spolsky, StackOverflow的创始人。

想像一下你生平第一次来的一家面包工厂。开始这里看起来像是一个无法理解的杂乱不堪的机器,一些工人在里面东奔西跑的忙碌着。仔细再看看,你就会看到一些你认识的东西。一些桶装的芝麻,大桶大桶的面团,一些小面球,还有些烤好了的面包条。

这些都是库存,或者叫积压。积压逐渐的堆在机器之间。在机器边上,是大桶的将被撒在汉堡面包片上的芝麻。生产线的尽头,是些装满面包的箱子和空箱子。它们在等着被卡车运到商店去。

维持积压需要费用。假设你的面包厂有6个50吨的面粉贮仓。贮仓空下来时,你就会把它填满。这意味着平均你有150吨面粉积压。按照现在的价格计算,你需要73000美刀来维持这个积压。一直需要占用这么多钱。

积压还有别的消耗,比如腐烂、变坏。面粉可以储存几个月,但是面包从它们出炉的那一刻起价值就在不断的降低;24小时之后,基本上就一文不值了。

为什么还要要保持有库存,有积压呢?因为缺货也会造成损失。如果订购芝麻需要2天,在你的芝麻用光的时候,你就2天没办法生产面包。库存可以防止类似的生产流程上的阻塞。丰田汽车的精益生产系统和限制理论,可以指导我们优化每一个生产环节上需要多少缓冲库存。

为什么我会关心这些呢?因为软件开发流程上也有几个主要的积压堆积点。这些环节上的堆积,会造成大量的时间和金钱的浪费。

你也许会问:“什么?软件怎么能跟工厂比呢?”

好吧,想像一下,把产品想法当作生产原料。根据你的流程不同,产品想法可能会经过下面这几个开发阶段,才最终完成为客户看到的软件的特性。

  1. 特性决策阶段 (我们真的需要实现这个特性吗?)
  2. 设计阶段 (特性描述, 白板讨论, 原型测试, 等等)
  3. 实现阶段 (软件编码)
  4. 测试阶段 (抓虫)
  5. 修复阶段 (杀虫)
  6. 部署阶段 (把代码发送给客户,或者部署到WEB服务器,等等)

(备注: 不是,这可不是“瀑布式开发”。真的不是。 真不是。 闭嘴。)

在这些阶段之间,就可能产生积压。比如:当程序员完成了代码开发(阶段3 实现阶段),把代码交给测试人员去测试(阶段4 测试阶段)。任何时候,都有一定量的的代码等着被测试。这就是代码积压。

代码积压的代价是巨大的。它很可能累积成6到12个月的工作量,导致生产线卡壳,产品交不到客户手里。这甚至有可能造成巨大的差别,就像时髦的尖端产品(如iPhone)跟永远在别人屁股后面追赶的产品(如Windows Phone)这样的差别。几乎不会有人会去购买Windows Phone,尽管iPhone其实仅仅比它先进6个月而已。很多市场都有网络效应,领先者意味着赢取几乎所有的份额。所以在开发流程上消除积压,能创造或毁掉一个产品。

现在我们来回顾一下积压累积的3个主要环节。

1.产品特性点子库

每个产品都有很多新点子,你实现点子的速度永远赶不上新点子涌现的速度,所以你就把他们记录下来,这就形成了产品特性点子库。点子库里很多点子其实是坏点子,你把他们记录下来,只是为了避免伤害想出这些点子的人的感情而已。点子库看起来能让每个人都感觉良好。

问题是,这些点子中90%的点子永远也不会被实现。所以花在这些永远也不会被实现的点子上的分分秒秒,记录、设计、思考、讨论,都是浪费时间。当我听说产品团队定期的开展“点子库梳理”会,在会上仔细的研究这些永远也不会被实现每一个点子,每天、每周细心的浪费着自己的时间和精力,我戳瞎自己眼睛的心都有。

建议:不要让点子库里的工作超过一或两个月。如果点子库满了,不要加入新的项目,除非你删除掉一些别的项目。不要花时间细化说明、设计、讨论这些点子库里的项目。产品特性点子库事实上应该被视为是一个关于你现在还不用讨论或开始工作的项目的列表。

2.缺陷数据库

缺陷数据库显然是很有必要的。缺陷报告应该完整、准确、可操作。但是我注意到在很多公司,大家似乎不想漏掉任何一个缺陷报告,这直接导致缺陷库的爆炸。你某天醒来,突然发现缺陷库里有3000个缺陷,其中一些已经太旧失去意义了,一些永远也无法重现,还有更多一部分太琐碎根本没有修复的价值。你仔细想想,就会意识到经年累月的时间被花在准备这些缺陷报告上,你问自己,我们怎么会即有一个很好的、客户喜欢的、每天使用的产品,同时又有一个有3000个缺陷的缺陷数据库呢?这时候你会意识到也许你花太多时间在缺陷数据库上了,这些时间本可以花在构建更好的产品上的。

建议

  1. 使用一个筛选策略决定:一个缺陷是否值得记录
  2. 不要让缺陷库的工作量(按照修复时间计算)超过两周
  3. 如果缺陷库里的缺陷超过了这个限制,停下手头的工作,去修复缺陷,直到你觉得自己在修复都是些无聊的缺陷为止。这时候你可以关闭这些缺陷,把他们标记为“won’t fix”。不用担心会标错,如果缺陷确实严重,它还会再次出现的。

3.未发布的产品特性

还有很多公司现在还在按照季度或者每年的版本发布,通常这是由于他们的部署过程比较昂贵。比如操作系统或其他任何需要每个用户自己安装的软件,通常是这样批量升级的。

未发布的产品特性,是最昂贵的软件积压之一。它本来可以帮你赚钱的,但是现在它却只能呆在仓库里,眼睁睁的看着别人的产品已经有了同样的特性。

更有害的是,有时候你并不能感受到这种痛苦,因为你团队里的每个人都已经使用这个新特性很久了。我可以肯定的说,在微软每个人都已经很happy的使用Windows 8一年多了,所以他们感觉不到那些天天在苹果的Mac OS X猎豹系统堆里兜售Windows 7的OEM提供商的痛苦。

建议:不要让完成的特性堆在那里不能为你赚钱。改进你的部署流程,使原来客户需要一年才能得到的特性几个月就能得到。如果你已经能按月发布产品了,那就想想能不能按周发布。不断提高发布的频度,不断减少每次发布的大小。

我是怎么想起这些的呢?

因为在Fog Creek,我们有全部上面说的三种软件积压:恐怖冗长的点子库、过度膨胀的缺陷库、等了一年的也没发布的已完成的新特性。所有这些每天在屁股后面盯着我们。我意识到我们需要一个系统来限制积压,使它不再堆积起来了。

我本来的想法是做一个叫Five Things的产品。这是一个项目管理工具,里面的用户最多只能被分配5个任务:2个他正在做的,1个接下来可以做的,还有几个正在计划中的。这个想法最终没有实施(但是如果你愿意,搞一个试试),但是却演化出了Trello

Trello里的任务在没超过一定数量的时候工作的很好,但是当一些列表里有太多的任务卡片的时候就开始显得拥挤了。关键就在这里:当积压开始涌现的时候,对你来说是显而易见的,很容易观察到。看看这里,这是Trello团队的开发看板

每天你看到你的Trello看板,看到17个已完成了的特性,他们都可以随时发布,但是不知道什么原因还没有发布。你马上就能发现瓶颈在哪里,并消除它。

每次有人向你建议一个疯狂的新点子的时候,你就可以看看你的产品特性积压,如果已经太长了,你就知道现在也许不需要浪费时间在这些疯狂的点子上。

希望这样能帮助你,花更少的时间和精力在那些永远也见不到天日的事情上。“梳理积压。” Sheeeesh。

参考:

当敏捷变得乏味

抢沙发

今天看到一片ScruM 与精益( Lean ) 软件开发及应用,对其中一段关于敏捷开发的问题颇有同感,摘录下来。以后有机会试试文中提出的解决办法有没有效果。

在第一年,敏捷开发对于整个开发团队来说可能还是比较新鲜的。但是开发团队很快就会对敏捷方式,特别是每天的 Scrum 会议感到乏味。一旦感到乏味并开始松懈,开发团队要么会放弃敏捷模式回到原有的开发模式上,要么会停留在对敏捷开发的肤浅应用层次上。这样一来,团队的积极性和创造性会受到打击,停滞不前。这重情况下,结合精益( Lean )开发方法能有效的解决这些问题。精益( Lean )模式提倡持续不断地改进, 减少流程中的浪费。这个概念应该被注入到整个团队中,让团队形成精益的思维和长期的习惯。

最近看了些关于Scrum的资料,也看多很多公司使用类似的开发模式。总觉得,敏捷的开发模式要求开发人员要有很高的责任感和主动性。不管怎样,Implementing Lean Software Development一书中,作者提出来敏捷开发的的7个习惯还是值的一读的,在这里做个记录。似乎是定律来着,但是我习惯习惯了,:)。
Scrum开发过程
继续阅读