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

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

• 一、请回望暑假时的第一次作业，你对于软件工程课程的想象
  • 1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
    在经过了一个学期的努力之后，真的花了很多时间来做软工实践啊，有时候想了想为啥自己当时来找虐呢，但是自己后来在上台讲我们自己的实验成果的时候，无论好坏，自己都充满自豪感。我觉得至少我通过一次次的博客，通过一次次构建之法的阅读和对于队员们的沟通以及自己做决定的一些事故，像极了以后工作中的各种状况。我觉得自己可能不适合编程，但是我发现了自己很适合做一个产品经理或者项目经理，至少在我如果考研失败，那么我还可以去应聘这方面的类似的职位，我一开始觉得可能产品经理对于整个以后的现实中的团队来说可能会没那么重要，至少从工资上可能差不少，但是经过了实践和一次次的和助教老师们的沟通，我知道了并不是这样的。收获很多。我觉得最大的收获就是让我自己找到了一个可能适合自己的方向，这让我以后可能会少走很多的弯路。让我自己去强化类似的技能和其他方面的知识。不足的话，对于每一个计算机专业的人来说，当然是希望自己的代码能力非常强。我这方面真的太欠缺了。自己也努力过，但是就是不开窍，我觉得自己找好方向万一以后这条路走不通还是得走程序员的老路。路在人走在人为，一切的一切，感谢队友感谢助教感谢老师，软工实践，受益匪浅。指引了我的方向，让我给自己的路有了个思考，至少我会朝着类似的方向努力。自己的缺点代码能力上多学习吧。长路漫漫。
    今天听了老师讲的项目管理的课感觉受益匪浅。项目管理中的第一阶段还是要当程序员。统称。万变不离其宗，在35 岁的时候还是要当上管理层的。就算现在不会变成也要学会看代码。还要丰富需求分析，原型设计，协调整个团队的能力。就像老师说的你如何在给你的人不是那么理想情况下完成任务，我觉得这是需要去哦好好考虑的并且需要更多地锻炼。但是我觉得自己感兴趣这方面也没用。感觉竞争还是蛮大的。虽然感觉挺简单但是感觉还是没有程序员有含量。装B还是得程序员。而且现在有技术有能力有情商的太多了。所以自己还是要多多努力。
  • 2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
    • 1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
      
      整个的阿尔法阶段和贝塔阶段的代码可能有3000-5000多行，我如果算上测试学习神马的应该有10000行了吧。因为在阿尔法阶段都是我自己在上传Git，所以这个数据并不准确。但是也差不多。但是和别人真的比不了。人家认真的有技术的都是十几万行的。这就看出来差距了。
    • 2、软工实践的各次作业分别花了多少时间？（做一个列表）
      见文章末尾 时间图表
    • 3、哪一次作业让你印象最深刻？为什么？
      阿尔法阶段验收的作业 啊。那次上台真的是太尴尬了，没完成也要去讲。那种心情真的不是滋味。人家都完成了美滋滋的去上面讲。我自己在上面尴尬的展示，给自己一首我们不一样。哈哈。真的是上了软工实践，神马不要脸的事情都搞过了，以后HR面试的时候问我问题我也能很好的回答，问我的经历问我的故事，那我就有的聊了，软工实践我能讲上三天三夜。
    • 4、累计花了多少个小时在软工实践上？平均每周花多少个小时？
      10月，11月，12月，每天晚上花几个小时学编程，冲刺阶段每天还要开会写博客，周六周日还要做周六的准备。可能这也算提前适应程序员的生活。平均每天3个小时，有的不是为了敲代码，一周20个小时，一共三个月240个小时吧。我的组员可能更多。致敬。
    • 5、学习和使用的新软件；
      AS，Git，idea，apache。
    • 6、学习和使用的新工具；
      Git，码云，markdown
    • 7、学习和掌握的新语言、新平台；
      Java，Android，还会写博客了。
    • 8、学习和掌握的新方法；
      最重要的软工流程。开发模式，从需求分析到原型设计到实际编码冲刺再到最后的成品成功，虽然我们感觉还是不太成功，但是至少我对于整个流程都有了一个直接的认识。虽然感觉还是失败了，但是学到的还是很多。但是肯定是没有那些做的好的感悟的多得。
    • 9、其他方面的提升。
      人际交往关系，了解了开发模式，知道了Android的原理，离自己并不遥远。最重要的是认识了一大堆的人。助教老师队友，开拓了眼界。知道了自己喜欢和各种各样的人交流协调进度喜欢认识各种人，喜欢最后团队做出完美产品的时候在上级面前的自豪感。也算发现了自己的特点吧。脸皮也变得更加厚了。（偷笑这个不算）
