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

一、驻足当下

1. 课程期望对比

开学初的课程期望——软件工程的实践项目课程的自我目标

• 对项目的整个开发流程有一个全面专业的了解
• 掌握《构建之法》的精髓，懂得如何管理一个开发团队
• 代码能力以及代码规范得到进一步的提升
• 做出一个具有网站端又有移动端的项目
• 项目能在各类比赛中大放异彩，并进一步商业化开发，投入市场
• 实践课保持依旧的魔鬼强度，又有所新的创新，让我们在敲代码的时候享受到快乐

课程期望履行情况

　　从实际项目的最终Beta版本可以看出，现实和期望基本还是挺吻合的：

• 软工实践整个过程，作为团队的PM，在经历过多次团队摩擦、意见不合之后，学会了如何处理组员之间的沟通，更加合理高效得管理一个团队，并通过一系列的任务计划与开会讨论，让整个团队的编码阶段有条不紊得进行中，让组员在编码时有着一个轻松愉快的氛围
• 我们团队开发了一个Web端的毕设导师互选系统，而这个系统的安卓版同时也有另外一个小组在开发。
• 因为系统的完成程度较高，所以很可能在下学期系统便会在学院内部上线运行，而后再尝试着将系统推行到其他学院甚至其他高校，进一步进行商业化的开发，投入使用
• 整个软工实践过程中，因为团队协作和课程需要，我扮演的基本都是一个PM的角色，负责项目进度的把控以及博文的撰写，所以期望中代码能力并没有得到显著的提升，这也是我整个软工实践过程中最大的遗憾，当然，团队要走得更前，必须有人做出牺牲，虽然说得好像有点假惺惺了，但确实挺可惜的。

2. 自我提升

新软件

• Typora：MarkDown编辑软件

• XMind：思维导图的设计

• Axure RP：原型设计软件

• Sublime：高效的代码编辑器

• PowerDesigner：数据库设计软件

• ShadowsocksR：FQ神器，顺畅浏览github

• GifCam：动态图制作神器！无需安装！只有1.5M！

  

新工具

• Git的使用
• JUnit单元测试框架的使用
• Wampserver64：Web项目的开发环境
• SourceTree的Github上的项目进行管理控制
• 利用燃尽图对项目进度进行把控

新语言

• 对PHP、JS、CSS、HTML都有了进一步的了解，但因为充当的不是程序猿的角色，对语言的掌握能力并没有显著的提升

新平台

• 全程使用Github平台进行项目的托管，包括Project管理面板的利用、issues的沟通、里程碑的使用等，有效得提高团队协作开发的效率
• 博客园。一开始让我写博文其实我是拒绝的，但是随着博文越写越多，才懂得写好一篇博文也是一门艺术。一开始接触MD时，内心除了吐槽还是吐槽，标题大小、缩进、排版等等都是一个头疼的问题，但随着不停得百度和查阅资料，对MD的使用日益熟练，也养成了属于自己的博文风格，而且博客作业也多次收到助教们的好评，证明自己的努力还是有收获的。

新方法

• 撰写博文的习惯。如今项目开发过程遇到什么问题，都会习惯性得在博客里面记录下来，这对自己的学习和以后的回顾都是有着一个很好的帮助。
• 通过issues进行项目粒度的划分以及完成度把控。团队整个开发过程中基本没有在群里互传过资料，都是通过issues全员可视化的形式进行管理，包括每一次的总结以及每个任务的完成情况，这样组员看得到彼此的进度，对自己也有着一个很好的督促作用。

代码完成量

• 又说到这个尴尬的点了，因为充当PM的角色，在团队开发过程中基本都是对组员完成的最后情况进行项目的审核，偶尔也会根据commit记录审核下代码，但次数较少，因为自己的精力大都是放在整体项目进度的推进以及博文的撰写，所以在代码上花费的精力较少。

其他提升

• 团队协作管理能力
• 良好的沟通能力以及采纳意见
• 文档编写能力
• 全局观念以及项目粒度的划分
• 物尽其长，能够合理得根据组员的擅长进行任务的分配

