alpha事后分析

【软工小白菜】alpha事后分析

例会照片：

一、设想和计划

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

我们的目标是开发一款支持网页端大部分功能的安卓手机app，我们要解决的问题主要是为广大博客园用户在移动端也能方便浏览博客园并使用其功能。考虑到移动端使用博客园的某些局限性，我们适当删减了部分功能以精简我们的app。

我们对软件要解决的问题有着比较清楚的定义。

在典型用户和典型场景上我们有比较清晰的描述，具体描述在功能规格描述。

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

我们达到了预期目标。原计划的首页、动态、博文、班级、我的功能我们都已经实现，其中首页功能也实现了浏览和搜索，动态功能实现了浏览和发布，博文功能实现了浏览和发布，班级功能实现了所有班级内信息的查看，我的功能实现了收藏以及各种个人信息的查看。并且在原计划功能的基础上，我们对UI也做了相应的完善和拓展，增加了下拉刷新等UI功能，美化了界面。

我们按照原计划交付时间如期交付，这得益于我们PM良好的协调调度能力和我们各个组员的不懈努力。

我们达到了原计划的用户数量。原计划用户数量为100，我们实际的用户数量为102。

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

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

一致。更近了。

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

我们一开始定下的软件要解决的问题是解决IOS用户的困难，这实际上是不可行的，对于五个没人任何开发经验的人，两周内都不一定能配好环境，另外IOS发布我们之前也没考虑过，这都是考虑不周。如果历史重来，我们一定会仔细考虑，研究软件到底目标是什么，早做准备，而不是中途修改目标

二、计划

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

我们有比较充足的时间来做计划。我们大约花费两周时间来做完整的计划，因为我们的博客园开发使用的是Android原生开发方法，因此其技术难度并不算很高，各个成员有相对充足的时间学习其技术并充分估算任务难度和任务时间，并做出完整的计划方案。

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

当组员间有不同意见时，我们通常会让PM先协调沟通，并且由于我们每位组员之间工作的关联性较高，因此每一位成员可以参与不同意见的分析和讨论，大家一起来权衡不同计划的利弊，并提出自己的意见，最终经过协商统一计划。

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

我们基本完成了原计划的工作，虽然在某些细节上并没有达到预期。由于时间问题，在UI的完善上和部分细节功能的实现上我们并没有完全完成，但是我们有信心在下一个阶段补全它们，因为这些未完成任务难度并不算很高，只需要一定的时间投入即可。

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

关于部分界面的无用设计，例如登陆界面，因为登陆是博客园官网实现的，由于当时我们对博客园登陆的不了解自行设计了一个登陆界面，事后发现并没有用到它。

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

是。详细交付件请查看团队任务拆解。

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

项目在开发中期我们遇到了无法获取授权码的问题，并造成项目在两天内无法顺利进行，最后我们发现是博客园官方文档出现错误。我们没有估计到博客园官方文档的错误情况发生，这么多开发者使用过其文档并成功完成开发后其官方文档仍然存在错误，这种情况是我们没有估计到的。我想这种不可抗力因素也是非常难估计到的。

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

无。

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

增加缓冲区，预留一些加班时间。并且在测试上进行更加详细的计划.

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

我们学到了如何在规定时间内对我们的软件项目进行系统的计划，并且在软件估计时要结合团队自身的能力，并且要参考前人的经验才可以做出有效的估计。如果历史重来一遍，我们会先对相关技术做更深入的学习，避免在开发过程中出现的某些无用功。

三、资源

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

有足够的资源。Android studio有许多教程可以参考，接口方面也有博客园官方提供的文档可以参考，同时也有上届学长可以问一些技术问题。

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

各项任务所需时间是按照以往学习经验估计的，其他资源基本是Oauth2.0下post，get请求的学习。除了因官方文档描述错误而耽误的时间外，预估的基本准确。另外有些任务通过团队之间相互交流，完成的甚至比预估要短一些。

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

测试时间有一些不够，人力和软硬件资源是足够的。不需要编程的资源没有低估难度，在最初预估时已经考虑到这些问题。

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

