3.3 Scrum经验可以直接使用
1）客户作为团队成员直接参与项目讨论
暂时不行，无论UI设计还是编码阶段，我们最终面对的客户都是市场，少量的客户会让我们的项目不具备普遍性
2）短期的交付周期
可行，我们可以在每周交付一款可运行的软件然后进行检验是否符合客户预期并与其他部门的人进行相关讨论
3）验收测试与驱动测试
可行，我们采用的是XP和Scrum混合的敏捷开发模式，驱动测试可以让我们的项目质量更高而且我们正在这么做,同时驱动测试有利于代码的重构和解耦合，保证代码的质量减少后期代码验收时的麻烦。
4）结对编程
暂时不行，结对编程是要从整个制度上改变现有的模式，无论是外包公司还是我们公司内部都是不可行。
将来有机会我们会进行尝试。
5）开放的工作空间
可行，有利于大家情报的共有。为了实现这一块我们特别在别的地方租了一个办公室让项目相关人在里边工作
6）简单的设计
可行，按照上面所提到的我们在前期加强了架构的讨论，对于更多的细节设计会在迭代中逐步完善
7）头脑风暴
可行，给了开发人员更多的机会去优化项目的机会。会产生一些意想不到的好点子
4.将来的工作计划
1）sprint的定义
无论是一些通俗的介绍还是敏捷开发的艺术等书籍都将sprint定义为一周，其实可以根据大家自身的情况进行适当的修改
我们部门采用的是两周制。这样可有一个时间段来适应突发的变化，不会造成工作效率的下降
2）每个sprint的终结
主要是对这个阶段进行回顾然后提出一些优秀的idea并讨论如何进一步的提高，但是不会在这个上面浪费过多的时间
3）站会
这个主要提出问题，但是并不是在这里解决，而是寻求后续的帮助
5.工具的介绍
在敏捷开发中，白板和笔是最好的交流工具，但是适当的工具有助于提高工作的效率
1）redmine由于进行交流和Bug管理
2）Git做的版本控制
3）Jenkins做的发布和自动测试
4）Twiki做的wiki管理
