什么是敏捷开发

敏捷开发实际上并不是一种开发模式，而是一种理念，一种理念，理念。敏捷开发提出了十二个准则，符合这十二个准则的交付模式都叫做敏捷开发。十二准则如下

1. 尽早交付有价值的软件
2. 欢迎需求变化，让软件更有价值
3. 频繁交付可使用的软件，建议采用较短周期交付
4. 项目过程中，业务人员和开发人员每天在一起工作一段时间
5. 支持项目团队工作
6. 面对面交谈是传递消息效果最好和效率最高的方式
7. 可工作的软件是项目进度的首要衡量标准
8. 敏捷过程促进可持续发展。项目主要干系人，开发人员和用户应该能一直保持节奏
9. 持续关注卓越技术和良好的设计，提高敏捷性
10. 以简洁为本，极力减少不必要的工作量
11. 最好的架构、需求和设计会从自组织团队中涌现
12. 团队要定期反思如何变得更高效，然后相应地调整自身

上述准则说得很绕，很模糊，其实也很直白。汇总成一句话就是减少不必要的工作量，持续交付可使用且有价值的软件。如果学习过精益思想的同学，甚至完全不需要理会敏捷开发到底是啥东西。

实践思路一：面对面交流，提高效率

刚来的研发小伙子中，有两个总是喜欢自己闷头干【这可能是很多刚步入工作的人的通病】。即使需求有问题，即使自己思路不明确，却还是想自己再努力努力。不仅需求上，就算是编码过程中有遇到没有头绪的bug，也应该及时寻求帮助，而不是自己苦苦猜测验证，这会浪费自己的时间，浪费团队的时间。主动提高沟通，遇到问题及时寻求帮助。只要不是同一个问题重复问，没有人会介意的。

实践思路二：提高需求质量

目前所在团队，大多为新人，因此存在几个致命的劣势：

1. 当前项目对业务知识要求较高，刚来的产品并不熟悉业务
2. 研发框架封闭且老旧，开发存在一定困难
3. 大家对库表的理解并不深刻

同时也存在一些优势

1. 用户对业务极其熟悉
2. 用户明确知晓自己想要什么。

原先的开发模式，产品拿到用户的需求，往往在确认交互没问题的基础上便安排给开发【因此产品并不了解业务，也不了解库表结构】。开发拿到需求，在确认交互没问题的基础上进行开发【因为也不了解库表，字段关联关系】。导致在研发过程中出现需求因为数据不支持而无法实现，或因数据关联复杂，代码白写，或因需求表述不明确，导致开发过程中出现滞留现象或者返工现象。

针对这一问题，我想做两件事。

1. 产品必须确认需求中的数据字段是否能取到，可要求研发协助。在拿到需求初期便抓住用户解决问题并完善文档【只有写出来的东西才能保证不会自己骗自己】，避免后续与用户的交互滞留。
2. 经过一段时间的交互，产品可熟悉部分业务，与用户和开发的交流会比之前顺畅，此时会削弱文档质量的要求，文档只需留有主要内容。开发与产品通过面对面交谈配合共同实现需求即可。避免无意义的编写文档时间。

实践思路三：结对编程

结对编程指两个人负责一个模块，一个主一个副。这看上去是一个浪费人力的举动。实际上并不是的。目前我使用结对编程目的有两个

第一：团队中有水平较低的人A，和另一个水平较OK的人B。 由B来辅助A做业务实现，一来能提升A的水平，二来就算A真的扶不起来，那把A换掉的成本就显得比较低了。通过这种隐形的交接会使人员流失时的成本变小

第二：我打算逐步结对，使团队中的每个人都尽量熟悉多的模块，为了达到任何人都能做任何业务功能的地步。因为我们的功能交付已经实现了短期阶段性交付（用户如此要求）。因此在任何人都熟悉每块业务代码时，我们能够承受住客户针对某一块具体业务的大量需求。人员配置更灵活、。

实践思路四：测试前移

我想让测试更早地干涉到研发中。因此每个需求都会要求研发做拆分解耦【敏捷开发黑话叫做拆分故事点】。每完成一小块有业务价值的功能，测试就介入。如此可提高测试质量与测试效率，避免研发压榨测试时间，到最后改bug的时间也没有【毕竟早测早改，加班也要改完。要不然交付在即再改bug，那就压力很大了】

后续还有一些规划，比如说两周一次的回顾会议，这是极其重要的，比如每日站立会（酌情而定，我会发表一些我的见解），比如工具支持。等下篇文章再讲吧

以上四点是目前正在做的，刚起步，有效果，但不是最终效果。因为这些要求稍微正常点的公司都实现了，只是小弟当前的公司有点那啥而已。

peace and love