计划
计划
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
作为Alpha版本，我们团队在开发前进行了讨论，认为Alpha版本应该着重实现核心功能，而一些非核心功能放在后期的Beta版本进行实现。所以，根据github上的issues整理，在冲刺阶段我们总共建立了xx个issues，并且在截止时间前全部顺利完成，根据issues的标签分类，我们将工作计划划分为以下加粗的六类，并对每一类进行划分和详细说明，其中第六类的工作计划为下阶段，即Beta版本的工作计划原计划工作之功能整合-
登录界面以及对应的跳转
因为需要和上一届学长开发的报课系统进行功能整合，所以
教师、系负责人、院负责人三个用户组的登陆功能不做修改，采用学长的登陆功能，而学生的登陆功能全新实现，并且四个用户组都能够顺利验证用户信息进行登陆，并跳转至不同的界面。完成度：100%
-
登陆之后的页面跳转
因为需要和报课系统进行功能整合，所以
学生在登陆之后直接进入导师智能分配系统，教师、系负责人和院负责人在登陆之后，先进入 报课系统／导师智能分配系统 的选择，选择后进入相应的界面，并且保持报课系统的功能不受到任何影响。完成度：100%
原计划工作之学生-
个人信息界面：
学生在登陆智能导师分配系统后，显示个人信息界面，该功能完成。但是，修改个人信息的功能尚未完成，因为在Alpha版本，该功能并不是核心功能，所以暂时未考虑优先实现。
完成度：95%
-
专业导师界面：
点击专业导师，可查看该学生对应系别的导师，可正常显示导师列表，并且分页功能也已经实现，每页显示7名导师，该功能实现。
完成度：100%
-
志愿填报界面：
学生通过下拉列表的方式进行志愿的填报，可正常显示所有导师，该功能实现。但是，在导师人数较多的情况下，浏览可能不大方便，在Beta版本考虑加入搜索以及模糊匹配的功能，该功能未实现是因为时间不够，并且该功能不是核心功能。
完成度：90%
-
志愿结果界面：
在时间期限截止之后，学生可以查看到所有的分配结果，包括导师信息以及相同导师的学生联系方式。
完成度：100%
原计划工作之导师-
可选学生界面
导师可以查看可选学生的绩点以及志愿信息，并选择或则拒绝自己想要的学生，接受之后分配结果会更新到志愿结果。
完成度：100%
-
课题提交界面
在课题提交的时间段里，导师可以进行进行学生数和课题的设置，该功能已经实现。但是，过了规定期限而未提交信息的导师的学生数和课题设置信息，系统将自动设置为默认值的功能，未实现的原因是技术上存在问题，不知道该如何处理，并且时间也不够。
完成度：95%
-
志愿结果界面
在截止期限之后，导师可以查看分配结果信息以及学生的联系方式。
完成度：100%
原计划工作之系负责人-
时间设置界面
能运用部件进行时间的设置，并对错误的时间设置（比如开始时间比结束时间晚、时间早于现实时间等）进行提示，该功能已实现。但是提示的界面显示还不够人性化，需要再完善，未实现完成原因是时间不够，美工稀缺！
完成度：95%
-
匹配设置界面
若采用师生互选的方式，可以对未分配到导师的学生进行人工分配；智能分配算法的输出可以在界面上显示，该功能已实现。但是，分配结果的界面暂时还未加入分页功能，以及对分配结果进行微调操作，这些功能未完成的原因是时间不够，且分也存在一定难度。
完成度：85%
原计划工作之院负责人-
导师分配情况界面
院负责人可以查看到以导师为导向的分配结果，并可分页浏览，该功能已完成。
完成度：100%
-
学生分配情况界面
院负责人可以通过下拉条的方式查看某个系的分配情况，并可分页浏览，该功能已完成。
完成度：100%
-
学生分配情况修改界面
院负责人可以对分配结果进行微调操作，通过下拉条的方式进行导师的选择，该功能已完成。
完成度：100%
-
导师分配情况修改界面
院负责人可以对分配结果进行微调操作，例如为某个导师新增尚未分配到导师的学生，或则移除某个导师的学生，该功能已完成。
完成度：100%
Beta版本的计划-
尚未开发的功能模块
-
四个用户组的个人信息修改界面
-
学生、导师信息支持Excel的导入功能
-
学生——专业导师：搜索功能
-
系负责人：学生管理、导师管理、结果导出
-
院负责人：管理系负责人
-
院负责人——导师分配情况：支持Excel的导出功能
-
院负责人——学生分配情况：支持Excel的导出功能
-
-
需完善的细节
-
UI布局及美化
-
网站的Logo设计
-
头像的上传、修改以及对应的界面显示
-
界面的自适应，浏览器缩放时的界面显示问题
-
志愿填报的导师搜索功能
-
智能分配时，系负责人可对结果进行微调
-
界面切换时的闪现问题
-
导师列表和学生列表点击头像或姓名后跳转到详细信息界面
-
在进行重要操作时的提示更为人性化
-
确认、提交提示框
-
时间设置根据不同错误进行错误提示
-
在不同时间段，文字提示和界面显示更为人性化
-
-
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
-
婷总说：“有啊，写着写着就发现之前写的提示信息应该写在模型中，这样就只需要写一次写，控制器来调用即可。其他的话好像就没有了吧！！！” -
胡总说：“有！有！有！就给按导师查询的页面赋值，做了半天，前端大大把他的页面给我，发现他把按导师查询页面和按导师修改页面合并在了一起，然后要直接用合并完的页面，之前那个单独查询的页面的赋值就白做了。好气啊。” -
许总说：“原本刚开始是全都自己编码的，后来发现只要用框架，就可以快速的完成。” -
涛神说：“绝对有！本来我负责导师分配情况界面和学生分配情况界面的前端设计，写了一部分但是由于比赛原因，没能很好的完成，于是另一位小伙伴帮忙我写完了，那我自己写的部份就没有用了，相当于白写了。” -
陈燊说：“我觉得没有，我的任务主要是项目管理和所有博客的撰写，因为每次实施计划前都考虑得很清楚，所以感觉并没有做了什么没有价值的事情。整个项目的推进和进展节奏都很好。因此Alpha版本的发布也相对比较顺利。”
-
-
是否每一项任务都有清楚定义和衡量的交付件?
有，因为毕设导师智能分配系统的功能比较庞大而且复杂，所以我们花了非常多的时间在需求确定上，对于每个用户组的每个功能模块，甚至是每个界面的每个按钮点击之后是什么效果，页面如何跳转，我们都进行了详细的说明，所有的需求说明都在之前发布需求说明书里有详细的说明，我们在冲刺阶段的Alpha版本开发也是严格按照需求说明书上，所以对于任务有很清楚的定义和衡量。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
-
我们有强大的PM，PM在每次实施计划前都考虑得很清楚，并且对每个人单独进行了issues的分配，规定了issues提交的时间，因此能够对整个项目的推进和进展把握很好的节奏，我们组相比于其他组来说较少熬夜，只是在Alpha版本发布前的一个晚上熬夜测试。项目开发较为顺利，并没有出现什么意外和风险。
-
唯一的意外是Alpha版本演示之前，团队里的一名成员想要修改提示的功能，但是不小心导致学生填报志愿功能的崩溃，把整个团队都吓坏了，还好之前有备份好几个版本，回退到早上六点多的版本后才安然无恙。
-
-
在计划中有没有留下缓冲区，缓冲区有作用么?
我们有强大的PM，当然有留下缓冲区啦-
每个人的每个issue都有规定的时间，并且PM在仔细了解功能的复杂程度后，同一个人的不同issues的完成时间也不同，并且要求及时更新。//PM的内心真是细腻
-
我们的开发时间提前于发布时间两天，剩下的两天时间我们一起解决了各个功能模块的一些BUG，因为PM对于项目进度的熟练掌握，我们较少熬夜，也有较充足的缓冲区来给各个成员进行交流和完善功能。
-
-
将来的计划会做什么修改？
- 根据栋哥可能随时发生的需求变更来做相应的计划修改 //最有可能需要修改的！！！
