团队作业7-Alpha冲刺之事后诸葛亮

 

设想和目标

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

  (1)我们软件要解决学习提醒的功能,能让用户自主设置提醒功能

  (2)对于功能定义的比较明确

  (3)我们小组成员都有过此经历,对同学们的需求也做了处理,所以对于典型用户和典型场景有比较清晰的描述

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

  可以说达到了预期的目标,原计划的功能完成了大部分,也按照原计划交付的时间交付了,用户数量也达到了。

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

  跟预想的差不多一致,离目标越来越近了。

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

   开发的过程还是很痛苦的,中间因为知识储备和粗心大意耽误了不少时间。如果再重来一次,我们的进度就能更快完成,就能开发出更多的功能。

 

计划

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

  有的,在开始开发之前就做好了计划。

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

  遇到不同意见的话,先听取他的意见,再一起讨论是否接受意见并修改。

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

  没有全部做完,在开发过程中,会感觉到开始的许多需求其实没有太大的作用,就删减或者修改了一些工作,再有就是时间不够了。

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

  有,所以我们每天做完都会有一段时间的讨论,然后删除一些没必要的功能或者需求。

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

  定义的没有那么清楚,不过大部分功能都实现了。

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

  出了许多意外,主要还是大家的编程经验不充足,也没投入很多的精力在编写代码上,导致原计划推进的很缓慢,许多功能都是后面加班加点完成的。

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

  有留一部分的缓冲区,但是感觉缓冲区倒是给了自己一个不想努力编程的理由。。

8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)

   把比较基础的问题时间安排的紧密一点,把核心的问题多留出一点缓冲区时间解决,这样能适当加快项目进度。

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

   制定计划没有想象的那么轻松和随意,需要对于项目成员的性格和软件需求有一定的了解。如果重来一遍的话,我们一定要做出更好的计划,更好的更合适的安排项目的进度。

 

资源

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

  a.技术资源:我们组的技术资源部分相较其他组而言,并没有太大优势,我们组的组员,大部分都没有太多的独立编程的经验,大家都比较局限于理论知识,实操较少。但好在我们选择了采用大家都系统学习过的JAVA语言,完成这次作业。且有两位在这方面比较优秀的组员引导大家,我相信我们能完成这次任务,并且每个人都能在任务中有所提升有所收获。

  b.时间资源:到达大三下学期,有几个同学报名参加校外的培训,有的同学还要考会计,可以说大家的时间都不充裕,但大家都表示一定会挤出时间,完成本次任务。

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

  时间资源是按照每天推进项目的进度,但是总会出现许多的意外,所以也会留出一部分缓冲时间。

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

  a.测试时间:由于各个方面的原因,项目的进度还是很缓慢的,也导致测试时间不太充裕。
  b.人力资源:人力资源方面还是够的,虽说开始大家磨合出现问题,但后来还是都能做到齐心协力。
  c.软件/硬件资源:资源上倒是没啥问题。在手机或者模拟器上就可以测试了。
  d.不需要编辑的资源:确实最开始低估了它们的难度,因为当整个APP页面出来,才能感觉到,美观并不容易做好,而且美观性往往也是用户非常在意的一部分。

4. 你有没有感到你做的事情可以让别人来做(更有效率)?

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

  一个项目开始之前,PM最好能全面了解各个成员的长处和缺点,这样才能更好的分配任务,也能让项目开发更加有效率。重来一遍的话,我们会先做一个成员长处的小调查,用于后面的任务分配,让大家在开发过程中发挥自己的优点。

 

变更管理

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

  敏捷冲刺的时候,每天的站立式会议都会交流进度和修改的内容。后面每天也会在群里讨论修改的需求信息。

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

  根据开始设计时和后面开发过程中对功能优先级的区分。

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

  预定的功能测试完成,软件也能正常运行,就“做好了”。

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

  没有制定应急计划

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

   可以,因为就算出了意外,也离不开大家的工作范围,大家一起讨论,基本都能解决。

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

   消息变更的信息一定要及时通知,功能的需求变化也要及时告知大家。重来一次的话,可能会更加频繁的在群里交流开发的信息。

 

