团队过后分析

设想和目标

咱们达到目标了么（原计划的功能作到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

Gamma阶段原计划的密码找回功能，排名功能，移动端的适配功能等均作到了，按照时间交付了，原计划的目标用户200已经达到，目前Django后台记录的数目为243个用户。

和上一个阶段相比，团队软件工程的质量提升了么？ 在什么地方有提升，具体提升了多少，如何衡量的？

整个团队的软件工程质量提升了，咱们有WIKI来保存全部的完整文档，全部的文件均有完整的注释，而且经过Code Review，测试保证等方式确保了代码质量。

有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

这个阶段咱们肯定了任务的优先级，改进了燃烬图，加了任务总量这条曲线，PM能更好地把控任务进度。由于家庭的缘由，PM有段时间未在学校，若是重来一遍的话，PM应该会更加注重进度的把控，随时push团队成员。

计划

是否有充足的时间来作计划?

咱们在每一个阶段的末尾都会提早讨论下一阶段的任务，在阶段的开始又会再次肯定好阶段任务，所以是有充足的时间来肯定计划的。

团队在计划阶段是如何解决同事们对于计划的不一样意见的？

咱们都是当面讨论，讨论任务的可行性和复杂性，针对你们提出的考虑来判断是否要作这个任务。

你原计划的工做是否最后都作完了? 若是有没作完的，为何?

都作完了，只是部分任务的完成度没有过高，由于时间仍是有必定的不足。

有没有发现你作了一些过后看来不必或没多大价值的事?

前端的分页功能，实现起来太过于复杂，老是出问题，其实如今以为让后端分页更简单。

是否每一项任务都有清楚定义和衡量的交付件?

有。每一个任务都肯定了优先级以及相关人员。

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?

基本按照计划进行。安全性问题在Alpha初期没有考虑到，准备添加在Beta阶段任务中，可是在Alpha阶段末尾网站忽然被攻击，于是采起了必定的紧急措施，恢复了网站的正常功能，避免了再次被攻击。

在计划中有没有留下缓冲区，缓冲区有做用么?

留下了必定的缓冲区。任务执行时出现突发状况时，缓冲区就可以避免任务整体进度出问题。

资源

咱们有足够的资源来完成各项任务么?

完成全部基本功能的资源足够，可是在完成一些比较麻烦的功能例如移动端适配的时候，时间不太足够于是不太完美。

各项任务所需的时间和其余资源是如何估计的，精度如何?

主要是由开发和测试人员依据Alpha，beta的经验来估计，精度比较准确。

测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?

资源足够，对移动端的适配低估了难度。

变动管理

每一个相关的员工都及时知道了变动的消息?

咱们组变动管理部分作的比较好，咱们主要经过微信群进行交流，所以项目任务有变动时团队成员很快就能获知。

咱们采用了什么办法决定“推迟”和“必须实现”的功能?

咱们使用了本身设计的燃尽图，其中有一项是当前任务总数，PM能抓住重点，及时判断任务可否完成，进而将下一阶段的任务提早或者砍掉某个任务。当某阶段任务稳定而且所有完成后，就达到了该阶段的出口条件。

对于可能的变动是否能制定应急计划?

咱们有必定的应急计划，好比咱们在网站受到攻击时，应急修复，在1.5小时就让网站成功从新上线，尽量减小了用户的损失。团队对于这类意料以外的任务处理起来也比较顺利，队员能主动认领，有效处理。

设计/实现

设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

后端的设计工做是在后端的线上会议的时候敲定的。设计由后端的两位同窗，结合项目具体状况，共同拟定。前端的设计工做是由UI和前端开发成员你一块儿决定的。

设计工做有没有碰到模棱两可的状况，团队是如何解决的？

在设计中，咱们遇到了这样的状况。好比，原项目中，并无采起先后端分离的设计方式，而是由后端所有完成，返回html给前端。咱们在发现了这个设计以后，通过讨论，以为不符合咱们的项目设计。决定更改总体的设计。

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

后端的代码复审，一般是一位后端的开发在完成了本身的任务后，经过issue或者即便通信软件的形式，联系另外一位后端开发同窗，通知他开发已经完成。再交付测试同窗以前，另外一开发同窗须要阅读实现了的代码，结合已经拟定好的后端接口文档，以及代码的规范要求，对于代码的功能已经标准性进行复查。若是遇到不合规范的状况，会在issue以及即时通信工具中提醒，要求开发人员进行更改。

测试/发布

团队是否有一个测试计划？为何没有？

团队有完整的测试计划。也有测试工具，而且进行了验收

Gamma测试工做反思

没有考虑到测试样例执行速度的问题，虽然是放着跑一下就完事了，但会占着那么久电脑，并且每次跑都要跑那么久确实是个问题。
测试样例的管理问题，虽然我当初的理想是使用tag进行管理。但事实上对上百个样例使用tag来进行管理真的是个折磨。一套更方便的管理系统可能更好，这有助于在测试样例执行速度没法提高的状况下选择性地进行测试。
对需求变动的即时响应问题，虽然我使用了page object方便了同类测试样例的批发式编写，但问题是当page自己发生变动时，个人即时响应方面，虽然工做量不大，但存在较高的抽象复杂度。由于我和前端那边对页面的抽象方式不一样，因此每次他们修改我都要想一想怎么适配成我这边的逻辑。手工工做量是减小了，但思惟工做量增长了。

总结

团队目前的磨合很是不错，处于“创造”阶段。整个Gamma阶段，在PM因特别缘由的缺席下，也能不延期地完成全部任务。同时团队成员也注重了软件工程的质量等，对安全性测试，兼容性测试，以及使用自动化测试工具等都很是熟练，相比起Alpha阶段和Beta阶段来讲，咱们组已经成为一个相对“成熟”的软件工程团队~