北航2022软件工程最后一次作业——回顾、总结、思考、感悟

软件工程最后一次总结作业

项目	内容
这个作业属于哪个课程	北京航空航天大学2022春季软件工程（罗杰 任健）
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	学习软件工程的基础知识和基本流程，通过团队合作开发一个较大型的软件工程项目并争取能够上线
这个作业在哪个具体方面帮助我实现目标	总结一学期的所做所学

对曾经提出问题的解答

原提问博客链接：软件工程第一次作业

1、证明软件可继续发展

能证明所开发的软件是可以维护和继续发展的。例如，对用户需求的分析有详细的文档说明，包括对将来发展的分析和计划。

——P17

Q：

我赞同软件开发需要有长远规划的观点，因为一个产品不可能永远停留在一个阶段，要想成功一定需要紧跟时代的步伐。

但是如何在最初开发的阶段“证明”它是可以继续发展的似乎不太容易。也许在当前的社会背景下，某种应用能够取得不错的市场，但是当社会的风向标转变时，一个比较庞大的软件很难做到迅速转型，而其最初指定的持续发展的目标方案在这时候就不一定行得通了。所以我对书中的这段描述有些疑惑。

A：

就拿我们的产品灵境作为例子吧，在alpha阶段，我们产品的定位更聚焦于3D场景下的用户交互。但是在alpha阶段的发布阶段，用户反馈这个产品可玩之处过少，可能很难来留住用户，因此我们在beta阶段增加了几个小游戏，丰富了产品的同时也增加了用户粘性。

在产品最初阶段，我们并没有进行很好的用户调研，但是在beta阶段，我们更多地向用户更迫切的需求靠拢，提升了产品的可持续性。但要点在于我们一开始的大方向是正确的，因此对于产品中期的调整可以变得更加游刃有余。

因此，提出的这个问题最本质的点不在于能否完成转型，而是在于产品设计之初是否在大方向上正确。如果产品一开始就偏离了社会的风向标，那无论怎么转型都毫无意义；反之，在大方向正确的前提下，面对用户新的需求，修改也就变得容易了。

2、软件工程师的成长

初级软件工程师如何成长呢？我认为有下面几种成长：

1、积累软件开发相关的知识，提升技术职能。

2、积累问题领域的知识和经验。

3、对通用的软件设计思想和软件工程思想的理解。

4、提升职业技能。

5、实际成果。

——P45

Q：

作者在文中提到的软件工程师的这几种成长，侧重了不同的维度，有专业技能、职业技能、思维技能等，那请问这几种维度是否有主次之分？哪一种或哪几种显得更为重要？

另外，像第四点的职业技能，似乎比较抽象，这方面的能力的提升有时候并不容易（相比于技术上的能力通过一般的学习和理解能够掌握来说），那请问这应该如何快速提升呢？

A:

首先，这几种维度的成长都很重要，只有这几方面都达到一定的成长，才能蜕变成一名合格的软件工程师。我认为，不同的维度的侧重点的差异性可能与软件工程师在团队中的角色有关。在本学期的实际开发中，就我个人经历来说，我更多的提升了技术和专业的技能，而两位PM在提升这些和技术有关职能的同时，也需要对团队管理、人际交往有更多的理解和提升。

说到职业技能的提升，虽然我们这学期只是几个学生一起完成一个项目，并没有涉及到职业技能。但是，我感觉到了正式进入职场后，职业技能肯定也能在无形之中提升吧。

3、爵士乐模式与敏捷开发

爵士乐模式有以下特点：

• 不靠谱（演奏时没有谱子）
• 没有现场指挥
• 也有模式
• 人数较少

这看上去跟“敏捷的开发模式”有点类似。

——P94

Q：

首先，我不认为这和敏捷的开发模式类似，在书中的第六章详细介绍了敏捷流程，其中一开始就介绍的敏捷开发的原则中有许多方面与爵士乐模式相违背。

