一、基本情况

小方的博客

• 现场答辩总结

  总体上达到既定目标，按照柯老师的指导，在最后一次课我们会给出明确的一张包括可跳过的APP图标和名字的图表

• 全组讨论的照片
  

• 评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例

二、总结思考

2.2.1 设想和目标

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

  我们计划研发的APP———AdKiller，是一款可以自动快速跳过手机APP起始页广告的APP
  秉承绿色安全非盈利的态度向Android手机用户开放使用
  对典型用户和典型场景都有清晰的描述

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

  我们第二阶段达到了原定计划的95%
  原计划的功能实现了自定义规则功能
  Beta阶段没做的任务只剩下最终的测试和与同类产品的对比了，
  由于本阶段开发的功能不是必要功能，是锦上添花的功能，所以我们按照原计划交付时间交付了
  计划用户暂未达到预期，因为本次Beta冲刺我们的开发和测试是同步进行的，软件更新速度很多，为了能及时地反馈，我们只是小部分群体试用测试，用户数量到达25名。

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

  25名体验者的反馈比较良好，但是面对一些“顽固”的APP起始页广告，
  我们毫不忌讳地承认暂时还不能达到100%成功率，但是小步的成功也令人欣慰，我们离成功更进一步。

• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进？

  我们最大的问题是前期准备工作不足，没有做成良好的软件分析，导致功能设计的过程中进度迟缓，
  除此之外，对技术的学习和掌握不够扎实，导致研发周期漫长，前几次现场答辩效果也不理想。
  如果能够重来一次，我们会前期做好严谨的软件需求分析和技术分析，做到事半功倍 。

2.2.2 计划

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

  在Beta冲刺阶段，都会在站立会议过程中进行对未来一天的小计划

• 团队在计划阶段是如何解决组员对于计划的不同意见的？

  通过线上QQ群，腾讯会议，时刻交流，针对大家提出的意见，产生的分歧，共同讨论。

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

  因为一些不可抗力，我们原计划的工作完成度为95%，局限于技术手段原因，一些APP的跳过暂时做不到。

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

  没有，毕竟时间紧迫， 都没有时间做很多事......

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

  大体没有意外，一切都在按部就班进行。
  只是有一些功能由于能力不足，确实优化不来，但实际中不影响软件使用。

• 将来的计划会做什么修改？

  会在测试与对比中对一些功能进行优化
  认清现实，毕竟有些技术暂时无法掌握，就不要想太多......

• 学到了什么? 如果历史重来一遍, 会做什么改进?

  我们学到了AndroidStudio的开发知识，
  更重要的是团队合作的重要性。

2.2.3 资源

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

  有，我们前期都是在虚拟手机上进行，有很多好用的软件，例如：夜神模拟器，AndroidStudio自带的手机模拟器。

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

  因为都是统一时间，一起工作，所以工作时间稳定，
  精度很高；我们尽量不加班，以便不占用大家其他科目的学习时间。

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

  我们有设置专门的测试组，发动同学，舍友，亲朋好友这些人际关系进行初步测试。
  我们也有设置前端组，对界面进行逐步美化。

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

  虽然我们大家都会遇到一些困难，可能让更适合的人做会有效率，
  但是，这是一个学习的过程，如果一直逃避那就违背了学习的初衷。

• 有什么经验教训? 如果历史重来一遍, 会做什么改进?

  最大的经验教训就是要尽早做好计划，同时不能急于求成，要考虑到自身的能力。
  要保持良好的心态，面对困难心态要稳住，面对技术上的欠缺，要有“等我发育再打团的心态”。

2.2.4 变更管理

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

  通过QQ群的群公告

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

  通过分析用户的需求“迫切程度”

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

  我们对Exit Criteria是有清晰的定义的，
  对完成的模块进行测试，如果测试组结果反馈良好，无bug，我们就可以称之为“做好了”。

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

  可以

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

  大家都很自觉负责，会熬夜加班，我们想睡觉！！！！

2.2.5 设计/实现

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

  由组长分化模块，组员主动认领。

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

  有，但不完全有，我们会进行“民主”讨论，得出统一的意见，
  所以整个“Beta冲刺”是一个peace and love的过程。

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

  有用到UML进行分析设计，后续过程中会进行单元测试等其它手段进行全面分析。

