这是一次一个面向老板出产品的经历，一个传统互联网公司想要转型成移动互联网公司的关键节点上，当时经过很长一段时间的产品调研和业务流程的梳理，每次会上都会有近十个总监级别的各个部门老大。
由于每次意见不统一，僵持不下，导致产品一拖再拖。最后老板迫于压力，在4月1日给出了一个命令，必须在4月20号做出来一个能看的产品。
迫于无奈，在4月10日进行封闭式开发，9天的时间完成了一个电商类型的小程序，已经面向酒店和公司的两个后台系统。
正是在这样的情况下，才能够体会到敏捷开发小而快思想的精髓。
尽管，前期我们有进行一个相对比较长的研究，但是并没有梳理形成一个完整体系。在整个研讨会上，也没有形成一个明确的产品目标以及产品的形态。以至于一直停留在梳理业务流程上，没有一个比较实质的进展，即产品原型、产品架构几乎空白。
面向老总出产品最尴尬的是他们不在意后台系统，也就是他们往往会忽略后台系统的工作量。公司又面临了资金紧张裁员、UI团队需要多方共用，一些系列问题。
总结一下我们遇到的问题：
以上的问题，当我们一起讨论分析，如果想要快速满足老板的需求，必须进行封闭式开发，而且整个团队需要严格的控制和监管，降低风险，那么就必须要有一个更高效的协作方式来完成目标。
敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法，通过快速、高效的反应速度，积极、高频的沟通为客户提供一条畅通的指挥通道。
Scrum： 团队最佳人数控制在5～9人，一个迭代为四周时间，不允许需求的变更。
XP：更侧重于测试驱动开发，一般迭代为1到2个星期，允许等量工作量的需求替换。
在整个开发过程中，因为技术团队、产品团队的成熟度还不高，无法提供完整的XP模式开发方式，而项目有偏向于使用XP模式。
综合考虑，我们在Scrum和XP模式下吸取各自的优点：
敏捷开发是一种快速响应需求的开发方式，不同于传统的瀑布式开发，在管理流程上也就不同。产品经理通过采集需求，整理出产品需求池（Product Backlog），然后输出到研发团队进行工作量评估、实现可行性，最后根据优先级进入到迭代需求池（Sprint Backlog）进行一轮迭代。
再通过每天的站立会进行对需求完成情况的审核，控制风险。
通常情况下，一个敏捷开发需要以下的会议来把控研发的进度：
当然，我们根据当时时间紧迫，在尽可能表达清楚需求的情况下，降低沟通的时间，这也导致了后续出现了一些问题。比如：整个团队对项目的理解不够深入，在开发过程中会存在一些偏差，导致需求返工的情况出现。
在高强度的开发中，如果没有一系列工具进行管理，将会让整个项目失去控制。
敏捷开发的工具主要有：
成员组成：一个产品经理、一个交互设计师、一个后勤、3个后端工程师、3个前端工程师、机动UI设计团队。
整个TAPD工作流设计：
产品规划 => 交互设计 => UI设计 => 实现中 => 产品体验 => 缺陷
缺陷的处理流程：
新 => 已接受 => 处理中 => 待验收 => 已验收 => 已关闭
由于离开上家公司的时候没有整理出来这些资料，大致上，我们通过9天的时间完成了：
并不是所有的项目都适合用敏捷开发，在项目没有特别明确的目标，团队技术水平太弱、需要工期本身比较长无法细化颗粒度的情况下，使用敏捷开发会存在很多问题。
而正常的燃尽图应该未关闭的线段贴合基线：
不过，尝试使用敏捷开发小而快的开发思想在自己的项目管理过程中也是不错的。
U482242448
U382062580
