软件工程：实际应用

OceanStar的学习笔记

于 2021-12-21 21:22:00 发布

阅读量1k

点赞数 2

分类专栏：计算机理论与基础文章标签： scrum

原文链接：https://time.geekbang.org/

版权

计算机理论与基础专栏收录该内容

310 篇文章 78 订阅

订阅专栏

小团队如何应用软件工程？

成本敏感、人少活多、缺少流程规范，这几个是小团队在项目开发中存在的主要问题。那么在小团队应用软件工程的时候，我们就需要去解决好这些问题。

成本敏感的问题，如果这个是客观存在的，就没有太好的办法去解决，只能说我们在做一些决策、制定流程的时候，需要充分考虑好成本因素，减少浪费。
人少活多，那么我们就相应地提升个人和团队的整体水平和效率。
缺少流程规范，那么我们就建立适合小团队特色的流程规范，让开发流程规范起来。

所以接下来，我就从团队建设、流程建设这两个维度来谈谈如何应用软件工程

团队建设

在实践的时候，最先应该考虑的却是团队建设，因为软件工程上讲的所有的过程、方法和工具，最终还是落地在人身上，需要人去基于开发过程去制定流程遵守流程；需要人去应用软件工程中总结好的方法；需要人去使用工具。如果团队对软件工程缺少认识，那再好的方法和工具也无法落地。

所以要实施好软件工程，也要同步做好团队建设团队建设，绕不开几件事：招人、培养人、管理人和开除人。

招人：难点在于成本有限，开不出很高的工资，品牌也不够吸引人招人的时候相对选择有限
- 比较现实的方法就是招有潜力的程序员培养。
- 在招人时，也不能一味节约成本，还要注意梯队的建设，中间要有几个有经验的技术骨干帮助把控好代码质量。
培养人：小团队不像大公司有完善的培训制度，资源也有限，难以请到外面的人来讲课，所以培养人主要还是要靠内部形成好的学习分享的机制。
- 在大厂，新人加入，通常会指定一个 Mentor，也就是导师或者师傅，可以帮助新人快速融入环境，新人有问题也可以随时请教。这种师傅带新人的机制其实对小团队一样适用，对新人来说可以快速融入，及时获得指导，对于师傅来说，通过带人，也能促进自身的成长。
- 除了有师傅带，新人的技术成长，更多还是来源于在工作过程中不断实践和总结，在这个过程中，及时准确的反馈很重要。软件工程中，像代码审查、自动化测试、持续集成都可以帮助对工作结果进行及时的反馈。
- 代码审查，可以帮助团队及时的发现代码问题，也能促进团队相互学习，代码风格统一；自动化测试，可以对代码结果马上有直观的反馈，有问题早发现修正；持续集成也是通过频繁的集成频繁的给出有效反馈，及早发现代码问题。
- 在小团队推行这样好的开发实践，让团队获得及时准确的反馈，有助于整个团队的成长。
- 还有在分工方面，不要因为一两个技术大牛能干，就把大部分工作都让他们做了。所以最好是让“大牛”一半的精力负责一些重要的像架构设计、框架开发的工作任务，同时还要有一半的精力在代码审查、带新人等方面，帮助其他人一起成长，整个团队的发展才能更健康。
管理人：小团队的管理，核心在于营造好的氛围，鼓励成员自我驱动去做事。
开除人：在这种情况下，首先对于有问题的成员肯定是要努力挽救，如果是能力不足，就给予帮助，给时间成长，对于态度有问题的，明确指出其问题，限期改正。但如果最终结果还是达不到预期的话，那就必须要果断地将这些成员淘汰。

流程建设

对于小团队，一开始也不宜有太多的流程规范，不然，如果流程不合适反而会成为一种束缚，最好只是先设置最基本的流程规范，然后在实践过程中针对团队特点和业务特点去逐步完善。

那么哪些流程是软件开发中最基本的流程规范呢？

（1）选择适合你的软件开发模型

