20201120-2 Beta事后诸葛亮会议
此作业要求参见：https://edu.cnblogs.com/campus/nenu/2020Fall/homework/11545
组名：板砖
组长：李惠璨
组员：张传玉 朱航序 王艳鹤 樊培毅 魏琛
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决给用户发送提醒日程的功能，并且能够每日提醒，通过微信小程序带有的订阅消息这一功能来实现。定义的非常清楚，典型用户对一些大学生每天需要打卡的场景
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?
原计划功能全部实现，beta阶段已经发布， 用户原定30人，现在已达到57人。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
原计划用户30人，目前用户57人，已经达到用户目标，修改了上次用户所提出的问题，如：修改了功能单一，界面简陋等问题
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
重新再来一遍可能会详细制定一个可行性分析，在最初版本发布的时候由于技术原因，敏感词不能过滤导致不能按时发布，如果在最初设计小程序的可行性分析的时候想到了这一点，那么就会避免这个问题。
合理安排每个人的任务量，首要任务是做出可执行的最小执行版本出来。
计划
1. 是否有充足的时间来做计划?
有充足的时间做计划，每天都会开会讨论安排任务，时间大多20分钟以上。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
对于不同意见还是要考虑可执行性以及大多数人能否接受，综合考虑，如果大多数人能够接受就可以。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划完成。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有
5. 是否每一项任务都有清楚定义和衡量的交付件?
是的
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
按照计划执行，但是项目再发布审核时遇到了比较大的麻烦。文本内容安全检测以至于发布了很多版本没有通过，第一次做这种小程序没有预想到这样的意外。
beta阶段的按照计划进行，没出现什么意外。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有，缓冲区还是让任务留有一定的余地，无法完成的情况下可以找其他人协助。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
最好再安排计划时提前一些，这样会使得整体项目更有规划性，对每个人的分工再详细一些，打好提前量
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一定要尽快实现项目的主要功能，在之后添加功能以及改善都会容易很多，也不会焦虑。
无论添加什么功能，都尽快完成，因为就算是一个很小的功能可能都会引起很大的错误，不要拖到deadline
资源
1. 我们有足够的资源来完成各项任务么?
有。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
都是安排一天之内能够完成的的任务量，精度也就是一天了。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间不是很充足，有些bug还是上线之后用户反馈才发现的，还好及时人力资源足够，没有低估美工以及文案的难度，文案是很需要花心思的。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
应该把任务分配的给更加细致一些，让每个人都得到应有的任务量。争取提前编写完界面，好让美工设计和文案的时间充分一些
变更管理
1. 每个相关的员工都及时知道了变更的消息?
知道
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
小组讨论，优先级高的先实现，优先级低的可以推迟。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，实现服务通知。
4. 对于可能的变更是否能制定应急计划?
能
5. 员工是否能够有效地处理意料之外的工作请求？
能，团队成员都有很好的能力来处理意外。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
成员之间一定要互相沟通，交流进展，有难题可以一起解决，成员之间的互相信任，互相帮助。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在项目分析阶段完成，由朱航序以及李惠璨完成，是合适的时间合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有使用这类工具
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
实现服务通知的时候产生的bug最多，首先是对服务通知的基础模板代码不熟悉，云函数的调用和本地函数的调用有区别，在发送信息是一直报错：40003，bug显示获取不到用户的openid,查阅了很多资料也没有解决，使用了四五种方法来避免这样的bug,但是最后的结果都不尽人意，最后通过把openid存储到数据库中，从数据库中选数据存放到云函数中设立的数组中，再然后在发送函数里使用数组里的数据进行发送，历经波折。
发布之后遇到的bug主要是获取日期的问题，在云函数中获取的日期当小于十号的时候是1，2，3，而我们选取的数据是01，02，03。主要原因是我们在测试的时候是二十几号所以没有遇到这样的问题，当月季更新时就出现了这样的问题。
beta阶段测试的时候不能同时发送给许多用户提醒日程，是因为在开发的时候都是一个用户进行测试的，没有考虑多个用户。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
多次复审，严格执行了代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
多做测试，避免后期很多问题。在发布之前测试再详细写会更好。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有
2. 是否进行了正式的验收测试？
没有
3. 团队是否有测试工具来帮助测试？
有，使用了小程序自带的测试工具，真机测试的方式
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有进行这样的测试
5. 在发布的过程中发现了哪些意外问题？
审核不通过，这是一个很严重的问题，为了解决这项问题我们也尝试了很多种的方案，最直接的是去除文本添加功能，使用选项代替，但是我们在开始的时候并不想过早的放弃我们的这一功能，所以使用了http调用的的方式，请求测试链接，测试输入文本是否符合规范，但是在反馈时却出现一个问题，wx.reques函数里面返回不了状态值，然后我们又尝试了将这个函数放在按钮的js中不需要重新调用函数，在真机测试的时候执行的很完美，但是在预览时出现了问题，在退出开发模式时程序不执行http调用，最后我们为了尽早项目上线，只能使用picker代替文本输入。
beta阶段没有意外问题，都是按照计划进行
我们学到了什么? 如果重来一遍, 我们会做什么改进?
需要给发布时间留够足够的时间来应付可能发生的意外，不能把时间凑得刚刚好。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
根据成员的能力来分配任务，人尽其才。
2. 团队成员之间有互相帮助么？
有
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队讨论，讨论出合理的方案
