项目	内容
这个作业属于哪个课程	2022北航敏捷软件工程
这个作业的要求在哪里	个人阅读作业-阅读和调研
我在这个课程的目标是	更好理解工程项目，对团队分工合作有个更好的了解
这个作业在哪个具体方面帮助我实现目标	工程部署及合作工具的使用

《构建之法》(第三版)——思考部分

问题1：关于对软件开发的工作量和质量的评估

在原书第49页中提到：

软件开发的工作量和质量怎么衡量呢？

书中给出了4个因素：

a. 项目/任务有多大？
b. 花了多少时间？
c. 质量如何？
d. 是否按时交付？

这四个因素确确实实地涵盖了所有方面，但却没有说明标准应该是什么样的，应该由谁评定，是由团队成员内部互评还是由业内专业人士评价，由谁评定才能获得让所有人都信服的评价。

团队成员内部的互评就显得具有一定的主观性，可能带有感情偏向，不适合作为衡量人选。并且，根据现在的软件更迭的需求来看，这个评估的工作大多都是由用户来给出的。软件的更新都是为了满足客户的需求。几乎所有的应用商城的软件下都有用户的评论，无论好评还是差评。由此来看，似乎用户群体更适合来评定软件的工作量及质量。但是有的应用商城里面并没有表明用户对这款软件的使用时间，有的用户可能只是跟风或者盲目的就下了结论，并没有一个完整的使用体验，甚至有的评论也有可能是水军给的评论，并不具备参考性。这样看来，用户的评论似乎也不能完全说明软件的工作量及质量。相对应的，专业人士的点评就更加客观，更具有参考性。

问题2：如何给别人提供容易接受的反馈

原书中第四章在第92页提到三明治方法：

先来一片面包；
再把肉放上；
再来一片面包；

通过激励提醒再激励的方式来获得一个好的反馈效果。但是，这个三明治方法并不能适用于所有的情况。理想的效果当然是给被反馈者一种安全的环境，让其接受反馈。但是，被反馈者可能会认为这是一种阴阳怪气的说法：你要提出来就早点说，为什么转弯抹角，显得是我拖了你的后腿。在现在的环境当中，我认为，只要不是恶意苛刻，合作中的人都会接受直接了当的建议，而不是希望合作伙伴绕个圈子来提醒自己哪里不合规范或者是做错了。

问题3：分而治之如何分

原书第八章在第185页提出分而治之的策略，也提出了如下几个要点：

1. 保证所有子节点覆盖了全部父节点包含的内容。
2. 保证各个子节点不要相互覆盖。
3. 叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止。
4. 从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发。

我认为，在第二点的表述上作者出现了失误，覆盖有包含的意思，表达的不够准确，应该替换为交叉。分而治之可以说是将整个项目流程进行划分，从底部往上进行整合，但子任务是交由不同角色去完成的，必然会存在着部分子任务完成而其余子任务还在进行中的情况，这时候是让其他人帮助进行未完成的子任务，还是等着负责人独自完成该任务呢。所以第四点中说要从结果出发而不是活动出发去构建WBS，我觉得是存在一部分问题的，预期总是会伴随着一些意想不到的事情。就比如COD17的开发，本来是由动视下的大锤完成开发，但因为人员变动的原因，最后交由T组来完成，以致于COD17因为开发周期只有1年半而被称作“半成品”。原本的开发时间本来是十分充裕的三年，到最后只有一年半。构建一个好的WBS，我认为，应该从结果和活动一起出发，以结果为主，活动为辅，考虑到可能出现的人员变动来制定计划。

问题4：服务质量的说明举例

原书中第十章在第225页中对三峡大坝到底能防多大的洪水给出了几张截图用来代表2003年到2010年大家对此的理解。我觉得此处的例子并不够恰当。

首先，书中给出的截图均是新闻消息的标题，这只能说是媒体对此的理解，而不是群众的理解，要更好的代表群众，应该放上群众评论的截图，而不是媒体新闻的标题。

其次，群众并不一定会完全相信这个标题，一般来说都是将信将疑的态度。否则，对于说法不同的两个标题，群众应该相信哪个？

最后，例子的时间跨度是否太大？从第一个时间2003年到最后一个时间2008年，时间跨度如此之大，几篇文章的参考信息难道还都是同一初始信息？这如何叫以谬传谬？

原本书中可能只是想传达需要清楚说明这个意思，但例子选择稍欠妥当。我认为，对此更好的例子应当是营销号的截屏。将同一时间段下的营销号文章进行对比来做到解释不清楚说明的后果就是人云亦云，以谬传谬。

问题5: 开发者向与会者报道内容

原书第15章的1.2小节复杂项目的会诊在332页中说到：

第一步：开发者提交参加会诊的Bug和修改方案，以及伙伴测试结果。
开发者必须向与会者报告的是：

1. Bug是什么；
2. 危害是什么，如果不修复，有何后果；
3. 用户会有什么变通办法；
4. 是否经过代码复审，是否经过伙伴测试。