• 二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
  作为后来的临时PM自己的不足太多了。在我心里的配置，一个团队的顶配是一到两个大神，两个可带的人，加上一个组长就能完成任务了。对于特别的强的组对于我们来说就是一个Android一个iOS一个后端兼职组长，期末考的学长就是这样的配置。真的大神。
  经验总结来说，最开始的计划阶段就要选择对于整个组有利的方向。如果是刚才的那种配置的队伍那么都可以，因为那样的队伍有组长给你分配明确的任务，有大神带你那样你会有一个明确的思路知道你要去做那一块。不会去徒劳的做其他的事情。你自己也要做好准备。然而肯定也会有各种队伍，就比如我们队，如果急真的摊上了这样的队伍，一定要努力积极地沟通，去整合一切的力量，因为这时候我们的目的就变了，据说下个学年软工实践是必修，那么大神的队伍可以浪可以有各种天马行空的创意但是人家做的完。我们的话，自己就要知道我们是为了不挂科的基础上来做这件事。对于我们最后一届的我们队伍里，我们后来的目的就是单纯的搞好不去搞砸。不像其他组各种蒂花之秀。但是如果我手下有的不是一些新手而是理想配置，那么我想我会更多的去发挥自己的想象力，让整个团队变得更好，所以在什么样的环境做什么样的事，不让结局更坏，抱着重在参与的心态积极地参加，当然这个心态也要天时地利人和，有时候总会有其他的阻力，那么就顺其自然。
  还有就是一定要遵循每一个阶段的规范，即使没有规范那也要自己心里有一杆秤。告诉自己要到截止日期了抓紧。还有如果队友是那种很努力的很努力的那么请珍惜，和他们合作你迟早成功。遵循Git规范每天完成任务积极上传做好组长分配给你的任务，那么软工实践就没白上。我真的是想说的太多了。
• 三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
  我觉得在你决定要选择软工实践的时候那么你就要找好你的队伍，别等到别人都组好队了剩下一群没组织的人去再组一个菜鸡队。组长特别重要，给不给你分配任务至关重要，没有人给你分配任务那么你就是一群乌合之众。漫无目的毫无效率可言。组里最好还有一到两个大神你不能之靠大神大神的目的是在你有疑问的时候解决你的疑问，让你更好地去学习改进，跟上项目进度。你自己也要积极地去了解。去在大二暑假的时候尽可能的去掌握Java，Android或者iOS后端森马的。在别人一教你你就会学的事半功倍。而且你要去学会你自己擅长什么。这样对你未来的一年很有好处。软工实践可以说是整个大学不可多得的实践课。让你了解整个软件的开发过程，了解整个团队的构成，以及各种的工具各种的新知识，以及发现你自己的优点和不足。还有尽量选择同一个宿舍楼的不一定是同一个宿舍的组队，这样好交流。
  对于换人这块，我们组没什么感受，但是对于我自己来说还是都可以的，换人是公司里常有的。而且老师这么安排肯定有他的道理。我觉得听老师的话是有好处的。但是我觉得应该鼓励而不是强制。这样应该效果会更好。
