Alpha阶段事后分析
Alpha阶段事后分析
1. 设想和目标
1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们要实现一个课程资源共享平台，为同学们获取资源、分享资源提供便利。对于要解决的问题我们小组定义得比较明确，对典型用户和典型场景也有较为详细的描述。
1.2 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
原计划实现的资源上传/下载功能都已经在Alpha阶段实现了，只是一些比较细致的功能，如资源收藏、评价等，还没有实现。我们的原计划是发布一周内用户量达到300， 实际结果为230左右。
1.3 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
目前只是实现了资源上传和下载的功能，目前接到的反馈有打开资源界面的时候太慢，这一点实际上我们已经在发布前注意到了，只是没有时间去修复了。在发布之后我们通过资源的分页显示优化了资源显示过慢的问题，目前使用体验较好。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
感觉没有抓住用户的痛点，下载资源的步骤感觉还是繁琐了点，应该在Alpha阶段实现一个“搜索资源”的功能会好一点，这部分我们在Beta阶段实现。
2. 计划
2.1 是否有充足的时间来做计划?
Alpha阶段共四周，其中第一周的时间主要都用于做计划上了，时间感觉比较充足。我们在第一周大致设计了网站的原型，并对数据库结构和一些接口进行了定义，但尽管做了很多计划，依然还有很多没有考虑周全的地方，比如数据库和接口在实际开发中做了很多修改。
2.2 团队在计划阶段是如何解决同事们对于计划的不同意见的？
好像在实际开发中出现意见对立的情况不是很多……一般采取的做法是PM将所有不同的意见汇总，综合利弊得出结论。
2.3 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原本计划是把资源收藏等小功能也给实现了，但资源上传下载这部分比想象中难不少，尤其是如何下载用户上传的文件是个问题，在这一部分花费的时间超出了预期。
2.4 有没有发现你做了一些事后看来没必要或没多大价值的事?
个人中心在Alpha阶段完全没用上，不过这也是为资源收藏等功能做铺垫，而且也没有耗费太多时间。
2.5 是否每一项任务都有清楚定义和衡量的交付件?
感觉并没有，PM只是说要实现一个什么样的功能，却没有说这个功能实现之后要达到一个怎样的标准，一个模棱两可的功能实现，最终也可以被交付。
2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
并不是，比如在爬取课程信息的时候一开始没有获取到课程类别和开课院系等信息，这样子就没办法筛选课程了，只能先把Beta阶段的课程搜索功能先实现了。还有一个意外就是之前提到的，我们的资源分为两种，一种是爬取的资源，其实就是引用一个课程中心的链接；另外一种是用户上传的，和课程中心上的是完全不同的原理，下载用户上传的资源我们费了不少时间。
2.7 在计划中有没有留下缓冲区，缓冲区有作用么?
计划中没有缓冲区，都是从issue堆里直接分配的（逃
2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
工作重心转移到后端，比起赶着实现博文功能，不如先把资源功能尽可能完善，把较少的功能做到极致。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
开发感觉缺乏计划性，尽管最终目标很明确，但是实际开发时是走一步算一步。我感觉计划方面要向NewTeam团队学习，他们在Alpha阶段代码编写之前就已经将任务细化到每人、每天上，这一点比我们强太多……
3. 资源
3.1 我们有足够的资源来完成各项任务么?
我们是一人测试，四人开发，两人前端，两人后端，资源算是很充足了，而且组员们能力都很优秀，遇到的很多坑在大家的努力下都一一踩实了。
3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?
以小时为单位记录任务时间，估计的时候首先对任务进行一个大致了解，然后通过商议、查找资料等途径判断其难度。
3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们有一名成员专门负责测试，资源还算充足，只是在进行压力测试的时候机器要一直开几天，感觉有些吃不消……我们团队没有美工设计和文案，只有码代码的程序员。
3.4 你有没有感到你做的事情可以让别人来做（更有效率）?
有时候网站功能出现问题了会帮忙debug，但需要自己先熟悉一下代码，这样效率感觉就有点低了（其实还是自己比较菜）。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
还是感觉分工出现问题，每个人只负责职责内的工作是最好的。要是能重来，我作为一个PM首先要保证文档是随着代码进度不断更新的，这样能够提高成员交流的效率，其实能节省下来不少时间。在实际开发过程中，很多bug也是因为没有定义清楚接口和功能导致的，感觉浪费了不少时间……
4. 变更管理
4.1 每个相关的员工都及时知道了变更的消息?
感觉并没有，有些私下决定的事并没能及时通知大家，这一点PM需要检讨。
4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
核心的功能必须实现（如资源的下载和上传），围绕着核心功能的小功能可以先放放（如资源的收藏和评论）。
4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
并没有，差不多能跑了就算出口了……
4.4 对于可能的变更是否能制定应急计划?
感觉并没有针对变更制定应急计划，这一点在计划中已经检讨了，遇到变更的时候只有应急，没有计划。
4.5 员工是否能够有效地处理意料之外的工作请求？
中途有临时给一些成员添加过任务，他们都接受了并且完成得很漂亮，但是我觉得意料之外的工作请求还是应当越少越好。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
由于计划性不是很强，所以对于变更也没有概念，这其实是个很危险的事情。另外如果出现了变更，PM要明确定义出“什么东西变了，什么东西没变”，这样成员们大概也有个底。
5. 设计/实现
5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计是在Alpha阶段第一周由PM完成的，软工团队项目是和结对项目无缝衔接的，因此时间还算合适。
5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，比如课程id这一部分，究竟是一个递增的整数，还是教务上的课程码，这一点并没能达成一致。后来id是按照整数算的，但是又加了一个code字段，用以和爬取的资源信息进行衔接。
5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
并没有用到这些工具，测试驱动的话感觉时间不是很够，UML感觉用处也不是很大，不过单元测试在beta阶段应当尝试一下。
5.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
资源的上传，因为这里需要将文件从本地转移至服务器上，在发布之后出现的bug有“无法下载上传的文件”、“超过1M的文件上传失败”等bug。由于时间较紧，我们只进行了简单的测试，没有想到“上传的文件也可以下载”这个问题；我们文件的上传大小限制为10M，我们先后尝试了上传1M以下和10M以上的文件，前者成功后者失败，以为功能没有bug，却没有考虑到1M~10M中间可能出现的问题。
5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
团队没有统一进行代码复审，只是PM在Alpha阶段结束之后浏览了一遍核心的view.py和interface.py两个文件。其中view.py中发现了未被调用的函数，这些有的是提前开发的Beta阶段的功能，有的是Alpha阶段废掉的函数。
代码规范较严格地遵守了，python部分大部分函数都在开头用注释标注了requires，modifies和effects，前端部分也遵守了npm的代码规范（否则编译都过不了……），只是没有规定变量的命名方式，这一点没有做到统一。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计阶段是软件开发的地基，值得重视。要是能重来，除了加强代码规范外，还要对设计进行充分的考虑，尽可能完善接口和数据库说明文档。
6. 测试/发布
6.1 团队是否有一个测试计划？为什么没有？
PM并没有制定测试计划，因为当时PM认为测试是要依赖于开发的，所以更多留意了开发部分而忽视了测试部分。
6.2 是否进行了正式的验收测试？
在验收的时候，除了运行测试样例外，还进行了负载&压力测试，测试同学还提供了一些优化建议。
6.3 团队是否有测试工具来帮助测试？
功能测试使用java版本的selenium，负载测试采用jmeter和badboy实现。
6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们使用jmeter测试网站的性能，在alpha阶段后期进行了一次耗时两天的压力测试，模拟100个用户连续访问，请求响应的错误率为0，通过这次压力测试，我们了解了网站的承受能力，当然这次测试也有需要改进的地方：
-
运行压力测试时要封闭其他用户登录，开放环境下压力测试得到的最大用户量比网站是实际能承受的用户量略小。
-
只在alpha阶段快结束时进行了一次压力测试，测试的次数太少，鉴于两天的时间比较长，测试期间网站不能更新版本，今后打算每次测一两个小时，每周测一次，以追踪网站效能。beta阶段后期再进行一次较长时间的压力测试。
6.5 在发布的过程中发现了哪些意外问题？
nginx默认的文件上传限制为1M，后来通过修改配置文件解决了这个问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
除了要制定开发的计划，也要制定测试的计划，而且要增加压力测试的次数。
7. 团队的角色，管理，合作
7.1 团队的每个角色是如何确定的，是不是人尽其才？
调查了一下各个同学的意愿，最终情况是，前端是有过开发经验的两名同学，测试是一名很细心、能力很强的同学，而后端是对后端开发抱有极大兴趣的两名同学。
7.2 团队成员之间有互相帮助么？
互相帮助是经常的，比如前端的两名同学会经常讨论一些技术问题，出了bug之后大家也会很积极地寻找原因。之前Ajax出现问题的时候大家也都积极地思考解决方法，并在群里告知大家。
7.3 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
组里关系很融洽，至今没吵过架（捂脸）。有时候代码衔接出现问题或是任务分配不当的时候，成员们都就事论事，没有争吵，而是共同寻找解决的办法，这是令我很欣慰的。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要了解每一名成员，包括但不限于长处、短处、性格以及时间安排等等，分配给每一名同学最适合它的工作是坠吼的，但是做到这一点很难很难……
8. 总结
8.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得处于第一档次，因为没有一个较为完整的计划，管理经验不足，实际开发变更较多。
8.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我认为处于创造阶段，团队中所有人的努力都是为了最终产品的质量，整体氛围很和谐，为了更好地达到预期的效果，小组成员会主动学一些技术，出现问题的时候群里也会有交流。
8.3 你觉得目前最需要改进的一个方面是什么?
任务分配，Alpha阶段任务分配太模糊了，组员不知道该做什么，应当做成什么样，这是PM的责任。如果能处理好这一点，规划好要实现什么，交付的标准是什么，明确了方向组员才能投入更多的精力在开发上，而不是在揣测“我们要做什么”上。
8.4 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 无论团队内外，面对面的交流始终是最有效的沟通方式：每晚召开的Scrum Meeting上，除了汇报进度外，还会对开发中遇到的问题进行讨论，寻找解决方法。由于所有成员都住在三公寓7楼，有时候遇到问题也会直接一起商量，很方便。
- 可用的软件是衡量项目进展的主要指标：在前后端衔接的时候，关闭issue的条件是对应功能可以使用
9. 全组讨论的照片
