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

 目录  

一、设想与目标

二、计划

三、资源

四、变更管理

五、设计与实现

六、测试与发布

七、总结

 

 

一、设想和目标

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

我们的软件要解决的问题是用户能够正常使用四则运算app，app可以出题，判断对错，显示结果，录入错题库的问题。定义得也比较清楚，包括出题，判断对错，显示结果，录入错题库。

用户主要针对学生，老师，家长，场景主要是练习四则运算，做题。

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

没有充足的时间，时间利用得也并不充分。

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

小组经过qq聊天，视频会议等方法一起协商讨论来解决意见冲突。

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

Alpha版本的用户目前只有我们自己和宿舍同学，最基础功能还是如期实现了，但还有许多功能尚未实现。 目前离目标越来越接近了！

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

一开始，我们预想alpha版本的功能并不复杂，对事情有些怠慢，但渐渐随着项目开展，我们开始认真讨论，慢慢学习，写代码。
接下来，我们会加紧脚步，做好app。

二、计划

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

原计划的大部分工作基本在最后都完成了，主要的问题是app会闪退的问题，后期我们会优化代码，解决闪退问题。

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

李志强（PM）：基础功能尚未完成，过早地开始想界面设计。

申悦（开发）： 小组讨论时聊着聊着，话题就偏了，没有深入探讨。

魏辉（开发）： 比较基础功能还没有做完，就找同学试下好不好用。

林方言（测试）：没有做这方面app的经验，自己学的有的并没有用上，反而拖慢了自己做事情的时间。

连永刚（开发）：太执着于功能的多样，但发现自己想的一些功能很鸡肋，想判断题这样，没有多少实际意义。

徐璨（测试）：过多的讨论界面怎么才会好看。

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

就定义来说，我们还是比较模糊的，但就目前来说，主要的功能还是实现了。

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

整个项目坐下来并没有完全按计划稳步进行。最开始的大家毫无经验，学习起来，还是比较麻烦的，毕竟每天都有课，晚上还不一定有空，想做完自己的东西，还是比较难的，做到最后，app居然会 闪退，就气死掉了。

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

并没有留什么缓冲区，一周就做好，听起来好像不是很难，但就是这么难。

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

未来会适当的留出些时间来解决最后的一些没有解决问题。

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

如果历史重来一遍，一定会做好计划，按计划来做，尽量完成任务。



三、资源

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

a.技术资源：我们组的技术资源部分相较其他组而言，并没有太大优势，我们组的组员，大部分都没有太多的独立编程的经验，大家都比较局限于理论知识，实操较少。但好在我们选择了
采用大家都系统学习过的JAVA语言，完成这次作业。且有两位在这方面比较优秀的组员引导大家，我相信我们能完成这次任务，并且每个人都能在任务中有所提升有所收获。
b.时间资源：我们组有两位同学在准备考研，有一位同学正面临一场非常重要的专业比赛。且已经大三下学期，可以说大家的时间都不充裕，但大家都表示一定会挤出时间，完成本次任务。

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

时间资源方面我们最开始的计划是精确到每天，进度安排也是根据之前发布过的计划来的。
然而后来一周开始几天发生了很多事情，队员间磨合出现了问题，导致开始几天并没有跟上进度，虽说后来勉强赶上进度，效果却并不理想。


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

a.测试时间：因为进度落下较多，导致我们上一周的测试时间不够。负责不同模块的组员，并没有充足的时间做好每个模块间的沟通和交流，故而在项目总体测试上并不是很顺利。
b.人力资源：人力资源方面还是够的，虽说开始大家磨合出现问题，但后来还是都能做到齐心协力。
c.软件/硬件资源：资源上倒是没啥问题。就是最开始我们在搭建环境上出现了一点小小的问题，最开始有三名组员的电脑都没法成功搭建环境，后来在其他组员的帮忙下才完成。
d.不需要编辑的资源：确实最开始低估了它们的难度，因为当整个APP页面出来，才能感觉到，美观并不容易做好，而且我们不得不承认，美观性往往也是用户非常在意的一部分。

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

