| 项目 | 内容 |
|---|---|
| 课程：北航-2020-春-软件工程 | 博客园班级博客 |
| 要求：正所谓"实践是认识的来源、目的、动力以及检验认识真理性的唯一标准"，在经历了一个学期的学习和实践后，请大家写一个提问回顾与个人总结的博客。 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 提升团队管理及合作能力，开发一项满意的工程项目 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾与反思，实践后认知的深化 |
小组博客链接：NAG2020
一、提问回顾
- 链接到以前提问题的博客：SE_Work1_阅读构建之法&项目管理实践
- 请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
- 是否原来的问题还不明白？如果有，请分析。
- 是否产生了新的问题？如果有，请提出。
1. 何谓工程项目？——科学与工程再反思
经过一个学期所学，发现工程项目，与科学研究之间有着明显的沟壑。
单单从人数上看，一个人是无论如何也不可能在短时间内完成工程项目的快速迭代，包括：实时要跟踪用户的需求、设计软件工程的功能规格、掌握开发项目所需的所有技术、稳定而高质量地实现各个模块的代码、做充分项目的测试、还要部署和发布、在各个平台上宣传等。
单单是部署一个DRF项目，如果不事先了解一下Django的基础知识，掌握uwsgi，nginx的工作机制，可能一个人配置几天都成功不了。要想一个人完成以上所有工作，即使是一个全栈工程师，还对用户的需求了解得很清晰，发布宣传的渠道也相当充足，关键是还有充足的时间和精力去开发……
想想都不太可能，没有人什么都会，即使什么都会，也不可能什么都做，根本没有那个时间和精力，能在一个工程项目有效的生命周期内完成。对于一个工程项目来说，最重要的反而不是代码本身，而是管理。软件项目管理就是如何使得一个项目使用最少的资源最快地开发出最好的质量，而且尽可能满足用户需求。
2. 实践出真知——团队模式再反思
我们所认知的可能很丰富，但我们真正实践起来却完全是另一个故事。理想中的团队模式：一个较大的团队是有很多较小的团队完成的。对于大团队犹如一个交响乐队，小团队犹如一个功能团队或者业余剧团。
| 编号 | 模式 | 描述 |
|---|---|---|
| 1 | 交响乐队 | 种类齐全，成员靠谱 |
| 2 | 功能团队 | 按功能划分，频繁互动 |
| 3 | 业余剧团 | 一人导演，其余演员 |
当我们真正6人或7人小组开始项目的时候，发现小团队成员之间的耦合性还是相当强的，如何划分就成为一个重要的问题。
团队(alpha)阶段，最开始划分为前端和后端两个部门，单独学习、开发各自的功能，类似于一种“功能团队”：前端+后端+PM，但实际上很多功能是必须前后端结合的（即使是Django Rest Framework也是有着相当的耦合性）。后端的Django连接着数据库，也对前端的请求进行回复，前端的需要给后端发送请求并接受回复，在页面上展示。如果将前后端分离，造成了任何一个功能都不能单独开发，而最后集成是付出的时间和精力代价是相当大的。
在(eta)阶段划分为三个功能开发小组，每个功能开发作为一个小组，各个小组之间互不相关，基本上做到了解耦。确实得到了不少进步，核心的功能集中开发完成了。而在(eta)最后的稳定阶段，团队形成了一种"业余团队"模式，PM导演，其余组员成为了bug修复、辅助开发的“演员”，角色都安排得清清楚楚，通过在github上开issue分配到人，也得到了较高的效率。
至于真正怎样做比较好，更多地还是实践起来慢慢改善和调整。不管我们看过多少这样的案例，思考了多少。不结合具体的实际情况，也只能是空想，对于最终实现的效率毫无益处。
团队模式也不总是一成不变的，可能在不同时期，使用不同的模式，如果思维僵化，拘泥于一种模式，反而为导致低效。同时我们也不要盲从他人提出的模式，而应该自己创造一种新的、高效的、适合自己团队的模式。比如以程序代替管理。
3. 个人对团队的影响
可以在你的软件工程项目中好好观察。 在一个软件项目中，有些人的作用是短暂的，例如给UI 做各种语言翻译的人， 但是他们的工作做不好， 也会给项目带来巨大的损失。
当我用乐团与软件工程队伍类比时，老师提出以上的建议。实际上两者虽然有着相似之处，但可比性不大（我们作为外行，也不好说乐团有着怎样特征）。
一个人对于团队来说，可能有以下几种类型：
- 作为团队的中流砥柱，一旦此人离开团队，团队的组织就会涣散，或者没有动力，没有人能够替代TA
- 作为团队的强力支持人员，虽然此人离开后团队不会解体，但开发速度会减慢，工程质量会降低
- 作为团队的辅助人员，对团队各项杂物有支持的作用，即使离开了其他人也能代替，只不过更辛苦一点
- 团队中不可靠的成员，安排某项任务不完成，拖慢工程进度，一连几天没有消息，布置的任务完成的质量较差
这样分类并不意味着团队的中流砥柱就一定不会犯错了，是人都会有错误，可能在某些任务上做的不好，从而使软件项目的质量变差。
但是作为一整个团队来说就不一样了，有他人协同，一个功能的实现，可能会有多人进行复审。如果“给UI 做各种语言翻译的人”工作做的不好，但是其他人测试时发现了，又即使修复了，当然也不算是“一个人坏了一锅汤”。
关键是第四类人，这种人在组内的存在就基本上毫无意义。作为NAG团队的PM，在此深有体会：
老师助教都知道，在α阶段，虽然我们是7个人，但是由于组员不配合，最后实际上是5个人在开发。为了与两个人取得联系花了不少精力，造成了不必要的困难。我们不可能奢望组内的所有成员都是第一类或第二类人（如果是的话，PM的地位就不保了)，但是尽可能避免第4类人在组中，耽误小组的进度。
当然，作为PM也需要对组员有十足的包容心，一次工作做的不好、或者一次没有回复，需要有足够的耐心。最重要的是要有一个合理的评价指标，让最后的得分能够充分反映组员到底是1-4中哪一类人，让努力的人无怨言，让无所作为的人承担自己行为的后果！这一点我认为我们做得还挺好，见团队贡献分分配规则。
二、学习“知识点”
- 软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。
- 请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。
1. 需求
需求一定要明确：在α阶段互相之间可能存在误解，因为需求不是非常明确。在β阶段进行了改进，我们最初完全以目标驱动，将所有人分为了封装、模型市场、模型推理三个核心功能开发小组。除了小组每星期3次同步会以外，各小组每周都会自行开3次小会。
2. 设计
MVP原则：通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。MVP对于创业团队来说是很重要的，可以快速验证团队的目标，快速试错。我们(eta)阶段在新功能的选择上，根据用户的反馈决定开发封装、模型推理、模型市场等功能。
核心功能优先完成：由于α阶段人手不足，我们放弃了很多功能的开发。在β阶段一开始的开发阶段集中完成核心功能，能肯定核心功能一定能完成。在后续稳定和测试阶段修复bug、调整界面、开发部分辅助功能。
3. 实现
人员和任务的分配十分重要：在我们的开发过程中，开发人员需要根据自己的情况来对PM分配的工作提出建议。在每次例会中，我们都会分配下一个阶段的任务，如果任务分配得不均匀，那么会导致工作效率的下降。但实际上，即使分配得相对均匀，依然存在部分组员很早能完成，而另一部分不能完成的现象。可能任务的分配并不是完全讲究均匀的。
github项目管理isuue的作用：在α阶段，github平台每人一个功能分支，相互之间可能有冲突，没有他人检查直接merge，并且开的issue没有和PR进行关联。在β阶段有了显著的改进，基本上所有的提交都通过PR的形式，并且尽量做到了与issue的关联，虽然并不是所有的都严格这么执行的，但是比起前一阶段有了大幅改进。
4. 测试
专门的测试人员：只有单元测试、或者PM的检查是不足够的，如果没有独立的测试人员，从用户的角度出发验证此产品质量，将会使项目出现低效停滞的现象（如下图）。独立专业的测试等同于代表客户对产品的认证，不可或缺。
5. 发布
用户数目是检验产品质量最重要的标准。对于一个商业项目来说，即使有了高质量的代码和项目管理，也能满足相当一部分人的需求，但是不宣传，不推广照样不能达到项目的初衷。因此要做到全面，大力的推广。
6. 维护
要时时刻刻了解用户的需求，对于用户的反馈做及时的产品调整，不然顾客群体会流失。
三、心得
- 结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
软工课程的的确确是实践性质相当强的一门课，而且也布置了相当多的博客作业，让我们在做中反思，不断吸取经验。
1. 个人项目
个人项目的难度并不高，总体上就是编个程序。但由于需要严格遵循软件开发的流程，尤其是测试环节变得非常重要。因为最后的软件是不会有专门的评测机供检测代码，而在发布软件之前就需要对软件进行充分的测试。
2. 结队项目
因为和组员没配合好，独立完成了结队项目，在SE_Work3_结队项目中有较为详细的描述。
使用远程桌面的方式真的对结队的打击很大，有诸多不方便的地方。最后我同时做了核心计算模块与UI模块（整个项目都是独立完成），发现也不是很难，而且通过自己编码更好地掌握。
结队项目让我充分了解到项目模块化带来的优势，核心计算模块和UI模块之间能够做到耦合度非常的低，以至于在商定好接口后，和其他结队交换毫无困难。
3. 团队项目
作为团队的PM，遭遇两个组员“失联”，天天开会、写博客，参与项目的需求、设计、开发、测试、发布、稳定全过程，坚持到项目结束，总与能松口气了。想想仅仅是团队项目就为了软工课花费了远超100个小时时间，更远远超过课程本身的学时，在此期间，写了多少博客、开了多少会议我都数不清了。
虽然投入了这么长的时间和这么多的精力，收获也是相当丰富的。至少，组织管理方面、与其他人交流合作方面，更加能自信地展示自己的项目，表达自己的优势所在。感谢课程提供这么好的机会学习，不知不觉中就带领着小组开发了一个大的工程项目，一个人凭自己的能力是无论如何也没法达到的。