个人作业——软件工程实践总结作业

一、请回望暑假时的第一次作业，你对于软件工程课程的想象

1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

达到我的期待和目标：
a. 组队并当了组长;
b. 学到了一些安卓前端知识；
c. 沟通交流处理良好。我们小组有一半的组员是之前没有任何交集的，从互不相识到协作还算是愉快，可以说是达到了期待;
d. 团队一起完成了一个还算是蛮喜欢的软件；
不足：
a. 高估自己的能力。软件开发的过程中我是担任了PM和前端的角色，本想着应该是可以很好的兼并两种角色，但发现自己还是太天真了。事实是，在团队只有两个前端的情况下，这种角色分配对于我本身还有另一位前端队友来说，都要扛着蛮大的任务压力，比如在beta阶段，后端早早地就完成了全部的任务，但前端却还有不少的工作。确实是有点高估自己的能力了，应该要多考虑一下实际的工作量，而不能太过主观。
b. 安卓前端知识缺乏系统的学习。同样是因为上面所诉的原因，我没有什么时间对前端的知识进行系统学习，而是采用速成的方式，需要什么功能的时候，进行针对该功能的知识恶补，这样虽然勉强可以完成功能，但其实只有自己知道，自己的知识网络还是破烂不堪的，经常因为一些很基本的问题卡壳。

2）总结这门课程的实践总结和给你带来的提升，包括以下内容：

1、统计一下，你在这门软件工程实践中，完成了多少行的代码；

作业序号	代码量	备注
1	0	个人作业-课程展望
2	138	个人作业-数独矩阵
3	0	团队第一次作业-团队展示
4	0	团队第二次作业-项目选题报告
5	0	结对第一次作业-原型设计
6	600	结对第二次作业-学生部门匹配系统
7	0	团队第三次作业-需求规格说明书
8	0	团队第四次作业-项目选题报告答辩总结
9	0	团队第五次作业-项目uml设计
10	0	团队第六次作业-需求分析答辩总结
11	50	团队第七次作业-随堂小测-同学录
12	750	团队第八次作业-alpha冲刺
13	0	团队第九次作业-alpha答辩总结
14	0	团队第十次作业-alpha事后诸葛
15	0	团队第十一次作业-beta冲刺前准备
16	3500	团队第十一次作业-beta冲刺
17	0	团队第十二次作业-华为云软件分析
18	0	团队第十二次作业-beta答辩总结
19	0	个人作业-实践总结
总计	5038

2、软工实践的各次作业分别花了多少时间？（做一个列表）

作业序号	耗时(h)	吃时间的怪物
1	1.5	思考人生
2	10	复习c++
3	1	p图^ _ ^
4	6	整理、修改报告；做ppt
5	20	完成原型设计
6	30	完成匹配算法、写bug
7	12	整理、修改需求规格说明书；写博客
8	7	调研测试、回答问题
9	6	用例图、博客
10	10	宣传视频剪辑、回答问题、博客
11	10	测试、博客
12	40	前端、博客、视频、~~催更UI~~
13	3	博客
14	1.5	博客
15	1	博客
16	70	前端、博客、视频
17	8	测试、~~调戏华为云客服小姐姐~~
18	3	博客
19	5	博客
总计	245

3、哪一次作业让你印象最深刻？为什么？

第一次作业
原因：
震惊三连：
a. 居然暑假就要开始做作业！
b. 居然问这么扎心的问题！
c. 老师和助教吐槽功力满分！
二脸懵逼：
a. markdown是什么？？？
b. github是什么？？？
说实话，对于一位不是大佬也不准备考研的人来说，看老师推荐的那些博客还是挺扎心的（虽然很激励），整个过程就是<写-停-反思-写-停-反思>,明明只要一个小时就能写完的东西硬生生花了两天。

4、累计花了多少个小时在软工实践上？平均每周花多少个小时？

共计约300个小时，肝作业时间+小组开会、调研的时间；
300 ÷ 7 ≈ 42.85 （小时）；

5、学习和使用的新软件；

