面对敏捷开发、快速迭代这些看似洋气的词语时，一定要看是否与自己的实际情况相匹配，不能为了追赶时尚就概念先行。
敏捷开发6点原则：
快速迭代
相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。
研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。编写可测试的需求文档
开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。多沟通，尽量减少文档
任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的交流，面对面沟通比邮件强得多。做好产品原型
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。及早考虑测试
及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。
对比上述的几条原则，逐一自检自身的这个小团队，是否符合敏捷开发？
我们大概两周左右做一次版本发布；需求文档和产品原型一应俱全，通常在这两份文档具备的情况下，与测试和开发人员一起进行需求同步，以需求为主线，进行技术实现的沟通和安排。
之后，技术开始进行框架搭建和开发准备，与此同时测试人员根据需求编写测试用例。在这个过程中，有任何问题随时交流，面对面的日常交流比文档传递更便捷，有改动的地方统一更新做标记。最后就是测试、bug修复及上线。
迭代与规划之分
我们一直在宣扬敏捷开发快速迭代，看着一个个版本号的更新，觉得很欣慰。
可在某次听一位嘉宾分享时，才发现，原来上述这样的情况并不属于快速迭代，老师主要讲了2方面：
快速迭代和整体规划的选择关键在于：是否能提前知道用户的准确需求，以及是否能快速得到用户反馈？
而在这一方面，to C和to B产品是有区别的：
to C产品受众多，需求确认难，上线后反馈快，相对于适合快速迭代；
to B产品受众少，业务稳定，但使用后的反馈路径长，反馈意愿低，相对适合整体规划。
让我印象最深的一句话是：如果你们计划做10个模块，每次上线一个，那不叫快速迭代，而是属于分期交付。所以说，于我们而言，一般是立项时做了排期，然后先做什么再做什么，一部分一部分分期进行，所幸我们属于to B产品，还算是符合大的规律。
快速迭代的判定
那么，如何判定快速迭代与否呢？
其实，快速迭代是一种产品研发理念，在这个理念支持下的产品研发是“上线-反馈-修改-上线”这样反复更新内容的过程。形式非常适合互联网产品或者移动端，通过收集数据或用户反馈迅速知道改进的结果，此种方式以极强的时效性让产品越来越靠近用户的需求，比如小米最初的时候。
因此，透过“上线-反馈-修改-上线”这个流程也可以看出，是否属于快速迭代，判定点在于是否有反馈和修改这一环节。如果是做完1接着做2，这不属于迭代，迭代一定是在原有基础上进行了优化更新，所以我们常常说把一些小问题放在下一个版本迭代中。
快速迭代虽好，但也有一定的实施前提：
一是环境，周围环境在快速变化、产品没有足够的时间来进行需求分析及相关测试；
二是用户，用户不知道自己真正想要什么，产品需要通过迭代的方式进行试错；
三是成本，一般情况下可迭代产品的成本都很低，并且可以快速的进行版本更新。
结束语
综上可以看出，其实快速迭代更适用于C端的互联网产品，而不太适用于B端的客户型产品。因为B端来说产品过重，用户有相对清晰的业务需求，不需要凭空去试错，再加上B端的产品若是进行迭代升级，大部分时候成本都不低，对于技术的架构、代码逻辑等都是一个考验，灵活型标准化产品除外。
所以，敏捷开发、快速迭代这些看似洋气的词语一定要看是否与自己的实际情况相匹配，不能为了追赶时尚就概念先行。所谓“小步快跑，快速迭代”，只有恰当把握快速迭代的核心才能真正实现产品的优化。
一起加油，共勉！
