想象一下，您没有功能蔓延的问题，您有一个积极且稳定的团队，明确定义的问题要解决，并且您了解与您的项目相关的领域/语言/工具。
您如何遵守时间表并完成 1.0 里程碑？
您对迭代运输的方法是什么？
我想特别为一个很少或几乎没有沟通问题的小团队提供建议。
Camilo Díaz
问问题
811 次
9 回答
19
- 专注于功能而不是实现任务。
- 以迭代方式工作（如每周或每两周一次）。
- 按优先级顺序将工作功能发布到您的暂存环境。
- 随时对您的代码进行单元测试，这样您就不会因为接近发布日期时呈几何级数增加的错误列表而减慢您的速度。
- 准备从不太重要的功能中减少范围。东西总是比你想象的要花更长的时间。
- 确保提前勾勒出 UI（如果有 UI），并将其展示给潜在用户。
- 测试，测试，再测试一些。这似乎违反直觉，但它节省的时间多于花费的时间。
于 2008-10-06T04:32:28.057 回答
5
这可能是一个乌托邦式的场景；-)。但无论如何，如果没有功能蔓延，非常好的团队和明确定义的需求，绝对没有沟通问题，那么按时交付产品的最佳方式可能是
- 每周与团队开会以评估当前状态（PM 与团队，如果有 PM）
- 团队负责人可以每天与团队成员举行一次小型会议，以评估他们对委派给他们的问题/要求的状态。如果有问题，那么他/她应该采取必要的步骤来解决问题。
- 项目计划跟踪和工作委派（团队负责人需要了解每个团队成员的个人优势才能适当委派工作）。
- 在技术允许的范围内，测试可以自动化。
- 每个团队成员对工作的所有权。
归根结底，归根结底是一个人对工作的热情。
只是我的 2 派斯 ;-)
于 2008-10-06T04:37:44.240 回答
4
这并不能回答你的问题，但我认为它确实表明需要坚持你的日程安排——即使你落后一天，你也需要以某种方式赶上它。（不幸的是，神话人物月的其余部分都是关于在大多数项目中如何没有“不知何故”......）
另外，请查看FogBugz等产品中的基于证据的调度。这将为您提供有关产品可能发货时间的最新估计——事实上，它提供了一个日期范围，以及每个日期的概率。如果您看到您可能的发布日期已超过截止日期，这将让您知道您需要对此采取一些措施——并希望有足够的时间来产生效果。
于 2008-10-06T04:41:33.530 回答
3
以前的海报遗漏了一个小点。为了满足最后期限，首先应该定义现实的时间表。项目应该分解成小任务，这取决于项目的大小，但在我的世界中，项目大约需要 3-4 个月，我们试图将它们分成最多 2-3 天的任务。通过这种方式，时间估计大多是现实的，风险会提前计算并添加到建议的时间表中。
于 2008-10-06T05:11:22.067 回答
3
这个帖子里有很多很好的建议。我唯一要补充的是采用定期发布时间表。几年前我的公司改用了这个，一开始很痛苦，但它确实有很多好处，其中最大的好处是让人们可以轻松地推迟功能。
推迟功能是可以的，因为您知道您的功能可以使其进入下一个版本，并且您知道该版本何时发布。这意味着，与其在最后一分钟急于获得半生不熟的功能，您可以花更多时间在下一个版本开始时将其加入。
于 2008-10-06T16:40:12.690 回答
3
除非销售/营销/管理的时间表不合理，否则您几乎已经排除了项目无法按时交付的所有原因。软件开发方法论的历史是一系列解决方法、减少影响和/或避免的方法：
- 定义不明确的范围
- 特征蠕变
- 缺乏领域知识
- 有沟通问题的大型团队
- 没有动力/不称职的开发人员
于 2008-11-26T03:40:47.907 回答
2
了解客户的关键任务功能。保护他们的进步。80% 的成功来自 20% 的工作，这通常是非常正确的。
于 2008-11-26T13:50:07.163 回答
1
为了产品团队的利益，使用当前接受的构建阶段定期（每月？每周？）产品演练。尽早开始这些。演示每个功能，无论它们当前的可用性如何；不要跳过那些落后的。
关键是让利益相关者清楚地了解项目过程中产品的当前状态。通过这种方式，决策者更有可能及时解决进度风险，而不是危及发货日期。
于 2008-11-26T04:04:31.480 回答
1
我想说的是，您可以选择功能集或发货日期，但不能同时选择两者。
以下是一些个人想法： - 不要乐观 - 先做困难的部分 - 不要在不推迟进度的情况下添加功能 - 以这样的方式编写功能，以便您可以将它们放到计划中
于 2012-02-27T01:39:45.980 回答