团队作业9——事后分析（Beta版本）

Posted 2020-10-18 Missy_by

 

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？

我们软件要解决的就是音乐播放器由于功能的繁琐，从而导致它不适用部分手机内存太小，老年人使用不方便等问题，我们的音乐播放器只通过获取到本地音乐的播放源，对应音乐的专辑背景，对其进行播放，以及音乐的歌词滚动，列表的循环方式从而减小了app的内存占用，以及简单明了的使用方法。

定位就是一款不占内存，功能简单的播放器。

 

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

   我们完成了大部分的目标，播放器在安装到本地后能获取到音乐，图片，同时也能对歌曲进行顺序播放，随机播放等功能，能监听手机的来电事件，同时对歌词文件的获取时常会不显示这个功能未能完善。只按照原计划交了一个比较完善的版本。因为这个项目对我们组来说是属于学习的阶段，所以还达不到上线的程度，自然，原计划的用户数量没有达到。    

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

跟上一个阶段相比，团队的开发效率明显提高了，分工也更明确了。在上一个阶段，播放器安装后还总会因为一些原因闪退，播放声音出错等，在这个阶段播放器改善后，整个播放器能完整使用，因为第二阶段时间相对富余，所以界面改善得更加人性化，也修复了alpha阶段的一些bug。

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

 对于现阶段而言，用这样的形式交付项目我们都是新手，但是部分还是一致的，老年人用起来还是比较顺手，不存在不知道该怎么使用这个播放器的地方，而针对年轻人的群体，虽然内存小，但是没办法实时的获取新歌，无法满足他们的需求，从而还是和我们事先预想的有偏差。离目标还是有一定的距离。

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

   如果历史重来一遍，在初期对需求的分析需要有更多的数据从而能更好的分析各个群体的需求，以及在计划定制，完成计划的过程需要更多的耐心和督促，在开发过程中，多花一些时间完善项目。

计划

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

时间不是特别多，计划做的比较草率，在需求分析阶段没有明确的框架和概念，对于项目计划比较粗略。

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

成员对于该项目的时间分配不可能做到一致，大部分以少数服从多数的原则，同时少数的理由如果足够充分说服其他人，如果避免不了一些客观情况，计划也是可以适当变动的，庆幸的是这次团队项目没有大的意见冲突。

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

原计划大部分是交付了，但是没有都做完，也有因为一些bug和经验不足陷入误区耽误开发的时间，也有花费的时间不够的原因。

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

有，有时候发现重点的位置都是在一直循环一个错误，应该早点与队友讨论，才不会让自己一直陷在错误里面。

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

大部分任务有，但是功能点的定义和衡量可能没有那么详细得说明。

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

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

 将来的计划可能会在分配任务上更加详细，让大家都知道自己负责的部分在哪里，才不会各种混乱

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

 我们学到了计划在项目开发的过程中是很重要的，计划决定了整个项目能否进行的很有条理，所以如果历史重来一遍，我们会详细的指定计划，并在一段时间开会对计划进行重新整改。

 

资源

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

    人力资源上：我们组的成员只有3个人，任务完成的时间其实是很紧迫的。

    开发资源上：android开发App已经是烂大街的技术了，网上也有很多资源可以学习，但是在相对紧凑的时间里要学会框架的部署，界面的设计，功能的实现，和sqlite的使用，从而 做出一个可以交付的小型的demo，其实任务是艰巨的，不过，因为成熟的技术，大量的学习资源，所以学习到的也很多。

    设备资源上：开发这样小型的App，设备资源是不足为虑的。

    时间资源上：在这次团队项目总，因为我们要同时学ios，Android两门语言，还有其他的课程安排，所以时间是比较不足的。

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

    各项任务所需的时间和其他资源是根据任务量估计的，精度方面，alpha阶段做的不大好，对于这样的开发模式比较生疏，，所以估计有些误差，但是在第二个beta阶段就做的相对好一些，精度也准确了。

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

除了软件/硬件资源是充足的，其他的资源都相对紧缺，其中最缺乏的还是时间资源。相对于功能的实现，美工和设计的难度对于我们来说不算难，更何况队里有两个女生，在美工设计方面不算有什么难度。

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

因为该项目的成员只有3个人，所以每个人都分配了挺多的任务，所以耦合性还是挺大的，很少存在某个任务需要别人来完成。

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

          需要改进的方面就是资源要是能多一些就好了，尤其是人力资源和时间资源上。

变更管理

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

