| 这个作业属于哪个课程 | 2020春|S班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 团队名称 | 如果有一天我变得很有钱 |
| 这个作业的目标 | 对alpha阶段团队出现的问题进行总结反思 |
| 作业正文 | |
| 其他参考文献 | 无 |
一.设想与目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 要解决的问题:解决记事本记账或纸质账本记账麻烦的操作和数据丢失的风险， 为用户提供简单方便的记账功能和可视化的数据统计展示功能， 让用户知晓每一笔钱的去向并让用户通过记帐对自己的消费结构有一个清晰的认识， 进而形成良好的消费习惯和理财意识。
- 产品定位：一款个人记账软件，通过精细的分类、简化的操作流程和优质的报表界面，让用户更清楚的了解到自己的消费习惯，提高自己的理财意识。
- 典型用户：花钱总是不加思考与规划，最后发现钱不够用，有意对自己的收支进行记录/管理的人
-
达到目标了吗？
核心模块中：我们基本完成了手动记账部分的功能；完成了报表展示的大部分功能；自动记账部分只是简单地完成了周期记账的功能，文件记账部分没有写完；其他功能如同步功能等，都只完成了部分。不过总的来说，我们在alpha冲刺中完成了大部分的任务，算是达成了原来预想的目标。 -
经验教训
- 在设计的时候在团队名等地方出现了些意见不和的问题，浪费了些时间去讨论，而且有时候讨论的事情可能没有太大意义。这时候就需要一个人统一大家的意见，并且朝着这个方向去实现。
- 设计阶段对产品的定位没有定位的很清楚，出现了老师和同学们对产品的一些误解：对于记账软件的目的，就是为了让使用更清楚的了解自己的消费习惯，更持久的保存数据等。我们只能更进一步的优化产品的流程和体验做到相对的足够“方便”，而无法避免掉记账本身固有的“麻烦”的属性。
- 设计时没有对后期实现的产品做出进一步的规划、对预想到问题做出进一步的思考，导致后面出现了问题，会出现没有相应的应急预案，只能临时想办法解决的情况。
二.计划及资源
-
alpha阶段是否每天有充足的时间来做规划安排？
组长在leangoo看板上对每个组员的分工进行明确的分工。组员拿到任务的时候，也对自己的任务进行了时间分工，由于没有使用看板的习惯，导致有些组员实现的东西没有展示在燃尽图上面 -
如何解决队友对于计划的不同意见
每天开组会的时候，都是由各端开发的人依次介绍自己当天的情况，当有人提出问题时，会先在会上自由讨论，能得出结果的就会上总结确认，会后按会议中讨论的结果去执行；会上得不出结果的，后续在群中继续讨论或是直接由相关人员私聊讨论交流。 -
是否都做完了？如果有没做完的，为什么？
大部分都做完了，没做完的原因总结几点：- 我们组涉及了安卓，ios，web，服务器四个端，开发力量分散，导致技术比较熟练的人承担了太多的工作量，而相对不熟练的人又需要临时学习
- 由于对任务不够重视或是其他未知原因，有组员没有做好准备且没有抽出足够的时间参与开发。
- 组长在项目出现进度滞后时，跟进了解不够频繁，不好意思施压。
-
有没有发现做了些事后觉得没必要的事？
貌似没有，我们组内的每个人都切实的需要负责项目中的一块任务，基本上所有人做的事都是完成项目所必须的。 -
是否有足够的时间、开发资源等来完成各项任务？
- 时间资源方面，由于工作量、安排存在不当等元婴，开发时间其实是比较紧张的。
- 开发资源方面，组员对Android，iOS和Web的开发许多时候都是现学现卖。像移动端，使用的大多是原生控件，没有利用第三方框架进行代码的优化和管理。导致功能与美观度上可能不尽人意。
-
人力/软件/硬件资源相关；对于不需要编程的资源（美工设计等）是否低估难度？
由于开发比较紧张，且没有给出足够的缓冲时间，测试的时间稍显不足，只完成了对项目的基本测试，可能缺少对测试的系统的安排。
不需要编程的资源在我们这也是不存在的，总体工作量大，只有每个人都参与才能保证项目完成 -
有没有感到某个成员做的事情可以让别人来做（更有效率）？
说没有那是不可能的。不过毕竟是团队开发，有的人比较熟有的人感到陌生，很正常。还是要多包容吧，说不定以后工作自己就是效率较低的那一个。 -
计划及资源部分的经验教训
- 应重视设计阶段的文档和风险的评估，对接口和分工做出更细致的完善工作。我们组对计划的重视还是不够完善，事先对接口文档的定义不够清楚，一些功能也没有定义验收标准。导致后期实现的时候需要花时间去完善接口的定义。在验收的时候也出现了不知道怎么算验收合格。
- 出现进度滞后时需要及时跟进确认，避免对整体计划的影响
- 应尽量预留出更多的机动时间，出现意外时能补上进度，并且可以对项目进行更全面完善的测试。
- 对组员应尽量做更加充分的了解，明确组员的优缺点和长处，对分工进行改进。
三.设计及实现
-
设计工作是在什么时候，由谁来完成的？
产品的设计有项目构思人和组员共同设计和完善，由组内两个女生完成基本UI设计，后端和两名组员完成数据库表设计，构思人完成功能模块的划分。组长完成分工。 -
测试工具的使用情况，是否有效
由于团队的人员缺少经验，现学技术时间不足等原因，导致后面测试的规划比较匆忙，可能不够到位。具体的测试安排及工具介绍如下：- 后端：对基本单元，比如dao层的各种函数，都会在开发中使用junit进行单元测试，此外在初步完成一个接口和完成所有接口后，都会使用postman使用各种参数对接口的可用性进行测试。有效性：使用postman测试接口可以方便、准确地调整发送的参数，可以有效地模拟前端发出请求并对结果进行验证。
- 移动端：由于开发人员对移动端开发没有一定的经验流程，导致只在真机或者安卓虚拟机上测试了基本的功能实现，没有进行更深入的测试。
- Web端：对接前保证页面上元素的基本可用性，对接后连接服务器对各项功能进行逐一测试。
-
项目开始时的UML文档和现在的文档有什么区别，是否需要更新
UML图的改进： 基本上依靠最开始的设计完成了程序的实现，不需要做修改。 -
什么功能产生的bug最多，为什么开始没有想到
- 在移动端开发时，发现周期记账功能会出现很多的BUG，如程序强制杀死后，计时器是否正常工作。计时器是否能完成基本的功能实现。周期事件被添加时，是否要给用户提示等。都出现了一些问题。
- 反思： 没有想到这些在设计的时候没有考虑到的原因可能有：1、只想到了用户体验方便快捷，没有在设计时考虑很多的细节。2、对要开发的系统/框架不够熟悉，以及对一些代码的运行机制原理不了解。等等
-
设计及实现部分反思总结
- 边学边编程基本上完成了项目的开发，对每个组员的自信心有了很大的提升。但是对一些编程方面的规范和重用没有足够的重视。
- 在项目的过程中没有认真的执行代码复审，每个人都是开发自己的，没有进行过代码复审。
没有很好的代码重用，每个人需要什么界面就直接新建，没有进行代码和界面的重用 - 有时会出现没有对功能和结果进行简单测试验证，在写好后就简单的提交到GitHub上面的情况。
-
改进：
- 学会代码的重用和代码复审，以此保证代码的质量
- 需要完善功能检验制度。
四.测试及发布
- 是否有一个测试计划？
测试计划：代码编写————》编写人员进行简单自测————》合并功能，由专人进一步系统地测试————》开发完成 - 是否有测试工具来帮助测试
见设计与实现部分地测试工具介绍 - 测试及发布部分反思总结
（测试的具体安排前面有介绍）
软件的开发离不开测试，但我们却只是做了一些简单的测试，没有系统、深入地的测试流程，对需要哪些更专业有效的测试工具缺乏了解。
在beta冲刺阶段，我们要争取完善测试流程及内容，去了解自动化测试等内容，更认真完成测试的过程。
五.团队的角色，管理，合作
-
团队的每个角色是如何确定的，是否人尽其才？
角色的确定：考虑到大部分同学都没有擅长的部分，以及我们的项目对安卓开发人员的需要，无明显特长的大部分同学都被组长分工的时候无情的划分到了安卓组。
队中对ios/web/安卓/后端比较熟悉的四位同学都被安排为四端的主力/负责人。自认为应该有做到人尽其才。 -
团队成员是否有互相帮助
当然有。互相帮助的例子包括但不限于：- 有同学出现bug自己无法解决时，队友会帮忙查看并尝试解决。
- 安卓开发中，零基础的队员需要图表、日期选择等组件，熟悉安卓开发的同学就把自己之前做app时使用过的相关组件分享到开发群中。
- 后端开发中，队员不熟悉token登录状态校验，后端负责人就找了些感觉比较靠谱的参考资料，最后队员学习资料后成功实现了后端的token登录状态校验。
- 等等。。
-
出现项目管理，合作方面的问题时，团队成员如何解决问题？
我们团队出现合作问题时一般是按以下的步骤解决：- 首先是尝试在当天的组会中讨论解决问题
- 会上的讨论不足以解决问题时，与相关人员使用qq进行进一步交流。
- 当需要讨论的内容较多，文字交流不便时，使用效率更高的语音通话，甚至是屏幕分享、远程控制进行讨论交流以及问题的协助解决。
六.如何在beta冲刺阶段提高软件工程的质量
-
代码管理、代码复审及规范质量应该如何提高？
让大家多熟悉之前制定的代码规范，同时可以配合IDE中的代码规范插件在编程中规范代码。在模块开发完后，再由专人对代码进行复审，排除现有的不符合代码规范、相似功能实现风格各异、代码缺少注释可读性较差等问题 -
beta阶段大致安排
- UI美化
- Bug修复
- 功能完善（文件记账，从服务器恢复数据等）
- 人机交互优化（适当时提示等）
- 安全性完善（数据传输、保存等）
- 更详细的测试