按时发运软件的最佳做法

Question

想象一下，您没有功能蔓延的问题，您有一个积极稳定的团队，明确定义的问题需要解决，并且您知道与您的项目相关的域/语言/工具。

你如何坚持计划并完成1.0里程碑？ 您对迭代运送的方法是什么？

我想专门针对一个小团队的建议，那里很少或几乎没有沟通问题。

Answer 1

1. 专注于功能而非实施任务。
2. 在迭代中工作（如每周或每两周一次）。
3. 按优先顺序将工作功能发布到您的登台环境。
4. 随时对您的代码进行单元测试，因此您不会因为接近发布日期时几何级别增加的bug列表而放慢速度。
5. 准备从不太重要的功能中切除范围。东西总是比你想象的要长。
6. 确保提前勾画出UI（如果有用户界面），并将其展示给潜在用户。
7. 测试，测试和测试更多。这似乎违反直觉，但它比节省时间更多。

Answer 2

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

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

一天结束时，它归结为一个人对工作的热情。

只是我的2个人; - ）

Answer 3

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

这不能解决你的问题，但我认为它确实需要坚持你的日程安排 - 如果你甚至落后一天，你需要以某种方式赶上它。 （不幸的是，“神话人月”的其余部分都是关于如何在大多数项目中没有“某种方式”......）

另外，请查看FogBugz等产品中的基于证据的计划。这将为您提供产品何时可能发货的最新估计 - 事实上，它提供了一系列日期，每个日期的概率。如果您发现可能的发布日期超过截止日期，这将让您知道您需要对此做些什么 - 希望有足够的时间来发挥作用。

Answer 4

以前的海报错过了一个小点。为了满足截止日期，首先要确定实际的时间表。 该项目应该分解为小任务，这取决于项目规模，但在我的世界中，项目需要3-4个月，我们试图将它们分成最长2-3天的任务。这样，时间估计大多是现实的，并且预先计算风险并将其添加到建议的时间表中。

Answer 5

这个帖子里有很多好建议。我唯一需要补充的是采用定期的发布时间表。几年前我的公司转而使用它，起初很痛苦，但确实有很多好处，其中最大的好处是让人们可以轻松推迟功能。

推迟功能是可以的，因为您知道您的功能可以进入下一个版本，并且您知道该版本何时发布。这意味着您可以花费更长的时间在下一个版本的开头使用它，而不是急于在最后一分钟获得半生不熟的功能。

Answer 6

除非销售/营销/管理层有不合理的时间表，否则您几乎排除了项目未按时发货的所有原因。软件开发方法的历史是一系列解决方法，减少和/或避免的影响：

• 范围定义不明确
• feature creep
• 缺乏领域知识
• 有沟通问题的大型团队
• 无动机/无能的开发者

Answer 7

了解客户端的关键任务功能。保护他们的进步。通常，80％的成功来自20％的工作。

Answer 8

为了产品团队的利益，

使用当前接受的构建阶段 定期 （每月？每周？）产品演练。尽早开始。演示每个功能，无论其当前的可用性如何;不要跳过那些落后的人。

重点是让利益相关者清楚地了解产品在整个项目过程中的当前状态。这样决策者就更有可能迅​​速解决进度风险，而不是危及发货日期。

Answer 9

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

以下是一些个人想法： - 不要乐观 - 先做好难点 - 不要在不滑倒计划的情况下添加功能 - 以这样的方式编写功能，您可以将其删除以达到计划

http://shipcamp.com