软件项目的任务积压管理

On

这是一篇关于如何管理软件项目需求、任务、缺陷的文章,来自大名鼎鼎的Joel Spolsky, StackOverflow的创始人。 想像一下你生平第一次来的一家面包工厂。开始这里看起来像是一个无法理解的杂乱不堪的机器,一些工人在里面东奔西跑的忙碌着。仔细再看看,你就会看到一些你认识的东西。一些桶装的芝麻,大桶大桶的面团,一些小面球,还有些烤好了的面包条。 这些都是库存,或者叫积压。积压逐渐的堆在机器之间。在机器边上,是大桶的将被撒在汉堡面包片上的芝麻。生产线的尽头,是些装满面包的箱子和空箱子。它们在等着被卡车运到商店去。 维持积压需要费用。假设你的面包厂有6个50吨的面粉贮仓。贮仓空下来时,你就会把它填满。这意味着平均你有150吨面粉积压。按照现在的价格计算,你需要73000美刀来维持这个积压。一直需要占用这么多钱。 积压还有别的消耗,比如腐烂、变坏。面粉可以储存几个月,但是面包从它们出炉的那一刻起价值就在不断的降低;24小时之后,基本上就一文不值了。 为什么还要要保持有库存,有积压呢?因为缺货也会造成损失。如果订购芝麻需要2天,在你的芝麻用光的时候,你就2天没办法生产面包。库存可以防止类似的生产流程上的阻塞。丰田汽车的精益生产系统和限制理论,可以指导我们优化每一个生产环节上需要多少缓冲库存。 为什么我会关心这些呢?因为软件开发流程上也有几个主要的积压堆积点。这些环节上的堆积,会造成大量的时间和金钱的浪费。 你也许会问:“什么?软件怎么能跟工厂比呢?” 好吧,想像一下,把产品想法当作生产原料。根据你的流程不同,产品想法可能会经过下面这几个开发阶段,才最终完成为客户看到的软件的特性。 特性决策阶段 (我们真的需要实现这个特性吗?) 设计阶段 (特性描述, 白板讨论, 原型测试, 等等) 实现阶段 (软件编码) 测试阶段 (抓虫) 修复阶段 (杀虫) 部署阶段 (把代码发送给客户,或者部署到WEB服务器,等等) (备注: 不是,这可不是“瀑布式开发”。真的不是。 真不是。 闭嘴。) 在这些阶段之间,就可能产生积压。比如:当程序员完成了代码开发(阶段3 实现阶段),把代码交给测试人员去测试(阶段4 测试阶段)。任何时候,都有一定量的的代码等着被测试。这就是代码积压。 代码积压的代价是巨大的。它很可能累积成6到12个月的工作量,导致生产线卡壳,产品交不到客户手里。这甚至有可能造成巨大的差别,就像时髦的尖端产品(如iPhone)跟永远在别人屁股后面追赶的产品(如Windows Phone)这样的差别。几乎不会有人会去购买Windows Phone,尽管iPhone其实仅仅比它先进6个月而已。很多市场都有网络效应,领先者意味着赢取几乎所有的份额。所以在开发流程上消除积压,能创造或毁掉一个产品。 现在我们来回顾一下积压累积的3个主要环节。 1.产品特性点子库 每个产品都有很多新点子,你实现点子的速度永远赶不上新点子涌现的速度,所以你就把他们记录下来,这就形成了产品特性点子库。点子库里很多点子其实是坏点子,你把他们记录下来,只是为了避免伤害想出这些点子的人的感情而已。点子库看起来能让每个人都感觉良好。 问题是,这些点子中90%的点子永远也不会被实现。所以花在这些永远也不会被实现的点子上的分分秒秒,记录、设计、思考、讨论,都是浪费时间。当我听说产品团队定期的开展“点子库梳理”会,在会上仔细的研究这些永远也不会被实现每一个点子,每天、每周细心的浪费着自己的时间和精力,我戳瞎自己眼睛的心都有。 建议:不要让点子库里的工作超过一或两个月。如果点子库满了,不要加入新的项目,除非你删除掉一些别的项目。不要花时间细化说明、设计、讨论这些点子库里的项目。产品特性点子库事实上应该被视为是一个关于你现在还不用讨论或开始工作的项目的列表。 2.缺陷数据库…

当敏捷变得乏味

On

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

Scrum敏捷软件开发的7个习惯

On

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