【Alpha阶段】M1事后报告

时间：2015-11-13 23:30

地点：七公寓一楼会议室

参与人员：窝窝头全体成员（王若愚因事请假）

设想和目标

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

“北航”Clubs旨在于解决北航校内社团管理与学生参与社团活动的困难的问题，通过构建一个校内社团发布活动or资讯的平台，使学生可以通过网站获取社团活动信息，使社团可以通过后台管理活动，群发通知。

典型用户和典型场景在之前的Alpha阶段产品功能说明书中有说明。

是否有充足的时间做计划？

有，早在项目第一周之前，就已经将项目产品设计、项目计划与项目设计安排很多，再加上第一周的项目计划时间，对于项目的各种安排已经做了充分的计划。

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

项目设计、项目技术安排等在团队计划阶段由PM指定，大家没有不同的意见。

如果历史重来一遍，我们会做什么改进

我们会将UI做的更好看

我们会将功能考虑地更全面，比如将“活动”发布流程、活动时间控制功能加强设计

计划

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

　　都做完了，因为我们第一轮迭代的目标很明确，就是要把所有的基础功能都实现。明确的目标也让我们在工作时有了方向。

2. 有没有发现你做了一些事后看来没必要或没多大价值的事?

　　没有

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

　　由于我们做的是web端，所以交付件的标准就是在网页上发生事件时能够完成相应的请求并返回正确的结果。

4. 是否项目的整个过程都按照计划进行，有什么风险是当时没有估计到的，为什么没有估计到?

　　大部分都是按照计划进行的。其中前后端数据传输中有一个难点是一开始没有估计到的，因为一开始传输数据都是header和body完全分开的，格式也都是手工的json形式，没有想那么复杂，当传输的内容对json有干扰的时候传输就无法正常进行了，但是很快就解决了这个问题。

5. 在计划中有没有留下缓冲区，缓冲区有作用么?

　　没有留下缓冲区，出现问题时大多都是熬夜紧急补救。缓冲区在大规模的项目中一定是有作用的，但是课内的而且就给这么一点时间的小项目是没有余下的时间作为缓冲区的，这也是课和实际项目的区别之一。

6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

　　尽量让计划分的更加细致明确，提前估计好每项工作的时间。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进

1.增加缓冲区的设置

设计/实现计划

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

　　设计在M1第一周前3天，由项目经验以及网站开发经验最丰富的PM江昊完成。团队认为合理。

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

TFS制定与建立任务时，存在模棱两可的情况，是项目产生无效任务的重要原因。更糟糕的是，团队也并未重视TFS任务，导致burndown图与实际有偏差。

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

设计：团队借用E-R图来对后端Model层设计进行建模处理，有效的推动了后端数据库的建立与后端dev对项目的认识。

实现：借用API文档来规范前后端接口，实现前后端交互。有效的降低了前后端工作的耦合性，提升了项目效率。

什么功能产生的Bug最多，为什么？

文章的编辑、上传和显示。

原因：功能较复杂，前后端均涉及较多，交互也较多；而技术细节也很难处理，实现时遇到了很多BUG和困难。

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

后端进行了代码复审，但并没有一套严格的流程，只是后端dev之间口头交流，粗略审查。

代码规范方面M1做的不好，开始计划时并未考虑。

如果历史重来一遍, 我们会做什么改进?

 1. 在做初期设计时，尽量的做好足够准备，避免出现大量无效任务的情况

2. 善用TFS的源代码管理或者github，少用QQ互传文件

3. 一开始对前后端的工作量预估失误，重来一遍对于前后端的分工会进行调整

4. 重视代码规范

资源

我们有足够的资源来完成各项任务么？

　　我们的资源十分充足，具体体现在我们能够在网上找到前端后端的详尽的学习资料，并且有开源的代码框架供我们使用。在服务器资源上，学校的资源和网上的资源足够我们使用。素材收集也很容易，通过百度搜索即可得到大量相关素材。

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

　　估计时间主要是通过PM来估计的，由于PM对技术细节了解得并不多，因此精度比较低，往往会出现做了任务不知道应该具体对应TFS上哪一项具体的任务。

用户测试的时间，人力和软件/硬件资源是否足够？

　　前端没有做专门测试，而后端花去了约三分之一的时间进行测试，人力、软件、硬件资源都足够。

你有没有感到你做的事情让别人来做更有效率？

　　我们的分工比较明确，大家完成得都较好，不适宜更换任务。

如果历史重来一遍, 我们会做什么改进?

1. 开始设定工作时大家一起来讨论有哪些任务来完成，具体分到每一个人头上。

2. 每周的开会更细致一点，对可能发生的意外情况提前进行预估。

变更管理

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

我们主要还是通过我们项目的qq群来传递变更的消息的，由于我们有很多人宿舍比较近，直接挂宿舍的通知也是很常见的。以及我们每周一晚上的碰头会。

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

