项目回顾
1、我们的软件要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清晰的描述？
在刚入学的大一新生中，存在许多刚开始接触计算机的学生， 由此他们对于计算机的二进制感到非常陌生，在学习二进制及其他进制时感到非常吃力， 尤其是多种进制之间的转换更加为难，所以这样的一款软件或者说是游戏时完全有必要存在的。 项目可以很好的实用到我们的学习中，有很大帮助；带给用户前所未有的用户体验
项目定义的很清楚
2、是否有充足的时间来做计划？
从项目开始工作前，一直都在为软件开发做准备，我们进行了个各类人群调研与需求分析
同时团队内对这项团结开发是否有实用价值进行了深入的讨论。
基于alpha和beta阶段的工作，可以说是有很充足的时间来做计划的！
3、团队在计划阶段是如何解决同事们对于计划的不同意见的 ？
由于人员个人能力有限，在计划阶段的时候，也产生了分歧，害怕自己不能胜任该项工作。
最后经过团队在一起开会讨论，解决方法如下：
1.团队计划阶段的负责人由团队成员进行投票取决。
意见遵循少数服从多数的原则，综合考虑各种因素。
2.除各个计划阶段主要负责人工作外，其余团队人员进行辅助工作。
每个人在各个阶段必须要起到辅助作用，并且相互汇报。
用户量、用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
接受程度基本与预想的一致，因为我们预想的很接近常理，离目标已经很接近了。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
接受程度基本与预想的一致，因为我们预想的很接近常理，离目标已经很接近了。
如果历史重来一遍，我们将：
在工作方面，团队积极讨论，以免产生不必要的分歧。
在代码方面，团队所有成员加强学习代码能力。
在能力方面，除之外我们还需利用其它时间来进行补充其它方面的能力。
以至于在团队整体提高了效率，对队员的工作方面也是一种很大的补充。
对计划的回顾
1.你原计划的工作是否最后都做完了？如果有没做完的为什么？
原计划工作基本全都已经做完，唯有一项代码功能没有做完。
因为我们团队成员代码能力有限，所以导致软件的一项排行同步功能没有做完。
2.有没有发现你做了一些事后看来没必要或没多大价值的事？
有发现，在软件功能方面由于看到网络上的大型游戏，因此自己也想在团队开发的软件，多做一些游戏功能来吸引用户。
结果团队队员能力有限无法实现众多功能，没有实现预想的价值。
3.是否每一项任务都有清楚定义和衡量的交付件？
是，我们团队的每一项任务都是在经过讨论并且已经协商确定，每个任务该完成什么功能都已经清楚，并清楚定义了任务内容。
并且在码云仓库分支下有相应的源代码、测试报告、bug提交、代码规范文档以及冲刺和整体项目的进度。
4.是否项目的整个过程都按照计划进行？
项目整个过程大部分按照计划进行的，有一小部分计划出现一些变动。
因为当时还没有开始项目之前，我们只觉得代码上可能会出现一些问题，
就没有提前进行软件的安装和软件的学习、准备，但是最后在发布软件时出现的差错。
5.在计划中有没有留下缓冲区，缓冲区有作用吗？
在计划中有留下缓冲区。
缓冲区非常有作用，我们团队主要是利用缓冲区的时间里进行我们项目代码的测试、查找项目的Bug和修复项目的已知Bug。
也利用了缓冲区这段时间进行团员之间的相互讨论交流，并根据讨论的结果对项目进行了整体的完善。
6.将来的计划会做什么修改？
将来的计划会做出的修改有：
团队成员方面：我想扩充一些人员到我们团队，这样使团队整体效率更快更高一些。
工作方面：将会预留更多一些的缓冲区，毕竟预留出缓冲区可以应付一些紧急，也可以帮助我们将我们的项目进行完善。
然后的话，我们会将任务工作安排得更加合理吧，避免着急赶进度状态。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
通过团队对项目计划的整体安排，我们学到了在进行工作时应该按部就班 井然有序。
如果历史重来一遍，我们团队队员不能完全按照完自己的意愿和思路乱工作。
必须团队内沟通得体，任务计划合理分配。
对资源的回顾
1.我们有足够的资源来完成各项任务么？
与其他团相比队，我们团队个人的能力资源不是很足够。
我们团队中有所有成员在编程代码方面的能力不是很强，
导致开发大部分项目的任务需要团队集体合作。
2.各项任务所需的时间和其他资源是如何估计的，精度如何？
各项任务所需的时间一般是按照任务的难度进行估计安排的
代码能力差所欲相对的时间就会长一点，设计图片较简单时间充裕。
测试的时间根据代码提交完成然后进行测试，并找出BUG。
3.测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源是否低估难度?
测试的时间紧凑，毕竟我们代码开发的人力资源不够。
有时不能按预期完成，没有完成的话测试就没办法进行。
否，代码能力虽然不强，但其他工作必须要认真对待，来补充我们的能力资源的不足。
4.你有没有感受你做的事情让别人来做（更有效率）？
有，有时候自己工作多了遇到问题的时候就会堵在一个地方觉得很烦倦，
有时候别人的思路会很清晰，旁观者清，当局者迷。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
代码编程能力是开发项目的一大硬伤。
如果历史重来我们会努力学习代码的知识，给其他项目工作留有足够的时间，
不把时间都浪费在代码身上，让我们得项目做的更加完美。
对变更管理的回顾
1.每个相关的员工都及时知道变更的消息吗？
每次变更管理的时候，我们都会在群里发布通知开会，并且全员到齐。
每位成员都会及时收到通知及时了解。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能？
我们采用的方法是从用户的角度出发，来决定哪些功能是软件内必备的，哪些是附加功能，哪些是可有可无的，
因此排出软件开发功能的优先级，来决定哪些是必须在第一次冲刺Alpha阶段完成的功能，哪些又是可以推迟到第二次冲刺beta阶段完成。
3.项目的出口条件 (什么叫做好了）有清晰的定义吗？
有，我们的开发的软件项目基本能满足用户体验的需求，包含游戏的移动、攻击、操作等基本功能都能使用。
4.对于可能的变更是否能制定应急计划？
可以的，我们团队已经准备并制定了应急计划。
在第二次冲刺过程中，我们团队代码环境运行出现问题，以至于我们团队耽误了几天。
最后通过队员以及外界的帮助，我们在期限内完成了我们的项目。
5.员工是否能够有效地处理意料之外的工作请求？
大部分员工是的可以处理工作之外的工作请求的。
只有及个别员工，因为自身原因和自己能力没有办法处理。团队内部可以理解。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们学到了项目工作的各个岗位的管理人员都需要做些什么。
如果历史重来一遍，我们将把各项工作做得更全面、更细致，不出现不该犯的错误。
大家团结在一起的精神，什么困难我们都能克服。
对设计/实现的回顾
1.设计工作在什么时候由谁来完成？是合适的时间 合适的人吗？
我们组成第一次团队的时候 由皱建华UI设计师来完成设计。
由于他专业方向是安卓方向，所以同时在项目设计时间，也是岗位对称。是团队的最佳合适人选！
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有碰到过，在程序方面我们原型设计中无法运行出来。
在图片加载后出现一些模糊不清，在我跟我们的团队讨论中
跟已经做出来的同学，去请教，然后团内研究讨论，最终研究明白，成功运行。
3.团队是否运用单页测试、测试驱动的开发、UML或者其他工具来帮助设计和实现？这些工具有效吗？
没有运用单页测试、测试驱动的开发、UML或者其他工具。
因为我们团队开发都是用安卓软件运行中出来，一次又一次的运行测试，才实现我们团队的理念。
4.什么功能产生的BUG最多，为什么？在发布之后发现了什么重要的BUG？为什么我们在设计/开发时没有想到这些情况。
在游戏运行时，在游戏进行的过程中，按钮出来的时候不统一，出来的不是慢就是快，步伐不统一。
因为团队缺乏经验，所在设计开发没有想到这些情况，导致疏忽从而出现BUG。
看起来不是很和谐完整，在我们开发设计中并没有考虑这些bug的存在。
5.代码复审是如何进行的，是否严格执行了代码规范?
复审是在软件中规范代码，每行每列都好好重新排列重新检查一遍，是否按照严格执行了代码的规范。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们学到了设计软件都有哪些功能，已经代码的编程后去实现项目的整体运行！
如果历史重来，我们设计更多的项目功能，完善整体项目使游戏更加具有挑战性耐玩性和刺激性。
并且严格按照代码规范进行编写代码，复审也将严格仔细认真查看！
对测试/发布的回顾
1.团队有没有测试计划？为什么没有？
每天都有测试计划，并且每天完成测试计划后，并开会汇报总结。
2.有没有做过正式的验收测试？
我们团队进行正式了的验收测试，测试达并且达到预计设想。
3.团队是否有测试工具来帮住测试？
有试着用测试工具帮助测试，但基本都是靠自己研究探索，毕竟缺乏经验。
没有进行正式的验收测试，就目前完成的软件来说。
仍存在着一些小小的问题，也还没有达到令人满意的程度，因此还在尝试完善优化软件。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
测量效能主要有软件是否正常运行，运行速度是否高效率，运行效果是否令人满意等。
从实际结果来看，测试工作还是有用的，在测试的过程中还是发现了一些开发时欠缺考虑的问题，
改进主要还是从软件本身出发，争取能更优化下用户体验。
5.在发布的过程中发现了哪些意外问题？
发布的过程中，也是因为网络的问题，没有统一规范的原因，导致了最终代码整合的时候出现了难以解决的困难，
基本上每次遇到的困难都是新的困难，都是令人意外的，之前没出现过的问题。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
软件的开发过程中，测试这一环节是必不可少的。一款软件即使测试完毕发布后，仍然会出现或多或少的问题，
而这就体现了在测试环节你付出了多少，就决定了你最后遇到的问题是大是小。
而测试也是需要有技巧性，有针对性的去测试你的软件，而不能照搬其他人的测试方式，软件都有各自独有的特点。
如果历史重来一遍。我们会在测试的过程前，再进行更多的交流和讨论，
争取考虑更多方面可能出现的问题，有针对性的提出一个详细的测试计划，
并分配给多人重复测试，争取减少发布后遇到的问题。
总结：
对团队角色、管理、合作的回顾.
1.团队的每个角色是如何确定的，是不是人尽其才？
产品项目经理这个角色，首先认为自己有管理能力和关于各项目情况都基本了解，并能积极督促团队成员的。
UI设计师这个角色是根据学习方向以及兴趣爱好来制定的。
软件工程师也是根据学习的方向选择来担任角色。
软件测试师根据兴趣和能力以及其他方面的不足来进行担任角色。
可以说是团队人员都是各尽其才，分配得体。
2.团队成员之间有互相帮助么？
互相帮助的情况经常出现，以上也说了，我们对代码能力不是特别的强。
因此为了我们团队整体项目发展，团队所有成员除完成自己工作外，一起共同开发代码完成项目。
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
当出现项目管理、合作方面问题时，团队也会积极组织开会讨论，并且发表问题，提出解决方案。
拿不准正确方案的时候即可投票表决，或者请其他人帮助解决问题。
4.每个成员明确公开地表示对别人帮助的感谢。
武超：我感谢 孙航、胡金鹏对我的帮助，在第一次冲刺任务下，因为计划安排成员的任务分配，团队成员意见纷纷，导致浪费了几天工作时间，他们俩站出来，帮助我开导我，并且也在我意 见下，提出了更加完善的解决办法和具体措施，让我不在焦躁闹心，也使团队整体和谐，认真工作。
皱建华：我感谢 武超 对我的帮助，因为我有时候不明白任务情况都会问他，我需要做什么都问他，他对我们组的贡献也非常大，每天都督促我们开每日例会，有作业也会第一时间通知我们。
胡金鹏：我感谢 皱建华 在程序设计图中给了我一定的选择，不然会出现游戏成功制作画面美感不和谐，感谢皱建华调整我的看官。
武嘉琦：我感谢 胡金鹏 对我的帮助，因为在编写代码的时候是他一直坚持不懈的帮助我，非常的感谢他。
孙航：我感谢 武超 对我的帮助，每次对发布的任务有不理解的或者不会的，他会帮助我解答难题，并且在进展有问题是及时督促我，也让我们更加团结完成这学期任务。
解云龙：我感谢 武超 对我的帮助，在软件测试过程中，遇到不清楚的和不会的问题都能得到及时的帮助且能一起互相监督、互相帮助的完成任务。
5.每个成员的软件工程水平有什么提高？
武超：在整个软件工程项目中，我担任项目经理一职，在用户分析工作 提高了我的观察理解和快速学习能力，在项目分配工作提高了我都分析管理能力，从而学习查找资料且与团队成员一起工作等提高了可以说是在软件开发、UI设计、和测试各个方面的专业能力。
皱建华：我在UI设计思路上提高了，想要什么样的图片，我会很快有一个框架，并且通过了解用户需求，创造出更加美观舒适的角色。
胡金鹏：在代码中 我充分的了解了安卓在其中运用代码程序，从开始不懂怎么敲写代码，没有思路，直到现在我才有独自能力完成一些代码运行能力，这是使我进步的缘由。
武嘉琦：在编写代码和个人创意还有一些ui的方面有很大的提升收获很大。
解云龙：在测试中 从最开始的什么都不懂，到慢慢理解一些测试bug的方法，能更准确找出bug并且及时反馈给代码工程师，其中在打包当面一直存在问题，在出现问题时及时询问其他组测试人员， 进一步提高自己打包、测试方面的能力，在每次的测试报告中记录着我这学期的成长。
孙航：我学会了如何测试bug和如何更加规范的书写测试报告；能更加熟练的使用码云仓库和打包构建，测试能力逐渐提升，每一次的测试报告的提交，都是我迈向成功的一小步。
6.你觉得团队目前的状态属于CMMI中的哪个级别？
目前团队属于属于CMM阶段。可重复级与已定义级之间，2个级别的内容展示如下:
可重复级：通过开发项目中的经验，建立了基本的项目管理制度，采取了一定的措施方案和工作时间。管理人员可及时发现问题，一定程度上可重复类似项目的软件开发。
已定义级：已将软件过程文档化、标准化，可按需要改进开发过程，采用评审方法保证软件质量和工作效率。
7.你觉得团队目前处于 萌芽/磨合/规范/创造阶段的哪一个阶段?
我觉得目前团队已经经过了萌芽、磨合的阶段，现在处于规范的阶段。
经过Alpha和Beta阶段，团队的每人都互相了解。
项目经理分配任务也会考虑每个人不同的情况，根据每个人的强项和个人能力去安排任务。
做事情还是规范化做起来效率较高，不用顾虑太多其他因素，规则定在那里就去执行。
8.你觉得团队在这个里程碑相比前一个里程碑有什么改进？
经历书上知识敏捷流程原则以后，我们对于软件工程项目比较了解了，不像之前只是纸上谈兵。
有了一些项目开发的经验，在之后的各项开发，不会很慌张，会有经验，并且遇到问题可以冷静处理。
9.对比本书5.3.7 TSP的原则或者敏捷流程的原则，你觉得目前最需要改进的一个方面是什么？
改进代码开发方面，功能多用户量也会随之提升。
根据进度及时调整功能，有些过于复杂的功能就暂缓开发，优先核心功能。
UI设计计划方面，关注用户需求，根据他们的需求和意见修改计划。
