标签：显示 读取 测试工具 敏捷开发 上传 会议 java 效果 注释
- 解决大学生利用碎片化时间来学习英语单词，备考相应英语等级考试。
- 微信程序的b名字叫“背背佳”，里面MVP功能就是单词学习，辅助功能也是围绕单词学习，所以是定义的很清楚。
- 我们的典型用户就是大学生，典型场景就是大学生在自己的课余时间等碎片化时间，可以随时拿起手机进行单词学习。
- 相对个人阶段，结对编程阶段，软件工程的质量提高了很多。比如说：
1.最突出的就是我们有一个项目可以上线，有一定的用户量。虽然只用MVP功能，还不够完善。
2.有体系化的编程规范文档。
3.有最后的BUG分析，功能测试，来完善我们的项目。、- 提高了一大截，以上的3点都是衡量标准。
- 相比我们alpha初期定下的目标，我们是有很多功能没有实现的，原计划有4部分，如下图。因为功能太多，能力和时间有限，最后只实现了主要功能，和部分辅助功能。
- 原计划是达到30个用户量。
找了几个试用者进行访问。对主要g功能的接受度和我们预想一致，但是我们还希望这个单词微信小程序有几处不同于其他单词程序的亮点，目前还没有实现（辅助功能），用户也很期待。我们离目标更近了。
由于Alpha阶段冲刺时间较短，我们花大量的时间在开发上，所以测试时间安排的不够。对于美工设计，我们并没有低估它的难度，也知道我们做的远远不够好。
没有。我们团队的每个人都是不可缺少的一份子。
是的。因为我们团队成员住的比较近，而且我们在社交网络上的联系也很紧密，一有变更信息，我们或是面对面通知，或是及时讨论组通知。
我们预期想要实现的功能有好友pk，但是技术难度较高，且听从老师建议，决定推迟实现。而我们小程序的核心就是单词学习，所以词库的引入单词的学习是必须实现的。
- 点击单词的时候具备语音播放功能
- 复习统计功能要完善
- 增加单词本中的向上按钮
- 添加设置功能，比如可以清除缓存
有。还没搭建服务器的时候，将词库放在前端，服务器搭建完后，就将词库转移到后端。
能。当我们队员出现没办法解决的问题的时候，我们都会积极协作帮忙，尽量做到在最短的时间内解决问题。
设计工作在敏捷开发前的就做了原型设计。后期实际开发时，前端根据需求对负责的页面进行修改。因为开发人员是最后实现软件界面的，所以是比较合适的人。后端的结构设计也是由实际后端开发者设计的。
最初设计时包括单词pk的模块，后来实际开发时才估计出时间不够，考虑要不要先放弃这个功能。后来团队开会讨论，最后队员一致赞成先做好MVP功能，砍掉pk功能。
小程序java后端运用了单元测试（jnuit）来帮助设计与实现。能确保能正确获取前端数据，和提取存储的单词。
单词的读取和调用接口翻译显示功能的Bug最多。因为这块涉及的数据传递较多，小程序的接口调用比较严格，数据传递时后期发现开发时小程序在开发工具上调试成功，但是实际真机调试时数据传递跟微信开发工具显示的结果却不一致。设计/开发前没考虑到，真机调试会和微信开发工具结果不一致，手机调试结果也会跟上传体验的版本不一致，只能边做边发现问题。
代码复审主要是检查各行代码，添加注释，删除无关代码，比如后期未用到的方法等，增加可读性。代码规范我们遵循了四格缩进，“{ }”字符的放置位置等都执行了代码规范。
有，但是没有很规范。
- 功能测试：邀请用户体验小程序的功能并反馈
- 易用性测试：用户界面的直观易用性
- 兼容性测试：在几种Android和ios版本上进行兼容性测试
- 安装测试：邀请微信用户通过搜索或扫码形式安装体验小程序
是，有邀请同学等作为用户和测试队员对软件整体的功能在发布平台上进行测试。
有，可以利用微信开发者工具测试，后端利用junit单元测试。但是压力测试工具在linux平台安装后无法正常使用。
我们通过邀请室友、朋友或者假扮用户来测试并跟踪软件的效能，因为是微信小程序，从授权开始，到每个功能都体验一遍，并询问反馈或得出结论，再根据这些来继续改进完善。这些测试工作是有用的，在做之前觉得可能不会有什么明显的效果，但是真的去测试后发现要改进的还是很多，有一些还是之前没有发现的。而我们找到的改进有：界面不够完善/功能有所欠缺/用户操作有时有误差
我们团队在发布小程序时，因为是第一次操作，所以最开始会一直卡在证书方面，后面查阅了很多也问了其他已发布程序的团队。后来发布好了后，发现不能通过关键字查找小程序，但是可以通过完整的名字查找小程序。
CMM/CMMI一共分为五个等级，(1)初始级(initial)；(2)可重复级(Repeatable)；(3)已定义级(Defined)；(4)已管理级(Managed)；(5)优化级(Optimizing)。
而我认为我们团队目前状态属于第4和第5级之间。
我认为团队目前处于规范的状态；虽然已经有了一个有了主要功能的英语单词学习小程序出来，但是还需要调和整理一下之前所做过的，把之前所做过的规范好，以方便新功能的开发。
对于团队来说，大家的凝聚力要比前一个里程碑时强很多，自觉性、自主性、学习能力都有所提高。
对于项目来说，改进很大，因为上一个里程碑时我们只有形没有状，经过了ALPHA阶段后，我们把状的架构支撑起来了，就有了一个较完整的结构体。这应该是最大的改进了。
目前最需要改进的方面应该是对于小程序的附加功能。现在我们的小程序可以背单词，但是其他附加功能还不够完善，我们是希望做出一个满足大多数用户需求的微信小程序。
①主张简单：我们做微信小程序而不是APP的目的之一就是为了用户群体能简单操作，所以我们在架构模型的时候，就很简单的只分为三大模块，其中只有一个模块为主要功能，尽可能的保持模型的简单。
②拥抱变化：主要功能不变，可是附加功能可以有所改变，所以在“我的”界面中我们保留了几处空白为了之后进行开发，用户需求是一直持续并会改变的。
③无论团队内外，面对面交流始终是最有效的沟通方式：教师布置的任务中就有一个每日站立会议，这个会议虽然用时不长，大家都把每日任务简要陈述，但是也就这十分钟左右的会议让大家都知道了今天的主要进展会到哪一步让大家都清楚整个项目的进程。
| 名字 | 角色 | 团队贡献排序 | 可验证的贡献 |
|---|---|---|---|
| 曾艺佳 | PM | 1 | 主要框架支撑者 |
| 徐璐琳 | PL | 2 | 分担PM开发指定与跟踪 |
| 祁泽文 | PL | 3 | 分担PM开发指定与跟踪 |
| 王 兴 | PL | 4 | 分担PM开发指定与跟踪 |
| 吴 玲 | MDE | 5 | 项目产品模块设计者 |
| 郭琪容 | MDE | 6 | 项目产品模块设计者 |
标签：显示 读取 测试工具 敏捷开发 上传 会议 java 效果 注释
原文地址：https://www.cnblogs.com/net15/p/9042603.html