Android studio 3.0.0 ：安卓开发必备。
staruml 2.8 ：团队uml作业的时候队友推荐的，算是一款很安全的uml制作软件，没有过于华丽的装饰，但是却很实用。推荐。
visual studio 2017 ：之前都是用小巧的dev c++，刚改用vs的时候还是不大习惯，现在应该是习惯了。
Adobe Premiere Pro CC：视频剪辑软件。(ﾉ･ω･)ﾉﾞ嘿呀，为了Alpha答辩的视频展示，花了20分钟速成学习，最后效果好像还不错？
Adobe Audition CC 2017：音频处理软件。和pr一样，都是做视频的时候速成学习的。

6、学习和使用的新工具；

百度语音：只要输入文字，就可以合成语音，炒鸡方便的好吗！（╮（￣▽￣）╭ 虽然只有四种声音选择，而且也不能正确识别标点符号），不过就简单的配音来说足够啦。
TeamViewer：远程控制器，前端队友安利的 ~~（主要是为了远程控制帮我找bug）~~ ，很棒(≧∇≦)ﾉ！

7、学习和掌握的新语言、新平台；

java： ( >﹏<。)只能算是学习了，掌握还说不上。
有道云笔记：用来拟博客还是挺方便的，但还是存在一些小问题，有时候有道云写的好好的，复制进博客排版就出现问题了。
leangoo：用来记录团队的项目推进情况，导出燃尽图。
processon：是一个在线画流程图/uml图等的平台，简洁易用。
github：(｡･ω･)可以说是程（找）序（de）员（mo）神器了。

8、学习和掌握的新方法；

NABCD模型分析： (๑•̀ㅂ•́)و✧ 很实用的分析方式，今天校赛答辩还用到了，效果棒棒的。
用例图：没错，就是它！很适合在整理软件逻辑时画，(=・ω・=)　是在课外有切实用到的东西。

9、其他方面的提升。