根据我们项目的具体情况，我们首相要实现项目的基础功能。我们的项目最主要的功能大概有以下几点，活动的查看、活动发布与编辑、人员报名参加活动、社团管理活动参与人员的名单以及相关的注册登录。完成了这些功能就已经有了一个社团管理平台的样子了，这些是我们“必须实现”的功能，其余的相关的功能，就可以在beta阶段逐步的添加进来。

项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

由于我们alpha阶段做成的只有一个web端的平台，所以“做好了”的直接效果就是网页上各个功能以及排版都能够实现其应有的功能，这也是比较好测试的。页面整合后，能够通过各项的测试，这样就算是“做好了”。

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

基本没有，出现的几次应急情况都是我们的成员熬夜补救的。

员工是否能够有效地处理意料之外的工作请求？

虽然dev的一开始的经验不足，但是在经验丰富的pm的带领下，每次出现意料之外的工作请求时，pm都会提出可行的解决方案，使dev实现起来省了不少力气，而且从结果来看，意料之外的工作的处理的情况还是不错的。

如果历史重来一遍, 我们会做什么改进?

用Git，用Git，用Git，重要的事情说三遍，大家统一在一个服务器上改代码实在是太痛苦了。虽然我们尽量错开文件错开时间修改代码，但是还是出现了好多了两人修改完之后用Filezila同时上传导致覆盖了的问题，多亏当时两人修改的部分都不太多，所以还没有造成较大的影响，不过这种现状确实是要改改了！！

测试/发布

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

　　团队有明确的测试计划。后端的测试主要是编写单元测试，功能测试和压力测试。

　　前端的测试主要是场景测试和在不同浏览器及不同环境下的测试。

是否进行了正式的验收测试？

　　后端测试完成了单元测试和功能测试模块，压力测试没有实施。

　　前端测试计划均已完成，并进行了验收。

团队是否有测试工具来帮助测试？

　　后端进行测试主要使用rails自带的单元测试模块，来编写单元测试和功能测试。

　　利用Fiddler4这一工具，来测试相应的API逻辑，对传入的请求和返回的响应进行检查。

团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

　　效能测试之前我们并没有考虑，主要因为时间有限，所以只做了一些基础性的测试。向效能测试和负载测试会在Beta阶段进行，对于效能方面，　　我们团队计划通过增加服务器的数量，将逻辑计算和数据交互分开进行，进而提高服务器的响应效能。对于负载方面，我们团队打算将数据库改用MySql实现，并且将后端rails框架改进为可以并行访问。

在发布的过程中发生了哪些意外问题？

　　发布过程中遇到的主要问题是界面一些显示的bug和前端JS代码逻辑存在一些问题，导致一些按钮的功能不能正常使用。这些问题，我们都及时的做了改正。

如果历史重来一遍, 我们会做什么改进?

1.执行压力测试

2.增强用户场景测试

补充问题：

1. 对比敏捷的原则, 你觉得你们小组做得最好的是什么? 

I.保持简明——尽可能简化工作量的技艺——极为重要

通过API文档，将项目任务细化为前端与后端。

后端采用rails框架，自带MVC结构，后端三人分别去做Model层，Controller以及Router。

前端采用界面也JS代码分离开发的方式，将任务分为UI设计界面实现，界面动态化展示。

通过以上的开发模式，虽然大家是各自编码，但是各个部分之间的耦合度非常低，整合起来比较简单明了。每个人只需要专注于自己的技术领域，学习成本降低，开发效率提升。

II. 无论团队内外，面对面的交流始终是最有效的沟通方式

我们每周都有小组会议。每周例会主要议题有两个，第一个是该周目标与任务安排，第二个是介绍采用的新的技术方案or开发工具、开发方式。第一个议题，使每个队员明确自己的任务，任务明确，是一个开发人员进行开发的最大动力。第二个议题，使队员知道接下来将如何和队友合作，如何什么样的技术实现将要开发的功能。
比如，我们在讨论用户状态控制时，涉及到后端的Token存储、API调用、前端sessionStorage存储以及header传递身份信息的验证方式，将整个技术流程介绍完毕，前后端队员就理解如何更好的和对方配合了。

III. 以有进取心的人为项目核心，充分信任他们

我们团队有明确的前端负责人和后端负责人。平时遇到一些问题，PM直接和负责人沟通，负责人再和自己组内人员分工讨论。PM充分信任负责人。把任务交给他们十分方向。这样PM才有更多的时间和精力宏观规划，整体把握。如果PM总是担心任务完成情况和质量，或者总是追着每个人催促进度，那么就没有充足的精力规划项目，项目质量就会下降。

2. 什么是在下个阶段 M2 要改进的地方？

I.开发前的准备工作要更加细致，包括产品业务流程设计，结合技术实现难度考虑，确定最终的需求目标。

II.UI应该做的更加漂亮，现在的UI设计很简单，没有出彩的地方，用户体验不是很好。

III.要使用代码管理工具，进行团队协作开发。将代码管理全部放到git上。

IV.重视代码规范。前端代码没有形成统一的规范，这会对将来的进一步开发产生较大的影响。

V.前端测试机制。

VI.执行压力测试。

VII.增强用户场景测试。