软工网络15团队作业7——Alpha冲刺之事后诸葛亮

Posted 2020-11-05 哈哈哈1112

设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

• 解决大学生利用碎片化时间来学习英语单词，备考相应英语等级考试。
• 微信程序的b名字叫“背背佳”，里面MVP功能就是单词学习，辅助功能也是围绕单词学习，所以是定义的很清楚。
• 我们的典型用户就是大学生，典型场景就是大学生在自己的课余时间等碎片化时间，可以随时拿起手机进行单词学习。

和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？具体提高了多少？如何衡量的？

• 相对个人阶段，结对编程阶段，软件工程的质量提高了很多。比如说：
  1.最突出的就是我们有一个项目可以上线，有一定的用户量。虽然只用MVP功能，还不够完善。
  2.有体系化的编程规范文档。
  3.有最后的BUG分析，功能测试，来完善我们的项目。、
• 提高了一大截，以上的3点都是衡量标准。

我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

• 相比我们alpha初期定下的目标，我们是有很多功能没有实现的，原计划有4部分，如下图。因为功能太多，能力和时间有限，最后只实现了主要功能，和部分辅助功能。
  

• 原计划是达到30个用户量。目前截至5月15日有14个用户。不过从统计图看，5月16日用户量有所增加。
  
  

用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

找了几个试用者进行访问。对主要g功能的接受度和我们预想一致，但是我们还希望这个单词微信小程序有几处不同于其他单词程序的亮点，目前还没有实现（辅助功能），用户也很期待。我们离目标更近了。

计划

是否有充足的时间来做计划?

• 有充足的时间来做计划，因为刚开学的前几周，老师就已经把她本学期的教学计划告诉我们了，而且我们住的比较近，所以就很方便讨论计划。

团队在计划阶段是如何解决同事们对于计划的不同意见的?

• 如果有小组成员跟团队大部分成员的意见不同的话，我们就会采取先让该成员分析一下她的这个看法的优点在哪里，然后我们说一下我们看法的优点所在，最后大家一起讨论，做到取长补短。

你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

• 最后我们的计划大部分是做完了，还剩下好友PK以及遗忘曲线还没有实现，这是因为在初期的时候，我们错误的估计了时间，导致最后任务非常多，老师也有在博客下面评论建议我们先做主要功能，所以我们最后讨论决定，先实现学习模块与打卡的功能，剩下的在Beta阶段实现。

有没有发现你做了一些事后看来没必要或没多大价值的事?

• 有，就是单词本文件，当时我们在前端和端都有放置单词文件，最后实现的时候发现前端根本没有必要放，因为直接从后端调用即可。

是否每一项任务都有清楚定义和衡量的交付件?

• 不是，因为我们有时候遇到什么错误可能会立即修改，这样就可能导致跟刚开始商量的不一样，所以不是每一项都有清楚定义和衡量的交付件。

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

• 项目出现最大的以外就是数据库的问题，冲刺开始的几天，负责后端的我们就开始纠结与数据库的问题，没有成功，最后使用的是文件。
• 没有预料到的风险就是小程序的发布，体验版发布后，电脑上运行是正常的，但是在手机上页面却跳转不了。至于为什么没有估计到，是因为这个风险就是个意外，我们都没有想过居然还有这种结果。

在计划中有没有留下缓冲区，缓冲区有作用么?

• 有啊，因为冲刺阶段我们有一个体测，缓冲区的作用就是给予队员调整自己和决定接下来如何确定学习计划的作用。

将来的计划会做什么修改？（例如：缓冲区的定义，加班）

• 有修改，团队讨论后决定把PK这个功能去掉，新增一个收藏单词的功能。接下来的冲刺，我们应该还是会留有一定的缓冲区的，因为如果没有缓冲区真的太累了，这学期课程比较多，每个人还需要为自己接下来的实习或者其他事情做准备。至于要不要加班，这个是弹性的，效率高的话就不用，万一哪天太拖沓了，那就知道加班了。

资源

我们有足够的资源来完成各项任务么?

• 从技术上来说，我们所学的java，数据库的语言的基础可以方便我们去看懂微信小程序专门的开发语言WXML等
• 从工具上来说，我们使用了微信开发工具专门的平台，同时用微信程序开发教程资源，方便我们学习和研究。
• 从人员上来说，我们有6个人，分工明确，各有所长，各司其职，配合度高。

各项任务所需的时间和其他资源是如何估计的，精度如何?

