敏捷开发一千零一问系列之三十六：如何做小版本迭代的代码管理

本文是敏捷开发一千零一问的第三十五篇。（栏目总目录）

问题

若要实现敏捷式的开发，对产品进行迭代式的小版本的发布，在代码管理方面应该怎么样管理呢？

我们目前的管理是在一个大的版本上不断的递增新的需求……但是要是有个需求做到一半，领导又要求做更重要的需求的情况，就很难将开发一半的代码剥离开。

答案

1. 每个版本选择相对内聚的故事群

所谓故事群，就是互相关联性大的用户故事。

比如假设有下面这些关于用户-团队-角色-权限……的用户故事：

比较合理的做法，不是东一榔头西一棒槌地做，而是一块一块地做。

比如先做用户中灰色的部分，如果领导不变更，再做团队（图中只有灰色的部分）；如果领导又没有变更，再做团队成员（图中只有灰色的部分）……总之留着角色和权限（都是粉色）的部分不做；而用户中与角色权限相关的几个操作（粉色）也不做。

这样的好处是，每次发版，发出的功能都是一块一块的能独立运行。

比如图中，灰色的部分都完成了，粉色的部分一点也没有动，可以独立发一个“只有用户-团队概念，没有角色和额外权限设置”的版本。

如果变化很快，下一个版本，要么做角色，要么做权限，肯定只做其中一个。

2. 缩短迭代周期

如果一个产品变化很快（要么很模糊，要么很创新，要么……），另外一个好方法是缩短迭代周期，这样也能避免中途变化，毕竟来不及变化，就已经完成了。

但这样也要主要保持上一条中的原则，每个迭代都独立成章。

3. 制定产品路线图

变更多，看似是客户或外界市场的原因，但仔细分析，很可能是因为我们自己心里没有谱造成的。

如果能提前制定一个产品路线图，约束一下接近3～6个月（实际上应该更长）的整体规划，那么就会有一个相对固定的方向，不会想到哪里做哪里。

这个问题的相关内容，请参考：敏捷开发产品管理系列http://blog.csdn.net/column/details/productmanagement.html中的前三篇文章。