---

　　从团队的角度来看，整个软工实践课还是非常成功的，小组的项目完成度高，组员的分数基本也都是在前十，小组目前也已经有两名成员获得了黄色领骑衫（估计还能领一件），这些都离不开每一个组员辛勤的付出。

二、人月神话

1. 项目经验总结以及例证分析

　　在整个软工实践过程中，我所负责的基本都是项目管理方面的工作，所以我从PM的角度出发，讲一下项目的经验总结。

• 团队沟通 ：作为PM，最关键最重要的点就是处理好和队员之间的沟通！一个良好的团队氛围是成功的一半。在软工实践课刚开始时，我们团队其实因为选题原因出现过不少的矛盾和摩擦，队员们都很有自己的想法，我们的选题也因此换了三次，此外在对作业的要求上我可能比较严格，很多细节方面都是精益求精，导致团队初期队员们的反应较为强烈。我其实一开始挺担心团队是否能够顺利得走下去的，但是之后团队开了多次的会议，经过大家的沟通以及协商，才逐渐确定了彼此的分工和职责，而我自身也把精力放在全局项目的推进上，对于细节方面改成冲刺最后再完善，此外还买了几次夜宵给队员，软工实践课结束后大家也一起聚餐，整个团队的氛围可谓说是越来越好，才造就了我们高效的开发进度。

• 任务分配 ：要做好一个PM，要学会如何第一时间从布置的任务中提取关键信息，并细化粒度分配到各个组员。同样的，在团队初期，因为对队员的擅长了解不多，导致了前几次团队作业一两个组员的任务量十分大，任务分配不均匀。但是随着团队的配合，逐渐发现了各个组员的擅长点，比如扬涛的的审美、齐民的尽责、伟炜的强大编码能力以及妹纸们的心细，并据此分配好各个任务，尽量让每个组员的任务量尽可能得平均，物尽其长。比如在软工实践的随堂小测上，我在和老师理清了作业的需求之后，便根据每个人的擅长点进行了任务分配。我们有四个人会JAVA，每个人负责一个功能模块，剩下三个人一个文档、一个测试、一个图表制作，在短短的一个上午里便完成了高质量的作业。此外还严格要求每个编码的组员都按照注释规范给代码加上注释，以保证作业的完成质量。

• 团队结构 ：我们团队 的结构属于1 + 3 + 3模式，即一个PM加3个后台加3个前端，PM负责统筹全局项目推进，然后3个后台前端两两配合、结对编程，负责对应的功能模块。此外团队博客的撰写全部由我负责，数据库的设计由齐民负责，原型的改进由许玲玲负责，算法的编写以及文档晚上、图标设计上面由杨涛负责，此外齐民和伟炜由于出色的编码能力，团队的技术指导基本由他们两个负责，当然因为我们团队的前端方面不是特别出色，我们又是也会请前端大神——立昊来当我们的技术顾问（感谢立昊(^__) ）。因此，良好的团队结构才造就了我们出色的配合默契。

• 项目管理 :项目管理是一个PM的主要职责，我们团队和其他团队主要不同的地方在于我们的项目管理基本都是在github上面完成的，包括github上project和issues的利用，团队群里基本没有互传过文件。无论是博客里每个组员的心得体会，亦或任务的分配以及项目进度的审核，都是在github完成。这样做的好处是把团队的所有工作记录集中在唯一的一个地方，当组员在查看issues时也可以顺便看到代码的commit记录，还可以在project看到整个项目的完成度，这样能加深每个人对项目进展的了解度。

