从开始做项目到现在也有一段时间了，我是项目中主要负责UI设计的代码编写这一块，同时也在探索怎么实现UI之间的消息传递、用线程实现的同步实现的网络通讯。
到现在为止，我遇到了瓶颈，越到后来发现越来越难继续开发下去，达到了寸步难行的地步。我仔细想了想这个问题，发现我们一开始就用错方法、走错路了。在项目开始的时候我们就确定了各自的分工，也确定了项目的目标和基本实现方法，这样的开始是可以的，但是后来产生的问题非常多。
1）各组员分工过于独立、组员的交流严重不足
在项目开始后，我们基本就各干各的了，查资料的查资料，找教程的找教程，看起来好像一切正在正常运行着。只到现在我逐渐感觉到问题的严重性。比如，如果我们各自做自己的工作，做需求分析的做需求分析，写网站的写网站，做UI设计的做UI设计，找数据库的找数据库，这期间的交流那么少，要是到最后要组合起来的时候，这里出个问题那里出个问题该怎么办？项目的进度如何保证？现在的情况是各自做自己的，每个人对于小组内其他成员的进度情况不够清楚，那么这就会导致最后每个人负责的模块向其他成员提供的接口无法使用，导致项目延期甚至直接失败，就是产生书上所说的“软件危机”。
2）项目开发并未严格按照软件工程开发模型来进行
最开始的我们组的想法是采用增量模型，先做出大致的框架，实现最基本的功能，最后再逐渐添加功能进去，但是最后并未严格按照流程来。比如UI设计，是我最开始做了一个基本的UI界面，这可能根本算不上框架，因为最基本的功能（网络通讯）都没有实现。也就是说，我们现在寸步难行，卡在了最开始的基础框架的开发上，我发现问题是我们在项目开发过程中犯了一个违背软件工程思想的极其严重的错误——在系统分析和设计还未充足的情况下提前编码。也即是说，我们现在产生的分析文档、设计分档基本没有。以我自己的体会为例，在上层的设计框架不明确的情况下直接开始写UI代码，然后又要去想怎么实现网络通讯，怎么实现客户端的异步和同步机制，然后又去查资料，找教程，整个写代码的过程极其混论，可像怎么实现的这些问题，根本不是编码阶段要思考的问题，这是设计阶段就要完全解决的！所以我建议项目组暂时停下开发的脚步，回滚到一开始的工作，重新开始系统的分析和系统设计。因为知道自己错了，退后一步就是进步！
总结就是，我们完全偏离了软件工程学的基本思想——先做分析、设计，再编码实现，同时，组员的交流太少，团队的合作效果不佳。所以我提出以下解决方案：
1）加强组员交流，每周定期开一次以上的讨论会，各成员把各自这周的工作向整个小组说明。
2）进一步扩展小组分工，覆盖到设计、编码、测试三大阶段，每个人都参与到三个阶段中去。
3）各个阶段必须产生一份合格的文档，以便于下一阶段的开发和测试。
总的来说，组员们的积极性还是非常强的，我们都在积极地负责自己的工作，只是在整体的层面，我们用错了方法，才到达现在项目开发进度不明确、开发步骤混乱、整个项目组寸步难行的境况。这周我们准备重新调整一下步伐，重新规划整个项目的开发。最后的产品好不好不重要（我们也不期望能靠这个实现奔小康），能学会软件工程学的核心思想，能将软件工程学的方法论贯彻到软件开发当中去，这才是最重要的。