浅谈我们团队敏捷开发过程中的问题
一开始，我们团队选择敏捷开发，是觉得我们的项目也不是特别庞大复杂，我们同学之间相互沟通了解比较多，不想让写文档占用太多时间，最后又觉的它是新型软件开发方法，想尝试一下，于是最终选择了敏捷开发作为我们团队此次的软件开发方法。但是两周下来，我发现可能是因为我职责上的一些疏忽，使得大家并没有进入到敏捷开发的状态。现总结反思如下：
首先，敏捷开发中强调个体和交互胜过过程和工具，在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。起初，我认为大家都是同学，平时就有沟通交流，每天上课会见面，肯定少不了面对面的交谈。但实际情况并非如此，上课的时候大家坐的都很分散，平时即使见面聊天也很少聊到正在进行的项目。我在群里说有问题就提出来大家一起讨论，也极少有人回应，结果，最后大家对于我们的项目并没有太多的沟通交流，反而都只是把自己的想法写到了所分配的相应的文档中，虽然写文档的时候是采结对完成的，但也只是两三个人的交流。我的计划是后面会尽量找时间邀大家一起开个会什么的，如果大家不想走路的话，可以群内语音解决，让大家提前想好自己有什么问题需要解决，然后集体讨论解决，让大家真正融入这个大团队中，而不是像一盘一吹就散的散沙。
其次，敏捷开发提到过度自信是编程的职业病，反馈则是其处方，每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。我感觉我们团队内部没有形成良好的及时反馈的风气，下面每个小组都独自的默默的做自己负责的模块，我不太清楚他们分别进展到哪一步了，也可能是因为前期主要是学习与设计，编码工作的进展还比较缓慢所以没有太多可以反馈的内容。我的想法是后面建立反馈机制，每周定个时间让每组派一名代表向我进行进度汇报以及阶段总结，然后再相应调整后面的计划，使得一个团队的所有小组能够协同工作，不会拉开太大的时间差距，致使最后项目的整合延期。
最后，敏捷开发主张简单，尽可能减少工作量的艺术至关重要。我们在对第一版产品的设计过程中也考虑到了这一问题，暂时不需要的第二版中需要实现的一些功能我们都没有设计。轻装上阵，模型尽量简单一些，这样也更方便日后的改进与完善。
我相信，随着项目继续深入的进行，以及不断的摸索与学习，我会渐渐了解到敏捷开发的真正内涵，并且带领大家逐渐步入正轨，感受敏捷开发的风格与特色。