没有。因为团队的任务是按各个功能模块划分的，各个模块之间的难度差异不大，所以大家的完成效率也都基本一致。

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

经验教训：官方提供的文档可能会出错，一定要早点和官方核实。

改进：早一点和官方沟通，可以尽快把接口问题解决，这样就可以花更多时间在UI设计，界面的层次划分上。

四、变更管理

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

都及时知道了变更消息，团队成员在微信群中都比较活跃。

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

根据技术难度和时间决定。最基础的浏览功能必须实现，某些最初设想的功能可能因博客园没有提供接口、实现比较麻烦、时间来不及而放弃或推迟。

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

没有十分清晰的定义，团队成员各自测试自己的模块，自己测试没有问题并且能够成功将所有模块整合在一起，即认为达到出口条件。

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

因为我们基本没有很大的变更，所以基本都在计划范围内。

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

可以。每个成员遇到的问题都会及时在微信群中与PM沟通，团队会一起想办法解决。

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

学到了遇到问题要积极与团队交流，众人拾柴火焰高，团队的效率会比一个人高许多。

改进方面就是在最初把问题考虑周全，尽量少做一些变更，这样团队成员能够有更多的精力和时间投入到自己的任务中。

五、设计/实现

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

我们的整体框架设计是由我们组的技术大佬炎龙铠甲设计的，时间大概是4月12日；各个部分的UI设计是个人完成的。事后来看总框架的设计炎龙是最好的人选，他之前用过一些安卓的开发经验，同时编程能力较强，然而UI由每个人自己设计目前来看虽然会导致风格差异很大，看起来不美观，但是这样效率比较高，只能说有利有弊。时间方面我们认为稍微晚了一两天，这也导致alpha阶段起步有些慢了。

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

没有遇到什么模棱两可的问题，如何封装，公共数据存储位置，每个是用fragment还是activity都讨论过并确定下来了，没有遇到模糊的概念。

3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

UML我们使用了，用来生成了一份功能架构图，每一部分要完成什么工作。用处是有的，因为在实际开发中，工作量很大，有时会记不住自己还有多少功能要完成，必须查阅文档确定一下。却别基本没有，alpha阶段确实有一些我们之前在设计了但是实际没有完成的功能，我们目前希望能在beta阶段完成这部分功能，所以没有修改UML。

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

最多的bug产生在调用有限个列表对象的时候(比如用户的作业，收藏等)会出现闪退等问题，这是因为调用这些列表比较复杂，需要先调用一个API获得一个总体信息，然后根据这个信息再调用API，由于在java中调用API需要开一个新的线程，而线程间的信息传递需要用到handler，这就出现了在一个activity中调用两个API还有先后顺序要求时，就必须使用handler嵌套handler，导致了一些莫名的错误；另一方面，调用API返回的数据有时为空，但是不同列表为空时返回的json是不同的，有的是null，有的是[]，我们一开始以为都是[]，所以按照这个标准来判断是否为空忽律了null，导致没有数据但是强行调用数据，程序闪退。在发布后我们发现了一个重要bug就是在闪存中多次切换桌面会导致闪存中内容消失，这个bug我们到现在都没有搞清为什么，所以在设计时也没有办法避免了。

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

我们修改了各个xml和java文件的命名方式，并对相关功能打了包，提高了可读性；另外检查了每个人使用的官方函数，是否有不符合版本要求的，对这些已经被安卓9.0以上版本舍弃的函数进行了修改。而代码规范我们是按照Android studio自带的格式检查设计的，没有太明确的规定。

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

学到了一个大型项目前期的设计必须要尽可能的完善，同时制定好各种规范，这样在后期敏捷开发时才能得心应手。改进的话还要把设计进一步提前，框架应该更早的设计出来，后面进度会快一些。

六、测试/发布

1、团队是否有一个测试计划？为什么没有？

测试计划是整合完毕和下载apk文件到各种手机上，运行每一个功能，并且在多个应用进程间切换，测试其线程安全性以及挂起后再进入时UI加载是否有问题。

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