设计/实现

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

  设计工作是后台程序完成之后大家一起讨论完成的,由于集合大家的意见,肯定很合适。

2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?

  有碰到,基本都是能顾全两边就顾全两边。

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

  有运用单元测试,基本都是每个人测试自己的模块,在遇到实在不懂得问题,大家一起讨论,在测试结果符合后再合并到一起。测试过程没有采用工具,基本是手工测试,遇到问题就修改。

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

  APP后台运行的功能产生的BUG比较多,因为大家经验都不充足,编写时总出现各种各样的问题。发布之后没有出现太大的问题。设计和开发的时候比较乐观,没有想到这么多

5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

   为了便于识别和修改,我们严格执行了代码规范

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

   代码一定要规范,合理规划时间和安排分工,项目经理及时督促,团队之间多沟通,共同解决成员遇到的问题。

 

测试/发布

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

  有,但是没有依照计划进行 原因:alpha版本的时候团队进度比较小,以至于deathline还有在修改代码,完善功能,留给我们的测试时间就大大减少了,导致测试计划没有如期进行。

2. 是否进行了正式的验收测试?

  没有进行正式的验收测试,只是每个人对于自己的部分做了测试,还有就是对源代码打成的APP包安装之后的测试。

3. 团队是否有测试工具来帮助测试?

  Eclipse里面有一个安卓虚拟机,可以用于测试。

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

  对于软件进行了预定功能的测试,从结果来看,测试工作还是有用的。不过还是有一些问题手动测试不出来。

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

   没有出现太大的意外吧。

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

   对于软件的测试要重视,要善于发现问题并且解决问题。再来一遍的话。我们可能会组织一个更加全面的软件测试,能把软件编写的尽善尽美。

 

团队的角色,管理,合作

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

    每个角色基本属于毛遂自荐。一部分人自告奋勇选择分工,剩下的大家再分配,基本是做到了人尽其才。

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

    各个分工也都有很多交叉的部分,大家在交流的工程中基本做到了互帮互助,氛围还是很好的。

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

     都是大家在一起讨论解决方案,谁能说服大家,我们就听取他的意见。

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

   在一个团队里面,角色很重要,交流和互帮互助也很重要。如果再来一遍的话,我们应该会更加注重团队沟通,互帮互助,提高编程的效率。

 

附件:

CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征:
1. 初始级
软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。

2. 已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。

3. 已定义级
已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。 目前,公司需要申请的就是已定义级别,通常称为CMMI3。由此,我们可知CMMI3是CMMI其中的一个等级。

4. 量化管理级
分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。

5. 优化管理级
可集中精力改进过程,采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据,并可据进行分析,从而得出最佳方法。 每个等级都被分解为过程域,特殊目标和特殊实践,通用目标、通用实践和共同特性。

总结:

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

  我觉得我们目前的状态属于第二个档次

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

  我们暂时属于磨合期,相信后面能很快达到规范期 

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

  大家编程经验更加丰富了,而且彼此之间的交流也更加频繁,契合度也更高了。

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

  大家对于新功能的开发和美工的完善不是太积极,可能需要在这个方面改进。

 


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

小组成员角色团队贡献分可验证的贡献
林清清PM20代码撰写,分配任务
郑莹Dev19部分代码、博客
陈惠Dev21部分代码、博客
林晓芳Test19测试、博客
栗海辉Test18    新成员
张中结Dev21代码、博客

转载于:https://www.cnblogs.com/1414group-03/p/6854300.html

1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看REAdMe.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看REAdMe.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看READme.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。
1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 、 1资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看READmE.文件(md如有),本项目仅用作交流学习参考,请切勿用于商业用途。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值