• 各项任务所需的时间是从个人的能力，以及分配模块的难度来估计的。
• 从这次开发过程中，还是由于能力时间有限，没有能和设想的一样实现的很完美。因为需要学习一个新的语言，再去开发。所以精度不是很高。但后面经过调整，助攻主要功能，效率一下就提上去了。

测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

由于Alpha阶段冲刺时间较短，我们花大量的时间在开发上，所以测试时间安排的不够。对于美工设计，我们并没有低估它的难度，也知道我们做的远远不够好。

你有没有感到你做的事情可以让别人来做（更有效率）?

没有。我们团队的每个人都是不可缺少的一份子。

变更管理

每个相关的员工都及时知道了变更的消息?

是的。因为我们团队成员住的比较近，而且我们在社交网络上的联系也很紧密，一有变更信息，我们或是面对面通知，或是及时讨论组通知。

我们采用了什么办法决定“推迟”和“必须实现”的功能?

我们预期想要实现的功能有好友pk，但是技术难度较高，且听从老师建议，决定推迟实现。而我们小程序的核心就是单词学习，所以词库的引入单词的学习是必须实现的。

项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

• 点击单词的时候具备语音播放功能
• 复习统计功能要完善
• 增加单词本中的向上按钮
• 添加设置功能，比如可以清除缓存

对于可能的变更是否能制定应急计划?

有。还没搭建服务器的时候，将词库放在前端，服务器搭建完后，就将词库转移到后端。

员工是否能够有效地处理意料之外的工作请求？

能。当我们队员出现没办法解决的问题的时候，我们都会积极协作帮忙，尽量做到在最短的时间内解决问题。

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在敏捷开发前的就做了原型设计。后期实际开发时，前端根据需求对负责的页面进行修改。因为开发人员是最后实现软件界面的，所以是比较合适的人。后端的结构设计也是由实际后端开发者设计的。

设计工作有没有碰到模棱两可的情况，团队是如何解决的？

最初设计时包括单词pk的模块，后来实际开发时才估计出时间不够，考虑要不要先放弃这个功能。后来团队开会讨论，最后队员一致赞成先做好MVP功能，砍掉pk功能。

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

小程序java后端运用了单元测试（jnuit）来帮助设计与实现。能确保能正确获取前端数据，和提取存储的单词。

什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

单词的读取和调用接口翻译显示功能的Bug最多。因为这块涉及的数据传递较多，小程序的接口调用比较严格，数据传递时后期发现开发时小程序在开发工具上调试成功，但是实际真机调试时数据传递跟微信开发工具显示的结果却不一致。设计/开发前没考虑到，真机调试会和微信开发工具结果不一致，手机调试结果也会跟上传体验的版本不一致，只能边做边发现问题。

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码复审主要是检查各行代码，添加注释，删除无关代码，比如后期未用到的方法等，增加可读性。代码规范我们遵循了四格缩进，“{ }”字符的放置位置等都执行了代码规范。

测试/发布

团队是否有一个测试计划？

有，但是没有很规范。

• 功能测试：邀请用户体验小程序的功能并反馈
• 易用性测试：用户界面的直观易用性
• 兼容性测试：在几种android和ios版本上进行兼容性测试
• 安装测试：邀请微信用户通过搜索或扫码形式安装体验小程序

是否进行了正式的验收测试？

是，有邀请同学等作为用户和测试队员对软件整体的功能在发布平台上进行测试。

团队是否有测试工具来帮助测试？

有，可以利用微信开发者工具测试，后端利用junit单元测试。但是压力测试工具在linux平台安装后无法正常使用。

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

我们通过邀请室友、朋友或者假扮用户来测试并跟踪软件的效能，因为是微信小程序，从授权开始，到每个功能都体验一遍，并询问反馈或得出结论，再根据这些来继续改进完善。这些测试工作是有用的，在做之前觉得可能不会有什么明显的效果，但是真的去测试后发现要改进的还是很多，有一些还是之前没有发现的。而我们找到的改进有：界面不够完善/功能有所欠缺/用户操作有时有误差

在发布的过程中发现了哪些意外问题？

我们团队在发布小程序时，因为是第一次操作，所以最开始会一直卡在证书方面，后面查阅了很多也问了其他已发布程序的团队。后来发布好了后，发现不能通过关键字查找小程序，但是可以通过完整的名字查找小程序。

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

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	项目产品模块设计者

---