最终作业 - 软件工程实践总结

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

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

  • 开篇回顾：

  • 在完成了软工实践后来看，说实话我认为自己在代码能力的提升方面是很有限的，身为PM在这次实践中并不负责项目的具体编码，而是将更多的时间和精力放在了团队管理和推进项目上。

  • 但在团队协作方面我认为完全达到了我的期待和目标，这次实践能够真正的管理一个9人团队并从始至终地完成了一个项目的开发，这对我来说是第一次，它大大提高了我待人处事的能力。

  • 此外就是对自己的时间管理能力也在这次实践中得到了提升，经历了实践才头一次觉得时间如此不够用，每天既要完成实践任务又要兼顾学习和周末的实验，这让我不得不学习如何合理利用各种碎片化的时间来兼顾实践与其他课程的学习。

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

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

  • 答：根据之前的beta总结的学习进度表的统计，我这个学期打了2550行代码，不过老实说我的代码量主要体现在实践的个人作业、结对两次作业上了，而到后面的团队项目时，我并没有在项目中贡献太多的代码，更多的代码用来验证想法的可行性上了，之后就将任务交给分配的人去做了。

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

作业名 花费时间
第一次作业 120
个人项目 960
结对项目1 580
团队风采展示 120
结对作业2 1620
团队选题报告 720
团队课堂UML设计 405
团队需求分析报告 915
Alpha冲刺 2385
团队现场编程 205(课后)+180（课上）
团队项目评测 215
Beta冲刺 1405
最终展示 180
  • 总花费时间：9810分钟

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

  • 印象最深的应该是团队现场编程的作业，那次作业我们在规定的时间内只是写出了预期的前端代码，所以课后我和后端组的@王源和@赵畅为了完成项目，从下午3点一起干到了凌晨一点，最终完成了项目的后端代码并部署到了云端上，也是这次作业标志着我们团队从学习状态真正转到了有一定生产力的阶段。
    此外也是这次作业让我们对自己的代码能力和学习能力有了更强的信心，毕竟在一天的时间内完成了一个网站从无到有的搭建，而关于后端laravel框架的相关知识，也是在一天时间内悟道的。

4、累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答

  • 实践前立下的flag

- 我打算每周拿出14小时左右的时间，平摊到每天大概两小时来花在这门课上，不过具体需要根据任务需求灵活调整，并且我希望我花在这么课上的时间是高效率的，不要最后成为自我感动的借口
  • 根据上面的统计，累计花了9810分钟在软工实践上，算起来也大概是每天两个小时╮(╯▽╰)╭ ，基本符合自己的预期

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

  • 原型制作软件：Axure

  • 矢量图绘制软件：Illustrator

  • 视频剪辑软件：Premier

  • Android Studio

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

  • 石墨文档（在线文档编辑）

  • SVG2Drawable（安卓矢量图转换）

  • 版本控制：git及github

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

  • 基于JAVA的Android开发基础

  • 基于laravel的web后端框架

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

  • 学习编写单元测试来检测代码质量

  • 学会使用python爬取网页信息

  • 学会撰写文档来规范团队的代码质量并以及引导团队前进

  • 学习如何给团队的每个人分配合适的任务

9、其他方面的提升。

  • 收获了多次在百十号人前展示自己的想法、思考、答辩的机会

  • 对软件工程的思想有了自己的切身体会，明白了一个项目有必要的规范文档做支撑的必要性（虽然很繁复，但是这是“工程”不可或缺的）

  • 收获了管理一个9人团队的宝贵经历

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

  • 人月神话在团队现场编程中有非常具体的体现，在现场编程的实践中，我一开始考虑到各个组员的技术栈，所以让司职后端和前端的组员依然按照各自的角色完成抽奖系统的前端和后端部分，而web平台的特点又导致前端页面的完成速度会远快于后端，但当我们的前端页面完成时，尽管解放了4个组内劳动力，但由于负责前端的组员对于我们选用的后端框架并不熟悉，导致出现了后端努力编程前端只能负责加油的情况出现
    这就像《人月神话》中描述的危机一样，在这样的情况下，即使增加再多的人手，因为擅长技术不同，到最后也只能增加沟通成本拖慢项目进度。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：

