本篇博客包括前期博文汇总、任务墙、团队管理细节与交流细节、代码管理、Beta阶段冲刺、团队总结、用户使用报告、Postmortem报告。html
服务器网址:http://47.106.227.154/前端
彩彩只能变身队:团队项目使用说明git
暂提供以下测试帐号(固然你能够本身申请帐号)github
教师端 ID:b@ustc.edu.cn数据库
Password: b编程
学生端 ID:aa397601@mail.ustc.edu.cn后端
Password: student1
服务器
学号:PB16060001框架
一. 我的总结汇总:工具
团队项目总结-王馨儿
团队项目总结-曾琪峰
团队项目总结-冯富禹
二. 前期博文汇总:
发布调查问卷 √
根据问卷结果分析痛点 √
技术框架调研 √
环境配置 √
任务分配 √
基本知识学习 √
初始主界面 √
登陆注册界面 √
教师端主界面 √
学生端主界面 √
(还有的界面名称须要补充一下)
基本知识学习 √
服务器部署 √
数据库的设计 √
用户各类数据的数据库的创建 √
与登陆注册界面进行交互 √
与教师端主界面进行交互 √
与学生端界面进行交互 √
……
进行alpha版本的测试 √
界面美化 √
进行beta版本的测试
用户反馈
反馈后调整
做业上交的困难和批阅的繁琐是中科大各个规模较大的课程都存在的痛点。目前,老师或者使用邮箱,或者使用纸质做业上交,这些工具和平台都存在着必定的问题。而咱们的线上课程做业管理系统正是基于这样的需求背景下提出要开发的。是咱们主要的特点,目标就是作一个操做很简单,很稳定的做业上交系统这个网站提供了一个方便老师和学生两方使用的做业上交系统。学生可根据本身的时间自行上网查询做业要求,提交做业文件,查询做业上交状况。老师也不用本身下载做业,经过在线预览就能够查阅做业,而老师不用面对拥挤的邮箱空间,也不用自行统计上交人数,提醒未上缴成员做业状况,从而轻松的管理该门课程的做业。
软件开发是一个须要协同做战的工做,团队是软件开发工做的基本组织,所以造成一个有效的团队是软件组织成功的基础。学期中,咱们主要经过每周一到两次的小组会议与线上交流做为主要的交流方式,七月份因为没法集中在一块儿,更多的是经过线上交流。
Github地址: https://github.com/Viarow/USTChomework
0. Alpha阶段遗留问题
先后端交互的遗留部分
文件操做
部署服务器
1. Beta阶段冲刺状况
7.9
改善路由框架,将教师端和学生端用两个router分别输出,后端根据前端的改变作相应调整。
7.10
引入pdf.js,能够预览本地的pdf文件。
7.12
因为咱们的网站最重要的功能是做业的提交与批改,可是在设计路由的时候咱们在以班级为单位仍是以一次做业为单位的问题上讨论了好久,最终肯定了总体的思路。
最后的思路是以班级的一次做业为单位,班级成员就是某一次做业须要提交的学生全体,这样比较清晰,也与咱们以前数据库的设计相符合。
咱们先入为主的观念经常是这样的:团队项目就是一群人码代码。然而软件的开发并不仅是单纯地敲代码,还要通过一整套严格的开发流程,包括对软件的总体构建,风险评估,需求分析,UI设计,开发,测试以及后续的相关维护等。所以统筹规划的能力至关重要。通过了一个学期共同的努力以后,咱们才慢慢体会到软件工程不只仅关乎代码关乎编程,而是一个引导咱们本身分析问题、解决问题的过程,而在这个过程中,时间管理、团队管理、成员交流等都是不可或缺的重要组成部分。
咱们的项目是完成一个线上的做业提交与管理系统,在项目初期,咱们也联系了上一届的学长,了解了一些基本的开发框架与工具。虽然咱们作的东西有相似的地方,可是咱们想要完成的与他们其实并无重叠之处,因此最后咱们放弃了增量式开发的想法。
一个项目的第一步首先就是需求分析,咱们开发出来的东西是给用户使用的,因此咱们就要站在用户的角度上合理全面分析他们的需求与痛点。并且在整个开发的过程中,还要考虑到用户需求的变化,要依据用户需求的变动及时作好调整。咱们的项目中一个很重要的用户群是老师,在需求分析这方面咱们没有作得很好,在开发的过程当中没有及时地去了解需求的变化,离用户始终有一段距离。这也给咱们之后的项目提供了一个宝贵的经验与教训。
咱们团队的成员当中没有人曾经接触过网站开发的相关知识,因此学习一些相关的基础知识其实花费了咱们不少的时间。可是团队项目的紧迫程度最终教会了咱们 Learning By Doing。这是一门课程,因此咱们不可能在学完了全部的知识之后再动手去作,只能边作边查边学。这一点不只仅适用于这一门课程,对于以后咱们的学习与科研,道理也一样如此。快速学习而且能够把所学当即运用到实际当中的能力是软工教给咱们的,也是咱们须要不断去锻炼与提升的能力。
再来讲一说敏捷开发。简单的说敏捷开发就是把一个大的项目分红多个相互联系,但能够独立运行的小项目,并分别完成,在此过程当中软件一直处于可用状态。敏捷开发就要求咱们要尽早交付能够供用户使用的软件,才能获得有价值的反馈,而后在用户需求之上开发,这样才是有价值的开发。可是敏捷开发就须要咱们拥有强大的学习能力,在短期内适应高强度的开发模式。
一个绩效良好的项目团队要有有效团队管理的能力。其中很重要的两个方面,一是有效的交流与沟通。这不只体如今平常问题、工做的及时有效的讨论与解决,也体如今代码规范与标准之中。一个团队完成一个项目,一份代码就势必要为全部人而懂。所以代码规范与代码注释就很是重要。另外一方面,是有效管理时间,团队成员要明确每周的目标,要控制干扰,努力不被外界所影响。团队中没有自个人概念,也就没有我的的胜败,若是项目成功了,每一个人都是赢家。
在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答辩以后,咱们也获得了来自老师、助教与同窗们的建议。
优点:目标较为明确,依据外界的反馈及时调整咱们的开发方向。
劣势:有时太过频繁的调整使咱们的思路不太清晰。