现在的软件开发，已经不再像以前那样采用原始边修边改的开发模型，而是应该采用科学的开发模型
那么小团队应该采用哪种开发模型比较合适呢？
- 敏捷开发是一种非常适合小团队的开发模型，整个开发过程非常有效率。如果能采用敏捷开发是最好的。
- 但需要注意的是，如果你的团队是以瀑布模型为主，大家都有丰富的瀑布模型开发经验，但是对敏捷开发都没有实践过，对于敏捷开发的各项活动还不熟悉，还没能充分理解敏捷的价值观和原则，那么最好不好贸然直接换成敏捷开发。
敏捷开发中哪些实践是适合小团队借鉴的呢？
- 首先在开发周期上，应该缩短交付的时间，使用快速迭代的开发模型。因为小团队的一个特点是需求变化快，要求交付的速度快，那么快速迭代或敏捷开发就是一个合适的开发方式。即使团队习惯了瀑布模型开发，切换到快速迭代也会比较容易，只需要把大瀑布拆分变成小瀑布。
- 具体在实施上，可以缩短并固定开发周期，比如说每 2～4 周可以发布一个版本。在做迭代的规划时，优先选择当前最核心最重要的功能；在一个版本内，不轻易接受新的需求变更，有需求变更放到下一个迭代中；在迭代时间结束了，无论新功能是否开发完成，都按时发布新版本，没完成的放入下一个迭代。
- 通过这样的变化，可以保证在一个迭代中整个团队的开发状态是稳定的，不需要受到需求变更的干扰，也可以慢慢形成适合团队的迭代节奏。
- 另外在会议上，敏捷 Scrum 的几个会议也可以借鉴，像每日站立会议，可以帮助团队及时了解项目进展，解决进度上的障碍；每个迭代的计划会议，可以让大家一起参与到计划的制定中；每个迭代的验收会议，可以让业务部门、老板及时的验收工作成果，看到大家的工作进展；每个迭代的回顾会议，可以帮助阶段性复盘总结，不断优化开发流程。
- 还有基于看板的任务可视化，也可以帮助团队直观的看到当前迭代中的任务进度，可以主动选取任务，而不需要去问项目经理下一步该做什么。

（2）构建基于源代码管理工具的开发流程
（3）建立外部提交需求和任务的流程

小团队在流程规范上混乱的一个体现是，业务部门包括老板对于提交开发任务非常随意，可能直接找某个开发人员私下让改一个需求，增加一个功能，导致开发人员不能专注于任务开发，经常被打断。还有多个项目并行而资源又紧缺的情况下，每个项目负责人都觉得自己的业务是最重要的，希望能尽快完成。这很容易出问题
软件项目开发中，无论开发任务有多少，只要你将这些开发任务排成队列，就可以有序地解决。如果一个业务团队的开发任务特别紧急要插队，那么意味着其他业务团队的任务就必须要受影响，那么就需要大家一起去协调。如果你不去通过流程规范任务，那么任务一多，必然就会乱成一团，无论是开发团队内部还是外部，都不会满意。
解决方法是建立外部提交需求和任务的流程，让所有人都基于任务跟踪系统去提交需求和开发任务，所有任务都先进入 Backlog（任务清单），然后在每个开发迭代中，去按照优先级选择当前迭代的任务，如果有优先级的冲突，应该需要事先沟通解决。对于提交需求和任务的人，也能通过任务跟踪系统，及时的了解到任务的进展。

以VS Code为例，看大型开源项目是如何应用软件工程的

VS Code 的开发迭代过程

如果你是 VS Code 的用户，你会发现 VS Code 每个月都会有新版本的更新，每次更新都会有很多新酷的功能。这是因为 VS Code 每个版本的开发周期是 4 周，每四周都会发布一个新的版本。

从开发模式来说，VS Code 采用的是快速迭代的开发模式，每四周一个迭代。那么这四周的迭代的工作都是如何进行的呢？

（1）第一周

每个版本的第一周，通常是起着承上启下的作用，一方面要准备新版本，一方面还要对上一个版本的工作进行收尾。
在这一周里，开发团队要去做一些偿还技术债务的事情，比如说重构代码，优化性能。所以如果你的团队抱怨说没有时间做偿还技术债务的事情，不妨也去学习 VS Code 团队，定期留出专门的时间，做偿还技术债务的事情。
另一个主要工作就是一起讨论下一个迭代要做的功能。其实这有点类似于敏捷开发中，每个Sprint 开始之前的项目计划会议。
如果上一个版本开发完成的功能，发现了严重 Bug，第一周还要去修复这些紧急 Bug。

（2）第二周和第三周

第二周和第三周主要工作就是按照计划去开发，一部分是开发新功能，一部分是修复Bug，所有的 Bug 都是通过 GitHub 的 Issue 来分配和跟踪的。
团队成员每天还要先检查一下分配给自己的 Issue，如果遇到线上版本紧急的 Bug，要优先修复。

（3）第四周

VS Code 团队把最后一周叫 End game，你可以理解为测试周，因为这一周只做测试和修复 Bug。
这一周要测试所有新的 Feature 和验证已经修复的 Bug，确保被修复。同时还要更新文档和写 Release Notes。
测试完成后就发布预发布版本，这个预发布版本会先邀请一部分人使用，比如说微软内部员工、热心网友。

