敏捷开发的想法之三---庞大的sprint0

 

以我从事设计开发十五年的工作经历来看，因为自己近十年从事的行业比较特殊，因此，在使用敏捷时，也和常见的敏捷有很大区别。


通常，我从事的行业，对产品概念完整性的要求非常非常高，使用小版本迭代，很大可能第二个版本发现要顺利进行，要推翻第一个迭代的很多东西（第一个迭代的很多东西需要推翻重写），而且这种情况随着开发活动的进展会越来越多，越来越频繁。


为了解决这样的问题，会衍生出一个非常庞大的sprint0。在这个sprint0里，其实不是敏捷方式来做的（不过这也不怎么要紧）。

再演变，可能会演变成另外一种场景，产品的第一个版本，不采用敏捷方式，而是传统方式来做，最重要的是，澄清和反复确认产品的最最精髓部分（一般产品的精髓和本质，是一组相互关联的概念）和架构（相当于人体的骨骼），然后在实现过程中，不断完善概念和架构。

因为概念的变化实际上是比较缓慢的，架构变化稍多一些，实现随着形势的发展，变化最多。所以第一个版本之后，基本上概念不大会变化了，架构也不大会进行伤筋动骨的改变，大多数时候，是一些实现上的调整，增加功能、功能变化。从此之后，倒是可以使用敏捷开发，来很大程度上提高产品的开发效率，提高产品质量。

或者说，第一个版本不能图快，要稳打稳扎，要打下一个扩展和改进的很好的基础（倒是无需考虑太多，只是打下一个清楚的底子非常重要）；后续的改进等等可以制定快速反应、快速发布的策略。第一个版本图快了，后面的改进势必变慢，或者把产品变成技术的简单堆砌，一锅大杂烩。