一、 设想和目标
1.我们的软件需要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清楚的描述？
- 我们的软件是要帮助小学生及其家长以及小学老师对于四则运算有需求的人群有一个便捷的途径来练习。定义明确，对典型用户和典型场景有清楚的描述。
2.是否有充足的时间来做计划？
- 有，但由于对开发的难度未知，只能做出大概的计划。
3.团队在计划阶段是如何解决成员对于计划的不同意见的？
- 展开团队会议，发表自己的见解，再由团队成员投票来确定方案。
4.有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 首先，如果可以重来的话我们一定会更加重视需求分析，花足够的时间用来分析用户需求这样就可以很了解该做什么样的APP了，就不会一直在加功能了。另外，经历下来感觉存在资源浪费，在分工方面可以更细化，将各个模块落实到每个人。
二、计划
1.你原计划的工作是否最后都做完了？如果没有做完的，为什么？
- 计划的工作大部分已经完成，由于技术以及时间问题，我们的用户登录功能还未完成。
2.有没有发现你做了一些事后看来没有必要或没多大价值？
- 我的团队在开始的时候就已经比较明确每个人的分工以及职责，所以在这一块我们基本没有浪费时间做没有价值的事情。在每个人细分的小任务中难免都会有些没有价值的事情，我们也都在改善中。
3．是否每一项任务都有清楚定义和衡量的交付件
- 这个我们的定义好像就比较模糊，主要就是测试代码能否正常运行，是否会出现什么bug。要是在测试过程中没有发现问题，我们就觉得这个应该是可以交付的了。在这个方面我们还需要改进，尽量出一些可以量化的标准。
4．是否项目的过程都按计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
- 我们这个项目没有完全按照计划来执行。在项目冲刺的第三天，我们由于app内置数据库问题卡住了，由于当时对于这方面不了解，耽搁了一些时间。项目冲刺第四天，在生成题目较多的时候需要滚动页面，在前面已经判断过的案会消失。由于当时无法确定出问题的地方，打乱了我们原本的安排，导致落下了我们当天原本需要完成的工作。其中有些问题确实困扰了我们很久，也耽误了很多时间。
- 在我们安排计划的时候，没有考虑过出现问题可能导致时间耽搁的问题。直到后来开始实践了我们才发现挺多事情拖慢了我们的进度。经过我们团队的反思，我们就是没有充分到每个任务的难度，导致了我们任务分配时的想当然，没有根据任务的难易来分配时间。
5.在计划中有没有留下缓冲区？缓冲区有什么作用？
- 留缓冲区，缓冲区可以让我们在计划出现问题的时候留下时间来解决问题。
6.将来的计划会做出什么修改？
- 分析任务难度，规划好时间，留下缓冲区
7.我们学到了什么？如果历史再来一遍我们会做出什么改变？
- 就像之前不断出现的，我们没有分析好每个任务的难度以及可能出现的问题，导致出现问题的时候拖慢了我们原定的进程。如果历史再来一遍我们会分析任务难度，规划好时间，留下缓冲区。
三、 资源
1.我们有足够的资源来完成各项任务么？
- 我们拥有一定的资源但不能说足够。在组内还是有编程能力较弱的成员，在开发时会有阻力，但好在团员有担当肯努力大家一起面对困难。
2.各项任务所需时间和其他资源是如何估计的，精度如何？
- 我们将任务模块化，平均分到每一天，精度不高。
3.测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编辑的资源（美工设计/文案）是否低估难度？
- 测试是我们较担心的一块，因为以前没有相关的经验。测试时间适中，也使用了市面上比较流行的手机进行测试，人力和软件/硬件资源较为充足。美工设计和文案方面有一定的重视，是有低估其难度，也花了一点时间。
4.你有没有感到你做的事情可以让别人来做（更有效率）？
- 每个人有每个人擅长的模块，当初分工就是按每个人的长处进行分工，暂时没有这个困扰。
5.有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 在每日任务方面应该考虑每个任务的难度，而不是每天平均分配任务，团队也要多加沟通，制定更加合理的计划，提高工作效率。
四、变更管理
1. 每个相关的成员都及时知道了变更的消息?
- 知道，通过博客的任务安排以及在qq交流群我们都会及时通知反馈。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 必要功能如基本运算和本地数据库“必须实现”，联网服务等可以等到下个版本“推迟”实现。主要依据事件规划的紧迫性来划分，主体功能放在“必须实现”的位置，次要功能可以等下下个版本的开发测试实现。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 小组对项目出口条件的定义是：根据实际的情况和用户反馈的程度来定义。我们组的PM也会合理的分配安排工作。
4. 对于可能的变更是否能制定应急计划?
- 目前暂时没有考虑项目的变更，毕竟已经趋于稳定，暂时没有相应的应急计划。
5. 成员是否能够有效地处理意料之外的任务请求？
- 出现了意料之外的任务请求也能够较好的产生计划，PM会根据个人的实际能力已经擅长的部分来合理的分配工作，创建合理的解决方案。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了各种不同工具的使用，尤其是git，确实是一个很好用的工具。但这不是最重要的，最重要的是我们通过团队协助，互相配合，最后落实到个人的这个过程，我觉得是本次收获最大的。如果历史从来一遍，我们应该还是一如既往的努力，把遇到的问题及时的磨合改变，应该能够做出更好的产品。
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 项目的整体结构是由邱文鑫同学完成的，以为他对这个比较感兴趣，所以这个项目的主要代码都是他敲出来的，相比其他成员更熟悉开发的套路，所以由他来完成项目的架构是合适的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 设计工作有遇到模棱两可的情况，因为我们团队的项目是四则运算自动生成器，这个基础功能是前几次的作业，所以团队的全体成员对这个项目还是比较了解的，大家也对这个项目都有自己的思考。但是正因为大家都有自己的思考，我们团队在设计这款软件的时候就出现了模棱两可的情况，有的队员认为这款软件的使用对象应该是小学生，小学生可以直接在这个软件上面进行四则运算练习；还有的队员认为这款软件应该主要是给老师使用的，老师可以导出题目给学生们做。
- 这个问题大家争论了好久，大家都各抒己见，但是公说公有理婆说婆有理，一下子僵持不下。于是我们的组长就建议来一个明主投票，少数服从多数，最后投票结果是支持以学生为主要对象，但是大家同时提出我们同样可以为老师设计一个登陆身份，这样也可以使我们的软件受众面更广。经过大家的讨论，我们终于解决了这个问题，同时还让我们的软件更加饱满。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 团队有进行一部分的单元测试，由于我们的项目是在前几次的作业基础上发展而来的，而前几次就有一次是要求我们对代码进行单元测试的，还对代码的覆盖率进行了验证。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 在设计错题复习功能时候产生的bug最多，因为这个功能是我们团队的“点睛之笔”，是区别于市面上那些四则运算软件的一个创造性的功能，所以这个功能设计起来并不是那么容易。我们首先需要搭建数据库，然后要把数据库跟这个软件连接起来，步骤比较繁杂，所以出现的bug比较多。另外，我们在完善这个功能的时候也难以避免地遇到很多bug，最开始的时候我们只能生成1-10题的错题，经过调研之后我们又把生成的错题数量提高到了任意数量，这就使得在翻页的过程中出现了已填写的数据丢失，经过两天的努力才解决这个问题。发布之后倒是没有发现什么重要的bug，就是我们登录界面还没做，所以功能还不完善。
- 为什么我们在设计/开发的时候没有想到这些情况？因为那个时候没有想到过把功能完善得这么好，所以就没有预计到多生成几倍甚至几十倍的题目可能造成数据丢失。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 我们在编写程序之前就召开了团队会议，专门对代码进行了规范，我们还制作了一份代码规范说明，这样不管是编写者还是读者只要查阅这个代码规范文档，就可以找到想要的答案。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 我们学到了磨刀不误砍材工这个道理，在开始整个项目之前，我们最好做好万全的准备工作，这样后续的工作才会很顺利地进行。如果历史重来一遍，我们一定会重视需求分析这一环节，因为这次我们在冲刺的七天里，由于重新做了需求分析，几乎每天都要修改功能和完善功能，这给我们带来很大的麻烦，如果早一点做好需求分析，就可以节约很多的时间和精力。
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
- 有测试计划，我们决定通过手机进行测试。
2. 是否进行了正式的验收测试？
- 是的，通过手机对各项功能都进行了测试。
3. 团队是否有测试工具来帮助测试？
- 没有用到测试工具，通过Android手机进行测试。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 在alpha版本阶段，每个完成一个功能就把ＡＰＰ发到手机进行测试，查看效果这个功能在手机端的效果，看看是否需要改进。最后的运行结果证明了测试工作还是有用的，发现了很多之前在电脑上没有发现问题。例如：因为手机的系统版本不同，有点版本因为系统太老就运行不了。
5. 在发布的过程中发现了哪些意外问题？
- 大的意外问题倒是没有，就发现有些比较老版本系统的手机运行不了ＡＰＰ，其他的倒和原本设想的差不多。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 在Alpha过程中我们学到了git仓库代码的迁入，以及软件的测试方法，还有应该对代码进行及时注释。
- 改进：因为刚开始我们的代码没有及时注释，所以在我们测试完需要对程序进行改进时比较麻烦，需要重新看一次代码，所以以后我们会注意代码的注释，还有，由于我们对用工具对代码进行测试不太熟悉，所以就没有用工具去测试代码，只通过手机进行测试，这样很不全面，所以以后我们会通过工具测试与手机测试相结合的方式进行软件测试。
七、团队成员在Alpha阶段的角色和具体贡献：
|
名字 |
角色 |
团队贡献分 |
可验证的贡献 |
|
余洋（201421123031） |
Test |
19.45 |
测试、博客编写 |
|
邱文鑫 （201421123043） |
Dev |
22 |
主要代码编写 |
|
潘志坚 （201421123044） |
Test |
19.47 |
测试、博客编写 |
|
念其锋 (201421123045) |
PM |
20 |
分配任务、博客编写 |
|
林青 （201421123047） |
Test |
19.55 |
测试、博客编写 |
|
黄子敬 （201421123052） |
Dev |
19.53 |
部分代码编写、博客编写 |
说明：因为我们小组邱文鑫同学主要负责代码的编写，工作量比较大，所以我们小组成员经过讨论决定给他22分；念其锋同学作为我们的组长，每次都由他分配任务和汇总博客，所以我们小组成员经过讨论决定给他21分；而我们组的其他成员也都及时完成了他的任务，所以他们都得19分。
八、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- CMMI二级：管理级
- 经过了Alpha的这个交流过程，我们组员之间的配合愈加默契，通过PM传达的老师的任务都是较为合理的完成，PM通过安排工作，组员按时完成，完成后并向PM进行汇报，每天都能够有一个完成进度表，方便查缺补漏，这个管理制度已经相当成熟。
2.你觉得团队目前处于[萌芽/磨合/规范/创造]阶段的哪一个阶段?
- 磨合阶段
- 我们的团队还不算磨合完成，经常都会出现意见上的分歧，所以需要每天通过每日例会来协商解决问题，一步步沟通完成我们下一步需要做什么，需要完成的是什么，哪些功能是可以先一步完成。
- 沟通是我们现有团队的一大解决方案，所以，我们的团队，目前为止还是属于磨合阶段，但是这个磨合阶段已经快要完成，准确的说，我们现在处于半只脚踏进了规范阶段，所以，需要更加努力的朝着规范阶段迈进，乃至创造阶段。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 迈过了一个初期的迷茫阶段，现在对于软件开发的过程会有更加深入的了解，对于接下来的里程碑会比之前那个阶段相对轻松。
- 经过长时间的磨合改进，团队之间的气氛相对于刚开始会更加的和谐与融洽。有利于接下来的工作更好的开展。
4.你觉得目前最需要改进的一个方面是什么?
- 目前我认为最需要改进的一个问题是个人的管理能力有所欠缺，许多时候团队的工作安排需要通过PM来下达，个人不能很合理的安排与分配工作，需要通过PM间接的把控，否则可能会出现成员的工作没有完全的落实，这是需要改进的一个点，也是目前出现的一个较为明显的问题。