在这里，我认为，应该加上一点：Bug是否良性且受用户欢迎，是否需要被修复。

我觉得这一点是非常重要的，就比如GTA5中的摩托飞天术。玩家发现，通过进行有一定规律的按键操作，可以使得摩托车在天上悬浮。由此bug带来的GTA5线上模式中的毒图制作就深得玩家喜爱，这虽然违反了物理定律，但是让玩家体验到了快乐。与之相对的，就是GTA5线上模式的漫长读取过程，有的时候，甚至需要20多分钟，这虽然不能称为bug，但是也影响了用户体验，经人发现，原来是GTA5在读取数据时，读取了开始不必要的数据，即车库的数据，而这消耗了大量的时间，在读取完基本数据之后实际上就可以进入地图中了，在进入后继续读取车库数据即可减少初始登入时间，这就算是一个需要解决的问题。
如果bug并不是恶性的，开发人员就毫不犹豫地将其修复，而用户表示对这个bug很是欢迎，这毫无疑问是向用户泼了冷水。因此，我认为，bug的修复是需要进行考量的。

源代码管理工具调研

GitHub

GitHub是一个面向开源及私有软件项目的托管平台，因为只支持Git作为唯一的版本库格式进行托管，因此叫做GitHub。

GitHub除了Git代码仓库托管及基本的Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱、代码片段分享等功能。其作为一个分布式的版本控制系统，在Git中并不存在主库这样的概念，每一份复制出的库都可以独立使用。GitHub可以托管各种git库，并提供一个web界面，并且在GitHub上，使用者可以找到海量的开源代码。

GitLab

GitLab 是一个用于仓库管理系统的开源项目。使用Git作为代码管理工具，并在此基础上搭建起来的web服务

可通过 Web 界面进行访问公开的或者私人项目。它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用。

可以简单的理解，gitlab 就是支持搭建在本地(公司)服务器上的一个 github。 支持相关的个性化设置和配置，同时gitlab 支持相关的 CI （持续化集成）， 为相关的项目自动化集成构建、测试、部署、交付提供了可能。

CVS

CVS是一个常用的代码版本控制软件，主要会在开源软件管理中使用。一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。

CVS版本控制系统是一种GNU软件包，主要用于在多人开发环境下源码的维护。在一台服务器上建立一个源代码库，可以存放源程序。由源代码库管理员统一管理这些源程序。每个用户在使用源代码库之前，首先要把源代码库里的项目文件下载到本地，然后修改，最后用CVS命令提交。这样一来，就好像只有一个人修改文件，不但避免了冲突，又做到跟踪文件变化情况。

SVN

SVN是一个开放源代码的版本控制系统，是采用分支管理系统的高效管理。它管理着随时间改变的数据。这些数据放置在一个档案库中。这个档案库像一个普通的文件服务器，但是它会记住程序源码的修改以及变动。这样的话，不仅可以把程序源码恢复到改动之前的版本，也可以浏览程序源码的变动历史。SVN系统实现对项目软件的版本控制，一方面是通过实现历史操作记录查阅，而另一方面是通过进行组员间的协同开发以实现对项目软件的版本控制。

异同点

相同点

• 都是面对开源代码的管理工具，隐私的代码需避免上传
• SVN和CVS都是集中式版本控制工具
• GitHub和GitLab都是基于Git的分布式版本控制工具

不同点

• GitHub和GitLab都是基于Git，与另外两个工具不同
• 相较于集中式版本控制工具，Git的优点：
  • 克服 克服网络依赖性：分布式可以进行本地 代码提交。
  • 加强数据安全性：分布式备份多份数据，防止中央服务器宕机。
  • 速度快、简单设计
  • 对非线性开发模式的强力支持（允许上千个并行开发的分支）
  • 完全分布式 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

CD/CI工具调研

GitHub Action

GitHub Action在没有梯子的情况下，使用比较看脸，个人仅用了一个小文件来进行在线编译及运行测试。
代码仓库: 代码仓库test
以下是YAML文件：

# This is a basic workflow to help you get started with Actions

name: test

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  #pull_request:
    #branches: [ main ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - name: checkout
        uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Set Up Python 3.7
        uses: actions/setup-python@v1
        with:
          python-version: 3.7

      # Runs a set of commands using the runners shell
      - name: Run test
        run: |
          python four_dp.py

成功运行截图如下：

GitLab CI

其本质和GitHub Action一致，只是语法有些许不同，但是需要额外为代码仓库配置一个gitlab -runner服务，本人在配置的过程中出现了一些问题，故最后没有一个较好的结果。

两者比较

GitLab CI/CD与页面，问题，程序包注册表集成，具有环境仪表板，审阅支持，手动管道，多项目管道，支持许多不同的报告(例如容器扫描报告)，良好的API，使用能力您自己的运行者，以及许多其他功能。而且，它是开源的。

GitHub Action -简单的CI; GitLab CI/CD-可配置且功能强大的开源CI/CD，具有与不同软件和独特功能的集成。

根据GitLab官网的描述，两者有以下差异：