• issues的利用 ：issues的利用我想单独当作一个点来讲，因为issues确实是项目管理的一个很好的辅助工具。先说说以往我们是如何进行团队合作的：任务分配都在群里或则群公告发布，然后定期根据commit记录审核项目，对未完成的点QQ私聊组员通知，心得体会也是群文件或则邮箱收集，这样的团队模式会导致文件太过杂乱或则消息过多，组员可能会遗漏到自己的任务点。反观依照老师的建议后，我们全程采用issues进行项目的管理，根据项目的功能模块，发布对应的issues，并注明标签分配到每个人，被分配到issues的组员github会自动邮件通知，确保了每个人都能及时了解到自己的任务。而在issues的开头我还会注明这个issues具体的任务要求是如何，每当组员完成对应的任务点时，便把完成情况提交到对应的issues下（文件/演示动态图/界面截图等），然后我会把项目拉下来，根据实际的运行对完成情况进行审核，如果有做的不好的地方，我便会在issues里面继续注明。此外，issues的一个关键作用是组员可以看到彼此之间的任务进展，当组员看到其他人的issues一个接一个得关闭，无形之中对自己也有着一种督促作用，毕竟若是issues都是自己的未关闭issues，站立式会议时自己肯定也免不了尴尬。

• 结队编码 ：在Alpha阶段和Beta阶段时，我们小组经常在活动室一起敲代码，项目要求上疑惑的点PM可以当场解答，技术上的难点团队的技术大牛们也能帮忙，整个团队互帮互助，互相督促，整个开发的效率简直高得可怕！在第一次活动室结队编码之后，组员便一直反应说希望多些这样的编码方式，而在Beta阶段我们便在活动室一起编码了好几次，大大促进了项目的进展。众人拾柴火焰高，以后的团队合作里，还会多多采用这样的编码环境。

• 冲刺时间的安排 ：软工实践课的强大确实是挺大的，这导致了挺多小组频繁出现通宵熬夜的情况。作为一名程序猿，虽然说熬夜是基本的技能，但是频繁得通宵熬夜可能还会适得其反。我们小组在整个软工冲刺里，就熬过一次夜(Alpha版本验收的前一个晚上，因为项目合并出现的一些冲突导致了熬夜)，很明显的我可以感受到在那次唯一的一次熬夜里，队员们包括我的情绪都变得烦躁了起来，开发效率大大降低，因此之后的话我便再也没有把冲刺时间段放到晚上。Beta版本的冲刺我们基本都是在白天，晚上最迟10点就结束冲刺，这样的话也能让组员有时间休息（毕竟妹纸最多的组，妹纸们还是需要美容养颜觉的），虽然没有熬夜，但是开发效率却逐步加快，使得我们团队在验收前的一个礼拜左右就基本完成了Beta版本。

三、经验建议

1. 对下一届实践的建议

• 作业分值的处理上尽量合理点，有很多团队作业的强度和工作量明显不同，但是最后的分值还都是15分。建议采用加权处理，根据预估的工作量分配分值权重；
• 可以增加一个技术问题记录的作业，博客这种东西，说实话没有作业的督促，很少有人会自己花时间去写技术问题的记录博客。下届实践课可以让每个学生都养成写技术记录博客的好习惯，这样几十个人的经验彼此分享，是一个非常宝贵的知识库！
• 听闻下届软工实践可能采取跳槽的新玩法？想法是很好，但现实很残酷。大学的课堂还是和公司很不一样的，同学之间没有那么多的利益争纷，若采取跳槽的这种制度，是否有考虑到被投票出局的同学的心理感受？因为一个软工课破坏了彼此间的友谊，我想这是所有人都不想预见的。所以依我看来，跳槽这种制度绝不可取！否则这将会成为软工实践课被黑得最惨最厉害的一个里程碑！

2. 对后来人的期许

• 选了软工实践课，就要做好付出无数时间精力的准备。软工实践课的收获在分数上是远远体现不出来了，它是公司里团队合作的一个缩影，对我们之后的职业生涯都是有着极大的帮助。
• 组建团队时一定要考虑周全，团队里最好至少有一个有项目精力的技术大牛，此外队员们的积极性的话也得充分调动，不然让每个人对作业都养成一种随便敷衍了事的态度，这对团队而言是一个恶循环。
• 在团队组建后的初期，要做好团队之间的沟通，明确好彼此的分工，这对之后每一次的团队合作都是至关重要的准备工作。

