标签：阅读 jpg 发布 条件 mamicode 选择性 不同 图片 push
Gamma阶段原计划的密码找回功能，排名功能，移动端的适配功能等均做到了，按照时间交付了，原计划的目标用户200已经达到，目前Django后台记录的数目为243个用户。
整个团队的软件工程质量提高了，我们有WIKI来保存所有的完整文档，所有的文件均有完整的注释，并且通过Code Review，测试保证等方式确保了代码质量。
这个阶段我们确定了任务的优先级，改进了燃烬图，加了任务总量这条曲线，PM能更好地把控任务进度。因为家庭的原因，PM有段时间未在学校，如果重来一遍的话，PM应该会更加注重进度的把控，随时push团队成员。
我们在每个阶段的末尾都会提前讨论下一阶段的任务，在阶段的开始又会再次确定好阶段任务，因此是有充足的时间来确定计划的。
我们都是当面讨论，讨论任务的可行性和复杂性，针对大家提出的考虑来判断是否要做这个任务。
都做完了，只是部分任务的完成度没有太高，因为时间还是有一定的不足。
前端的分页功能，实现起来太过于复杂，总是出问题，其实现在觉得让后端分页更简单。
有。每个任务都确定了优先级以及相关人员。
基本按照计划进行。安全性问题在Alpha初期没有考虑到，准备添加在Beta阶段任务中，但是在Alpha阶段末尾网站突然被攻击，因而采取了一定的紧急措施，恢复了网站的正常功能，避免了再次被攻击。
留下了一定的缓冲区。任务执行时出现突发情况时，缓冲区就能够避免任务总体进度出问题。
完成所有基本功能的资源足够，但是在完成一些比较麻烦的功能例如移动端适配的时候，时间不太足够因而不太完美。
主要是由开发和测试人员依据Alpha，beta的经验来估计，精度比较准确。
资源足够，对移动端的适配低估了难度。
我们组变更管理部分做的比较好，我们主要通过微信群进行交流，因此项目任务有变更时团队成员很快就能获知。
我们使用了自己设计的燃尽图，其中有一项是当前任务总数，PM能抓住重点，及时判断任务能否完成，进而将下一阶段的任务提前或者砍掉某个任务。当某阶段任务稳定并且全部完成后，就达到了该阶段的出口条件。
我们有一定的应急计划，比如我们在网站受到攻击时，应急修复，在1.5小时就让网站成功重新上线，尽可能减少了用户的损失。团队对于这类意料之外的任务处理起来也比较顺利，队员能主动认领，有效处理。
后端的设计工作是在后端的线上会议的时候敲定的。设计由后端的两位同学，结合项目具体情况，共同拟定。前端的设计工作是由UI和前端开发成员你一起决定的。
在设计中，我们遇到了这样的情况。比如，原项目中，并没有采取前后端分离的设计方式，而是由后端全部完成，返回html给前端。我们在发现了这个设计之后，经过讨论，觉得不符合我们的项目设计。决定更改整体的设计。
后端的代码复审，通常是一位后端的开发在完成了自己的任务后，通过issue或者即使通讯软件的形式，联系另一位后端开发同学，通知他开发已经完成。再交付测试同学之前，另一开发同学需要阅读实现了的代码，结合已经拟定好的后端接口文档，以及代码的规范要求，对于代码的功能已经标准性进行复查。如果遇到不合规范的情况，会在issue以及即时通讯工具中提醒，要求开发人员进行更改。
团队有完整的测试计划。也有测试工具，并且进行了验收
没有考虑到测试样例执行速度的问题，虽然是放着跑一下就完事了，但会占着那么久电脑，而且每次跑都要跑那么久确实是个问题。
测试样例的管理问题，虽然我当初的理想是使用tag进行管理。但事实上对上百个样例使用tag来进行管理真的是个折磨。一套更方便的管理系统可能更好，这有助于在测试样例执行速度无法提升的情况下选择性地进行测试。
对需求变更的即时响应问题，虽然我使用了page object方便了同类测试样例的批发式编写，但问题是当page本身发生变更时，我的即时响应方面，虽然工作量不大，但存在较高的抽象复杂度。因为我和前端那边对页面的抽象方式不同，所以每次他们修改我都要想想怎么适配成我这边的逻辑。手工工作量是减少了，但思维工作量增加了。
团队目前的磨合非常不错，处于“创造”阶段。整个Gamma阶段，在PM因特别原因的缺席下，也能不延期地完成所有任务。同时团队成员也注重了软件工程的质量等，对安全性测试，兼容性测试，以及使用自动化测试工具等都非常熟练，相比起Alpha阶段和Beta阶段来说，我们组已经成为一个相对“成熟”的软件工程团队~
标签：阅读 jpg 发布 条件 mamicode 选择性 不同 图片 push
原文地址：https://www.cnblogs.com/tbqjxjkwg/p/11079843.html