（4）下一个迭代第一周

每个迭代开发测试完成的版本，会放在下一个迭代的第一周发布。如果在预发布版本中发现严重 Bug，需要在第一周中修复。
如果没有发现影响发布的 Bug，那么第一周的周三左右就会正式发布上一个迭代完成的版本。

VS Code 团队的角色和分工

VS Code 的开发团队现在大约 20 人左右，一半在苏黎世，一半在西雅图。整个团队基本上都是开发人员，结构很扁平。

从分工上来说，在开发新功能和修复bug的时候，会有一些侧重，比如有人侧重做git相关的功能，有人侧重做编辑器部分功能。这样有侧重的分工对于提升开发效率是有好处的。

从角色上来说，除了开发，还有主要有两种角色：Inbox Tracker和Endgame Master。这两种角色在每个迭代的时候是轮值的，每个人都有机会去担任这两个角色。

（1）Inbox Tracker

Inbox Tracker 的主要任务就是收集、验证、跟踪 Bug。但这个工作对于 VS Code 团队来说可不轻松，现在 Issue 的总量已经超过了 5000，每天提交的新的 Issue 的量大概有 100左右。所以 VS Code 团队写了一个机器人叫VSCodeBot，可以帮助对 Issue 先自动处理，打标签或回复，然后 Inbox Tracker 再对剩下的 Issue 进行人工处理。
Inbox Tracker 要检查新提交的 Issue 是不是一个真正的 Bug，如果是提问，建议到StackOverflow 去问，如果是 Bug，打上 Bug 的标签，并指派给相应模块的负责人。

（2）Endgame Master

VS Code 团队是没有专职的测试人员的，所有的测试工作都是开发人员自己完成。在每一个迭代中。Endgame Master 在这里就很重要，要组织管理整个迭代的测试和发布工作。
Endgame Master 在每个迭代测试之前，根据迭代的开发计划制定相应的测试计划，生成Check List，确保每一个新的功能都有在 Check List 中列出来。
因为 VS Code 团队没有专职测试，为了避免开发人员自己测试自己的代码会存在盲区，所以自己写的功能都是让其他人帮忙测试。Endgame Master 一个主要工作就是要将这些测试项分配给团队成员。
最后整个测试计划会作为一条 GitHub Issue 发出来给大家审查。比如说这是某一个月的Endgame 计划。
团队的日常沟通是通过 Slack，在测试期间，Endgame Master 需要每天把当前测试进展同步给所有人，比如说总共有多少需要测试的项，哪些已经验证通过，哪些还没验证。

VS Code 的各个阶段

接下来，我们来按照整个开发生命周期，从需求收集和版本计划、设计开发、测试到发布，来观察 VS Code 各个阶段是如何运作的。

VS Code 的需求收集和版本计划

VS Code 每次版本发布，都能为我们带来很多新酷的功能体验，那么这些功能需求是怎么产生的呢？又是怎么加入到一个个版本中的呢？

VS Code 的需求，一部分是团队内部产生的；一部分是从社区收集的，比如 GitHub、Twitter、StackOverflow 的反馈。最终这些收集上的需求，都会通过 GitHub 的 Issue 管理起来。如果你在它的 GitHub Issue 中按照feature-request的标签去搜索，可以看到所有请求的需求列表。
VS Code 每半年或一年会对下一个阶段做一个Roadmap，规划下一个半年或一年的计划，并公布在 GitHub 的 WIKI 上，这样用户可以及时了解 VS Code 的发展，还可以根据Roadmap 上的内容提出自己的意见。
大的 RoadMap 确定后，就是基于大的 RoadMap 制定每个迭代具体的开发计划了。前面已经提到了，在每个迭代的第一周，团队会有专门的会议讨论下一个迭代的开发计划。在VS Code 的 WIKI 上，也同样会公布所有确定了的迭代计划。

那么，有了功能需求和 Bug 的 Issue，也有了迭代的计划，怎么将 Issue 和迭代关联起来
呢？

GitHub 的 Issue 管理有一个 Milestone 的功能，VS Code 有四个主要的 Milestone。

当前迭代：当前正在开发中的 Milestone；
On Deck：下一个迭代对应的 Milestone；
Backlog：还没开始，表示未来要做的；
Recovery：已经完成的迭代，但是可能要打一些补丁。

VS Code 的设计和开发

VS Code 的架构设计现在基本上已经定型，你在它的 WIKI 和博客上还能看到很多 VS Code 架构和技术实现的分享。

