团队做业9——过后分析（Beta版本）

 

设想和目标

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