福大软工 · 第十二次做业 - Beta答辩总结

福大软工 · 第十二次做业 - Beta答辩总结

 

Part 0. 开篇

组长博客:戳我进入html

  • 小组成员:
短学号
2219 奇豪(组长)
2209 毓明
2226
2204 水源
0236 礼亮
0215 翔宇
1124
1123 志铭

产品宣传视频连接:戳我进入前端

  • 评估团队中每一个人对本次做业的贡献比例

姓名 得分(百分制比例%)
柯奇豪 26.25
黄毓明 23.25
蒋雄 14.25
黄志铭 9.25
丁水源 9.25
林翔宇 7.25
林淇 6.25
杨礼亮 4.25

GitHub 项目连接:戳我进入数据库

Part 1. 原计划、达成状况及缘由分析

  • 原计划将什么功能作到什么程度小程序

    完成项目原先设定的全部功能,并作到界面简洁大方,操做友善,基本无bug,同时将其进行部署测试。后端

  • 实际作得怎样了微信小程序

    项目的功能基本已经实现,但存在部分bug以及一些不友好的操做,咱们会尽快修复改善并优化界面。此外,咱们因为某些特殊缘由,迭代掉了想法功能,但并不影响产品使用与定位。微信

  • 若是没有达成,反思是哪些因素影响的markdown

    有一说一,从最后的结果看,做为PM的我来讲,前期在工做任务的统筹规划上存在着问题,致使后续工做进度紧张,没有可以及时的督促组员进度,同时没有依据每一个人的能力分配任务,存在部分划水现象的出现以及工做完成不善的情形发生,这些都是项目进程中所遇到的问题点。

Part 2.Beta 版本展现

  • 小组模块(对于人员的编组,功能的执行对象)

  • 共享编辑模块(用于文章的多人编辑,做者进行审核应用或者版本回退)

  • 通知模块(进行事项消息的通知确认工做)

  • 个人模块(我的信息栏以及软件反馈处)

  • 签到模块(进行定位+wifi的准确签到)

  • 详情查看模块(对于我的已发布或参与的信息进行查阅)

Part 3 现场答辩得分

  • 小组 评分
    第一组 76
    第二组 77
    第三组 80
    第四组 84
    第五组 74
    第六组 73
    第七组 79.5
    第八组 86
    最低分 73(第六组)
    最高分 86(第八组)
    有效分数 76,77,84,74,79.5,80
    最终平均得分 78.4

Part 4 Q&A

(由于问题中存在部分重复性的提问,故这里作整理后进行统一答复)

Q1: 界面展现中的部分数据是从数据库实时获取的仍是写在前端页面中的本地数据?若是是后者请进一步完善/体验程序,有部分原生程序,是前端默认的数据吧,好像数据格式也不完整?/大家的功能是否真正实现,仍是只是前端作好

A1:你好,所有都已实现,咱们没有在前端听任何的数据,写一个静态页面只是浪费时间的事情,咱们也不可能拿一个原型去糊弄你们,所有都是经过受权后的openid从数据库调用的数据,只是前端存在部分逻辑错误,如今咱们已经修正大部分,若是仍有质疑,能够打开调试查看wxml,或者联系咱们。

Q2 :用户权限的定义能够更细致一些吗?

A2: 你好,用户权限咱们正在优化,目前已经完成的权限,匿名投票的信息查看,小组管理,我的发布信息查看,其余的暂时在考虑,可能存在部分逻辑错误,咱们也在积极寻找bug

Q3: 考虑过如何推广,增长用户量吗?

A3: 你好,咱们这是一个工具类软件,而且借助于微信小程序的平台开发,须要域名备案及其余相关杂项,相比于其余平台较为繁琐(也是咱们的准备不足),目前咱们已经经过初审,咱们将在小程序正式发布以后进行推广,从体验用户开始,咱们认为校园会是这个小程序的较好应用场景。

