并不是所有的项目都适合用敏捷开发，在项目没有特别明确的目标，团队技术水平太弱、需要工期本身比较长无法细化颗粒度的情况下，使用敏捷开发会存在很多问题。

图应该是这样的：

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，通过快速、高效的反应速度，积极、高频的沟通为客户提供一条畅通的指挥通道。在一个传统互联网公司想要转型成移动互联网公司的关键节点上，我们遇到了一个面向老板出产品的经历。

在整个研讨会上，由于每次意见不统一，僵持不下，导致产品一拖再拖。最后老板迫于压力，在4月1日给出了一个命令，必须在4月20号做出来一个能看的产品。迫于无奈，在4月10日进行封闭式开发，9天的时间完成了一个电商类型的小程序，已经面向酒店和公司的两个后台系统。正是在这样的情况下，才能够体会到敏捷开发小而快思想的精髓。

我们遇到了以下问题：产品设计几乎需要从0开始；大量的后台系统开发工作量没有被正确评估；研发团队人数不过；UI团队无法AllIn。以上问题需要解决才能满足老板需求。因此我们选择使用敏捷开发模式。

敏捷开发分为Scrum和XP两种模式。Scrum适用于团队最佳人数控制在5～9人，一个迭代为四周时间；XP更侧重于测试驱动开发，一般迭代为1到2个星期。考虑到项目需要中途变更等量需求且有依赖关系，在Scrum和XP模式下吸取各自优点：允许中途变更等量需求；严格按照优先级进行开发。

敏捷开发需要采用以下工具进行管理：Excel需求池、任务看板、燃尽图、计划扑克牌等。

我们实践过程中遵循以下原则：产品设计需要拆分高内聚低耦合模块并及时输出最小可用单元；每日完成手头上需求才算完成当天工作；每晚十点审核进度并确保缺陷不过日；每个模块需要完整走过工作流包括缺陷处理流程。

实践过程中遇到了以下问题：团队磨合工具不及时变更状态；预留给产品设计时间太少导致边界条件未充分考虑；需求排优先级出现错误等。

通过9天时间封闭式开发产生数据如下：完成300+个需求点并测试修复400条bug。

总之，并非所有项目都适合使用敏捷开发，在项目没有特别明确目标、团队技术水平太弱或者需要工期本身比较长无法细化颗粒度等情况下使用敏捷开发会存在很多问题。