目录  

一、设想与目标

二、计划

三、资源

四、变更管理

五、设计与实现

六、测试与发布

七、总结

一、设想和目标

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

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

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

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

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

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

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

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

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

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

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

二、计划

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、资源

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

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

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

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

李志强（PM）：

申悦（开发）： 

魏辉（开发）： 

林方言（测试）：

连永刚（开发）：

徐璨（测试）：

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

四、变更管理

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

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

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

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

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

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

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

  没有

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

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

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

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

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

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

五、设计/实现

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

界面原型设计在早期就已经由橙汁完成了，真实际界面的设计与原型还是有一定的差别比如按钮大小，字体大小，背景等等！因为找不到原来的背景图了。后期也考虑是否修改原型，因为设计出的界面无法适应所有分辨率的手机，控件都会有所偏差！

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

有的。就比如之前有过关于发布者身份是否与参与者的身份合并，是放在同一界面，还是分开作为不同身份，分开登陆。最终少数服从多数采用分开登陆的方式。

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

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

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

因为每个人测试自己的模块，所以有些人的不是很了解。就登陆界面来说，在登陆的时候会出现第一次正确密码可以登录，以后再次登陆就会失败。后来修复了。其他的还有就是侧滑框的实现不是很理想

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

一开始，制定了代码规范。然后就没有然后了，各自采用各自的命名??呜呜！等合并的所有的界面的时候就遭报应了

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

贯彻落实代码规范

六、测试/发布

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

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

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

说起正式验收测试，并没有。但是说起非正式验收测试，一大堆。

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

有，在网上有百度到J是一个很好的测评软件，但是后来由于功能的太多欠缺，以及不太懂测评

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

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

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

由于测试和完善做的不是很全面，导致我们组在7点钟还在活动室里调试，寻找bug，登录注册用户= =在此之前一直都没出过问题，谁知在汇报前期，竟然?? 这很尴尬啊，还好最后找到了原因，发布才能够顺利进行

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

用git及时整合，及时测试。

七、总结

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

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

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

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

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

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

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

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

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

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

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

八、图片和贡献分分配

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

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

1. 图表

   2.说明：我们团队这次在项目的具体开发上出现了问题，导致冲刺的前几天进展很缓慢，最后的过程中申悦担起团队的重担，在她的辛勤付出以及其他组员的配合下我们最终将任务完成。所以我们组一致决定给她最高的贡献分:25分。其他成员虽然在过程中分工不同，具体完成的任务也有所不同，但是大家都很认真的完成了组长分配的工作，所以其他组员每人19分。

附件：

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

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

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

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

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

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