在每个迭代开发的时候，一般小的功能不需要做特别的架构设计，基于现有架构增加功能就好了。如果要做的是大的功能改造，也需要有设计，负责这个模块开发的成员会先写设计文档，然后邀请其他项目成员进行 Review，并给出反馈。
VS Code 的开发流程也是用的GitHub Flow，要开发一个新功能或者修复一个 Bug，都创建一个新的分支，开发完成之后提交 PR。PR 合并之前，必须要有核心成员的代码审查通过，并且要确保所有的自动化测试通过。
VS Code 对自动化测试代码也是非常重视，在实现功能代码的时候，还要加上自动化测试代码。VS Code 的自动化测试也分为单元测试、集成测试和冒烟测试。
VS Code 的CI（持续集成）用的是微软自己的 Azure DevOps，每一次提交代码到GitHub，CI 都会运行单元测试和集成测试代码，对 Windows/Linux/macOS 三个操作系统分别运行测试。在持续集成上可以直观地看到测试的结果，VS Code 现在有大约 4581个单元测试用例，运行一次 1 分钟多；集成测试 466 个，运行一次大约 3 分钟。

VS Code 的测试

迭代的最后一周是 End game，这一周就是专门用来测试的，并且有轮值的Endgame Master 负责整个测试过程的组织。

具体测试的时候，大家就是遵循 Endgame Master 制定好的测试计划，各自按照 Check List 逐一去检查验证，确保所有的新功能都通过了测试，标记为修复的 Bug 真的被修复了。对于验证通过的 Bug，在对应的 Issue 上打上 verified 的标签。
在人工测试结束后，Endgame Master 就需要跑冒烟测试，确保这个迭代的改动不会导致严重的 Bug 发生。

如果你的团队也没有专职测试，可以学习 VS Code 这样的做法：留出专门的测试阶段，事先制定出详细的测试计划，把所有要测试的项都通过测试跟踪工具跟踪起来，开发人员按照测试计划逐一测试。

VS Code 的发布流程

在 Endgame 测试后，就要从 master 创建一个 release 分支出去，比如说 release/1.10，后面的预发布版本和正式版本包括补丁版本都将从这个 release 分支发布。
如果在创建 release 分支后发现了新的 Bug，那么对 Bug 修复的代码，要同时合并到master 和 release 分支。每一次对 Release 的代码有任何改动，都需要重新跑冒烟测试。
在 Release 分支的代码修改后的 24 小时之内，都不能发布正式版本。每次 Release 代码修改后，都会发布一个新的预发布版本，邀请大约两万的内部用户进行试用，然后看反馈，试用 24 小时后没有什么问题就可以准备发布正式版本。
发布正式版本之前，还要做的一件事，就是 Endgame master 要写 Release Notes，也就是你每次升级 VS Code 后看到的更新说明，详细说明这个版本新增了哪些功能，修复了哪些 Bug。
如果版本发布后，发现了严重的线上 Bug，那么就要在 Release 分支进行修复，重新生成补丁版本。
除此之外，VS Code 每天都会将最新的代码编译一个最新的版本供内部测试，这个版本跟我们使用的稳定版 Logo 颜色不一样，是绿色的 Logo。VS Code 内部有“吃自己狗粮”（eat your own dog food）的传统，也就是团队成员自己会使用每天更新的测试版本 VS Code 进行开发，这样可以在使用过程中及时发现代码中的问题。

像 VS Code 这样的发布流程，通过创建 Release 分支可以保障有一个稳定的、可以具备发布条件的代码分支；通过预发布内部试用的机制，有问题可以及时发现，避免造成严重的影响。

VS Code 使用的工具

VS Code 的源代码管理工具就是基于 GitHub，整个开发流程也完全是基于 GitHub 来进行的。

它的任务跟踪系统是用的 GitHub 的 Issue 系统，用来收集需求、跟踪 Bug。通过标记不同的 Label 来区分Issue 的类型和状态，比如 bug 表示 Bug，feature-request 表示功能请求，debt 表示技术债务。通过 Issue 的 Milestone 来标注版本。

VS Code 的持续集成工具最早用的是Travis CI和AppVeyor，最近换成了微软的Azure Pipelines

VS Code 的文档一部分是用的 GitHub 的 WIKI 系统，一部分是它网站的博客系统。WIKI主要是日常项目开发、维护的操作说明，博客上更多的是一些技术分享。

另外 VS Code 团队还自己开发了一些小工具，比如说帮助对 Issue 进行自动处理回复的GitHub 机器人 VSCodeBot。

