这是现代软件工程作业系列的一部分
1. 团队成员介绍
介绍每个成员(照片，主页，技术特长，在团队中担任的角色)。 建议拍一张有创意的合影。 在介绍的时候，可以采用艺术照等形式， 保护同学的隐私，不想说明真实姓名的也可以用昵称。
如果投入热情和努力，这个团队作业会是你一生的精彩回忆(福州大学团队1，2，北航1， 2)。
2. 如何决定个人贡献分， 如何决定 alpha 阶段后换组
团队项目一般有 alpha 和 beta 阶段， 每个阶段都要评 “个人贡献分”。 在alpha 阶段后，我们要求每个小组选出一名同学，他/她自行寻找下一个接纳他的团队。 请和每个小组成员商量好方式并写成文字。
请看《构建之法》 17章关于绩效的部分， 小组决定如何决定每个成员的贡献分(分数是如何构成， 贡献分参考链接)
在这门课中, 大部分学生要做”真实的项目” – 有真正用户的软件。 那些 “经典” 的项目, 例如图书馆管理系统, 学生学籍管理系统等, 如果没有大量模拟用户，不练习一些实战的功能，是不符合要求的。 项目要有活的用户, 只有活的用户才有活的需求, 才有活的场景, 活的测试用例。 只有活的用户才决定同学们写的软件是否值得使用, 有些团队写的小软件很好用, 在合适的用户群中引起共鸣, 短短时间内, 就会有几千到几万个用户, 也有的团队费了老鼻子劲, 写出来的东西用户量小于10, 自己团队成员包括在内。 这些不同的用户数量会迫使项目团队反思当初在需求分析, 设计上的问题。 另外这门课并不是算法竞赛, 或者代码集中营, 大家比的不是如何快速敲打出某个算法, 而是如何在有限的时间内交付有价值的软件给特定的用户。 “真实”这一条件也促使大家做 “现实”的项目和项目管理。 很多学生有宏大的梦想, 但是在短短的 8 周团队项目时间内, 他们宏大的构想往往因为非技术的因素而轰然倒地，团队也作鸟兽散。
既然真实，就会有人员流动的问题，因为：
- 有人想去做更好的项目
- 有人愿意去尝试别的项目和角色
- 有人离开公司(退课)
- 有人和团队中的人合不来
- 有人觉得自己应该得到更多报酬 (分数，钱，股票)，不愿意在原来的团队干了
- 有人做得很差，团队觉得没有他更好...
人员流动导致“可维护性”成为一个痛点, 否则项目没法生存超过半个学期。 所以，我们在团队项目的 alpha 阶段后，强制所有团队必须有一个人离开。 这个人要自己找能接纳自己的团队(不是原团队)，经过新团队的同意，双方谈好了 责任/权利/义务/报酬，就可以在一个团队工作了。 详细分析在这里。
3. 从前人的经验中学习
采访本课程的往届同学(含外校和毕业生)。现代软件工程这门课已经上了好几年了，以前有很多学生做过团队项目(说不定包括本校的学生)，请你们找一个以前的团队采访并整理：
- 这个项目叫什么？项目网页在哪里？用多少时间，多少人力开发出来的？发布时有多少用户，给了用户什么价值？ 现在还有人用吗? 为何没有人用了？
- 使用一下这个软件(如果还有可能的话)，稍微评价一下优点和缺点。
- 调查他们的软件工程质量指标(参见《构建之法》14章 关于 “软件工程质量”的描述)，例如
-
源代码/文档还有么？测试用例的数量、测试自动化的程度、每日构建的速度、自动部署系统的效率、代码覆盖率、文档的质量，等等。
-
- 这个项目能否给我们团队继续开发，源代码/文档还有么? 如果没有，为何源代码/文档没有保存？
- 项目开发有什么经验和教训？ 为何当时没有能解决这些问题？如果你要接手开发这个软件，你会怎么做？
- 关于学好软件工程，他们对学弟学妹有什么具体的、可以实施的建议。 (不是空泛的套话)
