敏捷软件开发方法中的6个实战经验(2)

　　团队要确保日常的交流，面对面沟通比邮件强得多。

　　敏捷开发鼓励日常的协调会议和碰头会，5~7人参与的会议尽量控制在10分钟内。碰头时，要过一遍昨天完成了什么，今天要做什么，哪些问题仍待讨论。可以用Burndown Chart(燃尽图)来形象展示工作进度。每次迭代的时候也都要开一个计划会议和评审会议，一般需要的时间可能会长些，比如半天。这些会议的目的就是对工作查缺补漏。

　　评审会议很重要，传统开发模式往往略过该环节，导致一些错误做法不断重复，好的做法无法推广。

　　开会时，可以将原先的分组打散，让整个团队都参与到项目的需求讨论和测试中来，这样可以突出成员个人，让大家更乐意参与。

　　5. 做好产品原型

　　建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。

　　一个常见的问题是软件新的功能与用户想要的不一致。为了避免这一问题，可以模拟真实操作，改进模拟操作过程中难以理解和不清楚的操作行为。

　　6. 及早考虑测试

　　及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。

　　敏捷开发中一个常见问题就是开发者没有对已有的代码库进行充分的回归测试。迭代周期很短，从开始到交付就是4周的时间，这样可以对迭代的设计、实现和底层测试一块进行回归测试。

　　一系列迭代之后，可以只针对测试活动再补充一个迭代。这个迭代可以将重点放在系统测试、与其他系统的集成度、性能等方面。敏捷开发过程中，可能会导致过少的测试文档。如果迭代周期为1个月左右，可以不必对测试文档过于要求，但要制定好测试策略。

　　最后

　　可能大多数公司或团队还没有开始尝试敏捷开发，不过可以开始从点滴做起，比如开碰头会、为项目管理采用一个更加高效的管理工具等等。最后，希望上面的建议能够为大家的软件开发管理带来帮助。(编译/王殿进)

原文转自：http://www.csdn.net/article/2013-12-09/2817746-6-practical-agile-techniques