一、请回望开学时的第一次作业，你对于软件工程课程的想象
对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
期待和目标：增加项目经验，提高自学能力，提升技术水平和职业技能。经过此次的经验，确实增加了项目经验和自学能力，技术水平某些方面经过练习确实提高了
存在的不足：团队沟通能力还有所欠缺
原因：与团队成员的交流还不够多，出现问题跟成员沟通的不够及时，自身沟通交流的水平还有待提升
|
总结这门课程的实践总结和给你带来的提升，包括以下内容：
1）统计一下，你在这门课程中，完成了多少行的代码；
2）软工的各次作业分别花了多少时间？（做一个列表）
| 作业 |
写博客时间 |
写博客的准备时间 |
| 软工网络15个人阅读作业1 |
3小时 |
2小时 |
| 软工网络15个人阅读作业2——提问题 |
2小时 |
4小时 |
| 软工网络15结对编程练习 |
2小时 |
10小时 |
| 软工网络15团队作业1——团队组队&展示 |
0.5小时 |
4小时 |
| 软工网络15个人作业3——案例分析 |
3小时 |
3小时 |
| 团队作业3——需求分析与设计 |
1小时 |
3小时 |
| 团队作业2——团队计划 |
1小时 |
10小时 |
| 软工网络15Alpha阶段敏捷冲刺 |
1小时 |
一周 |
| 团队作业6——展示博客 |
1小时 |
3小时 |
| 团队作业5——测试与发布 |
1小时 |
3小时 |
| 团队作业7——alpha阶段之事后诸葛亮分析 |
1小时 |
2.5小时 |
| 个人作业4——alpha阶段个人总结 |
2.5小时 |
3小时 |
| 团队作业8——敏捷冲刺（Beta阶段） |
3小时 |
一周 |
| beta版验收互评 |
0.2小时 |
1小时 |
| 个人作业5——软工个人总结 |
2小时 |
0小时 |
3）哪一次作业让你印象最深刻？为什么？ 原因3分
|
两次提问题吧。因为真的太难找了，也不能硬编，五个问题还是花了较多的时间，包括在网上寻找问题的相关经验知识来补充。后来回答问题的时候，发现经过开发和再思索，有的问题也没有那么困惑。
|
4）累计花了多少个小时在软工上？平均每周花多少个小时？
5）学习和使用的新软件；
6）学习和使用的新工具；
|
junit单元测试，jprofile代码覆盖率检测，git，原型设计工具
|
7）学习和掌握的新语言、新平台；
|
servlet，微信小程序开发语言wxml,wxss,js等
|
8）学习和掌握的新方法；
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
|
结对实践中，如果是修改原有项目的源代码要先对他们的代码整体结构了解透彻，再一起做一个完善功能的模块设计，不破坏原来的结构或模块，利用好原来的接口。
团队项目做时间规划的时候要考虑好风险。比如技术不足的风险还有突发的比如某一成员有急事得暂停一天的时候怎么办。
其他比较重要的就是熟悉使用git，避免出现问题
|
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。对于换人机制，有什么样的建议？
|
对于开学初的我，建议多花时间学习和掌握一门语言，多做些项目，学好数据结构和算法。
对下一届实践的建议：平衡好其他科目与软件工程的时间，早点做项目前准备，比如需要的语言那些，规划好任务和时间
对后来人的期许：做出一款持久有质量的软件
对于换人机制：还是希望可以选择换不换人，团队合作默契的话没必要换人
|
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？
|
<<构建之法>>提到的团队发展包括有萌芽阶段，磨合阶段，规范阶段和创造阶段。这几个阶段我们在团队开发过程中都经历了，初期团队有共同的期待，经过制定软件的开发规划，进行需求分析，功能划分，有了一致的目标。磨合阶段，我们经历的时间比较快，因为彼此较为熟悉出现问题也会一起去讨论寻找解决办法，再做进一步调整，彼此的信任逐渐加强。到了Beta阶段的开发，有了Alpha阶段的经验，有了更清晰的职责划分，流程也比较熟悉了，就进入了规范阶段。最后团队到达创造阶段，各个成员各司其职，各尽其责，共同合作完成了一款软件。
|
（参考《构建执法》第17章 人、绩效和职业道德）
五、怎样证明你学会了软件工程？
1.研发出符合用户需求的软件
- 必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
我们开发的小程序的用户有140个左右并且有递增的趋势
2.通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
- 有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
|
通过博客记录了项目的规划，需求，设计与发布整个过程。前期对任务做好WBS分解，敏捷开发过程中每日立会上了解各成员的开发进度。冲刺阶段利用燃尽图对开发进度有一个直观的表示。
|
团队博客地址：http://www.cnblogs.com/net15/
3.并且通过数据展现软件是可以维护和继续发展的。
- 而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
|
我们的软件开源源码利用码云管理。他人可通过readme文档了解此项目的界面，各项功能，采用的架构语言等，然后使用代码仓库同步代码，学习使用或改善软件。
|
码云链接：https://gitee.com/zyjjj/babaka