李志强（PM）：会啊！我感觉我们组有个别组员更适合我的工作，因为他看问题更全面，更能细化量化任务，明确分配到每个组员身上，并且比较了解大家优缺点，明白每个人更适合什么样的任务，更能调动大家积极性。这周他帮了我不少忙。

申悦（开发）： 因为自己对写代码挺感兴趣，并且相较我们其他组员来说，我有较多的编程经验，也有过项目经验。所以认为自己的任务并不需要分配给别人。

魏辉（开发）： 有！因为编程基础较弱，代码写起来还是比较费力，遇到问题要花挺多时间才能解决的，很担心拖慢大家进度。我认为比我有经验的人效率肯定比我高！

林方言（测试）：会！因为感觉自己不够细致，比我细致的人应该能完成得更好。

连永刚（开发）：感觉自己都按时完成了任务，如果交给更厉害的人肯定更有效率拉，如果水平差不多的话大家应该都没差吧。

徐璨（测试）：觉得自己还挺合适的，能比较高效的完成每次任务，且自己编程基础较差，并不适合开发任务。把最适合自己的部分踏实做好才最重要。

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

如果历史重来，我们会先了解每个组员擅长的部分，做好合理的任务分配，扬长避短，本周的经验教训就是把任务分配给了并不适合的人，导致效率低下，拖慢整个组的进度。

四、变更管理

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

我们每天会定时召开站立式会议，队员大部分时间基本都在一起，有什么变动相互之间都知道，还通过我们的QQ群公告来通知变更消息。


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

根据功能在整个项目中的重要程度，再结合用户的需求决定优先级。


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

所有页面整合在一起，通过了各项测试，就“做好了”

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

没有

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

基本都能，需要组员自身的调控，做事方面都是很积极的。

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

学会了使用git，之前没接触过git，但是经过本次课程，大家基本都熟悉掌握了git。

1.队员由于是进行在各自分支上,但有时候大家互相间不知道对方的进度。尽量每次操作之后，就提出一个pull request，这样让其他小组成员知道对方的项目进度，并且每次修改可以让大家共同审阅一下。

2.有时候会出现进度照着预计的时间退后些，应当将测试放在平时进行，随时完成一部分，就需要及时进行测试，进行修改。

五、设计/实现

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

界面原型设计在团队第二次作业需求分析和原型设计已经由申悦完成，实际上的界面的设计与原型还是有一定的差别比如按钮大小、颜色，字体大小，背景等等！因为找不到原来的背景图了。也因为时间和协调问题，只做了最基础的功能，注册登录也没有完成，设计是在一个合适的时间内完成的，人选也还OK！

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

有的。我们在是否要增加一类用户的时候产生了分歧，一部分认为要增加教师类用户，一部分人为不用增加，最后我们是为了尽力做到最全面的满足需求，在设计阶段增加了教师类用户，可是在alpha阶段未能完成。

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

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

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

因为是每个人测试自己的模块，所以到底是至于哪个功能产生的bug最多倒不是很了解。但是在个人的测试的时候，都出现了很多的bug，在发布之后我们产生最大的bug就是闪退！！导致我们在作品展示的时候都没有拿出一个完整的作品来。我们在设计阶段完全没想到，因为我们以为这种切换和页面的跳转一样，只要跳转正确就能切换到下一个，完全没想到会闪退。

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

一开始，制定了代码规范。然后就没有然后了，各自采用各自的命名⋯⋯呜呜！等合并的所有的界面的时候就遭报应了，导致我们一直出错，等把错误改完了之后就开始闪退，费了好大的功夫才弄好。

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

贯彻落实代码规范，合理规划时间和安排分工，项目经理及时督促，团队之间多沟通，共同解决团员遇到的问题。

六、测试/发布

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

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

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

