软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6698 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

40 | 最佳实践:小团队如何应用软件工程?

宝玉 2019-06-04
你好,我是宝玉。经过前期理论知识的学习,你可以开始尝试在实践中去应用所学到的软件工程知识了。
想象一下,现在你要加入一家创业公司,从头组建一个开发团队,一开始只有三五个人,你会怎么去应用软件工程的知识,让你的团队能高效率、高质量地开发软件产品?
或者说,你现在就是在一个小团队,各种流程不规范,开发效率低,软件产品质量不高,你打算怎么去应用学到的知识去改善现状呢?
在这一篇里,我将带你一起运用学过的软件工程知识,看如何在小团队中应用软件工程?(在这里我补充说明一下:本文讨论的小团队,不是指大厂的一个小组,而是小公司或者三五个人的小开发团队)

小团队在软件开发中存在的常见问题

不知道你有没有在小团队工作的经历,如果有的话,建议你可以自己先总结一下:小团队在软件开发中存在的一些常见问题是什么?
为什么说你需要先自己去发现问题呢?因为在学习完软件工程的理论知识后,并不是说你把所有知识点一股脑儿全应用上就解决问题了,而是要先去发现问题在哪,然后针对这些问题,再去应用软件工程的知识去寻找问题的解决方案。
就像小团队如何应用软件工程这个问题,你首先要先找出来小团队的问题在什么地方,然后去分析这些问题可以应用软件工程的哪些知识,从而找到适合你的解决方案。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 幻想
    我觉得两周为一个发布周期,很有可能导致代码质量低下。例如:两周一迭代里,我们可能没有时间在上个迭代里就做好下个迭代需求的分析,只能遗留到当前迭代,这个时候,需求分析、代码设计、接口设计就要花好几天,好了,由于限制死了两周要发布一次,导致测试人员死盯着发布日期,进行倒推,让开发人员尽量在某个时间点提测,不然迭代上线就风险很大,这样就导致了开发这边压力很大很大,开发时间短,代码质量低,提测后,又各种bug,也进而阻碍测试进度,整条线都非常疲惫紧张。最惨的是,由于测试人员急着测试,也未能做到详细测试,就上线了。又是各种线上bug。因此这种两周一上线,会容易让人死盯着上线日期,给全部人员带来很大的压力,相当于是给自己挖矿和约束了。很不应该的

     我觉得软件工程里,开发阶段是最关键的阶段,得给到合理的时间,不然这个阶段被动了,乱了之后,就会产生一系列的不好级联反应。因此,我觉得应该有开发人员来把控节奏,给出工作量,给出哪些可以优先测试。

    作者回复: 👍好问题!你说的担忧完全合理,也确实可能会出现这样的情况。

    我来解释一下为什么2-4周是可行的。我们假设你现在的项目是三个月周期,一共是12周,然后你大约2-3周在需求,2-3周架构设计,4周左右在编码,2-3周测试。

    那也就是说需求分析期间,其实开发、测试做不了啥事,架构设计的时候,主要是架构师在忙,编码的时候,主要是程序员在忙,测试的时候,开发和测试在忙。

    再假设你大概要完成10个功能,也就是这10个功能从设计到开发预计花了10周时间,平均每周一个功能。

    如果换成2周一个迭代,那么我们可以考虑每个迭代只选取2个功能,但是在这两周,整个团队的运作可能是这样的:

    迭代v1.1(2周)
    - 产品设计,准备下一个迭代v1.2的产品设计
    - 开发,设计和开发这个迭代v1.1的功能,同步修复发现的v1.0的Bug
    - 测试,测试上一个迭代v1.0开发好的功能
    - 开发完成后,部署开发完成的v1.1到测试环境
    - 发布测试验收完的迭代v1.0

    迭代v1.2(2周)
    - 产品设计,准备下一个迭代v1.3的产品设计
    - 开发,设计和开发这个迭代v1.2的功能,同步修复发现的v1.1的Bug
    - 测试,测试上一个迭代v1.0开发好的功能
    - 开发完成后,部署开发完成的v1.2到测试环境
    - 发布测试验收完的迭代v1.1


    也就是你差不多还是有两周时间开发新功能,两周时间测试,但是每两周可以发布一个小版本,而且整体节奏比较平缓。

    如果到时间内完不成所有功能,那么就发布完成的,没完成的放到下一个迭代,这样可以保证每周都可以发布。

    配合代码审查和自动化测试以及基于分支开发的流程,可以保证合并后代码质量相对是可靠的。

    如果这样操作有难度的,那么采用4周一个迭代,但是每个迭代功能减少,还是一样可行的。还有每个迭代结束后的上线发布,可以有两种类型,小迭代可以不发布生产环境,只是测试环境,几个小迭代后再发布生产环境。

    也就是说,方法其实是有的,观念上可以先调整,因为这样的迭代周期肯定是可行的。




    2019-06-04
    4
  • Joey
    请教宝玉老师,研发过程文档,是否有必要进行统一模版,比如方案设计文档、功能测试报告等。

    我们公司的现状,整个研发部门1000人左右,如果不设置模版,大家五花八门,别人不好检查;如果设置模版,研发人员又说限制他们的想象力等。

    作者回复: 我倒是觉得有模板的文档好写一点,填空就好了。

    对于文档模板,我没有什么建议,毕竟每个公司情况不一样。

    我经历过的公司没有强制规定要模板的,但会提供两种模板,一种是风格样式的,字体颜色什么的都采用公司品牌的风格;一种是基于内容的模板,把大标题小标题都列出来,写的时候填内容就好了。

    文档审查重点是检查内容,而不是格式。

    2019-06-05
    3
  • hua168
    像小团队比较乱的话,最好是规范哪些关键的地方?
    像我们小团队开发,首先看这个功能也没开发过,如果是开发过,就直接基于以前开发过的代码直接改了。
    然后就导致运维有问题,有些路径没有替换完,
    手工输入命令可以运行,用shell脚本监控,发现程序异常,就重启。
    结果就报错了,用脚本死活启动不起来。然后一发现没有路径及文件,叫开发改,要一拖再拖,都不愿意改。老是说赶其他项目😂😂

    作者回复: 流程规范的建立是一个逐步的过程,发现单个的问题,首先解决问题,解决完后就需要思考一下:是不是可以通过流程规范规避类似问题。

    就拿你这个例子来说,可以先把CI持续集成环境搭起来,然后在发现这个问题后,就针对这个路径的问题,提一个Ticket,要求补上这部分的自动化测试代码。这样以后每次提交代码,CI都会自动运行这个测试,出问题了就能及时发现,不至于到了生产环境再发现。

    开发人员任务多可以理解,但是你需要把这些任务通过任务跟踪系统统一管理起来,写一个Ticket给他,排上优先级。等其他任务忙完,就该把这个任务给做了。

    所以小团队乱,任务跟踪管理、开发规范,这都是需要优先建立的流程规范。

    2019-06-07
    2
  • hua168
    宝哥,像我们之前公司,小团队一个项目就2-3个开发,2-3个项目共用美工、有时甚至前端,公司就一个运维…
    有时候为了赶项目进度,有的开发,只是在很关键的,一般做了个简单的注解。
    两三年基本,原来开发的项目人都走完了。
    如果出现问题,人家都不知道怎么改。
    是不是docker化比较好,但是如果有些客户要更改需求,那是不是没得玩了?

    作者回复: 这种情况跟Docker应该没关系。

    这种情况应该从几个方面着手:
    1. 首先还是代码要规范,日常通过lint工具和代码审查强制代码实现的时候必须满足代码规范
    2. 要有必要的文档,例如设计的文档、架构的文档,可以建一个Wiki,日常有问题就记录在上面,尤其是一些操作手册什么的。

    2019-06-07
    2
  • alva_xu
    就“选择适合你的软件开发模型”,这一点,我谈谈想法。软件开发模型是瀑布还是敏捷对于软件开发管理来说有很大的不同;但即使采用瀑布模型,对于团队管理来说,我们是可以借鉴敏捷模型的。比如,我们可以采用看板管理来提高任务管理的效率和透明度,可以通过站会来加快问题的沟通,对于“建立外部提交需求和任务的流程”我们也可以借助敏捷管理的思路,通过每天站会或者周例会的时候,一起做个新需求评估。对于技术交流,也可以像敏捷团队里说的培养T型技能的人员为目的来开展。而且,先通过团队管理方式的转变,培养大家的敏捷文化,然后再切到敏捷开发模式,就会更加顺畅。我觉得,小团队管理,一定要培养自主自治合作分享的文化和能力,通过用轮值scrum master 的办法,一点点提高这方面的文化和能力。

    作者回复: 赞同,敏捷开发很多实践可以借鉴。另外团队成员的自主自治合作分享的文化和能力也很重要👍

    感谢分享

    2019-06-05
    2
  • Charles
    一直在小团队,最多的时候也就20几个人,然后分成2-3组开发

    碰到最多的问题:
    1. 公司或产品目标不明确,团队凝聚力不强
    2. 需求管理混乱,很多都是拍脑袋的需求,没有可行性分析
    3. 老师文中也提到的人才专业度欠佳,招牛人难,如果像我们二三线城市的那就更困难了

    另外问宝玉老师一个问题,在之前团队管理上的疑惑点,这篇文章中提到的团队内部分享,又让我想起来了,如下:
    小团队可能就10来个人,每个岗位可能就1-2个人,这种情况下做内部分享,希望大家都来参与,那么分享内容不好把控,如果太局限于本岗位知识,其它岗位参与度不高效果也不明显,浪费时间,如果只是本岗位的知识分享,那么就2,3个人讨论下就行了,很是纠结,有什么好办法解决这个问题?谢谢

    作者回复: 可以设定一些学习的课题分享,比如说最近有什么新技术很火,但是大家都不知道是什么,也很想了解,可以让一个人去学习研究,然后跟大家一起分享,分享的过程其实以讨论为主,分享的人也不需要太多压力,自己也能学到东西,其他听的人在讨论的过程中也能学到东西,共同学习提高。你可以从中做好主持的作用,最好提前也学习准备一些。

    2019-06-04
    2
  • 不靠谱的琴谱
    我们公司两个开发,三个老板。项目涉及8种语言(不包含js)。现在基本上是老板提需求我估算个时间直接做,天天催进度,没时间搭建一套自动化的流程;项目上线直接替换指定代码重启就算部署完成;以前别人开发的项目不支持集群,只能大半夜没人的时候发布,重构的成本太高,只能维持现状。看完软件工程感觉不能被这样的公司束缚,我是一个很喜欢自动化的人,包括我自己开发一些代码生成工具,让我更高效的完成任务。

    作者回复: 你说的这种情况其实很普遍,要单独抽时间出来确实不容易,只能是日积月累,一点点改进,一方面要保证现有业务运行,一方面逐步增加自动化比例。

    比如说新项目、新需求、修复Bug,都可以针对性的增加一些自动化测试代码,不用贪多求全,一点点来。

    项目间隙或者其他时间,写一些自动化脚本替代一些重复的体力劳动。

    另外尽可能使用现成的甚至收费的服务,通过简单的配置就可以帮助你实现自动化构建、部署等工作。

    总的来说这些自动化工作都是磨刀不误砍柴工,长远看收益很大。

    2019-08-31
    1
  • 小老鼠
    小公司赚到钱可能是首当其冲的,但需求方总在变需求,又不多给钱,阻碍了其他项目的接单,对于这个问题如何处理。
    2019-11-27
收起评论
8
返回
顶部