敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，通过快速、高效的反应速度，积极、高频的沟通为客户提供一条畅通的指挥通道。而作者经历了九天的封闭式开发，在文中跟大家分享这次敏捷开发的实践经历。
这是一次一个面向老板出产品的经历，一个传统互联网公司想要转型成移动互联网公司的关键节点上，当时经过很长一段时间的产品调研和业务流程的梳理，每次会上都会有近十个总监级别的各个部门老大。
由于每次意见不统一，僵持不下，导致产品一拖再拖。最后老板迫于压力，在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）——根据项目需要举行
- 项目复盘会议
当然，我们根据当时时间紧迫，在尽可能表达清楚需求的情况下，降低沟通的时间，这也导致了后续出现了一些问题。比如：整个团队对项目的理解不够深入，在开发过程中会存在一些偏差，导致需求返工的情况出现。
敏捷开发需要依靠什么工具进行管理？
在高强度的开发中，如果没有一系列工具进行管理，将会让整个项目失去控制。
敏捷开发的工具主要有：
- Excel 需求池，用于管理需求，一般分为产品需求（Product Backlog）和迭代需求（Sprint Backlog）；
- 任务看板，主要用于管理需求状态，跟踪延误的需求，查找成员是否成为绊脚石；
- 燃尽图，查看用户用例（User Story）是否按照计划如期完成；
- 计划扑克牌，防止研发因为考虑不全导致预估工期不准确。
第四点，敏捷开发实践过程及结果
成员组成：一个产品经理、一个交互设计师、一个后勤、3个后端工程师、3个前端工程师、机动UI设计团队。
成果：完成一个小程序、两个系统后台。
实践过程：
整个TAPD工作流设计：
产品规划 => 交互设计 => UI设计 => 实现中 => 产品体验 => 缺陷
缺陷的处理流程：
新 => 已接受 => 处理中 => 待验收 => 已验收 => 已关闭
我们在整个过程中，严格遵循以下几个原则：
- 产品设计需要拆分高内聚低耦合的模块，设计并且及时输出最小可用单元，保证项目不会产生类似瀑布流开发的模式。
- 每日完成手头上的需求才算完成当天的工作，确保每个人的需求能够完成保证进度。
- 每日晚上十点进行审核，事实上，为了让大家能够继续加班到凌晨的小技巧，也确保缺陷不过日。
- 每个模块需要完整的走过工作流，也就包括缺陷，出现问题及时调整。
实践遇到的问题：
- 刚开始团队磨合工具，没有及时变更工作状态。
- 预留给产品设计的时间太少，导致产品设计并没有太全面，边界条件未充分考虑。
- 需求排优先级出现错误。
- 需求会没有被重视，导致开发过程中需求重新开发。
- 测试环节节奏比较混乱，没有从头到尾测试联调。
- 产品更新原型，缺少比较好的同步工具，让所有人一直都是使用最新的文档。
通过9天时间封闭式开发产生的数据：
由于离开上家公司的时候没有整理出来这些资料，大致上，我们通过9天的时间完成了：
- 需求点大致上有300+个，采用前后端分开提需求点；
- 测试并且修复400条bug，基本上做到日清。
最后，注意事项
并不是所有的项目都适合用敏捷开发，在项目没有特别明确的目标，团队技术水平太弱、需要工期本身比较长无法细化颗粒度的情况下，使用敏捷开发会存在很多问题。
比如：
- 响应无法做到及时；
- 对工具的使用无法快速适应；
- 没有明确目标，缺乏紧迫感。
等等一系列问题，都会让整个敏捷开发变得不敏捷。
导致整个项目的燃尽图呈现下图这样：
而正常的燃尽图应该未关闭的线段贴合基线：
不过，尝试使用敏捷开发小而快的开发思想在自己的项目管理过程中也是不错的。
本文为@运营喵原创，运营喵专栏作者。
