在敏捷项目管理中如何做好release management？

[亦弄]

有哪位高手分享一下如何在敏捷项目里做好产品的release management的经验？因为敏捷讲究拥抱变化，这会导致无法准确估算若干个迭代之后产品的功能能够实现到何种程度。

[PM之友]

楼主虽然问的是release management的问题，但实际想解决的是在采用敏捷方式达到项目目标时，如何应对时间约束的问题吧？解决已经没有时间了确还没实现项目目标的问题。
采用敏捷方式开发，需要与客户达成一致，哪些对客户来说是有价值的东西，哪些价值高，哪些价值低，以此来安排各个迭代的内容，因为项目的目标是确定的，所以项目的大体范围还是确定的，所谓拥抱变化只是在这个范围之内的变化。所以，如果项目的目标明确了，并且对客户来说有价值的东西也明确并且排好优先级的话，楼主的问题应该就可以解决了。
另外，楼主对敏捷的理解可能存在偏差，建议再找本书详细看看。

[以专业开发人员为伍]

[Quote=引用楼主 bwwlpnn 的回复:]
有哪位高手分享一下如何在敏捷项目里做好产品的release management的经验？因为敏捷讲究拥抱变化，这会导致无法准确估算若干个迭代之后产品的功能能够实现到何种程度。
[/Quote]

你的理解显然是错误的。

首先项目肯定是有一年、两个、乃至两周以内的规划的。而灵活调整的只是功能点（用户故事），保证里程碑计划仍然是重点。只不过手段应该灵活变通，例如同样是达到了一个“提高用户缴费速度50%”的目标，可以有多种选择，这是拥抱变化而来的。

拥抱变化是靠技术，不是靠行政手段。靠行政手段那种人只会分解任务、施加压力，而靠设计技术的人则可以灵活调整技术，他可以清楚地看到每一个小时、每一个半天的任务以及之间的架构关系，因此可以灵活调整前后次序，调整它们发布时间。

[以专业开发人员为伍]

显然需要更加细致，更加专业，更加重视立刻进行测试和每天都以成功发布然后第二天、第三天再重构扩展这种思路去开发。这是更加高强度地发布产品，只不过把那种垃圾文档书写习惯扔掉而强调传统设计中可测试、可操作、可自动化处理的部分，不是什么都丢掉。

[以专业开发人员为伍]

项目肯定是有一年、两个、乃至两周以内的规划的 --> 项目肯定是有至少一年、两月、乃至两周以内的规划的

[yufei_yuxuan]

敏捷需要架构吗?

[亦弄]

谢谢各位的回复。最近看了看Henrik的Scrum And XP from the Trenches这本书，感觉收获很大。我其实想问的是PO如何估算敏捷开发团队能够在Deadline之前交付产品。只要能够通过团队的表现，计算出团队的velocity就可以估算了。