四、团队分析

《构建之法》里面提到的关于团队发展的阶段共有四个，分别是：萌芽阶段、磨合阶段、规范阶段、创造阶段。

• 萌芽阶段 ：在实践课初期，考虑到团队的人员配置以及项目的可发展性，我们经历了多次选题变更，最终才确定了“毕设导师互选系统”这个项目，并由Android端转型为Web端。根据系统的特殊性（每个学生大学只用一次），我们确定了我们的项目是基于Web端的，目标用户是学院的院负责人、系负责人、导师、学生等用户，并且当项目在学院试用情况良好后，可能还会向其他学院进行推广。

　　附：预则立&&他山之石

• 磨合阶段 ：确立了选题之后，我们根据用户给定的需求以及自身的实际经验，进行了项目的思维导图、数据库以及原型的设计，并定稿的项目的《软件需求规格说明书》，在文档里面对项目的主要功能模块进行了详细得介绍，并确定了项目的验收标准，以保证之后的开发都能严格按照验收标准进行。此外，我们团队构建了Github的团队协同环境，确定了编码规范以及开发工具版本的统一，以避免在团队开发中出现的代码冲突。我们还确定了项目的体系结构，采用MVC设计模式以及ThinkPHP框架进行开发，确保项目的完成效率。

　　附：需求规格说明书

　　　　体系结构与系统设计

• 规范阶段 ：在整个软工实践过程中，我们团队经历过两次重要的里程碑——Alpha版本和Beta版本。在Alpha版本里，我们团队完成了毕设选导的主要核心功能模块，并在验收时成功演示了整个选导过程；而在Beta版本时，我们主要的工作是修复Alpha版本时出现的BUG以及完善系统剩余的功能模块，此外因为Beta版本临时产生的需求变更，导致我们的系统部分界面需要重新设计。但是因为Alpha阶段的完成度较高，使得我们Beta版本总体而言的工作量并不会特别大，在验收前的一个礼拜左右基本就完成了Beta版本的所有功能模块。

　　附：【Alpha版本】十天冲刺集结令

　　　　【Beta版本】七天冲刺集结令

• 创造阶段 ：在Beta版本完成之后，我们团队的主要的工作重点便是放在所有模块细节方面的完善，比如Logo的设计，提示的规范化，界面排版布局的美化等等。此外因为我们的系统很可能会在今后上线使用，我们对实际用户进行了充分的调研，包括学生用户、系负责人用户以及院负责人用户，并根据用户的反馈意见对系统进行修补完善。我们还采用了真实数据对系统进行了模拟测试。

　　附：用户试用与调研报告

　　经过上述的团队分析，显然我们的团队最后应该达到了创造阶段，并很好得完成了项目。

五、文献笔记

论文 ：《Code quality analysis in open source software development》

摘要 ：开放源码软件开发的支持者认为，与传统的封闭模型相比，使用这种模型产生更好的软件。然而，很少有经验证据支持这些要求。在本文中，我们提出的试点案例研究的结果，目的是：（一）了解结构质量的影响；（二）计算出的结构质量分析的代码由开源风格开发交付的好处。为此，我们测量了100个应用程序编写的Linux的质量特性，使用的软件测量工具，并与工业标准，该工具所提出的结果进行了比较。本案例研究的另一个目标是调查的问题，在开源的模块化，这种特性被认为是至关重要的开源这种软件开发类型的支持者。我们有经验评估的应用程序组件的大小和交付的质量通过用户满意度测量之间的关系。我们已经确定，在一定程度上，应用程序的平均组件大小与此应用程序的用户满意度呈负相关。

　　在大一时最开始写代码时，自己的代码质量简直是惨不忍睹，变量的定义都是随随便便什么abcd，缩进什么的也都没有考虑，导致后来回头再审视自己的代码时，都不知道自己在写什么。之后大一的暑假，根据《马士兵的JAVA教学视频》自学了JAVA，更重要的是对代码质量第一次有了全新的认识，学会了大小驼峰命名法、注释的规范写法以及接口的抽象和面向对象设计的思想，整个代码质量有了一个突飞猛进的变化。自己现在日常在写代码时，都有着属于自己的编码风格，并会习惯性得加上注释，方便日后可能的再利用。

