软件工程:实际应用

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

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

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

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

团队建设

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

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

  • 招人:难点在于成本有限,开不出很高的工资,品牌也不够吸引人招人的时候相对选择有限
    • 比较现实的方法就是招有潜力的程序员培养。
    • 在招人时,也不能一味节约成本,还要注意梯队的建设,中间要有几个有经验的技术骨干帮助把控好代码质量。
  • 培养人:小团队不像大公司有完善的培训制度,资源也有限,难以请到外面的人来讲课,所以培养人主要还是要靠内部形成好的学习分享的机制
    • 在大厂,新人加入,通常会指定一个 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)认为成功的项目必须满足六个条件:

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

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

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

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

分析失败软件项目的原因

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

外部环境

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

技术管理

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

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

项目管理

很多项目失败不是因为外部环境导致的,也不是技术原因,而是因为糟糕的项目管理。

在一个软件项目中,项目经理掌握了资源的分配,还要制定项目的计划,对任务进行分配,组织分工协作,管理风险,项目成员的日常沟通等等。而这些决策通常很难量化,需要基于当时的情况进行权衡,一旦这些决策出现大的失误,就会导致项目的失败。

组织文化

在软件项目中,一个开放、平等、注重沟通协作的团队或组织更容易及早发现和解决问题。

如果细化一下,还可以总结出一些具体的常见的失败原因:

  • 不切实际或者不明确的项目目标;
  • 对项目所需要的资源估算不准确;
  • 需求不明确或者频繁变更;
  • 没有对风险进行有效管理;
  • 和客户之间沟通不畅;
  • 无法解决项目的复杂性;
  • 没有好的开发实践;
  • 糟糕的项目管理;
  • 上层的政治斗争;
  • 商业压力

软件工程是过程控制的方法论,而产品设计才是保证伟大的产品,两者应该结合

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值