Cur*_*urt 19 project-management time-management
作为一名首席开发人员,我经常会接受新项目的规范,并且会被问及完成所涉及工作的编程方面需要多长时间.
我只是想知道其他开发者如何准确计算这些时间?
谢谢!
哦,我希望这不是一个有争议的问题,我只是想找到最好的技术!
Bri*_*Kay 19
估计通常被认为是一种黑色艺术,但它实际上比人们想象的更容易管理.
在Inntec,我们承包软件开发合同,大多数涉及固定成本.如果我们的估计一直没有,我们很快就会破产.
但是我们已经经营了15年并且我们有利可图,所以很明显这个整体评估是可以解决的.
入门
大多数坚持估计不可能的人正在做出疯狂的猜测.对于最小的项目,这可能偶尔会起作用,但它肯定不会扩展.为了获得一致的准确性,您需要一种系统的方法.
多年前,我的导师告诉我什么对他有用.这很像Joel Spolsky的旧估算方法,你可以在这里阅读:Joel on Estimation.这是一种简单,低技术的方法,对小型团队来说非常有用.它可能会破坏或需要修改大型团队,其中通信和流程开销占据每个开发人员时间的很大一部分.
简而言之,我使用电子表格将项目分解为小的(少于8小时)块,考虑到从测试,通信到文档的所有内容.最后,我为意外物品和错误添加了20%的乘数(我们必须免费修复30天).
要让某人估计他们没有参与设计是非常困难的.有些人喜欢让整个团队估计每个项目并使用最高的数字.我会说,至少,你应该做出悲观的估计,如果他们认为你已经离开,你的团队就有机会说出来.
学习和提高
您需要反馈来改进.这意味着跟踪您花费的实际时间,以便您可以进行比较并调整您的估计意义.
现在在Inntec,在我们开始处理一个大项目之前,电子表格行项目在我们的看板上成为便利贴,项目经理每天都会跟踪它们的进度.任何时候我们过去或者有一个我们没有考虑的项目,这会变成一个小小的红色粘性,它也会进入我们的烧毁报告.这两个工具共同为整个团队提供了宝贵的反馈.
这是一张典型的看板上的照片,大概是一个小项目的一半.
您可能无法读取列标题,但他们会说Backlog,Brian,Keith和Done.积压按组(管理区域等)细分,开发人员有一列显示他们正在处理的项目.
如果你仔细观察,所有这些笔记都有估计的小时数,而我列中的那些笔记,如果要加上它们,应该等于8,因为这是我工作日的小时数.一天中有四个是不寻常的.凯斯的专栏是空的,所以他可能在这一天出局了.
如果你不知道我在谈论什么:站立式会议,scrum,烧毁报告等,那么请看一下scrum方法.我们没有遵循它,但它有一些很好的想法,不仅用于做估计,而且用于学习如何预测你的项目何时会在新工作被添加并且估计被错过或达到或超过时发生(确实发生了) ).您可以查看这个名为"烧毁报告"的精彩工具并说:我们确实可以在一个月内发货,让我们看看我们的烧毁报告,以确定我们正在削减哪些功能.
FogBugz有一种称为循证调度的东西,它可能是一种更容易,更自动化的方式来获得我上面描述的好处.现在我正在尝试一个几周内开始的小项目.它有一个内置的烧毁报告,它适应您的日程安排不准确,因此可能非常强大.
更新:快速说明.几年过去了,但到目前为止,我认为这篇文章中的所有内容今天仍然存在.我更新它使用单词kanban,因为上面的图像实际上是看板.
| 归档时间: |
|
| 查看次数: |
5123 次 |
| 最近记录: |