一、团队成员简介与个人博客地址
江昊，项目经理
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相关的操作不熟悉，造成曲线与实际仍然有相当偏差。主要体现在无效任务未及时清理，当项目进行过程中产生新任务时并未及时添加，以及成员并未按时更新任务进度。
所有功能及最出众功能介绍，用户如何受益：
四 团队成员在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阶段学到了什么，对，对这个具体的课程有什么批评建议？