进行了验收测试，按照之前定义的验收标准，我们在多台手机以及虚拟机上测试了程序的各个功能，发现了不少bug并修复，还有一些是目前无法解决的但是不影响用户使用。

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

没有找到合适的测试工具

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

软件测试工作用处很大，在之前的版本中会出现闪退等现象，而现在则不会出现了。改进的话，我们也希望有一些专业的测试工具进行系统化的测试，而不是手动在这里找，但是对于java前端的测试确实没找到什么专用的软件，在后续过程中会再着重找一下。

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

意外问题就是各个发布平台现在都需要一个国家软件专利证书，而这个证书又很难申请，这就导致我们原本打算发布在各个安卓应用平台上的计划泡汤了，只能采用百度网盘这一发布渠道。这也导致我们无法向社会人士推广，只好在一个专门的开发者交流群中进行了推广，来弥补社会用户的不足。

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

学到了写完代码后的测试是必须的，尽管每个人在写的时候都进行了不少测试，但是还是有很多bug被发现。如果历史重来，我们会先一步思考如何搞到国家软件专利证书，再找到一个合适的测试软件进行单元测试(如果有的话)。

七、团队的角色，管理，合作

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

由于我们的软工项目获取的数据都来自于博客园官方提供的接口，所以我们并不需要自己完成后端服务器的架构和维护，只需要按照博客园官方文档给的方法进行数据获取，所以我们的角色分配并没有前后端的分别，而是由每个同学平行的负责一个模块再进行整合。模块的选择是由个人进行选择，未出现异议情况。

整体的任务按功能进行了拆解，例如关于获得token和关于列表滑动刷新都有专门一人去研究实现，算是人尽其才。

2、团队成员之间有互相帮助么？

有。我们随时会在群内交流遇到的困难和疑惑，如果不予交流帮助各做各的可能会出现重复工作、思虑不全等极度影响开发进度和效率的事件，所以在有的团队成员解决了一个问题后，会及时在团队内分享，帮助遇到了同样问题的队员。或者是有队员提前完成任务后，会适当帮助未完成的同学一起跟上进度。

3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？

我们队员之间相处融洽，在遇到项目管理和合作方面的分歧时，每个人可以提出自己的意见进行理性的交流，最后在经过投票，由PM给出最终的方案。

八、总结

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

处于初始级和可重复级之间（不太规范的可重复级）。我们根据需求整理出了需要实现的功能，再把功能拆分，分配给开发人员，一旦有需求变更我们会进行统一讨论和分配。我们制定有一定的命名规范和开发计划，整体的进度基本可控。

2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

处于磨合和规范之间。希望在β阶段更进一步。

3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?

在分工和代码管理上有所改进，对队员之间了解更深。

4、你觉得目前最需要改进的一个方面是什么?

• 各自完成功能后，代码签入和整合不能及时完成
• 测试方面有所欠缺
• 代码规范不足

5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 面对面交流。我们在遇到问题时，会及时地进行讨论和交流，提出各自的见解看法。
• 每实现一部分功能我们会给出一个当前版本进行尝试。
• 不同模块之间的相似功能我们使用同样的模板进行复用，提高效率。
• 多次召开组会总结现阶段工作，整理下阶段任务。

6、成员之间的感谢

• 雪獒铠甲：我感谢炎龙铠甲对我的帮助，因为：他封装了请求的接口，制定了统一的架构模板。
• 黑犀铠甲：我感谢雪獒铠甲和风鹰铠甲对我的帮助，因为：雪獒给我讲解了怎么生成list，风鹰铠甲告诉我如何有顺序的调用两个API。
• 风鹰铠甲：我感谢地虎铠甲对我的帮助，因为他帮助我解决了界面中使用Tablayout的层次问题。
• 炎龙铠甲：我感谢黑犀铠甲对我的帮助，因为：他帮我解决了一些布局的问题。
• 地虎铠甲：我感谢炎龙铠甲对我的帮助，因为：他帮我解决了一些网络请求问题。

九、下一阶段如何提高软件工程的质量

1、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

