Project management 对数据驱动开发模型的建议

有人对在日期驱动的开发环境中工作有什么建议吗？基本上，我们每8周更新一次RIA。我在一个不到5名开发人员的小团队中工作，因此我关心如何管理不适合小周期的长期功能。此外，我还担心处于一种持续的紧张状态。

规则1。延迟功能

如果没有完成，（1）推迟到下一个版本，然后（2）找出原因

“推动”、“加班”和“更聪明而不是更努力地工作”实际上没什么作用。关键是对你的计划要实事求是

计划是预测未来的一种尝试

你无法预测未来

因此，你的计划将是错误的。总是

与其对“计划”、“承诺”和“客户期望”大喊大叫，不如考虑一下这一点

您的目标是以用户无法使用的速度交付功能。

争取2周的增量。经过测试、集成、准备生产

在前四次冲刺之后，你已经8周了，准备发布了。你会建立一些东西，延迟一些东西，最后会有一个延迟列表

通常，许多新特性的周期会让用户为变化的速度而烦恼。你不会发布每两周的sprint，因为用户不喜欢这样。如果你发布得太频繁，你会被告知将这些特性捆绑到一个更大的版本中，这样用户看到的变化速度就会变慢

你还必须做很多小循环。以两周的冲刺为目标，在那里你可以从你的积压工作中建立一些小的子集

---

你只是不发布每个小周期。

8周的时间很长……与一些发布1周或2周的商店相比……所以你很幸运。一些建议：

• 在每次发布后，在客户/业务负责人的帮助下，确定维护/错误修复的优先顺序，并从列表的顶部开始，按自己的方式进行修复…（听起来很简单，直到最后一分钟你必须在那里）
• 就规划而言，周期“D”的开发实际上应在周期“C”中开始，并应在交付前1-2周结束，以确保适当的QA和修复发现的问题
• 总是会有一些“事情”让你对推迟交货日期产生疑问-不要屈服-缩小范围/紧跟交货日期
• 将较大的交付分解为较小的交付，并以“存在”但没有“活动”（beta）的方式进行推广-此增量工作可能会增加一些额外的工作，但应减少交付结束时QA/bug相关的问题和风险
• 跟踪重要指标-用于规划和显示进度

---

看看这篇InfoQ演示文稿。这些人每周都在一个面向公众的高容量RIA网站上发布功能。他们谈论实现跨越多个迭代的特性。这是一块好表。