说起正式验收测试，并没有。但是说起非正式验收测试，一大堆，尤其是到了后期，只修改了一点儿细微的地方就要再测试一遍，而且我们的模拟器当时还带不起来，我们是导出到手机上测试找问题的。

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

没有。因为我们的模拟器实在是太慢了，我们等的花都谢了，就直接导出到手机上了，所以也没有正式的测试，对我们找问题所在也造成了很多的麻烦。

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

手动调试来跟踪软件的效能；测试工作有用，能够测试出bug，但是很难找到bug存在的准确位置和真正原因，正就是所需要改进的地方。

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

在发布的过程中我们发现的最大的意外就是软件闪退，我们查了很多资料最后是修改了group解决的闪退的问题。

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

用git及时整合，及时测试。大家对于分配给自己的工作要认真对待，项目经理也要多催促，抑制大家的惰性和拖延，提前做准备，不然真的来不及。

七、总结

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

我觉得我们的团队目前的状态是已管理级。原因如下：

1. 在Alpha冲刺之前，我们团队有针对我们的项目（四则运算App）做过需求分析以及项目计划

2. 在Alpha冲刺阶段，我们小组每天会开站立会议和视频会议分析问题，并汇报自己的完成进度和完成情况。

3. 在Alpha冲刺后，团队就可以说是有了类似项目（安卓）的开发经验，一定程度上可重复类似项目（简单的）的软件开发工作。

4. 我们小组是有专门的测试人员的，通过测试可以保证app的质量和可用性。

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

我觉得我们团队还处于磨合阶段。理由如下：

1. 在Alpha冲刺之前，我们团队每个人都没有项目开发的经验，虽然每个人都有一定的JAVA语言基础，但是并不懂安卓

2. 在Alpha冲刺阶段，我们组采用根据每个人在Android学习的进展程度来分配任务，具体的分配上学的快的承担更多复杂的工作，学的慢的承担稍简单的工作，同时多负责一些文档的构建工作。

3. 在Alpha冲刺之后，团队并没有形成大家都有单独一块较好的能力，只能是说在任务具体分配的时候看谁这方面的能力会比较强就有谁来具体负责。

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

1. 这次真正的体会了一个完成的开发过程，学到了更多的东西。

2. 团队在这次开发中是让我印象最深刻的，团队如何合作、在团队中如何承担好自己的角色，这很重要。这一点也是以前所不能学到的。

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

组长对于工作的安排以及贡献分的分配问题。每个人的能力不一样，会的东西也不一样，所以工作应该是和贡献分同时处理的。做简单的工作对应的就应该拿少一些的贡献分，做的工作比较多就应该有更多的贡献分。同时应该在一开始冲刺前就将这个工作做好，分配好每个人的角色以及大致任务并公布对应的贡献分，最后再根据每个人的完成情况对应的打一个最终分。

八、图片和贡献分分配

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

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

1. 图表

名字	角色	团队贡献分	可验证的贡献
申悦	Dev	24	主要代码撰写
李志强	PM	19.4	分配工作，部分代码
魏辉	Dev	19.3	部分代码，博客
连永刚	Dev	19.2	部分代码，博客
徐璨	Test	19.1	测试，博客
林方言	Test	19	测试，博客

   2.说明：我们团队这次在项目的具体开发上出现了问题，导致冲刺的前几天进展很缓慢，最后的过程中申悦担起团队的重担，在她的辛勤付出以及其他组员的配合下我们最终将任务完成。所以我们组一致决定给她最高的贡献分:24分。其他成员虽然在过程中分工不同，具体完成的任务也有所不同，但是大家都很认真的完成了组长分配的工作，由于工作还是稍微有不同的，所以我们组根据各个组员的具体工作情况和完成情况进行排序，最后的结果如上图。希望可以通过这种方式让大家都能不断地为小组做奉献，尽力尽心工作。把团队作业做的更加优秀。

 

附件：

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

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

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

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

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