| 这个作业属于哪个课程 | 2020春软工实践|W班 |
|---|---|
| 这个作业要求在哪里 | 作业的要求 |
| 这个作业的目标 | 团队及项目简介 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 无 |
一、设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决问题
- 由于疫情的影响，处在非常时期中的人们都不得不面临一个问题:远程教学/办公。体验了一周网络授课后我们的直观感受就是：APP和网页太多，来回切换复杂繁琐，没有办法一次性获取所有学科相关信息。这导致学生有些时候会忘记一些待办事项，比如某科作业没法及时完成，又或是某一个项目变更相应要求后没有及时看到变更的通知。如果没有一个APP能够兼顾所有功能，那么就必定会导致学习和工作效率下降，对于使用者来说体验也非常不友好。既然没有，那么就应该有，也必须得有一个能够直观显示所有信息并且加以提醒的软件，既能改善用户体验，又能拯救拖延症，于是便有了这个项目——Done。我们的想法就是把安排融入到日历当中，最直观的显示对应日期的计划以及各种事项。
定义是否清楚
- 我们对软件的定义比较清楚，明确是一款计划发布的软件应用
是否对典型用户和典型场景有清晰的描述
- 有以下几个描述样例：
- 公司职员 刘某
由于公司在疫情期间进行远程办公，导致许多杂事与通知没办法及时在办公室的通告栏上看到，许多行程冲突导致办公效率及其底下。为此，刘某十分需要一个能够解决安排计划让任务能够量化直观可见的应用，于是他开始使用Done... - 某大学生 陈某
学校正式开展线上教学，但是由于是第一次进行此类型的教学方式，导致每门课程没有统一的教学和作业发布平台，许多科目的事情混杂在一起会很容易忘记某科作业，于是陈某便开始使用日历来记事，但发现日历上能写的事情不够多并且显示不够直观，在经过他人的推荐下开始使用Done来管理学习相关计划...
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的功能
- 原计划功能三大模块基本完成，附加功能模块预计于本阶段完成，详细完成情况见下
是否按照原计划交付时间交付
- 除了一两个小功能以及部分数据交互失败之外基本上按时交付
原计划达到的用户数量达成情况
- 未达成，可能会在beta冲刺思考新的对策
- 上阶段燃尽图
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
质量是否提高
- 吸收了上次冲刺的经验，质量有所提高
具体提高的秒数
- 有关任务量化更准确了，与当初最开始学习框架还很陌生的状况完全不同，不会因为一些很基础的问题讨论半天，基本上现在问题解决都很迅速
- 有关代码部分，前后端代码都进行了一定的重构，保证代码质量有一定程度的提升，比如后端就修改了接口的一些格式和效率复杂度等
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户的试用反馈来看基本符合我们当初预想，不出彩但是功能够用，用户量倒是没有符合最初预期，只有极少数人试用，但通过beta冲刺我们的确在不断向目标前进
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 经验教训
有关后端部分，接口定义一定要十分准确，并且后端接口完成后要及时补全相关文档，与前端联调，保证效率
前端部分则是一定要留足时间以保证应对网页架构临时需要变动的情况 - 改进
优化前后端具体人员分配，留足时间，保证文档提供信息有效并且准确
二、计划
1. 是否有充足的时间来做计划?
事前准备计划
- 我们预留了两周来准备此阶段计划，所以时间算是很充裕的
进行计划
- 整个阶段对每天的计划分布是经过组员讨论合理后得出来的安排，所以每个计划对于每天是否能够完成的指标来说都是有足够时间的
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 通过组内讨论，交流然后进行表决，最后少数服从多数，最方便的解决办法
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 上个阶段任务没有完成的部分就是部分数据交互，原因我们也多次强调过就是时间没有很合理安排，以及人员分配的一点小问题
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 我们组统一表决出这件事就是后端分配了4个人（太多了）
5. 是否每一项任务都有清楚定义和衡量的交付件?
- 每一项任务都在文档上有清晰的要求，比如上传接口测试完成的图片，并附上文字说明等最基本的衡量要求
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 整个项目出的意外就是时间分配不断推迟，导致原本的一些任务工期都普遍延后了1-2天，带来的影响就是未完成的部分
- 当时并未设想到前端人手不足的情况下会带来这么大的压力，一度面临前端可能部分功能搁置的风险，主要原因还是组内没有拥有相关前端开发经验的人
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
- 我们总是预留将近一周的缓冲期，事实证明计划赶不上变化，缓冲区给我们的项目又带来了生机
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 有一些功能部分的开发不能拖到加班与缓冲时间，甚至有部分需求提前也是有可能的
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 时间真的需要合理安排，如果再来一遍，我们可能会增加1.5倍甚至double自己预估的时间，以防止时间再次带给我们巨大困扰
三、资源
1. 我们有足够的资源来完成各项任务么?
时间
- 由于第一次接触此类开发框架，需要耗费一定的学习成本，所以时间确实有所不足
技术相关
- 在不断的学习与熟悉技术的过程中，实际上小组成员都感受到虽然没有完全掌握，但对于开发此项目在阶段过程中所学到的技术勉强够用
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 通过小组内讨论与网上搜索相关项目开发经验分享，从而确定出具体的时间和其他资源所需量，并且在任务中不断完善，总体来看精度尚可
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 测试部分可以说时间部分勉强够用，人力资源由于向其他组进行交流，共享了一些技术心得方面等资源，所以比较丰厚，但有关编程外的部分比如文案等没有专门人员负责，导致有些部分反而耗费大量资源并且没有实现预期效果，落差较大
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
- 后端的人员由于比较饱和，所以每个人干事效率本来就足够，并不存在此类问题；前端则是感觉要是由更多人平摊任务那么一部分功能模块的实现效率必定会有显著的提升
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 对于资源方面，宁愿多算也不要少算，永远留下一个所谓的“提前量”
- 改进的部分就是对于任务资源分配方面要确定好难易度来更恰当分配资源，这样才能提高整体效率，而不是将资源平均分配
四、变更管理
1. 每个相关的组员都及时知道了变更的消息?
- 我们组内使用leangoo管理任务卡片，当任务部分变更时leangoo会自动发送邮件通知组员，并且在任务变更后我们也会在qq群进行@来通知对应组员相关事项
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 通过组内讨论衡量功能的重要性与难易度来判断
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 后端的接口是通过已经定义好的test并且与前端联调后才能真正被定义为完成，而前端部分则是在整体使用过后没有BUG出现或者整体流程下来使用正常算完成
4. 对于可能的变更是否能制定应急计划?
- 对于所有任务的制定我们都有相应的应急人员能够接手任务，所以制定应急计划完全可行
5. 组员是否能够有效地处理意料之外的工作请求？
- 在实际冲刺阶段中，组员都能够很好的接受并且完成附加的工作
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 需求不仅可以延后，还可以提前
- 要是能重来，会对一部分需求提前，一部分延后，通过开发难度来进行判别
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 我们每次的设计工作（编码前的所有阶段）都是通过组长先定初始人选，然后组员内部讨论最终决定的，每次任务的人员分工都在每个阶段的博客中详细体现，也能够较好的完成工作
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 遇到此种情况时我们都是通过投票表决少数服从多数解决的
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 单元测试：十分有效，能很直观表现出开发最终成果是否正确，并且定义起来也比较方便
- UML部分：由于在开发过程中有一些比较难实现的，或者有冲突的功能模块部分，所以需求时不断在变化的，我们的UML文档相比最初也有一定的变化，但并没有非常多
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 在小组功能模块部分Bug最多，因为小组部分进行的跨模块交互是最多的
- 发布后我们发现小组功能模块有部分功能是没有成功执行数据交互的，在开发时由于并没有很好的预留时间导致没能很好的为隐藏的问题提前预留出解决的方案
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 代码复审是由前后端两个部分分别制定一个负责人进行复审的，代码规范部分基本上就是结合各自模块开发人员的习惯编写的，所以执行的比较好
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 设计与实现都是开发过程中十分重要的环节，要整个小组一起不断学习，共同探讨存在问题才能更好的完成任务
- 对于一些不合理的设计，如果重来一遍我们会在冲刺过程中留出一定的时间进行重新讨论与设计
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
- 我们小组前后端分离开发，所以测试计划是肯定不可少的，通过自下而上的最基本测试方法进行软件开发过程中的所有必要测试
2. 是否进行了正式的验收测试？
- 由于时间的原因，我们的验收测试只是进行了项目整体的简单使用，并且体感评判测试等级
3. 团队是否有测试工具来帮助测试？
- 前端：直接通过浏览器进行验收，并且通过nodejs中的一些插件进行部分模块测试
- 后端：单元测试使用Junit，API则是通过POSTMAN进行测试
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 有关软件性能方面由于时间原因在上个阶段并没有进行，在Beta阶段将会考虑使用其他组已经拿出成果，实用的测试方法
5. 在发布的过程中发现了哪些意外问题？
- 在部署服务器的过程中由于每个人本地配置不一，照着统一教程进行配置服务器却没办法正确完成，换了几个人进行才最终能够配置本地服务器，云服务器不了了之
6. 我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 测试部分是软件开发必不可少的一环，并且测试并不是出现问题就一定是坏事
- 如果重来，我们应该会给测试环节多1-2天的时间，对整个项目需要测试的地方再次进行评估并且进行相应的测试
七、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
- 通过组内每个人自己意愿并且结合实际人员掌握技术进行角色确定，基本上每个人都能够较好的适应角色
2. 团队成员之间有互相帮助么？
- 由于我们开发项目经验较少，所以组内在开发时交流很多，经常互帮互助，解决一些问题，共同进步
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 我们小组经典投票，少数服从多数
八、总结
1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码管理
- 尽可能用较少的人数来进行管理，保证代码管理标准的统一性
代码复审和代码规范
- 复审则是需要尽可能多的人对不同的部分进行复审，规范制定方面则是要全部人员参与，各抒己见，交流得出最优的代码规范，并且有选择性的接纳他人的编码习惯
2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
- 整体程序架构应该通过相关资料查询，修改一些内部类的结构与使用，从而提高其架构
- 衡量通过代码总量，运行时占用内存与速度等指标来进行判别
3. 其它软件工具的应用，应该如何提高？
- 通过不断使用，在熟悉中熟练
4. 项目管理有哪些具体的提高？
- 时间部分与任务具体贡献比部分需要再多考虑，特别是任务量化部分需要再三考虑再下最终定论
5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
追踪
用户设置部分提供较合适的问卷，并且在使用中定时发送请求让用户反馈使用体验
用户数据相关
通过用户状态更新等数据库方面的数据变化来了解用户相关数据
6. 项目文档的质量如何提高？
- 多写，并且多学习其他组的文档是如何撰写的，结合自身不断撰写的经验与其他组的成品来提高质量
7. 对于人的领导和管理， 有什么具体可以改进的地方？
- 有关任务完不成的部分应该要有严格的惩罚机制，保证项目进行中能够有序高效
8. 对于软件工程的理论，规律有什么心得体会或不同意见？
- 文档方面格式要确定下来，避免不同组员的文档撰写习惯不同导致文档最终样式不堪入目
- 代码方面要有选择性的参考与借鉴，而不是盲目的ctrl+c，v来使用他人的代码
九、组员交接相关
081700308 付其佳（新组员）
职位
- 原 铁华团 后端开发人员
- 现 D6Plus 后端开发人员
交接部分
- 通过组内与组员交流并且询问组长原本岗位人员具体负责工作任务来进行交接
适应新环境
- 由于组内有认识的熟人，通过熟人来进行项目部分的介绍并且与组员相互认识，进行最直接的语言交流来获取信息，保证新组员能够快速融入小组
换组事项感想
- 暂无
221701138 林亿祥（组长）
职位
*原 组长
*现 组长
给新组员的安排
- 由于来的新组员是一位之前就认识的同学，并且也是负责后端的，所以就没有过多考虑让新组员直接补上原本组员的空缺部分，并且询问后得知我们组的所用技术他本人有所了解，认为上手比较快，有自信，所以也就比较放心的给他安排了当前的职位
有关旧组员离开
- 能哥是我们组的老同学了，大家平时关系都非常好，当时我们随机抽一个人换出去，其实不管是谁要走，都会舍不得，但是毕竟是项目开发中很现实的一环，所以最后我们也欣然接受，当然现在看到他在新的组里面也找到了属于自己的职位，并且很合适，所以最后也是很欣慰
安排任务
- 新组员主要是熟悉一下我们的项目代码，文档部分以及一些与其他组员的QNA环节，目的是让新组员能够快速适应当前角
换组事项感想
- 人员调动虽然在项目开发的职场中是十分正常的一件事，但是由于我们都是第一次经历，难免在最开始有些不解，但当我们真正接收后，整个小组又很快重新投入到开发中去，所以我个人认为换组给我们带来了一次宝贵的经验，虽然在今后的工作中可能司空见惯，但第一次的经验总是会给人带来启示，也希望调换到其他组的能哥能够在新环境顺利适应角色，完成整个beta冲刺！