团队作业1——团队展示
团队展示：
a.队名: wt.dll
b.队员学号：
201421123062 林 燕
201421123083 王李焕
201421123084 林至贤
201421123085 童毅南
201421123088 代泽旭 (队长)
c.拟作的团队项目描述：基于微信公众平台的课堂点名系统
d.队员风采：
代泽旭：擅长C#、C++等多门语言，拥有超乎常人的带头冲锋能力，有信心带领我们团队走向巅峰。
林至贤：擅长JAVA，C++等，为人谦虚谨慎，做事低调，有着崇高的艺术追求，对编程有着一定的自我理解。
王李焕：擅长JAVA、C++等语言编程，对网页制作也有一定了解，对编程有着浓厚的兴趣。
童毅南：擅长前端开发，有着多年的前端实战经验，勤奋好学，人称前端小王子，此称号响彻五号楼
林 燕：有着较突出的编程能力，擅长根据我们所要开发的项目分析用户需求和功能需求，统筹规划能力较强，善于举一反三，有着极强的学习能力。
e.人员分工：
一：前期调查与准备：林燕、林至贤
二：程序前端：林燕 、童毅南
三： 程序后端：代泽旭、林至贤、王李焕
四：程序调试：代泽旭、童毅南、林至贤、王李焕
- 团队的首次合照（有图有真相，合照风格可以发挥创意）；（待更新）
-
团队的特色描述，主要描述有别于其他所有团队的特点或核心竞争力，言简意赅。
团队成员自信阳光，积极向上，团员间有多次合作基础，培养了较好的默契。
团队码市地址：https://coding.net/u/lzx84/p/Signin/git
选题要求：
- 确立团队选题，确定之后每个团队需要写描述要做的究竟是什么系统，预期的用户量是多少。
随着信息技术的发展， 互联网+的时代来临， 智能手机在学生中的普及度很高，生活学习的方式也有所改变。传统的课堂签到方式费时费力，影响课堂效率，并且可能有所遗漏。因此部分高校里出现了各种各样的教学和管理系统， 如IC卡考勤系统、指纹考勤系统 、人脸识别系统、 、基于Android的课堂签到系统等，这些考勤系统不是硬件要求高，就是开发成本高。此时基于微信app的light app 的优势就体现出来。
为了帮助老师上课点名，避免学生带代点名以及未签到等问题，我们小组决定做一个基于微信的点名系统，前期会学习一些关于微信的编程，了解各个功能在微信上如何实现，讨论每个人的具体分工和团队之间的合作，做出相关调查，了解已经存在的点名系统的有点和缺点，取长补短综合考虑。
2. 围绕选题项目内容的 真实、可用、有价值（有情怀 作为加分项）目标来分别阐述。
目前校园对学生的上课出勤管理，基本上都是靠人为的点名。而都是采用企事业单位对员工的考勤管理，也只是采用传统的打卡、指纹识别等被动考勤制度。而这种考勤方式，往往会因为一些客观的条件限制，导致一定的不公平。我们渐渐发现，现在的考勤系统已经不能满足人们的各种需求了，原因如下：
（1）现在物理签到系统，布线麻烦、施工工期长、网络不稳定、系统总费用高昂、后期网络维护和更改困难。
（2）系统功能单一，需要安装考勤系统、数据采集系统、工控监测几套系统，才能满足考勤门禁收费、生产数据采集、生产设备监测等需要。
（3）系统不灵活，需要提交到系统制造商哪里进行个性化定制，造成系统更改困难，浪费时间与劳动力。
为了弥补以上缺陷，我们决定开发一个基于微信平台，利用WIFI考勤的系统。WIFI无线实时考勤系统具有强大的兼容性和扩展性，实现动态考勤，让考勤更加智能、更人性。
本项目的特色与创新点在于，客户可以通过简单的操作，就可以在我们的平台上实现考勤管理，节省了许多物理成本和人工成本。
团队计划：
根据发布的项目时间规划，初步确立团队任务计划，将团队的任务计划添加到Coding的团队项目任务里，要求：
- PM组织成员快速阅览《构建之法》第8章到第15章关于“软件开发完整生命周期”的相关章节，并回顾在词典App案例分析中初步练习过的项目计划设计的方法对项目做时间安排。同时请参考下面的团队项目每周环节进度表。
- 必须使用《构建之法》“计划和估计” 一节中提到的讨论方法和耗时估计公式来矫正计划的时间表，为每个环节定制好时间。并注意，不要贪图做太多的功能，而是要把关键的场景实现了。
| 第 6 周 | 1.团队组队、团队博客 |
|---|---|
| 2.团队介绍、成员展示、角色分配、选题确定 | |
| 3.制定团队计划安排，团队贡献分的规定 | |
| 第7周 | 1.需求规格说明书 |
| 2.原型设计，队员估计任务难度并学习必要的技术 | |
| 3.编码规范完成、平台环境搭建完成、初步架构搭建 | |
| 第8周 | 1.原型改进（给目标用户展现原型，并进一步理解需求） |
| 2.架构设计，WBS, 团队成员估计各自任务所需时间 | |
| 3.测试计划 | |
| 第9周 | 1. 团队项目Alpha任务分配计划 |
| 2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | |
| 第10周 | 1.用户反馈+测试计划改进 |
| 2. 团队Alpha阶段个人总结 | |
| 3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 | |
| 第11周 | 1. 团队项目Alpha博客：事后分析 |
| 2. 每个团队有一人必须离开，自己寻找下一个接纳自己的团队。团队发博客宣布离队和接纳的成员。 | |
| 第12周 | 1. 团队项目Beta任务分配计划，介绍新成员 |
| 2. 连续7天的Beta敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | |
| 第13周 | 1. 团队项目Beta博客：发布说明、测试报告、展示博客 |
| 2. 团队Beta阶段个人总结 | |
| 第14周 | 1. 团队项目Beta博客：事后分析， 宣布每人的贡献分 |
| 第15周 | 1.团队整个阶段总结，分析用户数据，整理文档，保证以后的团队能接手。 |
团队成员绩效评估方法
成员的绩效 = 团队获得的分数 + 个人的团队贡献分
在项目alpha 和 beta 阶段评审后， 团队会得到一个项目分数（每个成员都会得到同样的分数，做为自己的原始分数的一部分）。团队成员的努力程度不同，达成目标的程度不同，帮助同伴的付出不同，那就要在“团队贡献分” 上有所区分。 所有人贡献分的总和为 20N，其中N为团队的人数。 在alpha/beta 之后，团队按照自己制定的规则，把 （20N）瓜分给每人，这就是 “团队贡献分”。
要求：请每人阅读教材 “人、绩效和职业道德”一章，然后团队开一个讨论会，协商讨论团队贡献分的分配规则。每人得分为自然数，并且每个人分数不能相同。 请写一个团队博客详细说明每个团队的成员计划如何帮助团队完成任务，以及团队贡献分的分配规则。
要注意，有很多原因导致一个人的团队贡献分不高，alpha 阶段之后，每个团队会有一名成员离开，导致团队离开的原因也很多，未必和贡献分的高低相关。