Q4: 对下拉刷新的功能会进行修改吗?

A4: 你好,咱们应该不会考虑下拉刷新,而是改成及时反馈,这次展现多是忘记添加reload函数。

Q5: 请问大家beta版本分工是怎样的?/从alpha版本到beta版本,项目进度如此快,能够介绍一下大家的分工及各个模块具体花费的时间吗?

A5:分为两组,各4人(加上新队员),一组负责投票、签到、通知及用户和分组三个功能和界面,其他负责共享编辑开发及部分前端美化,顺带博客与视频。原定前端人员再作一些整体页面的美化。此外,具体的时间并无统计,可是常常加班到凌晨

Q6: 在遇到任务分配不均的时候是怎么样处理的呢?

A6: 以前α版本的时候确实遇到过,那时候不清楚先后端工做量,前端工做较重,自从上一版本发现问题后就积极解决,后端参与到前端js界面参与接口和调用,前端更多的去重构和美化界面。

Q7:后期打算如何推广,面对腾讯各类官方助手工具和WPS文档编辑?/和一些大厂作的在线文档相比,大家的优劣势在哪呢

A7: 咱们主打的即是集成、便捷的办公,咱们功能较全,同时比较方便,无需跨APP完成多种办公需求!此外,共享编辑的功能是git类型,推广的话,咱们认为校园会是这个小程序的较好应用场景,劣势的话,首要的即是用户量及知名度,另外,咱们的开发能力有限,可能没法考虑到更多的需求。

Q8: 在版本现场演示时给予用户操做引导,是否会是更好的展现方式?

A8: 谢谢大家的建议,咱们会考虑的,此外,咱们在”个人“页面加入了帮助文档,供初次操做用户学习。

Q9: beta阶段相比alpha阶段项目进度日新月异项目组是如何作到的?/针对beta冲刺有什么感想吗?

A9: 你好,咱们在alpha版本中踩了许多坑,致使效率低下,在beta版本中总结教训,明确分工,此外,咱们的大部分后端在alpha版本中已经完成。说到感想的话,或许有时候踩过的坑会成为一次经验。分工明确也会是一个好的选择

Q10: UI能够进一步美化

A10: 谢谢大家的建议,咱们会考虑进一步再美化的,emmm,尽全力符合大众口味

Q11: 定位签到功能可否如期实现?

A11: 定位签到功能目前咱们已经采用WIFI和位置签到两种方式,能够说是基本实现该功能啦~

Q12: 团队具体分工是怎么样的呢?

A12: 分为两组,各4人(加上新队员),一组负责投票、签到、通知及用户和分组三个功能和界面,其他负责共享编辑开发及部分前端美化,顺带博客与视频。原定前端人员再作一些整体页面的美化。此外,具体的时间并无统计,可是常常加班到凌晨

Part.5 我的部分

  • 我的PSP
PSP Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟)
Planning 计划    
· Estimate · 估计这个任务须要多少时间 10 10
Development 开发    
· Analysis · 需求分析 (包括学习新技术) 5 5
· Design Spec · 生成设计文档 5 5
· Design Review · 设计复审 (和同事审核设计文档) 0 0
· Coding Standard · 代码规范 (为目前的开发制定合适的规范) 20 30
· Design · 具体设计 30 30
· Coding · 具体编码 160 300
· Code Review · 代码复审 0 0
· Test · 测试(自我测试,修改代码,提交修改) 20 20
Reporting 报告    
· Test Report · 测试报告 0 0
· Size Measurement · 计算工做量 5 5
· Postmortem & Process Improvement Plan · 过后总结, 并提出过程改进计划 5 5
合计   260 410
  • 我的学习进度条(每周追加)
第N周 新增代码(行) 累计代码(行) 本周学习耗时(小时) 累计学习耗时(小时) 重要成长
11 50+ 2350+ 28 158 界面和接口复审完善,交互测试,总算顺利完成了,太好了
相关文章
相关标签/搜索