本篇博客包括前期博文汇总、任务墙、团队管理细节与交流细节、代码管理、Beta阶段冲刺、团队总结、用户使用报告、Postmortem报告。
服务器网址：http://47.106.227.154/
彩彩只能变身队：团队项目使用说明
暂提供如下测试账号(当然你可以自己申请账号)
教师端 ID：b@ustc.edu.cn
Password: b
学生端 ID：aa397601@mail.ustc.edu.cn
Password: student1
学号：PB16060001
一. 个人总结汇总：
团队项目总结-王馨儿
团队项目总结-曾琪峰
团队项目总结-冯富禹
二. 前期博文汇总：
三. 任务墙
前期调研
发布调查问卷 √
根据问卷结果分析痛点 √
技术框架调研 √
环境配置 √
任务分配 √
前端
基本知识学习 √
初始主界面 √
登录注册界面 √
教师端主界面 √
学生端主界面 √
（还有的界面名称需要补充一下）
后端
基本知识学习 √
服务器部署 √
数据库的设计 √
用户各种数据的数据库的建立 √
与登录注册界面进行交互 √
与教师端主界面进行交互 √
与学生端界面进行交互 √
……
后期
进行alpha版本的测试 √
界面美化 √
进行beta版本的测试
用户反馈
反馈后调整
四. 团队项目介绍
作业上交的困难和批阅的繁琐是中科大各个规模较大的课程都存在的痛点。目前，老师或者使用邮箱，或者使用纸质作业上交，这些工具和平台都存在着一定的问题。而我们的线上课程作业管理系统正是基于这样的需求背景下提出要开发的。是我们主要的特色，目标就是做一个操作很简单，很稳定的作业上交系统这个网站提供了一个方便老师和学生两方使用的作业上交系统。学生可根据自己的时间自行上网查询作业要求，提交作业文件，查询作业上交情况。老师也不用自己下载作业，通过在线预览就可以查阅作业，而老师不用面对拥挤的邮箱空间，也不用自行统计上交人数，提醒未上缴成员作业情况，从而轻松的管理该门课程的作业。
五. 团队管理,交流细节
软件开发是一个需要协同作战的工作，团队是软件开发工作的基本组织，因此形成一个有效的团队是软件组织成功的基础。学期中，我们主要通过每周一到两次的小组会议与线上交流作为主要的交流方式，七月份由于无法集中在一起，更多的是通过线上交流。
六. 代码管理
Github地址： https://github.com/Viarow/USTChomework
七. Beta阶段冲刺：
0. Alpha阶段遗留问题
前后端交互的遗留部分
文件操作
部署服务器
1. Beta阶段冲刺情况
7.9
改善路由框架，将教师端和学生端用两个router分别输出，后端根据前端的改变做相应调整。
7.10
引入pdf.js，可以预览本地的pdf文件。
7.12
由于我们的网站最重要的功能是作业的提交与批改，但是在设计路由的时候我们在以班级为单位还是以一次作业为单位的问题上讨论了很久，最终确定了整体的思路。
最后的思路是以班级的一次作业为单位，班级成员就是某一次作业需要提交的学生全体，这样比较清晰，也与我们之前数据库的设计相符合。
八. 团队总结
我们先入为主的观念常常是这样的：团队项目就是一群人码代码。然而软件的开发并不只是单纯地敲代码，还要经过一整套严格的开发流程，包括对软件的整体构建，风险评估，需求分析，UI设计，开发，测试以及后续的相关维护等。因此统筹规划的能力相当重要。经过了一个学期共同的努力之后，我们才慢慢体会到软件工程不仅仅关乎代码关乎编程，而是一个引导我们自己分析问题、解决问题的过程，而在这个过程当中，时间管理、团队管理、成员交流等都是不可或缺的重要组成部分。
我们的项目是完成一个线上的作业提交与管理系统，在项目初期，我们也联系了上一届的学长，了解了一些基本的开发框架与工具。虽然我们做的东西有类似的地方，但是我们想要完成的与他们其实并没有重叠之处，所以最后我们放弃了增量式开发的想法。
一个项目的第一步首先就是需求分析，我们开发出来的东西是给用户使用的，所以我们就要站在用户的角度上合理全面分析他们的需求与痛点。而且在整个开发的过程当中，还要考虑到用户需求的变化，要依据用户需求的变更及时做好调整。我们的项目中一个很重要的用户群是老师，在需求分析这方面我们没有做得很好，在开发的过程中没有及时地去了解需求的变化，离用户始终有一段距离。这也给我们以后的项目提供了一个宝贵的经验与教训。
我们团队的成员当中没有人曾经接触过网站开发的相关知识，所以学习一些相关的基础知识其实花费了我们很多的时间。但是团队项目的紧迫程度最终教会了我们 Learning By Doing。这是一门课程，所以我们不可能在学完了所有的知识以后再动手去做，只能边做边查边学。这一点不仅仅适用于这一门课程，对于之后我们的学习与科研，道理也同样如此。快速学习并且可以把所学立即运用到实际当中的能力是软工教给我们的，也是我们需要不断去锻炼与提高的能力。
再来说一说敏捷开发。简单的说敏捷开发就是把一个大的项目分成多个相互联系，但可以独立运行的小项目，并分别完成，在此过程中软件一直处于可用状态。敏捷开发就要求我们要尽早交付可以供用户使用的软件，才能得到有价值的反馈，然后在用户需求之上开发，这样才是有价值的开发。但是敏捷开发就需要我们拥有强大的学习能力，在短时间内适应高强度的开发模式。
一个绩效良好的项目团队要有有效团队管理的能力。其中很重要的两个方面，一是有效的交流与沟通。这不仅体现在日常问题、工作的及时有效的讨论与解决，也体现在代码规范与标准之中。一个团队完成一个项目，一份代码就势必要为所有人而懂。因此代码规范与代码注释就非常重要。另一方面，是有效管理时间，团队成员要明确每周的目标，要控制干扰，努力不被外界所影响。团队中没有自我的概念，也就没有个人的胜败，如果项目成功了，每个人都是赢家。
九. 用户使用情况报告
Postmortem报告：
1. 每个成员在beta阶段的实践和alpha阶段有何改进？
在beta阶段，团队成员对技术本身掌握得更加熟练，对网站总体也有了更加清晰和全面的认识。当然，团队成员之间的配合也更加默契。
2. 团队在beta阶段吸取了哪些alpha阶段的经验教训？
alpha阶段我们依然缺乏对项目框架的整体认识，对一些技术特别是前后端交互技术掌握得也不够深入与成熟。Beta阶段我们先对技术框架有了一个较为全面的认识，因为只有对技术框架的全面而清晰的认识，才可以减少无意义的重复性工作，提高效率。
beta阶段我们也对界面做了一定的美化，统一了网站的整体风格，努力使用户体验更好。
其次，在alpha和beta阶段我们充分认识到了时间合理分配的重要性。在今后做项目的时候，我们一定要提前合理全面预估任务量，将功能模块细分化。
3. 12条敏捷开发的原则中，团队做的最好的和最不好的各两点。
最好的两点：
1）不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
起初，因为全员需要学习技术框架所需要的各种知识团队项目的进度经常处于搁置状态，后来我们发现采用成员之间互相交流互相学习、集体面对面开发的方法更有效率。其次，我们发现，当把一些问题的讨论发布到QQ群中的时候，并不能引起所有人的注意。而当我们将问题拿出来面对面交流时，我们之间往往能够碰撞出不曾有过的火花。
2）以简洁为本，它是极力减少不必要工作量的艺术。
Simplicity--the art of maximizing the amount of work not done--is essential.
为了尽量追求敏捷开发的原则，我们以最迫切的用户需求为核心，追求以简洁为本。
最不好的两点：
1）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
由于Beta阶段团队各成员都有其他的事情需要处理，开发易受外界环境影响，没能做到按照恒定速度开发。
2）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
由于团队成员都没有网页开发的基础，所以花了大量时间学习相关技术。但在后期，我们越来越体会到尽早交付可以供用户使用的网页的重要性，从而做出相应的改善和调整。尽早交付软件才能得到有价值的反馈。软件工程不仅仅是写代码，其中还涉及很多为人处事的道理需要我们去领悟。
4. 对照The Cathedral and the Bazaar (大教堂和集市)，我们的团队开发模式是哪一种，优势/劣势在哪里？
我们初期的开发模式更加倾向大教堂模式，但在实际开发过程中，我们慢慢向市集模式转变。尤其是在Alpha答辩之后，我们也得到了来自老师、助教与同学们的建议。
优势：目标较为明确，依据外界的反馈及时调整我们的开发方向。
劣势：有时太过频繁的调整使我们的思路不太清晰。