敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，通过快速、高效的反应速度，积极、高频的沟通为客户提供一条畅通的指挥通道。而作者经历了九天的封闭式开发，在文中跟大家分享这次敏捷开发的实践经历。
这是一次一个面向老板出产品的经历，一个传统互联网公司想要转型成移动互联网公司的关键节点上，当时经过很长一段时间的产品调研和业务流程的梳理，每次会上都会有近十个总监级别的各个部门老大。
由于每次意见不统一，僵持不下，导致产品一拖再拖。最后老板迫于压力，在4月1日给出了一个命令，必须在4月20号做出来一个能看的产品。
迫于无奈，在4月10日进行封闭式开发，9天的时间完成了一个电商类型的小程序，已经面向酒店和公司的两个后台系统。
正是在这样的情况下，才能够体会到敏捷开发小而快思想的精髓。
第一点，我们遇到的问题
尽管，前期我们有进行一个相对比较长的研究，但是并没有梳理形成一个完整体系。在整个研讨会上，也没有形成一个明确的产品目标以及产品的形态。以至于一直停留在梳理业务流程上，没有一个比较实质的进展，即产品原型、产品架构几乎空白。
面向老总出产品最尴尬的是他们不在意后台系统，也就是他们往往会忽略后台系统的工作量。公司又面临了资金紧张裁员、UI团队需要多方共用，一些系列问题。
总结一下我们遇到的问题：
产品设计几乎需要从0开始；大量的后台系统开发工作量没有被正确评估；研发团队人数不过；UI团队无法All In。
以上的问题，当我们一起讨论分析，如果想要快速满足老板的需求，必须进行封闭式开发，而且整个团队需要严格的控制和监管，降低风险，那么就必须要有一个更高效的协作方式来完成目标。
所以，我们选择使用敏捷开发的团队协作方式。
第二点，什么是敏捷开发
敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法，通过快速、高效的反应速度，积极、高频的沟通为客户提供一条畅通的指挥通道。
开发方式一般分为：Scrum 和 XP。
Scrum： 团队最佳人数控制在5～9人，一个迭代为四周时间，不允许需求的变更。
XP：更侧重于测试驱动开发，一般迭代为1到2个星期，允许等量工作量的需求替换。
在整个开发过程中运营团队构成，因为技术团队、产品团队的成熟度还不高，无法提供完整的XP模式开发方式，而项目有偏向于使用XP模式。
综合考虑，我们在Scrum和XP模式下吸取各自的优点：
允许中途变更等量的需求，因为在整个过程中，很有可能面临老板的新需求，必须做到快速响应；严格按照优先级进行开发，因为时间短，User Story之间很有可能存在依赖关系，如果没有按照优先级进行开发很容易导致团队有些成员很忙，有些成员符合无法达到饱和；采用产品经理驱动项目进度，而不是使用TDD模式，主要原因是因为整个技术团队在TDD模式上未实践过无法做到自我管理的程度，只能通过产品经理人肉测试和项目跟进；第三点，我们怎么选定工具
敏捷开发是一种快速响应需求的开发方式，不同于传统的瀑布式开发，在管理流程上也就不同。产品经理通过采集需求，整理出产品需求池（Product Backlog），然后输出到研发团队进行工作量评估、实现可行性，最后根据优先级进入到迭代需求池（Sprint Backlog）进行一轮迭代。
再通过每天的站立会进行对需求完成情况的审核，控制风险。
以下是一个完整的产品迭代的过程：
通过什么会议进行管理？
通常情况下，一个敏捷开发需要以下的会议来把控研发的进度：
Sprint 需求规划会议项目立项需求同步会Sprint 功能规划会议估算会议——根据项目情况合并到 Sprint功能规划会议每日立会Sprint 评审会议（Review Meeting）——根据项目需要举行项目复盘会议
当然，我们根据当时时间紧迫，在尽可能表达清楚需求的情况下，降低沟通的时间，这也导致了后续出现了一些问题。比如：整个团队对项目的理解不够深入，在开发过程中会存在一些偏差，导致需求返工的情况出现。
敏捷开发需要依靠什么工具进行管理？
在高强度的开发中，如果没有一系列工具进行管理，将会让整个项目失去控制。
敏捷开发的工具主要有：
第四点，敏捷开发实践过程及结果
成员组成：一个产品经理、一个交互设计师、一个后勤、3个后端工程师、3个前端工程师、机动UI设计团队。
成果：完成一个小程序、两个系统后台。
实践过程：
整个TAPD工作流设计：
产品规划 => 交互设计 => UI设计 => 实现中 => 产品体验 => 缺陷
缺陷的处理流程：
新 => 已接受 => 处理中 => 待验收 => 已验收 => 已关闭
我们在整个过程中，严格遵循以下几个原则：
产品设计需要拆分高内聚低耦合的模块，
来源【企业推广】自媒体，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！