• 四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
  我们的团队就是假团队的状态，但是这几个阶段大致都经历过，从最初的萌芽期，大家都互相阿不认识，去摸索去理解去完成前期的任务，瓶颈就是磨合期，看清了谁是猪谁是鸡谁是鹦鹉，谁是想好好干的谁是来水的。到现在团队里面还有很大的问题，这个问题是多方面的，是各种因素导致的。也不去过多的深究。反正我们几个互相信任了，我们团队的绩效成绩拿不出手，那我就自己去抗，总要有一个人去负责的。但是过了这个阶段到了贝塔阶段，我们就到了规范期和创造期了，虽然没有其他组的好，但是我们确实规范的遵循了阿尔法阶段没有遵循的规则。并且最终达到了创造一些有意义的事情的地步，我觉得在最后我们算是勉强合格了吧。当然了对于所有的人我心里当然有一杆秤，区别对待那是肯定的。真想团队里面都是P1的就像晨瑶他们组。最后我都想把自己交换出去了。
  我们的团队我一开始就分析了，第一一开始没有好的领导者，当然我也不是一个合格的领导者，我多得只是比前任多了个归属感，多了个担当而已。第二团队中没有一个技术核心也就是老师上课所说的主程序员。当然现实中没那么理想就是了。第三我自己也是一开始混乱，我现在这个状态说是组长还不是，自封的组长，说是吧还没有和旧的组长交流过。反正我就稀里糊涂的当了临时PM。但是我一开始就是想当PM的但是自己实在没有什么卖点，感觉自己没什么能服众的。现在也是，我和组员之间也没有什么PM不PM之分，就是他们每天和我讲一下计划，我陪他们熬夜，给他们鼓励，我觉得这份情谊很珍贵吧。还有我觉得在中期的时候我们也实行了分隔，但是我们这个的原因有地理原因，有交流原因等等。反正最后确定是5-6个真正的team。老师今天一讲我觉得太像了。我的实践课不失败也不成功。所有的队员你有能力我愿意交流或者大家都愿意交流，那我们就在一起为了一个目标拼搏。good feel。
• 五、怎样证明你学会了软件工程？
  我觉得除了一下几点最重要的一点就是以瀑布模型为理论基础的整个软件工程实践过程。如果连这个都不知道那么所有的都是空谈。
  • 1）研发出符合用户需求的软件
    必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
  • 2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
    有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
  • 3）并且通过数据展现软件是可以维护和继续发展的。
    而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
    请在随笔中用数据证明上述内容或侧重选择之一。
    对于第二点我觉得我们团队失败的主要原因就是做好了原型设计原组长没有计划的对我们每个人做什么搞不清不分配，而且我们也有原因就是中期的时候不沟通。各种原因。导致延迟交付，谁都想搞出好的软件产品，可有时候自身和环境各方面的因素导致想做好一件事无能为力。这是最要命的。我们阿尔法阶段只有我一个人上传Git，一人代劳，敷衍了事。而在贝塔阶段我们每个人都有明确的分工，每个人每天按时上传Git。做出来的app不知道好了A阶段几百倍。
• 六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
  参考论文文献：

[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.

[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605

[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87

对于这里我自己的代码基础不是很好，但是每一个PM都要对队员的代码质量把关，我觉得这方面是我要更多地要去学习的。对于队员的质量把控，合格才是merge。

• 七、个性发挥，包括图文、照片和创意等
  听说有人十八门课的同时软工实践，我二十门笑笑不说话。天秀，陈独秀。
  

时间图表

作业名称	花费时间	总计
第一次随笔	三天	大约40天
第一次结对作业	两天
第二次结对作业	三天
第二次个人作业	三天
团队第一次作业	半天
团队第二次作业	半天
团队作业--规格需求说明书	一天
团队作业--系统设计	一天
团队作业--预则立他山之石	一天
UML设计	一天
Alpha阶段第一天到第十二天冲刺	十二天
Alpha阶段团队项目课堂展示	半天
随堂小测--同学录	四天
个人技术博客之1,2	两天
事后诸葛亮	半天
个人作业之软件产品分析	两个晚上
Beta阶段第一天到第五天冲刺	五天
Beta阶段团队课堂展示	半天
个人作业软工实践总结作业	一晚上
团队作业——项目验收与总结博客	一晚上