1）你有什么想建议、告知和期许想要告诉他们呢？

  • 我想说在寻找队友时一定要好好考虑，要从性格、价值取向、技术能力等多方面考虑，就我的实践经历来看队员之间有相仿的三观是十分必要的，这样不仅降低了大家沟通的成本，也能使团队保持一个良好的氛围。

2）特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？假设依旧是一个90+人数的大班

  • （既然我已经渡过此劫）那我想说：换！狠狠的换！这样才能更好的模拟现实生活中职员跳槽的情况，而且换队员后对团队的管理者来说也是一个既有趣又有挑战的问题(⊙﹏⊙)。

3）身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？

  • 我个人认为团队人数保持在5-7个人的规模应该是最合适的。

4）个人/结对/团队作业应该控制在怎样的规模？

  • 个人作业和结对作业的规模我认为没有问题，但是在团队编程实战中我认为任务的规模应该适当减小一下，毕竟这次的现场编程作业不像是3个小时可以完成的╮(╯▽╰)╭，此外我认为Alpha从冲刺的时间可以维持在2周的时间，而beta可以缩短到一周，个人倾向于长痛不如短痛的冲刺模式，既然伸头是一刀缩头也是一刀不如多熬几个夜直接将项目完成。

5）这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？

  • 我想感谢组内的后端leader@赵畅，在这次实践中作为后端的leader帮我负担一大部分后端的管理，让我能够把更多的时间放在对项目整体的把控上。

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

  • 萌芽阶段：这一阶段大概对应着我们从组队开始到第三次alpha冲刺时的情况，在这个阶段队员们都在学习相关的技术，对项目实现可能碰到的问题还没有一个非常清晰的认识。

  • 磨合阶段：这一阶段对应我们团队现场编程及之后的两次alpha编程，团队现场编程将我们团队当时存在的问题暴露了出来，这也是组内成员提出疑问最多的一个阶段，不过很庆幸团队成员直接能够相互理解，对项目的疑问也能通过当面交流指定解决方法，从而度过了团队的磨合阶段。

  • 规范阶段：从第六次alpha冲刺开始，我认为我们团队进入了规范阶段，我们在这时已经完成了项目的接口文档撰写、代码规范的约定、版本控制规则的制订，与此同时大家对项目所期望达成的目标有了清楚的认识，对自己负责的部分应该达成怎样的效果也了然于心。

  • 创造阶段：我认为我们的团队在beta冲刺阶段一定程度上触及了创造阶段，个人的体会是，在beta阶段我们相比alpha阶段添加了4个全新的功能点，在我和后端组编写好接口文档后，每个队员在明确了自己的任务后项目便开始了“并行开发”，我们的7次beta冲刺中，因为考试冲突挤掉了3次的时间，但我们的项目却依然早于预期的进度完成了，这说明我们整个团队已经能够排除杂念将大部分精力花在项目的开放上了。

五、怎样证明你学会了软件工程？

1）研发出符合用户需求的软件

  • 在项目开始时我们就发布了一份有100人回答的问卷，明确了用户的需求，并以此为依据开发我们的软件

  • 截至截图时，根据后台的数据库记录一共有141人/次 使用了我们的软件

2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

  • 这次实践中我们团队的代码完全托管在github organization上，每个人在上传代码前都需要遵循约定撰写commit信息

  • 团队的merge network图：

  • 前端：

  • 后端：

  • 前端commit情况：

  • commit信息（部分）

  • 后端commit情况：

3）并且通过数据展现软件是可以维护和继续发展的。

  • 团队的接口文档、技术文档等都是放在石墨文档上组内共享的：

  • 组内有详细的技术文档

  • 组内的代码规范

  • 组内的代码管理

4）对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。

  • 针对“硬的问题”：按照检查表，我认为自己还有非常大的进步空间，特别是JAVA部分的问题，在这次实践中并没有系统的学习JAVA这门语言，只是以项目驱动学到将将能看代码、写代码的程度

  • 针对"软的问题"：感谢软工理论课与实践，我对检查表中的这些问题都有了切身的体会，能够明白一些必要的“繁复”项目文档、相关调查、详细的规范都是为了支撑项目可持续发展的必要要素，虽然这会一定程度上降低效率，但却是保证项目能够成为一个“工程”不可或缺的。

七、个性发挥，包括图文、照片和创意

posted @ 2019-01-09 20:39  B3njamin  阅读(287)  评论(2)  编辑  收藏  举报