一、请回望开学时的第一次作业,你对于软件工程课程的想象
我期望在上完了这门课后,我能够掌握一些独立编程开发相关的能力,并且有一定编程开发的思维。我打算每周拿出八个小时的学习时间用在这门课上,希望自己能真正有所收获,不在因为自己碌碌无为而懊恼。
对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?
总结这门课程的实践总结和给你带来的提升,包括以下内容:
1)统计一下,你在这门课程中,完成了多少行的代码;实际完成的正确代码估计在一千五左右
2)软工的各次作业分别花了多少时间?(做一个列表)
3)哪一次作业让你印象最深刻?为什么?
第一次作业让我的印象最深刻。第一次作业让我对自我有了一个深刻的思考。“我会什么?我不会什么?我做的是什么?我要做什么?我要怎么做?
无论是大一大二的时候,寻找自己的兴趣和学习方向,异或是以后想寻找到一个适合的工作的时候,时时刻刻对自己有一个清醒的认识,毫无疑问是异常重要的。认识自己就像一面镜子,可以把我们会什么,不会什么,哪里好需要保持,哪里不好需要改进都清清楚楚的映照出来。自满时,认识自己能给我们清醒的头脑;懈怠时,认识自己能给我们努力的动力。而毫无疑问,如今的我们正是一张大大的白纸,在投入社会时,需要我们时时刻刻保持一颗谦卑努力的心并且为之奋斗,才可能有所成。
4)累计花了多少个小时在软工上?平均每周花多少个小时?
如图所示,和团队总体统计大致花了110小时,加上平时自己在进行两个阶段的冲刺前需要额外花费时间对所需的编程知识进行学习,实际平均每周可能花费15个小时左右
5)学习和使用的新软件;
LOADRUNNER,GIT,MYELIPESE
6)学习和使用的新工具;
Junit、leango、码云git
7)学习和掌握的新方法;
结对编程、敏捷冲刺开发、需求分析、软件测试,燃尽图制作,软件工程思想
8)其他方面的提升。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
(1)自己思考过才能真正学习到东西,在个人作业过程中,提问题和案例分析,都是只有自己做过之后,才会有收获,翻过书能提出问题,研究过案例,能准确地分析,这本身就是思考后才能做出的回答。
(2)团队成员之间的沟通很重要,不管是结对还是团队项目,互相沟通才能使项目顺利进行下去。就说我自己的团队,每日立会的照片很多博客里都有缺,为什么呢?因为等组长叫人来开会时,总会有人到不了,那么这一天的会就不了了之。好在有QQ,微信能够交流,团队项目的很多任务都是群里分配,群里解决的,倒是有惊无险的结项了。
(3)自我提升很有必要,我也看到其他团队在做项目时还学习了新的东西,。我自己的团队也一样,从原来的没人有懂测试,到学会使用工具测试代码,学会使用工厂模型设计软件,将数 据结构运用到项目中去等等,从项目开始到结项,学习到了很多新知识。
三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,你有什么想建议和告知的呢?对于后来人的期许。对于换人机制,有什么样的建议?
(1)要合理管理及分配时间。在软工的团队开发阶段会花费你很多时间,加上你可能有其他们课的作业需要完成,时间上的合理分配就显得十分重要了
(2)一定要掌握一门编程语言。有可能有的人会有我不走编程这一条路的想法,但是作为一个学计算机的学生,一定会碰到各种编程作业或者你的毕业设计;
(3)如果你想学好编程的话,一定要多敲代码,可以尝试去参加项目,在项目中提升自己。
对于换人机制,我个人觉得很好,有助于队员学会和不同人该如何磨合,该如何沟通。但是如果在冲刺阶段的团队表现和期末平时分挂钩的话,那么建议助教对进行换队的队员的贡献进行审核。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建执法》第17章 人、绩效和职业道德)
《构建之法》上说团队的发展有四个阶段,分别是萌芽阶段、磨合阶段、规范阶段、创造阶段。
萌芽阶段:一开始我们团队刚组建的时候,都还处于一个熟悉的阶段,不知道该如何实施团队的计划;
磨合阶段:在这个阶段,队员开始适应了团队开发的模式,开始讨论分工,了解自己在团队中处于什么角色,该做哪些事;
规范阶段:团队渐渐走向正轨,队员之间能够合作交流,每一位队员都开始按照计划完成自己的任务;
创造阶段:团队仍然存在着不少的问题,只能勉强到达规范阶段,并没有达到创造阶段
五、怎样证明你学会了软件工程?研发出符合用户需求的软件
a阶段成果
b阶段成果通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件
需求分析
a阶段敏捷冲刺
b阶段敏捷冲刺
a阶段项目总结
b阶段项目总结
研发出符合用户需求的软件
必须公开发布,有实际的用户,一定的用户量和持续使用量 (3 天后能保持10 - 100个用户);而不是: 做没有用户使用的软件
通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护,有定时的进度发布 ; 而不是: 通过临时熬夜,胡乱拼凑,大牛一人代劳,延迟交付等方式糊弄
并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码,代码无文档,代码不能编译,没有task/bug 等项目的发展资料