总结

VS Code 使用的是快速迭代的开发模式，每四周一个迭代：

第一周：偿还技术债务，修复上个版本的 Bug，制定下一个版本的计划；
第二、三周：按照计划开发和修复 Bug；
第四周：测试开发完成的版本；
下一迭代第一周：发布新版本。

在团队分工上，VS Code 的团队很扁平，没有专职测试，通过轮值的 Inbox Tracker 和Endgame Master 来帮助团队处理日常 Issue 和推动测试和发布工作的进行。

在工具的使用方面，VS Code 使用的是 GitHub 托管代码，基于 GitHub Flow 的开发流程使用的。还有使用 Azure DevOps 作为它的持续集成系统。

为什么程序员的业余项目大多都死了

失败原因

想法大，时间少；
过于追求技术，缺少约束；
缺少产品能力和运营能力

怎样提升业余项目成功的概率？

针对想法大、时间少的问题，可以借助软件项目金三角的理论，去缩小范围，在做项目时，可以采用 MVP 的开发模式，先实现核心需求，再逐步增加功能。
针对过于追求技术、缺少约束的问题，应该要对你的项目制定计划，设定里程碑，把时间点告诉你的家人和朋友，让他们监督你执行，通过 Dead Line 来保障项目的进度。
针对缺少产品能力和运营能力的问题，需要有针对性地去学习相关知识，也可以去组建小团队，弥补这些方面能力的不足。

为什么程序员应该做一些业余项目

强烈的建议你多尝试做一做业余项目。因为做业余项目，即使项目失败了，一样可以让你收获很多：

通过业余项目，你可以学习和使用工作中不会使用的技术。你工作中做后端开发，你业余项目完全可以体验 iOS App 开发。
通过业余项目，你有机会去按照自己的想法去实现。很多时候在工作中，因为你无法去做决策，无法改变架构的设计或产品的设计，而在自己的业余项目中，你可以完全按照自己的想法去尝试，去证明自己。
通过业余项目，可以锻炼你的大局观和工程思维。当你真的去自己负责一个项目时，就会更多地去站在项目的整体去思考一个项目，而不是局限于专业领域。
通过业余项目，帮助你更好地在项目中沟通。在做过业余项目后，在工作中，和产品经理、测试沟通，你会更懂他们，因为他们的工作你也体验过了，你会体会到他们的工作其实不像你最初想的那么容易。

失败的软件项目

什么样的软件项目算是失败的项目？

项目管理协会（PMI）认为成功的项目必须满足六个条件：

按时交付。
成本在预算范围内。
能按照当初的设计正常运行。
有人使用。
满足项目最初的目标。
项目出资方对项目满意。

相应的，如果上面有一个或者多个条件没有满足，那么项目就有可能是失败的，比如说：

没能按时交付。
成本超出预算。
Bug 太多，无法按照当初的设计正常运行。
产品没有得到市场认可，没有人使用。
产品偏移了最初的目标。
项目出资方不满意。

而那些特别失败的项目，往往是多个条件甚至所有条件都不能满足，并且时间、成本、交付结果跟最初目标都相差很大，无疑都造成了巨大的损失。

分析失败软件项目的原因

对于一个失败的软件项目案例，要去分析：外部环境、技术管理、项目管理和组织文化，这样才能帮助你找到项目失败的根源。

外部环境

如果你去看看历史上那些有名的失败的项目案例，其中政府主导的项目占大多数，而且通常主要因素不是成本，而是各种政治因素导致的不切实际的项目进度，或者是频繁变更的需求，从而严重的影响了成本和质量。
而对于商业软件项目，很多是由于缩减成本导致的。因为商业竞争的大环境，企业为了节约成本，总是希望用更少的人做更多的事情。
还有一些常见的场景就是在一个项目开始之前，销售为了拿下项目，通常会过度夸大项目的成果，而又会相应的压缩项目预算、时间，并且也可能低估了技术实现的难度，最终项目要开发的时候，开发人员才发现根本无法如期完成当初承诺的项目目标，最终导致项目失败。

技术管理

很多软件项目失败的原因是技术原因导致的。

比如说在项目中使用了不成熟或不熟悉的技术，最终导致技术不可控，或者浪费大量的时间在技术的学习上。
项目的规模也会导致技术复杂度直线上升，想象一下，做一个普通的个人网站和做一个淘宝这样的网站，复杂度不可同日而语。通常越大的项目，技术越复杂，需要考虑各种软件硬件的交互，服务之间的耦合。也就是说，项目规模越大，失败的概率也更大。