开会速度++：现在可以及时在其他小伙伴跑偏题的时候拉回来，而不是之前跟他们一起偏23333。重要会议的时间基本可以控制在一个小时内。
答辩技能++：软工的答辩算是让我既喜欢又抗拒，喜欢是因为友好的辩论算是自己比较拿手的吧（ ≧▽≦每次都有附加分敲开心的好嘛），抗拒的是每次答辩完都要写答辩总结(>∧<)┙へ┻┻。
后端了解++：这学期刚开始的时候对于安卓后端的了解情况基本为负，通过一个学习的熏陶以及前后端队友的纠正，算是了解啦(o´ω`o)ﾉ

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

我的人月神话：从大辣鸡到小辣鸡，从口头到行动。
上学期的暑假一直是在做原型和ui设计的工作，完全没有触碰编程，所以这学期刚开学的自己可以说是一只大辣鸡，连c/c++这种基础语言都忘了差不多。
第一次编程作业，我花了10个小时，其中3/4的时间在复习语言，最后虽然是完成了作业，但可以说是蛮差劲的一段程序了，不仅没有代码规范，封装性还差。那时候在作业博客里我是这样写的“希望下次的编程作业能够完成得更优雅些”。
看起来确实像是一句“泛泛而谈”的话，但是现在我可以拍着胸脯说，我并没有在“泛泛而谈”。在第二次编程实践，也就是结对第二次作业中，为了程序更优雅、效率更高，我在负责的匹配算法部分用到了之前没有尝试过的队列，并改掉原来一个函数到底的坏习惯，尽可能将每个程序都用函数封装起来。代码规范也是严格按照和勤勤商定的来做（参考了课本及网络上的命名规范）。
之后的团队编程中，也是按照前端的代码规范来做，编程水平相比刚开学也长进了不少。
虽然现在还是一只小辣鸡，不过是一只想成长的小辣鸡 (￣∇￣) 。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。特别地，特别地，下一届要不要中途换队员？

对下一届学弟学妹们（和开学初的我）的建议和告知：
希望你们在考虑要不要选这门课的之前想好以下几个问题：
a. 你这学期的安排如何？有没有什么特别耗时间的任务，例如计划参加某些竞赛？如果有的话，我比较赞同软工和竞赛选一个，不然要么累了自己，要么累了队友。
b. 你有足够的心理素质接受各方面的质疑吗？如果你较玻璃心的话，建议绕开软工，毕竟软工实践课上，你面临的可能不仅仅是老师的质疑，还有其他同学、助教、其他班助教、甚至是你的队友的质疑。
c. 你愿意用一个学期大半的课余时间去换取一个真实的项目经历吗？如果你还在犹豫，想一想，一些你原本可能拿来玩的课余时间能够换得一个软工学习大礼包（编程实践+商业企划书+需求规格说明书+掌握各种类图+掌握新的工具+一个只属于你和你的团队的软件），还是很划算的吧，那就勇敢的上吧 ⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄。
如果你们决定加入这门课程，针对团队实践，我有一些不成熟的小建议给你们参考一下：
a. 如果你想当队长的话，请确保你有足够的热情、责任心及沟通能力，一个团队的队长必须是这个团队的精神支柱。
b. 担任PM的同学尽量不要安排重要的编程角色，不然不仅自己会太累，还会影响整个团队的进度，把重心放在团队管理及项目推进会更好。（当然，前提是该团队人员较充足，如果只有2.3个人的话，当我没说^_）
c. 顺应上条，尽量能组个大团队，就不要2.3个人硬凑了。
d. 在前期分配角色时，一定要估计好这个项目具体各个角色的工作量，千万不要像博主这样，直接五五开，导致前后端工作量偏差过大，既会让工作量大的一方感到压力大，又会让工作量少的一方没有发挥空间。
对大一的我的建议：
别浪费时间在社团上啦，要多读书多看报，多敲代码，多睡觉(¦3[▓▓]，把黑眼圈留给两年后的软工吧。
关于中途要不要换队员：
虽然我们班没有经历过强制性换队员，但是我们队有个队友是alpha阶段跳槽过来的，这可以算是在自愿的情况下换队员吧，所以蛮说一下我的看法。
在双方都是自愿的情况下，我是支持换的。毕竟刚开始组队的时候，可能仅仅是因为不知道跟谁组就稀里糊涂地组了，后面才发现与其他队员在对于项目的看法有偏差，与其勉强合作，不如重新选择适合自己的团队。
如果是强制性换的话，分两种情况，一种是每个团队原本就都是兢兢业业的，并不存在有谁扯后腿的现象。这时如果老师下发命令一定要踢出一个人，是个人都会受伤的，而且新换进来的人可能也不如之前的做得好，可能会打乱这个团队之后正常的发展。这种情况下不支持。
当然，上面说的是在团队属于理想的情况下，但实际可能是另一种情况：有部分团队中存在队员划水的现象。而这时强制性换队员确实可以达到一定程度上防止划水的现象。这种情况下支持。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章人、绩效和职业道德）

**√ ** 萌芽：团队中的一半的队员是属于之前互不认识的，因为软工而成为一个团队，彼此之间还有些生疏和客气，但可以看出，大家都有在努力地适应自身的角色。
**√ ** 磨合：刚开始团队协作时，因为个人习惯不同等问题，偶尔也会发生一些小摩擦，比如惯用平台、软件版本不同等，当然，大家或多或少都有为了这个团队更好地发展进行过妥协，例如佳莹，我亲眼目睹了她下载了不下5遍的Android studio （滑稽），原因是我和另外一名前端队友都升级到了最新版本，而佳莹一直更新失败，只能重新下载，然后重新下载又失败，来来复复好几遍，唉，心疼， ~~哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈嗝~~
**√ ** 规范：我们团队目前应该就是处在规范阶段，角色定义落实，任务定义分了前端、后端、UI三个大块，后端及UI有具体到每个人的任务分配，前端小部队是按照具体进程动态分配给每个人。
创造：达到创造阶段还是需要一些时间的洗礼，目前并没有达到。