Section 1:团队组建
1、队员姓名与学号
队长： 方慧琳 2016012098
队员： 王璐瑶 2016012095
队员： 曹 滢 2016012102
队员： 许征航 2016012096
队员： 王超超 2016012030
2、队名：客官来点啥？
3、团队项目名描述：
拟制作一个随机决定吃什么的软件。
用户可选择快餐，面食等类别或者不选择类别，使用按钮随机决定吃什么。
使用过后，用户可以选择 “顶，一般，踩” 功能使得该店出现的概率随之变化。
4、队员风采：
方慧琳：
风格：统筹策划，踏实负责
擅长的技术：Java，bootstrap，ssm
编程的兴趣：功能设计，web后端
希望的软工角色：PM
一句话宣言：真正危险的不是计算机开始像人那样去思考，而是人类开始像计算机一样思考。
王璐瑶：
风格：勤于动手，勇于实践
擅长的技术：C/C++编程开发，数据结构，C51编程开发。
编程的兴趣：AC or program runs successfully。
希望的软工角色：团队算法设计以及坚定的行动者。
一句话宣言：无限的0与1组成独特的征程
曹 滢：
风格：虚心请教，认真学习。
擅长技术：HTML、css、jquary、js。
编程的兴趣：web前端开发。
希望的软工角色：前端开发的编程角色。
一句话宣言：努力是最好的幸运。
许征航：
风格：踏实认真，谦虚谨慎。
擅长的技术：C/C++编程开发，算法分析与设计，图论，数据结构。
编程的兴趣：可以坐在电脑前敲一天的代码。
希望的软工角色：团队的算法设计与开发，行动者，听领导指挥。
一句话宣言：用更短的代码，用更少的时间，做更优秀的事。
王超超：
风格：认真，专注。
擅长的技术：JAVA，数据结构。
编程的兴趣：了解更多编程知识。
希望的软工角色：行动者，听领导指挥。
一句话宣言：用较少的时间完成自己的任务。
5、团队的首次合照
（拍摄者：王超超）
照片介绍：在这张照片中，小队成员每人手持筷子，或喜或愁，正如我们的项目——“E-What”，是要为用户解决选择困难症的，有自己独特的风格。同时贴切主题。
6、团队的特色描述
头脑风暴，团结活泼，踏实勤奋。
Section 2:团队选题
1、项目概述及意义
“人生每天三大问：早上吃什么，中午吃什么，晚上吃什么。”这句话在半个月前的朋友圈和空间着实火了一把，在我们身边，有这样一部分人，他们有着一定的选择困难症，不知道自己每顿饭应该吃什么。这本不是什么大事，但是单独提出来就觉得确实是一件事。所以我们小组希望做出一个能够推荐每天饮食的小项目，用以记录用户的每日膳食并做出一种基于用户喜好的饮食推荐。
针对如此，我们小组还在身边做了随机抽样的小调查，在近百份抽样结果中，有百分之四十六的人表示，自己不知道每天吃什么，有百分之十八的人表示会在食堂窗口犹豫好久才能决定，有百分之三十六的人表示自己明确知道自己想吃什么，并不会犹豫。而当我们将我们将我们的项目构思告诉他们时，有百分之六十五的表示对这个项目有着一定的兴趣，并愿意尝试我们的项目。
2、NABCD分析
N、(Need)需求方面：
我们的目标受众是对于自己饮食没有明确的意向的在校大学生，用以解决或缓解他们在饮食上的犹豫问题。
A、(Approach)做法方面：
我们选择对用户每日餐饮习惯做出统计，之后对其对饮食的满意程度进行加权记录，之后通过权值随机推荐每日饮食。
B、(Benefit)好处方面：
我们的项目意在缓解大学生在饮食上的选择困难体现，即犹豫表现，并且通过初步的101份统计调查得知身边确实存在如此现象，而受众也愿意尝试我
们的项目，所以我们认为是值得一试的。
C、(Competitors)竞争方面：
因为我们的主要受众是在校大学生，而在校大学生中，目前还恰恰缺少着这样一款软件，用于个人需求。所以我们认为我们的竞争压力较小，主要压力
在于如何更好地满足用户需求。
D、(Delivery)交付方面：
我们可以在自己学校，自己学院优先进行推广试用，也可以通过在食堂发放宣传单、二维码的方式进行推广，由小到大，由专及广地进行推广。
3、编程语言
在编程语言方面，我们选择java作为我们的开发语言，小组内成员各有所长分工明确，有着专门的前端后台开发人员，算法设 计人员，运营人员。在技能方面，每个人的熟悉程度为
方慧琳：java、mybatis、SpringMVC、数据库------------9
王璐瑶：C/C++、java、C51-----------------------------------9
曹滢：html、css、jquary、javascript------------------------9
许征航：C/C++、java、DP、数据结构----------------------10
王超超：java、mybatis、SpringMVC、数据库------------7
section 3 贡献分配
我们团队的每个成员在仔细看过“(Alpha)Let's-Chronos分数分配规则”以及“【Alpha】团队贡献分配计划”这两篇博客后，在第一次讨论会上决定综合两个规则的长处制定一份适合我们团队的贡献评定制度。
邹欣老师提到的评分方式简言之是：分数=贡献百分比+任务完成好坏，其实这个评分方式出发点是正确的，评分角度也是恰当的，但是问题有这么两个：一是如何界定贡献的多少，因为贡献这个范围比较大，包括项目内和项目外；二是任务完成好坏由谁来评定、怎么评定。
“(Alpha)Let's-Chronos分数分配规则”这篇博客是针对邹欣老师的评分方式提出异议、做出改进的；而“【Alpha】团队贡献分配计划”这篇博客是针对OKR制度做出的评分方式，即“分数=80%的关键成果评分+20%的工作时长评分”。虽然两篇博客都各自陈述了两种评分方式的优点，但在我们团队看来两种方式都有不足之处。第一种方式罗列的细则很详尽，也给出了比分算式，但是并没有说这些细则由谁来规定优劣之分以及等级高低；第二种方式工作时长占的比重又太重，倘若队友是一个拖沓（厉害）之人，拉低（提高）效率的同时也延长（减少）了项目完成时间，这就给了对方一个可趁之机，对其他人显得不公平。所以综合两种评分方式，我们团队给出了这样的评分准则：
分数=项目内外的贡献20分+工作效率10分+完成任务的效果20分
（互评三项后总分数取平均值，平均值舍去小数点后的值；若同分，则由所有成员投票评判谁更优；所有人分数的总和为50*N，其中N为团队的人数5人。）
1、项目内外的贡献20分说明
包含项目代码实现外的开发前好的主意5分、个人参与的积极性5分，项目代码实现内的开发过程中的帮助其他成员5分、个人为项目代码实现的贡献5分。
2、工作效率10分说明
工作效率为关键成果比上工作时长。
3、完成任务的效果20分
包括代码的运行无误程度10分、代码实现效果10分再减去总项目因此调bug数2分/次。
以下是个人评分表样式：
|
XX评分表 |
||||
|
项目内外贡献 |
开发前好的主意 |
满分5分 |
打分 |
|
|
个人参与的积极性 |
满分5分 |
打分 |
|
|
|
开发过程中的帮助其他成员 |
满分5分 |
打分 |
|
|
|
个人为项目代码实现的贡献 |
满分5分 |
打分 |
|
|
|
工作效率 |
关键成果比上工作时长 |
满分10分 |
打分 |
|
|
完成任务效果 |
代码运行无误程度 |
满分10分 |
打分 |
|
|
代码实现效果 |
满分10分 |
打分 |
|
|
|
项目因此调bug数 |
扣分2分一次 |
打分 |
|
|
|
总分 |
|
|||
|
平均分 |
|
|||
我们团队经过讨论给出以上贡献评分规则。分数是衡量团队成员工作的指标，合理的团队贡献分制有助于完成工作。最终换人时，我们团队也将根据分数高低换掉分最低者。