alpha阶段事后分析
Alpha阶段事后分析
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件是为了解决同学们选课的难题，通过课程评价对课程了解从而帮助同学们选课。定义的比较清楚。对于典型用户和典型场景有描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?·
原计划的功能基本达到，权衡之后舍弃了几个功能，例如对评价的回复，标签以及点赞功能。交付时间推迟了几天，原计划达到的用户量并没有达到。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
我们的用户量较少，可能是我们做的还不够好，不能吸引用户，与我们事先的预想有些不一致。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
从这一次开发中我们学到了很多东西。基本技能方面，我们学会了一个网站的完整设计实现过程，并且合作完成了这一项工程。同时我们还学会了怎样在一个团队中发挥自己的力量，共同完成一项大的工程。如果重来一遍，我们会在团队合作时少一些迷茫，会更恰当地分配任务，合作完成。而且我们会意识到文档的重要性，文档可以使这个项目不仅当前开发人员能够理解，并且接手的人或团队其他开发人员能够理解。
计划
1. 是否有充足的时间来做计划?
有充足的时间来做计划，大家也一起讨论过，但是讨论没有和实践相结合，因此很多考虑不充分的情况在实现时暴露了出来。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
对于不同的意见，大家一起讨论，然后通过讨论一起决定这件事情，少数服从多数，问题得以解决。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大部分工作都已经完成了，实现了核心的评价课程功能，一些没有完成的工作不影响这个阶段的发布使用。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有一些，比如说一开始定义了一些接口，但是在实现的过程中基本上没有按照这一定义和设计去做，而是通过接口两端开发人员的讨论实现接口。
5. 是否每一项任务都有清楚定义和衡量的交付件?
对于每一项任务有个大概的定义，即大概要做出个什么样子，但是并没有特别清楚，一些细节没有提及。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
在最开始的阶段我们就曾遇到过很大的问题。在设计时我们对前端后端做了一个划分，并根据这个划分做了很多设计，但是设计中出现了很多问题，导致设计的复杂度越来越高。最后的解决方案是修改前后端的划分，最终解决了这个问题。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有留下缓冲区，基本上都是压着时间点完成的。缓冲区还是有作用的，毕竟不是所有的东西都可以考虑到、成员可能也会有特殊情况，留有缓冲区可以应对一些未知问题。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将计划时间往前推，防止出现不可抗力因素导致任务无法完成时，影响到整个项目的进度。从而使得项目的进展更加平稳。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
好的计划能有效地推进整个项目的进展。在计划前，对项目开发本身有一个较清晰的整体印象，对于做出一个好计划很有用。
资源
1. 我们有足够的资源来完成各项任务么?
资源还是有很多的，首先网上就有很多教程，基本上搜一下就有一大堆，学习新东西或者查找一些东西很方便。其次，老师也能提供一些帮助，比如说提供服务器什么的。因此，总体上资源还是很丰富的。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
任务的所需时间在估计时没有做太多计算，而是根据对任务的整体感觉做估计。因此精度并不高。存在一些预估耗时和实际耗时相去甚远的情况。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
在测试上我们并没有投入太多的精力，在网站基本完成，上线之前，我们团队对其进行了一些测试。在这一方面的资源并不缺少。在网页界面设计上我们没有低估其难度，相反，我们花费了较多的时间去设计一个网页，从最初的勉强实现功能，到后来不错的界面，我们在其中花费了较多的精力。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
暂时没有，觉得每个人都有自己相应的任务，大家基本也是对这些不是很了解，编程经验也不够，都需要学习，也就没有说让某些人做哪项会更有效率。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
应当合理的分配各项资源，合理估计各项任务所需的时间。并且留有一部分缓冲余地。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
如果项目出现变动，在团队的群里会及时告知大家，再加上密集的团队会议，消息还是很及时的。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们团队将项目的核心定位为课程评价平台，突出课程和评价，因此与核心关系越紧密的任务越不可推迟。以此会标准进行团队讨论，根据前期的调研和实际功能的必须程度、实现所需时间、剩余时间综合决定。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
并没有很仔细考虑过。大约是没有明显bug，各基本功能实现，用户可以完整地使用功能而不会有问题为标准。
4. 对于可能的变更是否能制定应急计划?
由于项目本身较小，一般是变更后再制定新计划，没有提前的应急计划。
5. 员工是否能够有效地处理意料之外的工作请求？
团队成员在这一方面做的很好，团队凝聚力较强，遇到意料之外的问题都能积极完成。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
项目进展不可能完全在计划内。对于突发的情况做出及时的反应与部署很重要。 开会时更加有目的性，更注重效率。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在项目决定后的一段时间，经过团队成员的团队讨论，由PM总结整理。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在规格、页面设计、功能的选择上有过模棱两可的情况。在团队会议上讨论，各人发表意见，最终决定下来。一些暂时无法清楚的部分等项目先进行一段时间后再决定。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
在前端部分我们使用了mockplus原型设计工具来设计网页的原型。然后根据原型实现各个页面。通过这个工具，我们在设计时就能够更好地表达理想的页面的模式。团队在开发过程中使用了Django自带的单元测试功能进行单元测试。对比项目最开始的设计文档，我们在实现时做了很多修改和补充。在最后阶段我们对文档进行了更新。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
搜索功能和前端的JS动态网页中出现了比较多的BUG，主要原因在于团队成员在项目开始后才开始接触JS和solr技术，因此使用并不熟练。在发布后我们发现了一些比较重大的BUG，例如已经提交的评价和评分不能修改，不能删除，同时一个用户可以对一门课程做多次评价。一些BUG是我们在开发过程中没有考虑到的，另一些是团队经过重要性和时间的权衡放弃实现的功能。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们团队没有做代码复审。在测试阶段，测试人员发现并报告BUG以后，团队会共同对项目代码进行检查和规范，修复BUG或是将其修复工作放到beta阶段的任务中。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们团队在开发过程中学到，开发过程绝不仅仅是编码的过程，这仅仅是其一部分，我们应当更加关注于文档的更新，设计工具的合理高效运用，以及代码质量的保证。并且在编码的过程中还应当注重自我测试。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
我们团队的测试计划大体分为两个部分，一个部分是团队成员完成当前任务编码以后，对自己的代码做自我测试，另一部分是基本功能都实现之后，整合于服务器上做整体的功能测试。
2. 是否进行了正式的验收测试？
我们团队的测试人员在最终网站上线后对其做了各项综合测试，并整合成为了测试结果文档。
3. 团队是否有测试工具来帮助测试？
是有使用测试工具的，主要是scrapy的框架和浏览器自带的网页反应时间功能。
有关功能可用性和兼容性的测试主要通过在不同机型和不同运行环境下通过用户的反馈进行测试。而网站稳定性的测试主要通过scrapy的框架对网站的主页和数据查询页面进行模拟访问进行，再通过浏览器自带的网页反应时间功能获取结果。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
有关功能可用性和兼容性的测试主要通过在不同机型和不同运行环境下通过用户的反馈进行测试。而网站稳定性的测试主要通过scrapy的框架对网站的主页和数据查询页面进行模拟访问进行，再通过浏览器自带的网页反应时间功能获取结果。
这些是比较有用的，通过在不同机型和不同运行环境下的运行，我们发现了一些由于环境不同所导致的不同的功能上的bug，并开始修正这方面的问题，通过对网站的压力测试，我们发现网站的承受压力还比较有限，如果有较大的用户（比如100+人在1秒内同时搜索相同内容）同时访问数据库，可能会导致网页的运行速度有比较大的降低。
改进：在部分环境下的部分功能还存在问题（不显示，点击无反应等），网站的抗压能力应该进行改进提高。
5. 在发布的过程中发现了哪些意外问题？
- 发布前夕，发现因为没有进行实名认证导致域名不能用。（实名认证后可以使用）
- 事先以为网站方面的开发最终结果兼容性应该比较好，但是实际测试在不同环境下会或多或少出现部分功能无法正常使用的问题。
- 部分机型手机测试方面搜索页面布局不够美观。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了网站测试的相关技术和对于多方面综合测试的思维。
- 改进：
- 在设计初期就定下最后的测试标准，这样开发人员也能有更明确的开发方向，测试人员也有实现测试的准备。
- 更全面地考虑网站本身的特性（包括可能收到恶意评价，刷分），进而推测可能在发布阶段出现的问题，从而在开发过程中消弭可能出现的bug。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
在团队会议中，PM确定大概分工，组员各自选择位置。大概是。
2. 团队成员之间有互相帮助么？
有。在遇到问题、或者在需要多方协调时，大家会互相帮助。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
讨论解决。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
成员之间互相熟悉有利于项目各部分的交流，也不容易出现不良情绪。 可能在开始时搞个小活动增进下感情233
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
初始级与可重复级之间。不算完全混乱，但也没能达到较规范的地步。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
成员之间互相较为熟悉了解，能进行有效的沟通。
你觉得目前最需要改进的一个方面是什么?
我们认为最需要改进的方面是对项目进度和任务的整体把控。不能因为时间紧迫就忽略了测试，设计文档和代码规范的重要性。
对比敏捷的原则，你觉得你们小组做得最好的是什么？
经常在团队会议、qq、寝室，对于开发中存在的问题进行面对面讨论。
什么是在下个阶段要改进的地方？越具体越好
- 在设计前详细的确定好我们需要完成哪些功能，需要怎样实现。不能是一个模糊的方向。
- 设计文档及时更新，在设计时增加对设计文档的依赖。
- 团队内部增加更多的交流，及时控制项目进度。同时可以更好推动成员完成任务实现最终目标。
全组讨论的照片。
