设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
相比于alpha阶段来说，为提高网站的扩展性和维护性，我们beta阶段计划的任务是重构网站后端同时针对用户对物理实验考试训练的需求设计题库。在重构方面我们在alpha阶段结束后就已经有了明确的方向，同时针对题库功能的设计也已经定义的比较明白，主要是针对用户对题目训练需求我们计划了在线题库验证答案的功能，来满足有题库需求的用户。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
在一定程度上我们低估了重构后端的工作量，导致在题库对接方面存在时间紧张的问题，同时后端人员认为前端的界面设计太过简陋以至于无法面对用户而放弃了对接，加之时间的原因我们决定做好重构的工作以及完善部署文档，将重构好的原有功能进行发布，由于延期发布的原因导致原计划用户数量没有达到。在这方面上我感觉主要还是自己作为PM没能很好地协调组员之间的工作，在组员之间任务分配上和管理上存在很大的不足，导致组员按计划分配的任务没能及时完成，同时自己对于整个设计大局的把握没能掌握好，导致组员之间的分工不均，一定程度上导致最后的对接出现了问题。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
相对来说，相对于上一个工程来说，团队的软件工程的质量有所提高，同时也存在一些问题，首先重构后端提高网站的扩展性和可维护性，同时在开发过程中个人的任务工作比较明确，虽然PM一直询问组员之间的进度，但对进度迟缓的组员没能及时做出补救，仍然按部就班的进行，导致出现一定的问题。相对来说，我们质量在关键在重构后的代码和文档上，相对之前的设计我们重构后使得代码更加精简，同时通过部署文档使接收人员能够快速掌握网站的设计，扩展性提高。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于我们延期发布的原因导致我们没能收到足够的用户反馈，只是通过测试人员的测试处理对重要功能的测试使得我们对自己重要功能和我们预想接近，但用户的反馈仍然是我们后阶段急需要的。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
通过这一阶段的实践，我还是发现我们组存在着比较大的问题，首先是我自身的能力组员协调问题，然后是任务分工问题，同时还有对于组员进度的掌控和改进问题。如果能再来一遍，我们应该会确定好分工问题，不能因为组成员的独断而自领任务形式导致最后无法按时完成目标，同时在组员协调上及进度掌控上设计好贡献比及奖惩措施，对于不能及时完成任务的组员针对任务及时做出调整，能够抓紧时间按计划完成既定目标。虽然历史不会重来，但这些教训需要我们在后面的学习中做出改进，提高我们的团队效率，针对团队的问题做出改进。
计划
1. 是否有充足的时间来做计划?
在新功能和人员的安排上我们还是花费了充足的时间去做计划的，首先针对人员来实施分工，针对需求设计功能，按前后端拆解分配任务等等。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
针对组员之间不同的意见我们会通过会议的方式交流讨论，比较每个人意见的好坏 ，一起选择一种最佳方案。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划本来是加上新功能题库的，但由于对接上存在一些问题导致没能及时完成，同时为了能够按时发布我们暂时搁置该新功能全力做好发布工作，准备后期再去实现补充。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有的，前端有开发一些附加功能而后端对接中舍弃了。
5. 是否每一项任务都有清楚定义和衡量的交付件?
任务的分配都有通过GitHub中issue的方式分配，通过组员任务的交付PM审核通过后关闭issue，未通过继续修改。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
开始任务分配都预估好了时间，但开发人员在开发上进度比较缓慢，在交流中通过探讨解决问题而实际上没能很大程度改善，同时作为PM没能对这种情况及时做出调整，导致项目进行总在计划之外，风险主要是组员对于技术的掌握程度不够和对工作的按时完成度不够，没有估计到的一部分原因是我以为在alpha阶段他们已经学习掌握了技术，但实施起来发现存在一定的问题，同时拖延问题和beta阶段时间紧张的问题也从一定程度上导致项目进度缓慢。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
相对开始计划时是留下了缓冲区的，但最终进度的缓慢导致缓冲区时间也不够。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
我认为在缓冲区方面已经设置好了，关键亟待改善的是要提高进度，可以在分工上明确分工，对拖延处理上能够及时处理并改进，使实际按照计划的方向迈进。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
通过这一阶段的实践，我们通过一些失败的惨痛教训学到要合理分工，积极发挥每个人在团队中的作用，开始就应该预估风险并做出一定的计划安排，是最终能够针对特殊情况及时做出改善。
资源
1. 我们有足够的资源来完成各项任务么?
相对来说，我们的资源是足够了的，只是我们没能很好的利用好资源，我们需要的合理分工，切实发挥每个人的作用，提高组员在团队中贡献的积极性，较好的利用资源完成任务。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
一般都是通过对各项任务中功能代码量的预估来实现时间资源的估计的，但在实际操作中发现这种方式精度不是很高，因此需要及时调整。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间还是比较充足的，但后端人员的工作量有些大，因此在后端上安排存在不足，原计划安排测试人员协助后端操作但考虑到学习时间迟迟未决定，这方面一直是分工的一大问题。相对来说前端界面设计上没有低估难度，反而是后端方面低估了工作量，导致对接时存在问题。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
由于我自己存在很大的问题没能很好的带领组员去解决突发问题，感觉如果当时能够及时让更适合的人员来处理会更加有效率，自己在面对组员进度未按时完成时也没有很好的处理优化改进，导致进度上存在问题。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
通过这一阶段的学习，我们发现虽然我们有较好的资源但没有能很好的利用，如果可以，我感觉可以从多个方面做出改进，首先我自己身上在协调组员方面在面对组员未能及时完成任务时及时沟通，发现存在问题的的地方，合理安排人员及时做出改进；同时在人员分工上需要果断做出改进安排，在组员积极性方面要积极调动，提高组员的积极性，改善团队合作氛围。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
变更消息我都会在群里和会议中及时说明，因此组员都会及时知道变更消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
开始时间充足时，我们会考虑用户需求迫切性来决定這些功能，例如我们在准备题库时将期末题库决定为必须实现的功能，而绪论题库可推迟（beta阶段绪论考试结束）。
然后在时间不足时，我们或考虑那些满足当下的基本功能，例如我们最后决定完善重构的原有功能，保证基本功能不丢失。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
项目出口条件就是完成计划功能，无影响用户体验的bug，同时能够有较好的用户体验，满足用户的既定需求。
4. 对于可能的变更是否能制定应急计划?
在整体的实施中相对原有的计划变更的动作幅度一般不会太大，相对一些小的变更会及时更新安排，能够及时处理。当遇到例如用户需求变更较大的那种我们可能要重新考虑设计安排，由于我们开始设定了缓冲区，能在一定程度上对变更作出反应。
5. 员工是否能够有效地处理意料之外的工作请求？
在我们这一阶段的实施中，我们相对的变更没有太大影响总工程，对于重构的部分后端人员对重构的技术已经很自信了，前端所做更改不大，因此组员还是能处理 这些工作请求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在这一阶段中，我们开始统筹安排的地方尽管有一些不合理但开始实施时还是有一定进展的，但后期对组员的监督力度不过导致积极性有些下降，最终影响了最后的对接。相对来说，我们需要改进的是合理安排分工，提高组员在团队中贡献的积极性，提高合作，协调组员，能够对突发状况做出合理的应对措施。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
beta阶段开始时我们就开始了设计工作，主要由PM设计功能和界面设计，然后通过会议组员提出自己的改进计划，通过讨论实现最终的设计，同时分配组员工作，相对来说我们在开始就设计好是合适的时间，开始觉得可以，但后期设计出来后后端又觉得无法面对用户，因此在交流方面仍然存在问题。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在界面设计上还是存在一些模棱两可的情况，因为我自身在美工方面不是很好，只能说设计出一个原形，交由前端人员去选择好的界面设计模式来使前端更用户友好化，但最终发现效果也不是很好，这方面也是对接上的一个问题。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
相对来说我们的测试还是停留在功能测试和开发人员进行输入输出的测试，没有使用工具来测试。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
前面主要还是社区功能产生的bug比较多，因为我们是直接借用的插件来设计的社区，导致其中存在一些问题我们还没能做出改进。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
主要是PM进行功能审核，对接代码接口查看，感觉还是没有严格执行代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
通过这一阶段的实践，我们学到了要做好设计，明确各项任务的细则，否则在对接中就会出现很大的问题，代码规范很重要，要求严格按照要求编程有助于对接更加方便。如果可以，我们可以在设计上做出改进，在初期设计各部分确定好满意的设计，保证在后面实现后不会出现问题，同时在代码规范上要严格要求，通过代码复审来改进代码可读性，有助于对接扩展。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
初期计划时开发人员针对开发的结果自己进行一部分测试，然后最后测试人员通过测试工具进行功能，压力等等测试。
2. 是否进行了正式的验收测试？
由于开发的进度原因最后只进行了功能测试，针对网站的一些功能进行用户级测试，完成一些简单的测试。
3. 团队是否有测试工具来帮助测试？
暂时没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
通过测试矩阵测试网站在不同测试环境下各个功能的正常情况，相对来说这些测试并不能很好的测试出来结果，应该通过工具来进行压力测试，稳定性测试等等相对能够更加说明 问题并及时对此做出改进。
5. 在发布的过程中发现了哪些意外问题？
在发布时我们发现很大的一个问题，就是用户无法收到邮件验证的问题，后来通过紧急排查及时解决了这个问题。但这说明我们的测试在一定程度上是有很大的问题的，需要我们后阶段及时做出改进，避免后期出现更大的问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
通过这一阶段的学习，我们更加明白测试对于软件开发的重要性，测试的关键在能够在面对用户前发现问题并及时改进，避免在面对用户时暴露错误造成巨大的损失，因此我么你需要改进的是合理安排测试工作，针对测试做出好多测试计划，按时按量完成测试工作，合理利用测试工具，提高测试覆盖率，保证在面对用户前软件已无影响用户体验的问题。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
团队的角色安排基本沿用alpha阶段的人员安排，原PM更愿意去后端开发，其他基本保持不变。但最后发现这样的安排存在一些问题，首先beta阶段的任务重心发生偏转，后端人员工作量较大，而测试人员在初期工作量较小，因此并没有做到人尽其才，分工上存在一些问题。
2. 团队成员之间有互相帮助么？
相对来说，我和组员之间的交流较多，通过和组员之间的交流发现各自存在的问题，然后我会在会议上提出这样的问题一起交流解决方案，实现互相帮助。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们在这方面存在一些问题，当出现项目管理上的问题时，基本上组员之间很少交流，同时在合作方面更多地也是通过我来传达，而我自身协调不足导致在合作上存在一些问题，导致合作方面存在问题，例如要求代码签入时尽管我多次说明仍有组员拖延签入导致合作上进度减缓，存在一些问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在这一阶段，我们相对来说在管理合作上存在比较大的问题，一方面由于我自身协调能力不足导致组员之间的桥梁责任没有做好，导致最后在对接上存在一些问题，同时在调动组员积极性上存在一些问题，时常无动于衷，导致进度有些缓慢。相对来说我们急需改进的是提高组员积极性，做好组员之间的协调工作，做好对接合作，完成既定目标。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
感觉介于初始级和可重复级之间，之所以这么说是因为我们的管理有一定的章法但并没有很好的制度化，PM会追踪组员开发进度，开发人员按计划实现开发，但总存在一些不足，开发进度时有拖延，并不能很好完成计划。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范。现在通过一个阶段的合作实践，虽然我们之间仍然存在一些问题，但我们在实践中已不断磨合，会经常交流，有共同的目标，需要在这之中形成一种规范，使得我们的团队进程能够稳步向前，吸取经验教训，一起进步。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
任务分工虽不均但明确，有一定的进度追踪，不过我们仍然需要改进自身存在的一些问题，让我们在这个团队中更好的进步，更好的前进。
你觉得目前最需要改进的一个方面是什么?
协调管理，促进交流，能够稳定解决突发事件。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
相对来说我们在这一方面做得不尽人意，仍需要改进。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈：相对来说我们有问题会在会议中交流解决，选择好的解决方案。
总的来说，在整个beta阶段，我们团队还是暴露了一些问题，导致我们的项目并没有很好的按照预期实现，通过分析，我们感受到在管理，分工，合作等等方面存在比较大的问题，因此我们后期需要做出改进，在以后的团队合作中不断改进自己，实现进步。
附上开会照片：