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

规则1.延迟特征。

如果没有完成,(1)推迟到下一个版本,然后(2)找出原因。

2. 你无法预测未来。

3. 因此,你的计划将是错误的。总是。

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

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

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

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

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

你只是不释放每个小循环。

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

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