Alpha阶段展示报告

一、团队成员简介与个人博客地址

江昊，项目经理
http://www.cnblogs.com/haoj/

王开，后端开发
http://www.cnblogs.com/wk1216123/

王春阳，后端开发
http://www.cnblogs.com/wcysoftware/

杨墨犁，前端开发（UI）
http://www.cnblogs.com/pikali/

徐丞，后端开发
http://www.cnblogs.com/ericxuc/

付帅，前端开发
http://www.cnblogs.com/fusluv/

王若愚，前端开发
http://www.cnblogs.com/ruoyuwang/

团队博客地址：http://www.cnblogs.com/wowotoubuaa/

二、软件工程展示

一）团队项目目标：
实现一个为北航社团提供社团管理服务，为学生提供社团活动资讯的网站

预期的典型用户：
1.社团管理者小A，通过“北航Clubs”社团后台，创建与发布活动资讯，在收集活动报名同学信息后，进行群发Email及短信操作。
2.学生小C，通过“北航Clubs”网站，浏览近期社团活动并报名，报名后收到社团管理者小A发来的活动信息。

预期功能描述：
服务社团的功能包括，登陆、活动发布、活动编辑、活动删除、查看活动报名名单、向活动报名者发送Email邮件及短信。
面向学生的功能包括，注册、登陆、活动信息浏览、活动报名。活动报名后可以收到社团发送的相关邮件及短信。

二）用户需求
（结合现场展示，让用户去操作）

　　1. 学生用户：注册，登录，浏览活动详情，报名活动

2. 社团用户：登录，查看/编辑/删除目前已发活动，创建新活动，查看/删除活动名单，对名单内人员发送email及短信

三）软件用户量

学生注册用户：57

社团注册用户：3

四）团队合作

分工协作：

分工

Member	角色	分工
江昊	PM	负责统筹整体开发流程，及时调整需求以及监督进度
杨墨犁	DEV	负责UI和界面开发
付帅	DEV	负责实现前端的动态展示
王若愚	DEV	负责实现前端的动态展示
王开	DEV	负责数据库模型建立、控制器以及邮箱功能实现
王春阳	DEV	负责API文档、路由以及控制器实现
徐丞	DEV&TEST	负责数据库模型建立、单元测试以及控制器实现

协作：前后端通过后端制定的API文档进行统一交互；前后端内部则继续细分任务，其中前端的动态展示以及后端的Model层实现均采取了结对编程的方式，来保证项目的完成效率与正确性。

经验教训：

经验之谈

1.软件架构设计提高开发效率

在进行开发前，我们制定了API文档，规定了API各项参数与细节，使得前端后端可以完全独立开发，互相不受干扰与影响，专注于自己的技术领域，学习成本降低，开发效率提升。

2.任务的细化可以让每个队员都贡献力量

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

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

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

于是任务以比较平均的方式细化到每个人身上，为每个人设计了自己的关注焦点，调动起团队的力量。

3.要有一个不写代码，专门解决问题的人

这个人就是PM。PM的职责不单单是设计项目技术方案，推动前后端进展，督促节点任务完成保证项目进度，还有为可能的技术难题做“预热”，提前查询技术难题的解决方案，做到心中有数，保证大方面上项目技术路线的可行性。

4.每周例会，不是形式

每周的例会推动项目不断进展。每次到周会前，项目都会“进展神速”，实现本周要求的任务。

每周例会主要议题有两个，第一个是该周目标与任务安排，第二个是介绍采用的新的技术方案or开发工具、开发方式。第一个议题，使每个队员明确自己的任务，任务明确，是一个开发人员进行开发的最大动力。第二个议题，使队员知道接下来将如何和队友合作，如何什么样的技术实现将要开发的功能。

比如，我们在讨论用户状态控制时，涉及到后端的Token存储、API调用、前端sessionStorage存储以及header传递身份信息的验证方式，将整个技术流程介绍完毕，前后端队员就理解如何更好的和对方配合了。

教训之谈：

1.API文档要保证最新且真实可用

作为最重要的团队文档，API文档应该被精心维护，有动态更新应及时告知队友。

团队开发中，比较浪费效率的一次就是后端更改了API的一个参数，没有及时更新API文档，导致前端开发队员苦调半天而无果。

2.前端重于后端