应该更熟练灵活地掌握Git和GitHub的使用。代码复审主要还是由组员之间互相审查，代码规范我们是按照Android studio自带的格式检查设计的，没有太明确的规定，后续可以指定更严谨详尽的规范。

2、整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

我们已经将各个模块架构整理的较为明确，各个队员对代码的修改基本只需要在自己的部分进行，模块之间耦合程度低，完全的重构耗时耗力，不可取。后续可以整理一下xml文件的代码。

3、其它软件工具的应用，应该如何提高？

目前使用Android Studio/Postman足够满足我们的开发需求。

4、 项目管理有哪些具体的提高？

下一阶段应该严格按照时间表和issue来完成任务并签入代码。

5、项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

由于我们并未进行后端的开发，关于用户的数据存储在博客园官方的服务器中我们无法获得，因此我们无法知道活跃用户等数据。暂时只能知道百度云链接上的下载和浏览数量。

6、项目文档的质量如何提高？

将各模块功能划分的更详细一些，制定一些代码规范与命名规范，避免整合时做一些不必要的修改。

7、对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

在小团队中其实PM和其他开发人员差异并不是很大，大部分的问题都是由大家一起讨论决定，解决。我们团队只有五个人，所以PM也参与到了开发，文档和博客也是由大家一起讨论完成。但是PM确实有增量的工作，例如每日例会报告等，在衡量PM的贡献时会将这些增量工作也考虑在内。因为我们团队规模较小，完全分化一个PM角色代价较高，所以暂时保持现状即可。

8、对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

• 软件工程的开发是一个长期的迭代过程，不是简单地写几个程序，还有程序的测试、维护，团队之间的交流协作。总之它模拟了一个软件的开发流程，在日后工作中真正开发一个软件时，可能会对我们有很大帮助

• 对于敏捷开发的原则，我们认为是高效有利的，但是对于较小的团队和小规模的项目来说，我们觉得一些标准和要求有些难以实现。

十.对比敏捷的原则，你觉得你们小组做得最好的是什么？

• 可用的软件是衡量项目进展的主要指标

  我们小组在最一开始确立的目标就是功能优先,ui其次,先完成功能以让软件整体可以运行,而暂时不考虑美观的问题,等到后续再将ui进行优化。同时,我们又强调了要有限完成主要功能的开发,将一些附加功能先放起来,先让整体可以差不多能跑起来,再去考虑一些细节上的一些功能。

• 无论团队内外，面对面的交流始终是最有效的沟通方式

  虽然无法做到真正意义上的面对面交流,但是在视频会议上交流也基本上和面对面没有太大的差别,而且我们几乎保持了每天都开一个简短的会议,同时每当遇到问题或者有重大决策都会开一个会议来讨论。

• 时时总结如何提高团队效率, 并付诸行动

  我们组几乎每天都会开会,在会中会提出如何对现有的情况进行改进以提高整个团队的效率。

• 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。

  我们组计划,每增加或者完善一些功能之后就对软件进行版本升级,并将升级后的版本进行发布。

• 敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。

  我们将根据用户对当前版本的使用反馈,来考虑下一个版本的迭代,增加用户普遍需求的功能,删去用户不太需要的功能,修复bug,根据用户的使用体验来完善整体的ui设计。

• 以有进取心的人为项目核心，充分支持信任他们

  我们将PM和开发人员作为整个项目的核心,根据他们来调整整个项目的工作计划,并且充分的相信和支持着这些团队中最有进取心的人。

• 只有不断关注技术和设计才能越来越敏捷

在项目开发的过程中,我们一直密切关注着技术和设计,思考着怎样的框架可以提高开发的速率,用怎样的技术可以更方便开发。

十一.什么是在下个阶段要改进的地方？越具体越好。

• ui方面太过简陋,不美观,并且存在ui风格的不统一问题,需要对ui进行整体的优化
• 部分功能没有实现,例如通知消息,对博文的收藏,评论和点赞等
• 整体的操作不是很流畅,用户体验不佳,需要对细节进行进一步的优化
• 修复alpha阶段再发布之后出现的bug