【软工小白菜】Beta阶段事后分析
例会照片：
一、设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的目标是开发一款支持博客园网页端大部分功能的安卓手机app，我们要解决的问题主要是为广大博客园用户在移动端也能方便浏览博客园并使用功能。在典型用户和典型场景上我们有比较清晰的描述，具体描述在功能规格描述。
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划增加功能为
- 增加我的收藏的添加删除功能
- 增加班级作业公告的发布，班级成员的添加与删除功能
- 增加退出后的记忆功能，不用重新登陆
- 增加首页博客的评论回复功能
我们在Beta阶段不仅达到了原有目标，并且在此基础上增加了一些便利性的改善
- 增加博问关键词搜索功能
- 增加博问浏览历史记录功能
交付时间如下图所示
在5.29日完成了所有的功能扩展。
我们在Beta阶段计划的用户数量120，截止本篇博客的下载数量为109，还未达到目标。但是目前有更多用户已加入我们的用户反馈群，在群中共享的apk文件未计入数量。随后的时间我们会继续宣传推广，达到预期目标。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
相比我们上一个阶段，我们团队的软件工程质量有所提高。具体表现在以下方面。
- 代码管理方面
- 每个组员创建自己的分支并提交代码至该分支，防止了一定程度的冲突
- 完成自己部分目标后，进行有序地代码分支合并
- 每次组会讨论需要完成的功能，并公示在github-issue中。
- 测试
- 相比alpha阶段的手工测试，我们使用了wetest等自动化测试软件，提高了测试覆盖度和测试效率。
- 除去对功能的测试，我们还进行了兼容度的测试。
4. 用户量、用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量与我们预想一致，当前的用户量接近我们的目标。相比alpha阶段，我们离目标更近了。
用户对于博客、博问、班级管理等模块接受程度与我们的预想一致，一般用户对博客、博问模块需求度比较高。班级管理模块功能适用于学生和老师等教育人群。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
我们对项目的管理会更加重视，对代码规范和commit格式进行相应的要求。
二、计划
1. 是否有充足的时间来做计划?
我们有比较充足的时间来做计划。首先我们已经完成了alpha阶段任务，我们的app有了一个雏形，我们所要做的更多是ui的美化和在原有基础功能上的拓展。我们大约花费两周时间来做完整的计划，因为我们的博客园开发使用的是Android原生开发方法，因此其技术难度并不算很高，各个成员有相对充足的时间学习其技术并充分估算任务难度和任务时间，并做出完整的计划方案。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
当组员间有不同意见时，我们通常会让PM先协调沟通，并且由于我们每位组员之间工作的关联性较高，因此每一位成员可以参与不同意见的分析和讨论，大家一起来权衡不同计划的利弊，并提出自己的意见，最终经过协商统一计划。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们所有的工作全数完成，所有issue都已关闭。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
关于部分界面的无用设计，例如登录界面，因为登录是博客园官网实现的，由于当时我们对博客园登录的不了解自行设计了一个登陆界面，事后发现并没有用到它。
5. 是否每一项任务都有清楚定义和衡量的交付件?
都有清楚定义，详见issue。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
我们没有估计到博客园官方文档的错误情况发生，这么多开发者使用过其文档并成功完成开发后其官方文档仍然存在错误，这种情况是我们没有估计到的。我想这种不可抗力因素也是非常难估计到的。
项目在中期出了一个UI的bug：在博问页面中登录后跳转至已登录的页面，但是未登录的界面并未消失。主要是alpha阶段的遗留没有发现，在Beta开发阶段才遇到这个问题。
7. 计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，我们在29号已完成所有的工作。其后一个星期为缓冲区，主要做一些测试和UI统一优化。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划会预留更多的缓冲区，用于当期用户反馈的收集。
我们学到了什么? 如果历史重来一遍，我们会做什么改进?
我们意识到了测试的重要性，我们要对前阶段的产品进行充分的测试，以免后续开发出现“历史遗留”问题。
三、资源
1.我们有足够的资源来完成各项任务么?
有足够的资源。我们小组各成员经过alpha阶段的开发已经掌握了相当的开发经验。同时得到了博客园官方提供的接口文档的支持，还得到了许多学长的技术参考支持。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需时间是按照在alpha阶段的开发经验估计的，其他资源基本是Oauth2.0下http请求的学习。除了因官方api一些错误导致耽误的时间外，预估的基本准确。另外有些任务通过团队之间相互交流，完成的比预估要短一些。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时间充足，人力和软硬件资源足够。美工设计有点低估难度，我们对很多完成之后大家开会讨论后不太满意的ui进行了推翻重做,导致花费了很多时间。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
没有。因为团队的任务是按各个功能模块划分的，各个模块之间的难度差异不大，所以大家的完成效率也都基本一致。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
经验教训:ui的设计确实被我们低估了,很多时候弄完了才发现和心中所想的有点差距,不得不推翻重来
改进: 应该先讨论一下ui的设计,并且先做一个大概的界面看一看效果
四、变更管理
1.每个相关的员工都及时知道了变更的消息?
都及时知道了变更消息，团队成员在微信群中都比较活跃
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据技术难度和时间决定。最基础的浏览功能必须实现，某些最初设想的功能可能因博客园没有提供接口、实现比较麻烦、时间来不及而放弃或推迟。
3.目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
完成了我们设定的功能,且运行流畅没有bug,ui设计美观大方
4、对于可能的变更是否能制定应急计划?
我们的工作分配基本是按照功能模块进行划分的,新增成员主要是完善之前离走的成员负责的模块,而如果没有新增成员,则我们将着重完善离走成员负责的模块的ui设计方面的工作。
5、员工是否能够有效地处理意料之外的工作请求？
可以。每个成员遇到的问题都会及时在微信群中与PM沟通，团队会一起想办法解决。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一定要做变更规划以免到时候措手不及
改进方面就是进行变更规划,和应急方案,进行多手准备
五、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在Beta阶段，整体的架构已经完成，主要的目标是完善功能，修复bug和美化UI，所以在Beta阶段的主要设计工作就是UI界面。我们希望能找到一个好看的，统一的UI样式，因此这部分工作由炎龙来完成，因为他在Alpha阶段做出的UI最好看，同时有着较强的布局能力，从最终的用户反馈结果来看，UI的修改很成功，因此我们认为炎龙是最合适的人选。至于设计时间，是在第三周前也就是5月23日左右，挑这个时间的原因是在这个时间段，我们基本完成了对APP功能的添加和bug修复，因此所有的布局文件已经建立好，不会再有大的改动，可以开始UI工作了，从事后的角度来看，这个时间还算不错，在结束前有充足的时间完成。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
UI的设计其实是一个不断调试的过程，谁也无法说怎么样的UI是最好的，必须得实际做出来并在手机上查看才能确定是否美观。因此我们一开始没有统一的标准，是在炎龙完成大体设计后，大家开会讨论一点一点调整修复的，这个时间花费的很多，因为只有不断地调整才能做出好的效果。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
UML我们使用了，用来生成了一份功能架构图，每一部分要完成什么工作。用处是有的，因为在实际开发中，工作量很大，有时会记不住自己还有多少功能要完成，必须查阅文档确定一下。项目开始和结束时UML基本没有区别，因为经过了Alpha阶段后我们已经知道了哪些功能能做并且要加，哪些功能没多大用处，所以到结束也没做改动。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
其实产生bug最多的是UI界面，在自己的手机上看着好好的到了组员那里显示的乱七八糟，这是因为我们对UI的设计有些不熟悉，不太明白什么样的约束才能保证这一控件在任何机型上的相对位置不变，因为手机的分辨率是不一样的。这就导致我们发现了大量的UI加载问题。在发布之后，有助教和用户反馈了很多问题，只有一个是bug的就是记忆状态无法传递到webview中，这是因为cookie没有插入到webview中。我们在开发时其实想到了网页不同步这一点，也进行了设置，但是没有考虑到在webview中再次跳转时cookie还是消失的问题，主要原因是有点想当然了，觉得插入了cookie应该能一直用，但事实是跳转到不同的网页cookie是不同的。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们修改了各个xml和java文件的命名方式，并对相关功能打了包，提高了可读性；另外检查了每个人使用的官方函数，是否有不符合版本要求的，对这些已经被安卓7.0以上版本舍弃的函数进行了修改。而代码规范我们是按照Android studio自带的格式检查设计的，没有太明确的规定。
我们学到了什么?如果历史重来一遍我们会做什么改进?
UI的设计是一个艰巨的任务，必须经过不断地调试适配才能完成，同时在使用布局时，尽量少使用dp定位，更多的使用自带的center等方法，避免在不同手机上出现问题。如果历史重来一遍，我们会在做UI时就考虑到这些适配问题，尽量减少后期返工。
六、测试/发布
1.团队是否有一个测试计划？为什么没有？
吸取了Alpha阶段的教训，我们这次有了一个完整的测试计划。首先我们找到了很多型号的手机，进行了功能测试，对我们的每一个功能都进行了测试(包括Alpha阶段的功能)，确保UI和功能没问题后，我们使用wetest进行了兼容性测试，对安卓7.0版本以上的20多种型号的手机进行了适配，通过率达到94.6%。
2.是否进行了正式的验收测试？
我们按照上述方式进行了验收测试，测试的详情在测试报告中。
3.团队是否有测试工具来帮助测试？
测试工具就是wetest网站，可以进行兼容性测试和性能测试。
4.团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们没对软件进行压力测试，因为我们没有后端，所有数据来自于API调用博客园的官方数据库，因此我们认为压力测试意义不大。测试工作用处巨大，我们发现了很多UI的适配问题，还有一个博客园官方的问题导致闪退，对于这些问题我们进行了修复工作，现在的发布版解决了这些问题，给客户更好的体验。
5.在发布的过程中发现了哪些意外问题？
发布过程没有任何意外，因为和Alpha阶段的发布过程是一样的。
我们学到了什么?如果历史重来一遍我们会做什么改进?
测试是非常重要的，一个好的测试计划往往能起到事半功倍的效果。因此在测试前一定要做充足的计划，所谓磨刀不误砍柴工，如果历史重来一遍，我们会把网页跳转这里也测试到，避免发布后被用户发现问题。
七、团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
由于我们的软工项目获取的数据都来自于博客园官方提供的接口，所以我们并不需要自己完成后端服务器的架构和维护，只需要按照博客园官方文档给的方法进行数据获取，因此我们的角色分配并没有前后端的分别，而是由每个同学平行的负责一个模块再进行整合。模块的选择是由个人进行选择，未出现异议情况。
对于新成员的加入，刚刚好填补转出成员的空缺，他直接接受转出成员的模块工作。又由于我们每人平行的负责一个模块，模块之间耦合度低但是技术上相似度高，因此新成员能很好的融入团队并进行开发。
2、团队成员之间有互相帮助么？
有。我们随时会在群内交流遇到的困难和疑惑，并一起讨论并相互指导。同时，在每次组会上，大家都会汇报自己的进度以及遇到的障碍，团队成员解决了一个问题有新的进展后，会及时在组会上分享，帮助遇到了同样问题的队员；同时当有的团队成员有障碍时，组会上大家会集中讨论研究该问题，一起找到好的解决方法。并且，在beta阶段，由于部分组员完成其模块功能较快，会去帮助负责其它模块的组员，例如负责首页模块的组员在开发后期会帮助负责班级模块的组员一并开发班级功能，而负责我的模块的组员在后期帮助团队统一UI。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们队员之间相处融洽，在遇到项目管理和合作方面的分歧时，每个人可以提出自己的意见进行理性的交流，最后在经过投票，由PM给出最终的方案。
八、总结
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
处于初始级和可重复级之间（不太规范的可重复级）。我们根据需求整理出了需要实现的功能，再把功能拆分，分配给开发人员，一旦有需求变更我们会进行统一讨论和分配。我们制定有一定的命名规范和开发计划，整体的进度基本可控。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
处于规范与创造阶段之间。团队的流程与工作方式已经比较清晰明了，每位成员都分担了一定的领导责任，并且我们团队也有着一致的目标，成员们相互鼓励，积极提出自己的意见和建议，也对别人提出的意见和建议给出积极评价和迅速反馈。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
首先从项目来讲，我们的博客园APP在beta阶段功能更加齐全，UI制作更加美观，用户体验性有了极大提升。此外对于我们团队，我们相比alpha阶段更加团结，团队协作更好，共同解决了许多的难题。
4、你觉得目前最需要改进的一个方面是什么?
还是UI方面的问题，虽然UI整体相比alpha已有较大改进，但博客下面的评论中扔提到了许多我们没有注意到的细节的UI问题，我们也会听取意见进行修改，使得我们的项目更加完善。
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
团队协作。我们基本每天都会开组会，来交流一下今天干了什么，遇到了哪些问题。同时会共享屏幕，帮助修改一些bug，讲解一些代码逻辑，感觉比个人开发效率高很多。
版本管理。每实现一个功能，我们都会及时生成一个版本进行测试，避免最后太多问题形成冗杂。此外，不同模块的相似功能我们会使用相同的模板进行复用，提高了效率，也避免了一些bug、UI不统一的问题。
6、成员之间的感谢
- 炎龙铠甲：我感谢黑犀铠甲对我的帮助，因为：他帮我修复了一些bug
- 风鹰铠甲：我感谢黑犀铠甲对我的帮助，因为：他帮我统一了班级界面的UI
- 黑犀铠甲：我感谢炎龙铠甲对我的帮助吗，因为他设计了UI格式，方便我们修改UI
- 雪獒铠甲：我感谢炎龙铠甲对博问模块的改善，因为他对博问模块进行UI优化，并且增添了搜索功能。
- 地虎铠甲：我感谢炎龙铠甲对我的帮助,因为他帮我修复UI