格式描述
- 这个作业属于哪个课程：软件工程实践
- 这个作业要求在哪里：(https://edu.cnblogs.com/campus/fzu/SoftwareEngineering1916W/homework/3316)
- 学号：221600432
- 这个作业的目标：软件工程实践总结
一、请回望开学初的第一次作业，你对于软件工程课程的想象
（1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
通过学习这门课程，确实提高自己的代码能力以及经历了完成项目工程的各个流程，明白了代码规范对团队合作的重要性，以及提高了项目中抗压与心态调整能力。不足是知识量和实践能力还远远不足，自己统筹安排一个项目的能力与执行力、知识还有所不足。
（2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
- 统计一下，你在这门软件工程实践中，完成了多少行的代码；
通过学习这门课程，确实提高自己的代码能力以及经历了完成项目工程的各个流程，明白了代码规范对团队合作的重要性，以及提高了项目中抗压与心态调整能力。不足是知识量和实践能力还远远不足，自己统筹安排一个项目的能力与执行力、知识还有所不足。 - 软工实践的各次作业分别花了多少时间？（做一个列表）
| 序号 | 作业 | 时间（h） |
|---|---|---|
| 1 | 个人作业第一次—准备篇 | 4 |
| 2 | 结对作业第一次—原型设计（文献摘要热词统计） | 16 |
| 3 | 结对作业第二次—文献摘要热词统计及进阶需求 | 24 |
| 4 | 团队作业第一次—团队展示 | 3 |
| 5 | 团队作业第二次—项目选题报告 | 12 |
| 6 | 团队作业第三次—项目原型设计 | 12 |
| 7 | 团队作业第四次—项目需求分析 | 8 |
| 8 | 团队作业第五次—项目系统设计与《》数据库设计 | 13 |
| 9 | 团队作业第六次—团队Github实战训练 | 17 |
| 10 | 团队作业第七次—项目Alpha冲刺 | 37 |
| 11 | 团队作业第八次—事后诸葛亮 | 3.5 |
| 12 | 团队作业第九次—项目Beta冲刺 | 35 |
| 13 | 团队作业第十次—Beta阶段团队项目互评 | 5 |
| 14 | 个人作业第二次—软件工程实践总结作业 | 5 |
-
哪一次作业让你印象最深刻？为什么？
github实训，因为这是一个短时间，相当考验团队合作，特别是组长的任务分配组织力和执行力，这点我还做的相当欠缺，那次也是几乎全天思考工作，所以我印象深刻。 -
累计花了多少个小时在软工实践上？平均每周花多少个小时？
应该有200+小时 平均每周花20个小时 -
学习和使用的新软件和工具；
墨刀 gitkraken Staruml -
学习和掌握的新语言、新平台；
unity的网络知识等，markdown，github -
学习和掌握的新方法；
vs2017单元测试的方法
unity单元测试的方法
阅读官方文档寻求帮助 -
其他方面的提升。
了解了软件工程的整个流程，明白打代码并不是软件工程的全部。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
1、组长并不老是帮助组员解决的问题的存在，而是更倾向于培养组员的思考能力，同时要保证自己在项目中的步伐，不能过度劳累操心，相信组员的工作，这样才能保持良好的心态，轻装上阵，一步一步，有条不紊。在github实训中就是自己没放松心态，身心俱疲，影响了自己的工作效率
2、需求分析是可以说是一个项目成功的基石。
3、团队之间的沟通交流非常重要的，每个人擅长的都不一样，要根据各人的能力和特性进行任务的分配，否则就会出现任务完不成需要别人收尾的情况。阿尔法阶段和github阶段我们就在任务人员交换上浪费多余的时间。
4、团队要严格遵守代码标准注释规范，不然就不容易整合代码，也不容易看，在github团队项目实训时就因为忙乱未注释，增加不少阅读难度，为后面时间来不及埋下伏笔。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
1.团队中交流是很核心的一部分，同时也能带动团队的积极性
对中途换队员的看法
2.换队员首先我觉得可以增加有一个自愿推荐
的环节，就是各组队员有自愿的优先，这样某种方面比较符合现实跳槽或离队的情况，也能提升部分接受度，然后也可以让其他团队给出自己项目需要的语言技能，进行统一整合，提高换队员时技能配合度
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建之法》第17章 人、绩效和职业道德）
萌芽阶段:
在初选题的时，大家之前都未有进行进行完整项目开发的经历，大部分人忙着自己学习游戏开发的知识，百废待兴。
磨合阶段:
我们小组较长时间处于磨合状态，一方面大部分人还是刚入门unity的状态，布置任务下去往往需要花费较长的时间去完成，如何安排找找安排合适的任务，提前学习，不做因为有太大困难而让其他人来接手而浪费一定的效率是我当时主要考虑的问题。各组员此时还处于待磨合的齿轮状态，转动起来磕磕碰碰，无法连贯。
规范阶段:
在后期贝塔阶段，我认为我们团队一部分跨入了规范的门槛，新组员的积极的融入，一定程度上带动各组员的的经济性，团队成员互相帮助，有问题时也互相依赖而不是自己埋头苦干，同时个人也能相对独立的进行自己的工作
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
我们的项目小人大作战已经在阿尔法阶段发布在：https://www.cnblogs.com/beifengtuanzi/p/10886779.html，在用户的试玩后收集意见，再迭代开发
用户建议
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
经历了原型设计，需求分析，系统设计和数据库设计，并在开发出可运行的版本后，发布给用户进行
试玩，经过试用一段时期，即可根据用户意见，对该原型系统加以修改或扩充。
游戏初期设定与需求分析
在项目中团队合作中依靠燃尽图显示项目流程。
项目分工
和git的issue模块进行项目管理和规划
3）并且通过数据展现软件是可以维护和继续发展的。
不过暂未经历新人完全通过文档，不需要他人来完成项目的过程，这些文档还有不足缺漏和改进的地方