准时交付软件的最佳实践

1. 关注功能而不是实现任务。
2. 在迭代中工作(如每周或每两周)。
3. 按照优先顺序将工作特性发布到登台环境中。
4. 单元测试你的代码,所以你不会因为一个错误列表而放慢速度,当你接近发布日期时,它会以几何形式增加。
5. 准备好从不太重要的特性中缩小范围。事情总是比你想象的要长。
6. 确保您提前画出了UI(如果有UI),并将其展示给潜在的用户。
7. 测试,测试,再测试一些。这似乎有违直觉,但它节省的时间比需要的要多。

这可能是一个乌托邦式的场景;-)。但是无论如何,如果没有特性蔓延,非常好的团队和明确定义的需求,绝对没有通信问题,那么最好的按时交付产品的方法可能是

1. 每周与团队会面以评估当前状态(与团队会面,如果有PM)
2. 团队负责人可以与团队成员进行一次小型的日常会议,以评估他们对委托给他们的问题/要求的状态。如果存在问题,他/她应采取必要步骤解决问题。
3. 项目计划跟踪和工作授权(团队领导需要了解每个团队成员的个人优势,以便适当地授权工作)。
4. 测试可以在技术允许的范围内实现自动化。
5. 每个团队成员对工作的所有权。

一天的结束,归根结底就是一个人对自己的工作有多热情。

只有我的两桶;-)

Question: How does a large software project get to be one year late? Answer: One day at a time!

这并不能回答你的问题,但我认为这确实表明你需要坚持你的时间表——如果你甚至落后一天,你需要以某种方式赶上它。(不幸的是,剩下的神秘人月都是关于在大多数项目中没有“不知何故的”……)

另外,请看一下基于证据的产品调度,例如 FogBugz . 这将给您一个最新的产品可能发货时间的估计——事实上,它给出了一系列日期,以及每个日期的概率。如果你看到你可能的发布日期超过了最后期限,这会让你知道你需要做些什么——希望有足够的时间来产生效果。

以前的海报漏了一点。为了满足最后期限,首先应该确定所有实际的时间表。 项目应该分成小任务,这取决于项目的大小,但在我的世界里,项目大约需要3-4个月,我们试图将它们分成最多2-3天的任务。这样,时间估计基本上是现实的,风险是提前计算并添加到计划中的。

这方面有很多好的建议。我唯一需要补充的是采用一个定期的发布时间表。几年前,我的公司就转向了这一点,起初很痛苦,但它确实有很多好处,其中最大的好处是允许人们轻松地推迟特性。

推迟特性是可以的,因为您知道您的特性可以进入下一个版本,并且您知道该版本何时发布。这意味着,您不必在最后一分钟匆忙地将半成品特性引入,而是可以花费更长的时间,并在下一个版本的开始时将其引入。

除了销售/营销/管理部门不合理的时间安排之外,你几乎已经排除了项目不能按时交付的所有原因。软件开发方法的历史是一系列方法的集合,这些方法可以解决、减少和/或避免:

• 范围界定不清
• 特征蠕变
• 缺乏领域知识
• 有沟通问题的大团队
• 不活跃/不称职的开发人员

了解客户机的关键任务特性。保护他们的进步。通常情况下,80%的成功来自于20%的工作。

舞台 周期性 (每月)?每周?)为了产品团队的利益,使用当前接受的构建进行产品演练。尽早开始。演示每个特性,不管它们当前的可用性如何;不要跳过那些落后的特性。

重点是让涉众清楚地了解项目过程中产品的当前状态。这样决策者更有可能迅速处理进度风险,而不是危及船舶日期。

我想说,您可以选择一个功能集,或者一个发货日期,但不能同时选择两者。

以下是一些个人想法: -别乐观 -先做最难的部分 -添加功能时不要忽略计划 -以这样一种方式编写特性,您可以将它们放到符合计划的位置。

http://shipcamp.com