• 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

  有很大区别，后面的更加完善，具体。因为随着开发的进行，我们的功能设计会发生改变。

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

  在检测活动界面控件时产生的Bug最多，因为不同APP的布局是不一样的，有些软件的开屏广告是单独的界面，有的则就是主界面，导致搜索方式不同。
  发布之后发现有个地方初值设置错误，好在改回来了。
  我们在设计/开发的时候确实没有考虑到不同品牌的手机、不同APP在一些地方上的差异，但我们也的确无法解决这些差异性，只能在大多数情况下实现功能。

2.2.6 测试/发布

• 团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？

  有，我们会在测试软件本身功能可用性的情况下，加入与同类型软件的对比测试。

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

  通过不同机型的安卓手机和模拟器进行测试。

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

  有一次发布忘记了keystore的密码，还在最后想起来了

2.2.7 团队的角色，管理，合作

• 团队的每个角色是如何确定的，是不是人尽其才？

  团队的每个角色一开始是有规划的，但最后采用的是谁行谁上的策略。
  大家都尽力地做好了自己的部分，算是人尽其才了。

• 小组成员之间有互相帮助么？

  of course

• 当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：

  高靖涵：

  • 我感谢文涛对我的帮助， 因为某个具体的事情:这个项目做起来很费力，Android技术我也是无法全部吃透，多亏他熬夜加班带着我们坚持了下来。
  • 我学到了要善于阅读官方文档，不然对已经可以拿来直接使用的工具不够熟悉，已经有了工具，却还是埋头苦干
  • 如果历史重来一遍，我会先做好规划，看看我具体的任务需要哪些知识，其实不必从头一点一点学，先学会急迫需要的。

  赵文涛：

  • 我感谢吴永铭对我的帮助，因为某个具体的事情:他和我一起开发软件高级功能的时候，由于一直没有进展，我都准备放弃了，但他坚持查阅资料，最终写出让人满意的功能。
  • 我学到了要善于使用搜索引擎，有时候很多东西其实网上都有现成的资料，埋头苦干最终做出来的东西，其实效果远不如前人已经写好的。
  • 如果历史重来一遍，我会在一开始就想好要做什么，大概该这么做，做不做的出来，充分考虑代码的可拓展性，而不是做一半突然想到某件事要做，导致原先写的代码还要修改。

  吴永铭：

  • 我感谢 赵文涛 对我的帮助， 因为某个具体的事情: 在功能的完善上给了我很多建议和帮助。
  • 我学到了安卓的一些新知识，比如：任务栈。
  • 如果历史重来一遍，会提前做好规划，以免和其他课程或考试有冲突而导致时间紧张。

  王佳明：

  • 我感谢 刘双 对我的帮助， 因为某个具体的事情:作为搭档互相分担任务，一起做软件测试，学习JAVA的时候也给我提供不少的建议让我少走弯路。
  • 一个人的能力总是有限的，当你什么事情都能自己应付得来时感觉自己无所不能，但是像我这样技术不是特别好的人，有一个能一起奋斗的队友是多么的重要
  • 如果历史重来一遍，我会在这学期之前就学好Java，在组内多承担一些事情，也给自己组的主力减轻一些压力。

  黄建玮：

  • 我感谢高靖涵对我的帮助， 因为某个具体的事情: 帮助我修好bug，并帮助我修改博客中的问题，帮助我查阅资料和文档。

  王亿平：

  • 我感谢高靖涵对我的帮助， 因为某个具体的事情: 博客的格式之前并不了解，导致文本并入到组内文本时一直格式错误，他告诉了我博客应该使用Markdown编辑器，同时教了我相关的格式，从而保证了Alpha冲刺报告没出现格式上的问题。
  • 我学到了对于自己认为正确的东西，实际上很可能并不正确，有一个人帮忙指正可以纠正自身的错误认知，减少不必要的扣分。
    -如果历史重来一遍，我应该去提前去了解小组博客的文本格式和编辑器的统一规范是什么，好好的完成自己的任务，减少组长的工作量。

  • 刘双：
  • 我感谢王佳明对我的帮助， 因为某个具体的事情:在我想偷懒或者松懈的时候总能督促和提醒我，而且也在完成作业的时候给予我一些指点，帮助我解决了难题

  刘苇：

  • 我感谢王佳明对我的帮助，因为某个具体的事情:他在我对安卓开发一无所知的情况下给我提供了帮助，起了一个头。
  • 我学到了要多利用网上前辈们的劳动，我们现在要学的知识其实前人已经帮我们总结好了，只等我们自己去寻找学习。
  • 如果历史重来一遍，我会在一开始制定详细的计划，而不至于毫无头绪。

  陈静：

  • 我感谢王佳明对我的帮助， 因为某个具体的事情: 提供测试建议。

  杨寓荃：

  • 我感谢 高靖涵 对我的帮助， 因为某个具体的事情: 给我提了不少建议。
  • 我学到了很多东西不一定要自己埋头想，参考别人的东西会带来更多的启发。
  • 如果历史重来一遍，我会先确定好设计再进行开发。

