敏捷软件开发中的版本规划
如上图，开始之前我们假设产品backlog做过第一次梳理，并且总的故事点为127.
0. 在迭代开始之前，需要有一个产品backlog， 并且其中顶部的一些故事是相对更详细的。
1. 产品backlog需要符合 INVEST标准（ 参见我的一篇博客）。为了达到这个标准，需要产品负责人（PO） 和团队一起（早期有可能是团队代表或核心人） 对产品backlog进行优先级排序，估算（有故事点估算、 团队估算、三角估算等方法）等梳理工作。
2. 假设我们有一个产品backlog如附件所示， 每个sprint为3周， 第一个sprint团队计划完成21个故事点，基于以上假设， 这个项目需要6个sprint完成，即6x3=18周时间
3. 当第一个sprint结束的时候，很不幸， 团队只完成了14个故事点。那么需要基于这个事实， 对于发布计划进行调整。需要10个sprint完成， 即10x3=30周时间
4. 如果第二个sprint完成了18个故事点， 则基于第一个和第二个sprint的数据， 发布计划调整为8个sprint，即8x3=24周。此时， 由于有了2个sprint的数据，我们可以对发布计划的承诺是在
24周（最好的情况下）~30周（最差的情况下）之间。
5. 如果第三个sprint完成了20个故事点， 则基于前三个sprint数据， 发布计划调整为7个sprint，即7x3=21周。此时， 由于有了3个sprint的数据， 我们可以对发布计划的承诺是在21周（最好的情况下）~30周（ 最差的情况下）之间。
以此类推，一般来说，我们都是在3个迭代之后，对项目的发布计划做出承诺的。
================================================================
欢迎大家提出其他不同的版本规划方法，或者建议。谢谢！
-----------------------------------------------------------------------
微信公众号: 敏捷那些事儿（agileplus）
Agile1001公开课，每月一次，旨在推广和传播敏捷开发思想和Scrum，希望更多的开发者受益。欢迎关注。课程信息会定期发布，敬请关注。公开课汇总链接。