一开始，项目侧重于后端，因为数据的存储、API的提供、服务器环境的配置直接关系到项目能否顺利进行，因而比较看重。然而真正开发两周后，却发现，后端重要归重要，在一定规模层级之内，后端的开发也是最轻松的。

相比而言，前端开发才真是叫苦不迭，界面绘制已经很坑了，前端JavaScript代码更是难于编写与维护，因为写JS代码涉及到方方面面的相关知识！而且，前端不好看，对项目的用户体验、展示效果都是致命伤。所以在一轮迭代开发后期，项目侧重点是偏向了前端的。而如果一开始就能对这样的情况有所了解，我们会少走很多弯路。

五）团队如何平衡时间/质量/资源争取如期完成任务的

团队整体：PM发挥PM的作用，面对每天的时间，找到优先级，作出判断与分工。团队通过每天的scrum meeting进行总结，对项目安排进行相应调整

前后端开发各自内部：通过个人能力与时间等依据，每天制定计划分工与目标任务。

六）代码工程质量及数据证明

团队代码的软件工程质量：

关于测试：本次项目单元测试总共有24个，包括单元测试与功能测试，代码覆盖率为92%。测试用例的编写使用的是rails自带的单元测试框架，同时使用fiddler4脚本测试所有的API是否能正确执行。

目前存在的尚待解决bug:

在进入网站页面时，页面有时会出现卡顿的情况

2. 由于登陆时没有做数据验证，所以一些非法的注册信息也可以注册成功

3. 在不同的浏览器或者不同大小的屏幕上可能会出现布局的问题

代码规范：由于rails本身对代码的规范有许多默认的约定，比如变量，常量的命名，路由，控制器，模型的命名等都有一套默认的规范，我们在进行后端的编写时遵从了rails本身默认的这些约定。并且，对api格式的规范还有注释的要求进行了统一规定。

关于文档：具体的文档已经发布在窝窝头的团队博客中了，包括后端设计文档，需求分析文档，api设计文档

三团队项目的进展过程

开发期第一天：（均在学习，进展缓慢）

第二天（开始具体设计实现，进度加快）

第四天（进度明显减缓，前后端都进入到深度学习阶段）

第八天（进度稳定，前后端开发均在进行，但已经产生无效任务不知如何处理的情况）

第九天（后端进入测试修改阶段，但因为无效任务以及新增任务的影响，燃尽图已与实际情况有出入）

迭代末期（之前无效任务只能在此时更新，造成后期曲线急速下降，但后期实际上项目进入调试阶段，进度一直很平稳）

总结：

scrum在大致上反映了我们的项目进度趋势：前慢后快——前面处于学习阶段，学习成本导致进度迟缓，后期明显提速。

但因为项目开始前存在制定的无效任务，外加对TFS与backlogs相关的操作不熟悉，造成曲线与实际仍然有相当偏差。主要体现在无效任务未及时清理，当项目进行过程中产生新任务时并未及时添加，以及成员并未按时更新任务进度。

所有功能及最出众功能介绍，用户如何受益：

http://www.cnblogs.com/wowotoubuaa/p/4971388.html

四团队成员在M1 的角色和具体贡献

Member	角色	具体的, 可衡量的, 可验证的贡献
江昊	PM	负责统筹整体开发流程，及时调整需求以及监督进度
杨墨犁	DEV	2500行代码，负责UI和界面开发，scrum发布
付帅	DEV	1000行代码，负责实现前端的动态展示
王若愚	DEV	1000行代码，负责实现前端的动态展示
王开	DEV	400行代码，负责数据库模型建立、控制器以及邮箱功能实现，所有文档的审核
王春阳	DEV	400行代码，负责API文档、路由以及控制器实现，燃尽图管理
徐丞	DEV&TEST	800行代码，负责数据库模型建立、单元测试以及控制器实现

五团队从用户那里得到了什么反馈，有什么样的bug？这是预料之中的还是没想到的？

如果现场评审成员发现了bug，但是我们项目小组的测试人员并没有发现这样的bug，那么对每一个bug，这个团队的成绩扣掉10分，扣到0 分后，继续扣，团队项目得分可以为负分。

7) 总结，整个团队在Alpha阶段学到了什么，对软件工程的教育，对这个具体的课程有什么批评建议？

http://www.cnblogs.com/wowotoubuaa/p/4971388.html