其一，敏捷开发中，文档还是非常重要的，并不是像爵士乐模式中的即兴发挥就可以；另外，爵士乐模式的没有指挥似乎在敏捷开发中也行不太通，一个开发团队还是需要一个leader的。因此我认为这两者并不是“类似”的关系。

A：

在这个问题下我还是赞同我当时的想法的，我们本学期的项目也是基于敏捷开发的，其中的一些方面还是和爵士乐模式中的一些特点有违。

我们的团队协作中，文档占了很大的作用，不仅是前期的需求分析、规格说明书，还是中期的会议记录、技术文档，又或者是后期的发布说明、总结反思，都能让我们更好地进行产品的推进。我们的团队中，PM的作用也是极其重要的，文档编写、团队协调沟通等任务都是由两位PM完成的，发挥了不可忽视的作用。

因此，敏捷开发并不是“即兴开发”，它和爵士乐的即兴创作还是有本质区别的。

4、敏捷流程与28定律

程序员写完功能的时候，我们感觉好像项目完成了80%，殊不知后面的20%往往要花费80%的时间，敏捷流程没有明确表明到底何人何时以何种优先级来完成这20%的任务。

——115

Q：

我们的课程采用的是敏捷开发流程，那么如果在开发过程中遇到了这20%的任务，应该如何处理呢？如果我是项目负责人的话，当开发时间有限时，我肯定不会去考虑那20%；如果还有时间，我可能也会选择去提升优化产品的其他方面（如推广等）而不是死磕这20%。不知道我这样的做法在敏捷开发中是否合理？

A：

这个问题是几乎所有项目都会遇到的问题，毕竟每个项目在后期都有还需要提升的地方，但是越到后期，一些“顽疾”问题就越难解决。

我不知道其他团队对于这个问题是如何解决的，我只说说我们这个团队是如何进行任务的时间规划的。我们在每个阶段的开始都划分出几个具体的需求，有些是必须要完成的，有些是选择性完成的，比如我们的beta阶段启动时，将AR技术作为可选择性需求，先调研半周，如果无法完成则放弃这个需求。到了正式的冲刺阶段，我们每个人都会尽力去完成划分给自己的需求，同时，为了更好完成任务，成员之间也会进行跨需求的合作。到了产品开发的后期，剩余的大部分任务都是功能性bug和用户体验的改进。此时，距离交付仅剩的时间不多了，PM在开会时指出对于没有完成的需求，如果不影响整个产品的话就放弃，在已完成的需求中，功能性bug优先级最高，然后再是其他任务。

总之，由于敏捷开发的时间周期短等特殊性，我们只能做到尽全力开发，按优先级完成任务。也就是说，在28定理中，若这剩余的2优先级非常高，我们还是要继续“死磕”的；反之若不那么重要，则可以把剩下来的时间花在其他可以优化的地方。

5、PM所需要的的能力

成为一个合格的PM，需要哪些能力呢？

1. 观察、理解和快速学习的能力
2. 分析管理能力
3. 一定的专业能力

——P188

Q：

结合文中这段话后面提到的PM的具体任务，我认为PM所需要的的能力还应该包括“沟通与号召”能力，PM作为项目经理，需要得到成员的支持，如何得到支持，那就是经常与成员和客户沟通，了解双方的需求，同时有一定的号召力能让项目成员一起向着目标前进。因此，我认为文中这部分的介绍还有上面这些可以补充的地方。

A:

​虽然我不是我们团队的PM，但是在经过一学期的团队开发中，我也向我们组的两个PM学习到了一些PM所必须的技能，除了书中提到的那些，我再做下面的补充：

首先是团队协调的能力，不仅局限于团队内部的协调，也包括和其他团队的交接。我们的项目时和中传合作的，PM在整个流程中不仅协调好了我们课程成员内部，也很好地完成了和中传团队的交接和沟通。

​其次，和团队成员的沟通能力，我们在beta开发后期，团队成员和PM有过一定的争执，但最后还是由PM和成员进行沟通解决了矛盾，并且在最后的总结会议中进行了反思和改进。

