敏捷开发修炼之道

敏捷开发宣言：

1 个体和交互胜过过程和工具

2 可工作的软件胜过面面俱到的文档

3 客户协作胜过合同谈判

4 响应变化胜过遵循计划

虽然右项也有价值，但是左项具有更大的价值

一种以人为本，团队合作，快速响应变化和可工作的软件作为宗旨的开发方法

敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善

具体含义：

1 小型团队，一般十人

2 一起工作，一起共享代码和开发任务

3 和客户或者软件的用户紧密工作在一起，尽可能早且频繁地给他们演示最新的系统

4 使用自动工具不断地构建和测试

5 不断地重新设计，改善代码，重构系统

6 以迭代的方式工作

7 尽可能频繁地发布系统版本让用户使用

 

 

态度决定一切

做事：指责不会修复bug，把矛头对准解决问题的办法，而不是人，这是真正有用处的正面效应

欲速则不达：不去深入了解真正的问题和后果，就快速修复代码，只能解决表面问题，需要投入时间精力保持代码的整洁

对事不对人：好的软件需要大量的创造力和洞察力，分享并融合各种不同的想法和观点，远胜单个想法为项目带来的价值，负面评价和态度扼杀创新

特殊技巧：

1 设定最终期限：没有最好的答案，只有更合适的方案，最后期限能帮你在为难时做出决策，让工作继续

2 逆向思维：先找优点，再找缺点，采用优点最多缺点最少的方案

3 设立仲裁人：仲裁人确保每个人都有发言机会，并维持会议的正常进行

4 支持已经做出的决定

脱离实际的反方观点会使争论变味

排除万难，奋勇前进：必须有勇气做认为对的事情，也要衡量是否鲁莽

 

 

学无止境

跟踪变化：不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯

对团队投资：沟通分享新知识新技术

懂得丢弃：学习新技术时，丢弃阻止你前进的旧习惯

打破砂锅问到底

把握开发节奏：项目开发需要一致和稳定的节奏，开发，测试，复审，迭代，发布

 

 

交付用户想要的软件

让客户做决定：开发不应该做业务决定，让业务负责人决定

让设计指导而不是操作开发：设计满足实现即可，不必过于详细

合理使用技术：不要盲目使用新技术，新框架

保持可以发布：保证你的系统随时可以编译，运行，测试，部署

提早集成，频繁集成：

提早实现自动化部署：

使用演示获得频繁反馈

使用短迭代，增量发布

固定价格就意味着背叛承诺：让团队和客户一起，真正地在当前项目中工作，做具体实际的评估，由客户控制他们要的功能和预算

 

 

敏捷反馈

单元测试：自动化的单元测试能够为你的代码提供及时的警报，如果没有到位的单元测试，不要进行任何设计和代码修改

先用它再实现它：TDD测试驱动开发

不同环境就有不同问题：使用持续集成工具，在每一种支持的平台和环境中运行单元测试

自动验收测试：像是协作完成的单元测试，仍然是在编写测试，但从其他人那里获得答案

度量真实的进度：使用待办事项，而不是日程表

倾听用户的声音：每个抱怨都隐藏了一个事实

 

 

敏捷编码

代码要清晰的表达意图：编写清晰的代码

用代码沟通：使用细心选择的有意义的命名，用注释描述代码意图和约束，注释不能替代优秀的代码

动态评估取舍：考虑性能、便利性、生产力、成本和上市时间

增量式编程：在很短的编辑，构建，测试循环中编写代码

保持简单：开发可以工作的，最简单的解决方案

编写内聚的代码：让类的功能集中，让组件尽量小，不要创建无所不包的大杂烩类

告知，不要询问：不要抢其他组件的工作，告诉它做什么，就可以了

组合优于集成：多使用组合委托，而不是继承

 

 

敏捷调试

记录解决问题的日志

警告就是错误

对问题各个击破

报告所有异常：处理或者向上传播所有异常

提供有用的错误信息

 

 

敏捷协作

定期安排会面时间：站会

架构师必须写代码：不知道系统的真实情况，是无法展开设计的

实行代码集体所有制：让开发人员轮换完成系统不同领域中不同模块的不同任务

成为指导者：分享自己的知识

允许大家自己想办法：指给他们正确的方向，而不是直接提供解决方案

准备好后再共享代码：不能提交尚未完成的代码，没有编译通过或者没有通过单元测试的代码

做代码复查：

及时通报进展和问题

 

 

走向敏捷

引入敏捷：管理者指南

1 站会

2 架构师加入日常开发

3 开展非正式的代码复查

4 让客户参与项目

5 版本控制

6 单元测试

7 自动构建

8 调整团队节奏和习惯

9 分享知识

引入敏捷：程序员指南

1 单元测试

2 编码习惯

3 自动构建