　　如何审核代码质量关键有一下几点：1. 代码注释；2. 编码规范（各种命名）3. 代码的可扩展性和可移植性

六、项目分析

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

　　我们的项目定位比较明确——毕设导师互选系统。整个项目的开发都是基于用户（栋哥）所给定的需求，而对于需求变更也进行了相应的处理，以保证最终的产品完美得符合用的需求。此外，因为项目的性质比较特殊，若当学院采用了我们的系统进行毕设选导，那么用户量基本不成问题，政策要求的话，所有老师和每一级的学生都会成为我们的用户，而且当系统试用情况不错之后，我们还会向其他学院甚至其他高校推广我们的系统，以进一步得扩大用户群体。

　　附：用户试用与调研报告

　　　　项目产品宣传推广方案

2. 能在预计时间内发布“足够好的软件”

　　从上述的团队分析里可以看出，我们团队有着完整规划性的开发流程，从项目规划=>需求=>设计=>实现=>发布都依次经历过，但是系统因为还未上线，所以维护阶段暂时没有精力。我们团队采用github进行项目的托管以及团队的协同开发，并利用每次冲刺会议里展示燃尽图以及项目的进度，而在项目的issues里面也可以看到每一个任务点对应的完成时间点以及完成情况，这充分表明了我们团队能在规定的期限里很好得完成项目的开发。

• Alpha版本燃尽图

• Beta版本燃尽图

• 项目Beta版本的部分issues

3. 软件的可维护性和可发展性

　　整个系统项目托管在开源的github平台上面，以便后来者可以在我们项目的基础之上进行发展和开发。此外，项目相关的文档也均汇总在github项目下的doc文件夹里面，项目使用者可以根据文档内容对整个系统有着一个充分全面的了解。我们团队在项目开发过程中，后台部分采用了接口的设计，增加了项目的可移植性的灵活性，利于之后的维护和进一步的发展。

　　此外，我们团队还推出了系统的官方网站，这样用户是需要一个网址，便可以在官网上面可以了解到这个系统的大概功能以及运行流程，也可以看到关于我们团队的相关信息。用户若是对系统感兴趣，可以通过官网上面的联系方式直接联系到我们团队。

　　附：Github项目链接

　　　　毕设导师互选系统项目链接

　　　　毕设导师互选系统官网链接

七、自我风采

031402304 陈燊

爱代码，爱运动、爱美食、爱生活，江湖人称燊哥哥

博客地址

　　我叫陈燊（shen 第一声！），来自于“我说的都队”团队，是团队的PM兼职业软文写手。因为身为组长的原因，我在实践课上“抛头露面”的次数比较多，所以感觉同学们和老师应该得记得我（至少知道我名字怎么念！）我是一个“完美主义者”，组员们的眼里的“强迫症患者”（其实是认真！负责！严谨！好吗！），无论任何事情都要尽可能得做到最好，最直观得体现就是所写的博客上面即使多一行少一行空格我都感觉不舒服，一定得让整个版式规整统一！虽然“完美主义”确实耗费了我不少的时间精力，但是也直接保证了我们团队每一次的作业 完成质量！

　　再者呢，就像我个性签名说说的那样，我这个人呢，比较矛盾，喜欢宅在宿舍敲代码却又向往健身和打球，喜欢各种美食却迫于某些原因不得克制自己的吃货欲望，喜欢音乐舞蹈却天生五音不全（不过幸好高中时有在晚会上跳舞唱过歌，也没留下什么遗憾了）。

　　总而言之，很幸运遇上软工实践，很幸运遇到你们，很幸运遇到“我说的都队”，人生不说再见，青春永不谢幕。往后的日子，我一直都在！

"我说的都队"——拍摄于文楼，一群要搞事的程序猿