另外来说，PM如果能够有更高的技术水平的话，那对整个团队能起到更好的稳定作用，一些难点和PM进行讨论并由PM提供一定的帮助，也能让其他成员在开发的时候更加安心。

在实践中学到的各阶段知识点

1、需求

在需求确定的阶段，使用NABCD需求分析方法来把握产品定位，我们的产品从需求（need）、方法（approach）、好处（benefit）、竞争（competitors）、交付（delivery）这5个角度进行需求分析，确定了元宇宙高校这类产品的必要性和重要性。

2、设计

设计阶段要遵循一定的设计原则，如信息隐藏原则、接口设计原则、高内聚低耦合设计方法等，在实际开发中，我们制定了功能规格说明书和技术规格说明书，将各类规范和原则以文档的方式记录下来，从而使得后面的开发“有文档可依”。

3、实现

产品的正式开发阶段，代码和进度管理是一项重点。我们在开发阶段，使用coding平台进行代码仓库的管理和issue的分配，同时PM也制定了issue的模板，使得任务确定和缺陷提出更加规范化，这样的方式使得进度管理变得更加高效。

4、测试

为了减少正式发布时产品出现缺陷，对产品进行各项测试是必不可少的。我们团队负责QA的同学对产品进行了正确性测试和压力测试，一方面在最大程度上避免发布时产品出现bug，另一方面也减少别人的恶意攻击，最终由其他开发人员修复bug，并生成测试报告。

5、发布

发布是为了让更多用户能够使用产品，因此需要”广而告之“来进行产品推广。在正式发布时，我们的灵境通过朋友圈推广、群聊转发、Bilibili推送视频等各种方法扩大产品的影响范围，来让更多用户能够了解并使用我们的产品，这也是发布阶段的核心目的。

6、维护

测试阶段并不能保证所有bug都能被发现和解决，因此维护阶段就需要不断接受用户反馈，通过他们的反馈解决产品还存在的问题，并及时更新。为了能够得到用户更加直接的反馈，我们建立了一个用户微信群，用户在群内提出意见，我们及时做出回应。

总结与心得

这学期的软件工程是一门挺“肝”的课程，不管是前期的阅读、调研作业，还是之后的结对编程，再到整个课程的重头戏——团队项目，都花了我大量的时间，但是最终的收获还是非常丰富的。具体技术方面的收获在这里就不细说了，我想谈谈其他的一些想法和感受。

在学期刚开始的阶段，我还时常抱怨罗老师软工班作业太多，相比于其他班，我们多了好多前期的作业，包括为期两周的结对编程，让清明假期都不能好好休息。但是随着课程的推进，我越来越能感受到罗老师班的优势了，其他班的项目大多是由老师确定好了主题，跟着老师的要求一步步完成；而我们的项目完全由自己决定，整个开发过程从需求分析到最终产品发布也由自己把控时间，由于是自己选择的主题，在开发过程中动力也就更多，最后完成整个项目的自豪感也就越强。

再来说说我们的这个团队，在组队时，我并不认识队伍中的全部人，我还能记起第一次组会时大家介绍自己还不太放得开，但是到了前几天我们开的最后一次总结会议时，大家都畅所欲言，各种吐槽、调侃、笑声，会议整整开了3个小时，我们几个靠着这门课成为了一个很紧密的团体。而在具体的开发阶段，每个人都展现出了自己所擅长的地方，7个人各有分工，互相帮助，也没有因为谁的懒惰而耽误进度，大家都朝着最终产品发布的目标努力着。

​此外，因为我们的项目适合中传的同学进行合作的，所以在代码的开发战场上由我们几个拼搏，而在商业推广、美工建模等领域由其他学校的同学提供支持。我们的互相沟通和交流，最终使得产品能够更好地呈现在大家的面前。在未来，这个项目还会继续推进下去，我们和中传同学的合作也会继续下去。

​最后，再一次感谢团队中的每一个成员以及罗老师、任老师，让我收获了一段难忘的软工课经历。