这是一次一个面向老板出产品的经历。一个传统互联网公司想要转型成移动互联网公司的关键节点上，当时经过很长一段时间的产品调研和业务流程的梳理，每次会上都会有近十个总监级别的各个部门老大。由于每次意见不统一，僵持不下，导致产品一拖再拖。最后老板迫于压力，在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 需求池
- 任务看板
- 燃尽图
- 计划扑克牌
第四点，为什么我们使用TAPD进行开发
通过上面的描述大家应该都比较清楚，敏捷开发的方式。我们在做事情的时候一般是,先战略后战术，然后是执行。在我们确定下来要达成什么目标，使用什么方式进行开发，进一步就是如何执行的工具选择上。
传统的纸质或者一些道具显然不是很方便，可能它的学习成本相较于线上工具的学习成本要低，但是制作成本和后期的数据统计导出就需要更多人力来制作。在开发前期，我们通过对TAPD的了解，它的基本功能需求、迭代、故事墙、需求规模等等映射到传统敏捷开发所需的管理工具，并且还提供了工作流自定义功能，管理bug的缺陷。
在整个项目进行过程中，产品经理或者项目经理可以实时查看缺陷统计、燃尽图来把握产品进度。
第五点，敏捷开发实践过程及结果
成员组成：
一个产品经理、一个交互设计师、一个后勤、3个后端工程师、3个前端工程师、机动UI设计团队
成果：
完成一个小程序、两个系统后台
实践过程
整个TAPD工作流设计：
产品规划 => 交互设计 => UI设计 => 实现中 => 产品体验 => 缺陷
缺陷的处理流程：
新 => 已接受 => 处理中 => 待验收 => 已验收 => 已关闭
我们在整个过程中，严格遵循以下几个原则：
产品设计需要拆分高内聚低耦合的模块，设计并且及时输出最小可用单元，保证项目不会产生类似瀑布流开发的模式
每日完成手头上的需求才算完成当天的工作，确保每个人的需求能够完成保证进度
每日晚上十点进行审核，事实上，为了让大家能够继续加班到凌晨的小技巧，也确保缺陷不过日。
每个模块需要完整的走过工作流，也就包括缺陷，出现问题及时调整。
实践遇到的问题
刚开始团队磨合工具，没有及时变更工作状态
预留给产品设计的时间太少，导致产品设计并没有太全面，边界条件未充分考虑
需求排优先级出现错误
需求会没有被重视，导致开发过程中需求重新开发
测试环节节奏比较混乱，没有从头到尾测试联调
产品更新原型，缺少比较好的同步工具，让所有人一直都是使用最新的文档
TAPD上的数据
由于离开上家公司的时候没有整理出来这些资料，导致没有办法直接展示TAPD上的数据。
大致上，我们通过9天的时间完成了：
需求点大致上有300+个，采用前后端分开提需求点
测试并且修复400条bug，基本上做到日清
最后，注意事项
并不是所有的项目都适合用敏捷开发，在项目没有特别明确的目标，团队技术水平太弱、需要工期本身比较长无法细化颗粒度的情况下，使用敏捷开发会存在很多问题。比如：
响应无法做到及时
对工具的使用无法快速适应
没有明确目标，缺乏紧迫感
等等一系列问题，都会让整个敏捷开发变得不敏捷。导致整个项目的燃尽图呈现下图这样：
而正常的燃尽图应该未关闭的线段贴合基线：
不过，尝试使用敏捷开发小而快的开发思想在自己的项目管理过程中也是不错的。