2.2.8 总结

高靖涵

通过这学期的软工实践，我学习了Android的一些皮毛
这次冲刺我们真的没什么可以修改了，技术有限
peace yoh!~

赵文涛

Beta冲刺的时间里我做的工作其实就是对功能的完善，写一些Alpha没时间做的功能，但最后很多功能由于自己能力不足，还找不到资料，最终只能放弃，还是觉得挺可惜的。
通过这次软工团队作业，我发现原来大家都这么强，我和大佬们的差距已经这么大了，这的确是打击到我了，但同时也激励了我，他们行，那我也行，未来我一定会加强对自身能力的锻炼。

吴永铭

Beta冲刺主要任务就是对功能的完善,在完成隐藏最近任务这一功能上,找了好久的资料。困扰我的在于如何通过开关控制隐藏功能,最后查询到一篇关于任务栈的文章才得以解决。
总体来说，这次作业提高了自学能力，入门了Android开发，收获很大。

刘双

大家都是第一次做有关Android应用，刚开始比较迷，不知道从哪着手，
多亏组内大腿推荐相关的教学视频学习，
在完成作业的过程中学到了很多，非常感谢队友的照顾。

王佳明

因为学习安卓需要用到java,作为一个只会一点c++的人只能先学习java,加上正好有好几门考试导致没时间学习安卓算是一个遗憾
认识到自己在大一大二的时候太水了，没有在空余时间多学习学习，现在和别人差距挺大的，不过学习不怕晚，现在努力也不是很迟，就是可惜之前的时光都荒废了。
但是作为测试组成员也很高兴，和搭档一起做测试，我的两个手机下载到发烫有时候时间紧任务重第二天就要结果，通宵做测试也挺爽的
这个课程挺好的，虽然挺累的(实话实说)，但是和队友相处融洽，在我敲代码(Auto.js)时因为学的不多函数不太会用，队友疯狂上网给我找函数用，太好了

陈静

这次Beta冲刺中对于前端界面进行了改进，收获很多（虽然可能是负向优化了ಥ_ಥ）
通过这学期的软工实践学习到了很多，比如前端学习，安卓应用开发，无障碍服务等，最重要的是学会了更好地规划时间！

杨寓荃

这次团队作业确实没有怎么帮上队友，反而都是队友们在帮助我，让我认识到我和别人还有一定的差距。
在这次作业的过程中，确确实实学到了一些东西，个人能力也有所提升。

刘苇

这次主要是软件测试，软件测试不仅可以测试功能，还可以和同类软件横向比较
通过这次实践，我对软件开发有了更多认识，知道了团队合作交流的重要性，还学习安卓无障碍技术，收获满满

王亿平

在本次Alpha冲刺中我学习到了很多有关于安卓开发方面的知识，和团队一起做项目感觉很充实，激发了每一个人的热情，虽然有很多大作业缠身，但还是挤出了时间去学习本次开发的知识，参与讨论和测试。
我感受到了一个有凝聚力的团队对于软件的开发是相当重要的，倘若要一个人只能自己去开发一款软件，不仅效率低，效果差，且没有精力去除bug，一个团队相互合作可以将每个人的特长集合起来，使得软件既美观同时又兼具良好的功能性，大大吸引可能存在的用户群体。
软件还可以让身边的其他同学帮忙测试，除了可以帮助其他同学广告的困扰外，还可以得到更充分的测试样本，帮助我们更快的锁定软件的bug，帮助我们去分析和修改，使产品做得更好。

黄建玮

这学期的软工实践，让我在极短的时间内学习了大量的知识，并且增强了自己的学习能力
学习需要多实践，多查阅资料，不能闭门造车。
感谢所有帮助过我的组员，respect！