为大众提供一个匿名聊天、倾诉心事的场所。
定义为匿名性强、不以交友为目的的聊天软件。
针对 传播不法、违规信息的用户 及 恶意举报、进行不符合道德交流的行为 制定处理方式
定义较为清楚
在需求分析文档和系统设计文档中都有清晰的描述，下面进行简单的概括总结。
原计划完成相遇的朋友，个人中心，登陆模块和动态模块。
基本按照原计划交付时间交付，燃尽图燃尽。
未达成，还未发布。
经验教训
有关后端部分，接口定义一定要十分准确，一定要与前端及时沟通，保证效率
改进：
增加预留时间，同时强化前后端组员采用共享文档的方式进行小组的接口的协调和确定。
在beta冲刺前我们又两周来准备此阶段计划，所以时间算是很充裕的。
先由组长和另外的管理人员指定计划，如有异议，则成员提出问题，征求各个组员的意见，实在不行最后投票，大多数人同意的通过。
基本都已经完成。有些模块功能虽然完成，但是明显交互或者内部一些部分不合理，等待beta阶段完善。
测试人手不足，环境当时的确定有点草率。
一项任务都在文档上有清晰的要求，要求组员并又一定的交付基本的衡量要求，如图片，文档。
项目在α阶段因为新组员的磨合和线上开发的问题，导致配合及共同开发出现了一些问题，整体进度中间有出现滞后的情况，此时我们组通过及时开展讨论共同解决以免滞后影响后面进度，好在最后项目基本按计划完成。
我们项目留个五天缓冲区，这五天主要用来学习新知识，还有就是开发过程中遇到的问题能及时进行修正完善。
保留缓冲时间，如重要的功能进度落后则必须加班在期限内完成。一些功能部分的开发不能拖到加班与缓冲时间，提倡提前完成任务。
时间的合理安排真的很重要，我们会强化在线文档的使用，力求通过在线文档能使组员的进度和完成情况有实时的认识。同时对开发时间的缓冲区进行保留甚至增加，力求实现能达到更好。
模块较多，且重要功能的相关框架较为复杂，使时间这方面较为不足。
在beta开发前有一段时间的休整期，这段时间有督促组员去完善自己所在部分的知识，但是仍然感觉知识方面只是勉强够用。
通过各模块成员目前自己对自己知识的掌握程度，提出一个最长的时间，然后在最长时间内除以1.5得出最终计划的时间，并要求他们按这个进度开发。
测试的时间，人力和软件/硬件资源这方面应该算是足够的。但是关于美工、文案方面，没有专门的人负责，导致由组长进行书写有时感觉压力确实太大了。
后端人员可以适当帮助前端人员进行测试，后端人员有点太多了。
我们组采用teambiton和在线文档的方式共同管理，组长根据组员的每日完成情况，进行管理工具的更新，同时组员可以收到来自组长的关于任务变更的消息。
通过功能的重要性与难易度来判断
接口联调好同时和前端进行接口的使用确认成功就算功能做好了，同时前端要通过界面的测试和整体使用过程没有问题的出现。
万一出现意外，我们会进行沟通并联合解决。
组员能完成自己分内的事情和即时对意料之外的工作请求进行反馈。
设计工作都是由组长先进行人员分配，然后询问组员意见，没有意见的话就按原本的执行下去，有的话就共同讨论决定。每次任务的人员分工都在每个阶段的博客中详细体现，也能够较好的完成工作
讨论，投票解决。
单元测试：有效、快捷、能实时进行处理，同时很方便进行重复的操作，有助于代码的完善。
UML部分：在开发中，实际本来想得一些事情，在后期的处理中进行了简化并实时更新，这样也为后续的迭代提供了保证。
动态功能产生的功能较多，首先是前端动态界面出现了大大小小的显示和逻辑响应的问题，之后后端对于点赞的处理也出现了问题，前后端接口的商讨和交互有问题。
后端每个人在开发过程中进行代码风格的统一，前端自己进行约束统一，因为习惯差不多，代码没有出现太大问题。
采用自上而下的测试方案，后端采用postman+junit 前端采用hbuider+mui进行测试。
前期时间有限，验收测试只是在对基础功能的使用上进行了基本的测试。
后端：postman+junit
前端：hbuider+mui+模拟器
有关这方面的测试在alpha阶段没有进行。
alpha阶段主要采用的是本地测试，所以对于发布这方面的问题还未知。
根据前期组员的兴趣爱好的方向确定的，基本做到人尽其才。
有，因为是新团队，所以经常遇到问题共同在群里讨论共同解决。
观点投票制度，少数服从多数。
通过这十天以来的alpha冲刺，我们组的预期计划主要是完成登陆模块、个人中心模块、相遇的朋友模块、广场模块，和管理员模块的主要功能，当初设想的是我们的项目的模块较多而杂，且不同模块间功能有一定的相互影响，我们组通过三个人员（计划组）两个后端一个前端讨论后，决定先实现基本项目的雏形和功能，其中一些类似推荐算法、安全性问题留作beta冲刺阶段再做，因此最终划分出来的alpha冲刺的模块就为上方所说的几个模块构成。
现实进展的话，因为中间有一些前后端人员商量沟通不足，接口不明确的问题，导致中间有一定的进度停滞，我们组采用的是大家停下来，一起帮忙查看问题并加快解决，不使之后留下任务持续落后的情况，这也使我们的任务不会在任务燃尽时与原本进度有太大偏差，最后整合测试阶段虽然还发现一定的bug，但是经过询问讨论也得到了解决，与预期进度没有太大的落后的情况。
前后端人员的交流沟通有待加强，在测试阶段，发现一些错误明显有一定的沟通就能顺利解决，接口虽然用的是json工具类，但是交互的方式也有所不同，同时有发现一定的按钮失灵的现象。
解决：去找该模块的前后端人员进行询问，以屏幕分享的方式问其中的一些逻辑和交互。
心得体会：前后端人员前期和开发过程中的协商和交流很重要，有详细的沟通可以使最后测试的问题大大减少。
因为我们团队里没有真正做过大项目的人，所以一开始的ssh环境配置碰到了不少问题，因为网上大部分是spring+springmvc+readies 环境配置，所以我们在环境配置过程中也有遇到service无法注入，编译器环境无法通过的问题，tomcat无法启动等等。
解决：最后通过查找资料都得到了解决。
心得：项目的环境配置也是门大学问。
在各个模块分工下去后，因为我们前端人员在前期对后端环境的配置有点问题，同时我们经过讨论决定在alpha阶段使用本地环境测试，等beta阶段再部署到服务器上，所以发现部分模块的前后端的测试明显不足，导致到最后的整合测试阶段对代码的改动调整还是有点大，使的测试的过程与预期进度相比较显得有些慢。
解决：后面整合测试的人员就问题统一与模块人员沟通进行修改测试并发布整合到github仓库中。
聊天部分使用netty难度有点大，一开始遇到配置自启动的问题，客户端连接的的问题、 还有聊天过程中消息的传递和存储的问题。
解决：最后通过网上查资料和多次尝试，成功解决了。
心得：短时间内想要很好的完全理解掌握一门技术不容易啊，还是要经过多次尝试和查阅才能很好的解决自己的困惑。
项目管理真的不好做，因为当有些问题真的是很难的时候，进度不好规划，好在之前有先和另外两个组员共同规划，给出了适当的模块规划和任务规划，中间虽然有碰到大大小小的不同问题，好在最后燃尽图也顺利燃尽了。
复审则是需要尽可能多的人对不同的部分进行复审，规范制定方面则是要全部人员参与，各抒己见，交流得出最优的代码规范，并且有选择性的接纳他人的编码习惯
这方面架构的知识还不清楚，后期会通过查询相关知识提升质量。
应该多尝试性能和压力测试工具，提前为项目发布做准备。
经常被说贡献度平均，下个阶段采取责任制度，对组员贡献度有一定的把关。
问卷方式进行用户的调研和项目的改善。同时，有后台系统对用户的信息进行查看。
在文档编写上，文档格式一定要有提前的确定，同时对各部分的质量也要做好把关。
代码使用的话，可以多去查看一些有用的sdk,和查看他人代码，但是不要进行盲目的复制粘贴。
原文：https://www.cnblogs.com/RATE-MAX/p/13082424.html