标签：
设计/实现
如果历史重来一遍, 我们会做什么改进?
1. 在做初期设计时，尽量的做好足够准备，避免出现大量无效任务的情况
2. 善用TFS的源代码管理或者github，少用QQ互传文件
3. 一开始对前后端的工作量预估失误，重来一遍对于前后端的分工会进行调整
4. 重视代码规范
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计在M1第一周前3天，由项目经验以及网站开发经验最丰富的PM江昊完成。团队认为合理。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
TFS制定与建立任务时，存在模棱两可的情况，是项目产生无效任务的重要原因。更糟糕的是，团队也并未重视TFS任务，导致burndown图与实际有偏差。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
设计：团队借用E-R图来对后端Model层设计进行建模处理，有效的推动了后端数据库的建立与后端dev对项目的认识。
实现：借用API文档来规范前后端接口，实现前后端交互。有效的降低了前后端工作的耦合性，提升了项目效率。
什么功能产生的Bug最多，为什么？
文章的编辑、上传和显示。
原因：功能较复杂，前后端均涉及较多，交互也较多；而技术细节也很难处理，实现时遇到了很多BUG和困难。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
后端进行了代码复审，但并没有一套严格的流程，只是后端dev之间口头交流，粗略审查。
代码规范方面M1做的不好，开始计划时并未考虑。
资源
如果历史重来一遍, 我们会做什么改进?
1. 开始设定工作时大家一起来讨论有哪些任务来完成，具体分到每一个人头上。
2.学习前端开发的测试机制。
我们有足够的资源来完成各项任务么？
我们的资源十分充足，具体体现在我们能够在网上找到前端后端的详尽的学习资料，并且有开源的代码框架供我们使用。在服务器资源上，学校的资源和网上的资源足够我们使用。素材收集也很容易，通过百度搜索即可得到大量相关素材。
各项任务所需的时间和其他资源是如何估计的，精度如何？
估计时间主要是通过PM来估计的，由于PM对技术细节了解得并不多，因此精度比较低，往往会出现做了任务不知道应该具体对应TFS上哪一项具体的任务。
用户测试的时间，人力和软件/硬件资源是否足够？
前端没有做专门测试，而后端花去了约三分之一的时间进行测试，人力、软件、硬件资源都足够。
你有没有感到你做的事情让别人来做更有效率？
我们的分工比较明确，大家完成得都较好，不适宜更换任务。
如果历史重来一遍, 我们会做什么改进?
1. 用GITHUB来管理我们的项目进度，确保每个人得到的信息同步。
2. 每周的开会更细致一点，对可能发生的意外情况提前进行预估。
变更管理
每个相关的员工都及时知道了变更的消息?
我们主要还是通过我们项目的qq群来传递变更的消息的，由于我们有很多人宿舍比较近，直接挂宿舍的通知也是很常见的。以及我们每周一晚上的碰头会。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据我们项目的具体情况，我们首相要实现项目的基础功能。我们的项目最主要的功能大概有以下几点，活动的查看、活动发布与编辑、人员报名参加活动、社团管理活动参与人员的名单以及相关的注册登录。完成了这些功能就已经有了一个社团管理平台的样子了，这些是我们“必须实现”的功能，其余的相关的功能，就可以在beta阶段逐步的添加进来。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
由于我们alpha阶段做成的只有一个web端的平台，所以“做好了”的直接效果就是网页上各个功能以及排版都能够实现其应有的功能，这也是比较好测试的。页面整合后，能够通过各项的测试，这样就算是“做好了”。
对于可能的变更是否能制定应急计划?
基本没有，出现的几次应急情况都是我们的成员熬夜补救的。
员工是否能够有效地处理意料之外的工作请求？
虽然dev的一开始的经验不足，但是在经验丰富的pm的带领下，每次出现意料之外的工作请求时，pm都会提出可行的解决方案，使dev实现起来省了不少力气，而且从结果来看，意料之外的工作的处理的情况还是不错的。
如果历史重来一遍, 我们会做什么改进?
测试/发布
团队是否有一个测试计划？为什么没有？
团队有明确的测试计划。后端的测试主要是编写单元测试，功能测试和压力测试。
前端的测试主要是场景测试和在不同浏览器及不同环境下的测试。
是否进行了正式的验收测试？
后端测试完成了单元测试和功能测试模块，压力测试没有实施。
前端测试计划均已完成，并进行了验收。
团队是否有测试工具来帮助测试？
后端进行测试主要使用rails自带的单元测试模块，来编写单元测试和功能测试。
利用Fiddler4这一工具，来测试相应的API逻辑，对传入的请求和返回的响应进行检查。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
效能测试之前我们并没有考虑，主要因为时间有限，所以只做了一些基础性的测试。向效能测试和负载测试会在Beta阶段进行，对于效能方面， 我们团队计划通过增加服务器的数量，将逻辑计算和数据交互分开进行，进而提高服务器的响应效能。对于负载方面，我们团队打算将数据库改用 MySql实现，并且将后端rails框架改进为可以并行访问。
在发布的过程中发生了哪些意外问题？
发布过程中遇到的主要问题是界面一些显示的bug和前端JS代码逻辑存在一些问题，导致一些按钮的功能不能正常使用。这些问题，我们都及时的 做了改正。
标签：
原文地址：http://www.cnblogs.com/wowotoubuaa/p/4991272.html
