一、请回望开学时的第一次作业，你对于软件工程课程的想象
1.对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
-
达到的期待和目标：
毕竟做这么多人的团队任务是第一次，主要是在团队合作交流这方面有所提高，然后就是在做项目的时候，不会的东西边学边用，还是受益良多，而且虽然还不是很懂软件工程，但是从一学期的学习做项目的过程中还是可以了解开发一个项目的大致流程 -
存在的不足：
在代码开发这一方面还有待提高，感觉学了挺多东西，但是大部分都是浅尝辄止，没有深入学习
2.总结这门课程的实践总结和给你带来的提升，包括以下内容：
1）统计一下，你在这门课程中，完成了多少行的代码；
- 应该有500行以上
2）软工的各次作业分别花了多少时间？（做一个列表）
| 作业 | 花费时间(h) |
|---|---|
| 软工网络15个人阅读作业1 | 2 |
| 软工网络15结对编程练习 | 24 |
| 软工网络15个人阅读作业2——提问题 | 5 |
| 软工网络15团队作业1——团队组队&展示 | 2 |
| 软工网络15个人作业3——案例分析 | 5 |
| 团队作业2——团队计划 | 2 |
| 团队作业3——需求分析与设计 | 5 |
| 软工网络15Alpha阶段敏捷冲刺 | 60 |
| 团队作业6——展示博客 | 5 |
| alpha阶段项目复审 | 2 |
| 团队作业7——alpha阶段之事后诸葛亮分析 | 2 |
| 个人作业4——alpha阶段个人总结 | 5 |
| 团队作业8——敏捷冲刺（Beta阶段） | 40 |
| 团队作业9——项目验收与总结 | 6 |
| beta版验收互评 | 2 |
| 个人作业5——软工个人总结 | 4 |
3）哪一次作业让你印象最深刻？为什么？
- 提问题那次博客真的挺难写的，首先就要通读全书，然后自己去发现一些不懂的地方，提出质疑和自己的理解
4）累计花了多少个小时在软工上？平均每周花多少个小时？
- 大约有180小时，平均每周大约10小时
5）学习和使用的新软件；
- 码云，leango
6）学习和使用的新工具；
- 墨刀，微信web开发工具
7）学习和掌握的新语言、新平台；
- 微信小程序开发平台，js
8）学习和掌握的新方法；
- 对发现问题，解决问题的能力有所进步，还有就是大致了解了软件工程开发的大致流程
9）其他方面的提升。
- 团队协作能力的提升，遇到问题积极沟通交流
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 首先一定要在团队项目开始时规划好要做什么，做什么样的东西，不要边做边计划，不然等到好的计划出现已经回不了头了
- 然后在做任务规划的时候分工要合理，特别是对整体项目进度的估计要考虑突发因素的影响，最好在做项目时间规划时预留几天时间来应对可能发生的突发事件
- 再就是不能好高骛远，如果觉得自己的能力不高，时间不够，那就放弃一些天马行空的设想，努力做好自己可以做到的东西
- 最后就是团队项目中的沟通真的非常重要，在遇到难题或者瓶颈时，多问问身边的人或者其他成员，这比自己一个人瞎琢磨效率要高得多，而且说不定在一起讨论的过程中也解决了别人的问题
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。对于换人机制，有什么样的建议？
- 几乎每一个大一新生都会以为大学与高中相比那是天堂，我觉得在刚入学的时候可以放纵一波，但是与此同时也请竭尽所能地在欢乐的时光之余多学一些东西，总之前两年多学一些东西，后面总是不亏的，特别是编程语言这个方面，大部分人将来还是需要它的。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
- 萌芽阶段，磨合阶段，规范阶段和创造阶段。我的团队经历了萌芽阶段、磨合阶段、规范阶段和创造阶段，其中做得不好的主要是规范阶段，一直都把重心放在怎么做出一个可行的东西出来，忽略了规范这一步骤。萌芽阶段和磨合阶段在alpha阶段算是比较久的，从想法到分工合作，再到熟悉自己的项目确实花了挺长时间，最后的创造阶段就是一群不是很懂的人搞出来一个不是很懂的小程序，还是有点东西的，尽管最后实现的东西比较简单
五、怎样证明你学会了软件工程？
1.研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
- 项目小程序二维码：
2.通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
- 使用燃尽图控制项目进度：
3.并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料