是，每个相关的成员都能及时知道变更的消息，因为是一个宿舍的，成员又只有3个人，对于小型的变动直接发文件给对方。

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

从两个方面考虑，一个是实现难度，还有资源消耗。如果一个功能点实现难度是比较大的，代码量也比较多，就可以决定推迟，如果是已经花费了一定的时间和人力的资源，且已经明确分配的功能，就是必须实现的功能。

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

             APP无崩溃、闪退等现象。

            测试发现的Bug得到修复。

            典型用户场景得到测试并无bug。

            测试矩阵中的典型情况得到测试并无bug。

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

    能，在不影响整体工程完成的情况下，具体情况具体分析，解决。

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

           可以，对于该项目的完成难度，时间充裕的情况下我们是可以处理意料之外的请求的。

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

           变更是项目开发过程中常见的现象，但是一个有计划，有条例的计划是可以减少变更的出现的，也可以减少资源的消耗，所以，如果历史可以重来的是，我们会更加重视计划设计的合理设计的。

设计/实现

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

在alpha阶段，我们没有明确的设计计划，所以在beta阶段的时候，我们就设计了整体工作的框架，一起商议各种任务的实现计划，对于功能点的实现，是我们三个商议分配的，前端的设计主要是两个女生负责，后端的实现是三个人共同完成的，测试则有欧阳时康完成，项目的bug修复和文案记录主要是我和苏晓微完成的。

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

有遇到，一般如果是难度较大的设计工作，就放到后期若是时间允许的情况再商议，若是难度不大的情况，细化之后分配给各个成员完成。

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

没有用到单元测试，该项目是基于移动平台开发的一款小型App，暂时没有用到代码测试工具测试，我们在跟进项目的完成情况的时候一般是直接在模拟器或者真机上运行测试。

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

    实现sqlite接口的时候产生的bug最多，起初没有添加读取sd卡的权限，导致歌曲加载错误，以及涉及到数据的加载，和最近播放的音乐的数据的封装，这些都是需要实现的，所以要全面得考虑才可以。

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

         代码复审没有严格按照代码规范进行，只是针对自己实现的功能代码重新审读。

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

          开始的时候并没有对于项目的设计并没有成文的详细的计划，只觉得分配完任务后就可以，各自完成自己的工作，后来发现因为事先设计的计划不充分，出现了项目完成进度有所误差。所以一个明确的设计能起到事半功倍的效果。

测试/发布

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

我们团队是有一个测试计划的，在beta阶段因为在alpha阶段的时候就已经完成了一部分，所以只针对beta阶段的工作加以测试。

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

验收测试不算正规，只是大致完成。

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

  没有，采用的是人工测试。

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

  软件的效能主要是指并发性和压力测试，由于这款音乐播放器是基于本地资源的操作，所以不存在并发性的问题，我们是在不同型号的手机上进行测试，功能效果还行。

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

 在发布的过程中发现有些手机安装之后第一次启动的时候会出现闪退的情况，再次运行的时候又可以运行了，可能是App的稳定性存在问题导致手机安装App的时候会闪退。

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

       对于该阶段，我们学会了用正式的计划和框架开发项目，完成情况比较乐观，但是因为一套完整的管理措施和制度化的规划，所以实现过程中存在很多的误差，但是因为成员数量并不多，所以商议调整还算比较及时。

 

团队的角色，管理，合作

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

     团队的每个角色是按照每个人的擅长的领域确定的。

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

    有，成员是一起学习一起讨论的。

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

    因为我们这个项目只有3个人，所以没有出现项目合作方面的冲突。

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

           该项目的完成让我们学会了如何规范正式得按照开发模式开发项目，如果能重来一遍，我们会计划设计更加详尽，少走弯路，提高开发效率。

总结:

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

          目前团队属于CMMI一级，属于完成级。在完成级水平上，对项目的目标与要做的努力清晰，项目的目标得以实现，但是对计划与流程的规划不够清晰，无法保证任务的完成效率，所以还是属于完成级的状态。    

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

         磨合的阶段，团队成员还在相互的了解中，对于代码格式或者团队之间的规则还不够清晰，所以目前还是处于磨合阶段。   

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

         改进的方面还是团队的沟通，以及团队内职责的分化不够清晰。团队还是应该经常面对面沟通，多说出自己的意见，提高效率。

博客要附上全组讨论的照片

 

 团队成员在Beta阶段的角色和具体贡献：

姓名	角色	贡献值%
张慧敏	前端	40
苏晓微	后端	37
欧阳时康	PM	23