我理解的敏捷开发实践

流行的敏捷开发方法有SCRUM与XP，下面我谈谈对其中一些实践的个人理解。

1）scrum团队。scrum团队分为项目负责人、产品负责人与团队成员，要求是一个自组织的团队。在小型项目中，一般项目经理既负责管理有负责需求，这两个角色没有工作性能冲突，可以兼职。另外项目经理的工作方式也要由指令型方式转变为指导型方式，为团队成员扫除环境障碍与干扰以专心与技术开发工作。

2）时间盒（时间箱）。scrum要求严格按照预设的时间盒（一般一个月）交付本次迭代产品，这样的要求更能明确把控时间进度，增强开发节奏感。对于很难按照时间盒的工作需要在迭代计划评审时提出，通过评审后才可打破预设的时间盒。

3）产品功能列表。将产品功能按照业务性质划分优先级不仅是敏捷的做法，也是一般迭代开发的做法。通过优先级的划分，从整体上把握客户要求，从而驱动开发工作面向市场、聚焦用户。

4）迭代计划。制定一个月的短期计划更容易把控，更体现出计划指导实际工作的真实性。

5）每日例会。通过每日例会能及时检查发现问题，及时纠正、指导解决问题，是敏捷重视执行监控的体现。

6）全员参与。在敏捷小团队中，全员参与更容易实现。全员参与能够集思广益、能够使团队成员互相理解容易形成共识、能够有效提供团队的执行意愿与执行力。

7）迭代总结。在每个时间盒完成后进行总结能够及时分析出现的问题，能够将实践经验及时应用到后续的迭代工作中。

8）持续集成与交付确认。开发的复杂性带来的问题通过及时验证能够得到有效解决，需求的不确定性通过及时交付客户验证更是有效可视化确认方法。

9）测试驱动。个人觉得测试驱动是需求驱动的高级阶段，实现了代码方法级别的功能准确性与高质量代码。

10）结对编程。没几个人的小项目就别太考虑了，除非重要的核心代码。不过我觉得结对设计、结对编程倒是教练式培训与指导的好方法，同时起到了代码评审的效果。

12）重构。觉得重构是为了系统的非功能要求而进行的，例如安全性、性能、扩展性、可维护性等。对于重要项目与核心产品重构的意义重大。如果没有对应详细设计说明或明确的代码注释，在初始编码人员不在的情况下，重构是极其困难的。事后重构的成本很高，时间越长成本越高，重构需尽早执行。

13)白板。白板可视化好，起到了公示的作用。白板与每日例会结合，提高了短期工作计划与监督的灵活性。觉得白板可以是电子版的，只要团队成员均能明显看到、并可以方便更新即可。