软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 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讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

12 | 流程和规范:红绿灯不是约束,而是用来提高效率

宝玉 2019-03-23
你好,我是宝玉,我今天想与你讨论流程和规范的价值,以及如何参与制定好的流程规范。
不知道你所在的软件项目中是不是也有各种流程规范,例如:
开发人员不能直接在生产环境修改代码操作数据库,必须在本地先测试验证后,由运维操作;
代码需要 Review 通过才能合并主分支;
代码需要遵守各种规范,像命名、格式,还有缩进用几个空格还是 tab 的细节问题;
遇到 Bug,先提交到 Bug 跟踪系统。
在我经历的项目中,或多或少都会有各种各样的流程规范,而且越是大的、正规的项目团队,流程规范越是多。
然而很多人对于流程规范并不是很理解,甚至觉得是一种约束。

为什么要有流程规范?

从某种程度上来说,流程规范确实是一种约束:约束了我们如何做一件事,约束了我们用什么标准做事,约束了我们用特定的顺序做事。
既然如此约束我们,为什么还要有流程规范呢?

提升团队效率

从个体来看,因为流程规范的存在,确实可能存在效率降低的情况,但从团队的角度来看,好的流程规范反而是提升效率的。
这其实很像我们生活中的红绿灯,用一个简单的规则:红灯停绿灯行,来约束车辆行人按照指示灯行进。
从单个车辆来看,看似是因为红绿灯的存在而影响了效率,但是从整体来看,因为红绿灯的存在,有效避免了拥堵,反而是提升了大家出行的效率。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(20)

  • kirogiyi
    流程和规范相当于国家的法律法规,制定不好引起矛盾,执行不好引起反抗。

    良好的流程和规范的制定,需要根据当前公司文化、发展方向、人才培养等几方面综合考虑。从公司角度来看,长远发展、快速发展是第一位;从员工的角度来看,舒适度、积极性、成长空间、既得利益是第一位。但怎么来控制这两者之间的平衡,宝玉老师能否帮忙指点一下?

    作者回复: 这是个好问题。

    员工利益和公司利益其实大部分都是一致的,否则也无法走到一起。公司发展,员工才有机会成长,获得更多利益;员工成长,公司也会有更大发展。

    作为管理者,不能一味站在公司利益不考虑员工利益,这样的管理者得不到拥戴;也不能一味站在员工利益不考虑公司利益,这样的管理者公司是不喜欢的。

    皮之不存,毛将焉附。首先要带领团队为公司创造价值,然后才能有更多话语权,从而可以帮助员工谋取更多福利,帮助他们成长。

    供参考。

    2019-03-24
    6
  • 纯洁的憎恶
    流程规范是工业化大协作的基础,它不仅可以提高整体效率、细化分工协作、人治变法治,且标准统一、易扩展推广,还具备极大自动化潜力。

    通过共商流程规范,让客户、产品经理、项目经理、开发等角色充分参与到需求变更过程,从而高效寻找到各方均能接受的平衡点。这个思路令我眼前一亮!感谢老师🙏

    不过细想起来,在具体执行中依旧会遇到各方僵持不下的局面。当然这就不仅仅是流程规范的问题了。可能需要从其他方面想办法了吧?

    作者回复: 👍其实我没说啥,是你自己想到的思路😅

    需求变更的话题,我会在后面章节(20 | 如何应对让人头痛的需求变更问题?)再细讲,帮你分析背后的动机,从而找到可能的解决方法,除了流程规范,其实还有其他办法可想。

    2019-03-23
    5
  • hua168
    我之前一个公司没有运维,一接手,那个乱呀:
    1.放网站没有统一路径,还好网站目录放在一个大目录中,
    2.到处乱挂NFS,空间不够就挂NFS来解决😓,而且没有放进开机启动里,弄的服务器出问题都不敢重启!😂
    3. 每台服务器上面都不知道装哪些东西,要一个一个进程去查!😭
    后来统一迁移到阿里云,共花了我5个月时间😢,我简单做了规划,
    1)统一网站、日志、软件安装目录
    2)系统管理FTP
    3)弄一套简单的服务器规范,如目录、命名、使用规范

    老师接触过运维流程吗?能简单说下吗?

    作者回复: 你这已经做的很好了👍

    我没运维经验,我的建议是:
    你的运维,一定要尽可能脚本化自动化,比如说,脚本规定好放在什么目录,你不需要人工去放这些目录,每次部署的时候,将程序打包好(需要定义好格式),然后执行你的部署脚本,自动放到应该放的地方、自动更新配置文件。
    自动化才是最好的流程!

    2019-03-23
    3
  • 起而行
    Python的缩进机制为代码设立了很好的规范。在开始,认为Python的缩进要求苛刻降低了灵活性。但后来,看到c++的大型项目中,大括号的风格各式各样,可读性低,难以辨认。这才知道,Python的缩进规范,能使得别人阅读源码时,能更好地接受他人风格。
    当然,另一方面,在大型项目上,也很少有人使用python

    作者回复: Python我用的少,现在写js代码,每次保存文件的时候vscode自动把代码格式的整整齐齐漂漂亮亮的,感觉特别好!

    2019-03-23
    3
  • 起而行
    可能在学校的小组合作课设里,如何分工是个较大的问题。并且经常难以分工,比如3个人的小组,课设要求做数据爬取和数据分析,而组内三个人对这两项基础都是现学现用。这个时候做数据爬取的同学做完后,可能看不到数据分析的同学付出了多少,任务量是多少,有可能造成双方认为对方做得少了,有什么好的解决办法吗?

    作者回复: 在用《构建之法》当教材的学校,做项目,一个阶段后要换组的,这样可以去体验一下其他人做的事情。

    我觉得这个可以借鉴一下,把课设分成几个阶段,到一个阶段了换一下分工,应该可以很好解决。

    供参考。

    2019-03-23
    3
  • titan
    我 曾经写过一篇文章:论企业管理的核心,请老师指正:
    https://mp.weixin.qq.com/s?__biz=MzU2MzgxNDYwNQ==&mid=2247483679&idx=1&sn=b62016eb0397d0eceb23afafd211fcd6&chksm=fc55c8bdcb2241ab804a72aab715415238bd41ecc9dbb530998e5befbcb888723feab5a51b02&token=204486878&lang=zh_CN#rd

    作者回复: 已拜读,写的非常好👍
    而且已经超越了项目管理,到了企业管理的高度。

    其中的企业规章制度和项目的管理流程还是有很多相似相通之处

    2019-03-25
    2
  • Charles
    目前小团队更多的还是依赖于人,流程规范也有,像老师课程里说的很多规范没有执行到位,有点像摆设!比如有版本概念,版本目标也比较清晰,口头+issue,也有git工作流(改进版),但是总感觉版本细节任务不够清晰,时间估算可能不准,没有站立会议也没有日报几天才会了解进度更多靠自觉,经常版本延误!

    想参考老师课程中讲的项目管理工具从任务、所属人、时间和进程排序上下点功夫,另外就是站立会议好像不大适合5,6人团队有点太过正式,想主动在上午了解下每个人进度之类的,看看效果是否好

    再有就是目前感觉一些工具和服务反而用的挺好,git和工作流、持续部署等,上线不操心,其他跟着老师的课程慢慢尝试🙏

    作者回复: 站立会议我强烈建议你开一下,5-6人其实刚好的,超过7个人就要考虑分开开了,一起15~20分钟就结束了,组织的好,可以实时了解进度,及时发现障碍。

    前期可以先试行一段看看效果,主持的时候不要发散:重点说做过什么、什么计划、有没有什么障碍。

    2019-03-24
    2
  • 小伟
    好的流程规范需要项目管理的人(也可能是产品经理或技术经理)制定和发布,并设定奖罚机制,看到很多团队制定者都不遵守,后来形同虚设,所以关键是执行起来,反复迭代即可。

    作者回复: 是呀,制订了还不执行,那还不如不制定呀!
    不执行,也要分析原因:
    1. 是不是不具备可行性
    2. 是不是没有严格执行

    如果能改进就改进,不然就不如取消。

    2019-03-23
    2
  • Joey
    请教宝玉老师:站在开发部门层面,如何做好研发质量管理?或者说有什么管理机制或手段可以分享下?

    我们现在有的流程机制有:
    1、瀑布模式下的需求、开发、测试、安全等各环节的过程管控;
    2、也有一个量化体系用来表明研发过程中各个环节的效率以及质量,效率主要有需求分析效率,研发周期效率,测试效率等数据;质量方面有缺陷发现率、缺陷流出率,生产事件响应机制等。

    感谢老师解答!

    作者回复: 一点建议:
    首先,人是其中最大的变数也是最重要的因素,要保证团队有一批靠谱的水平不错的人。多花一点时间精力在团队的招聘和培养上面。

    然后要建设好流程制度上,从制度上保障质量。
    比如说:
    - 在关键环节要有严格的评审,需求评审,设计评审;
    - 单元测试、代码审查都是行之有效的手段;
    - 把基于CI的代码自动测试、发布流程要建立起来;
    - 有规范的Bug跟踪和修复流程;
    - 对于线上故障有合理的应急处理流程。

    量化的数据是很好的参考,可以充分利用起来帮助及时发现风险。

    给测试留有充足的时间,不要压缩测试时间。测试后期,要冻结需求,一边增加需求一边修改Bug质量是没法稳定下来的。

    线上要有监控,对于关键的指标设置阈值和报警,比如:说http错误率超过5%报警。

    项目结束后要有总结、反思和调整。

    供参考!

    2019-04-11
    1
  • hua168
    我去猎聘、51job提前了解了一下技术管理方面的,运维主管/经理 看到有些要求会ITIL

    作者回复: 那你可以学习一下,总不是坏事 :)

    但我觉得这一定不是主要的障碍,关键还是多积累项目管理经验。

    2019-03-28
    1
  • hua168
    老师,
    1.管理类要学ITIL的吗?
    2.它的六个模块:即业务管理、服务管理、ICT基础架构管理、IT服务管理规划与实施、应用管理和安全管理。
    都要学吗?
    3.实际IT行业应用ITIL的多不?
    如果不多,是用什么?

    作者回复: ITIL我真的不了解,不好妄加评论。

    IT行业的管理一个就是软件工程,对软件项目过程的管理,一个就是项目管理,对项目人和事的管理。

    2019-03-28
    1
  • 舒偌一
    制度流程和规范的目的是减少沟通提供效率,成员行动一致,做事是步骤,结果检查有标准。
    由于行业特性,我们系统的更新必须是到客户现场进行,之前由于没有制定整理更新包的步骤和现场更新的步骤,出问题时,导致准备更新包的同事和现场更新的同事的矛盾,客户也很有意见,认为做事不专业。后面我们制定了更新包准备清单、更新包验证清单,现场更新验证清单,几个月反复修改补充,效果不错,遗憾的是到现在还是手工执行。

    作者回复: 🙏谢谢补充,很好的案例。

    如果这个更新包发布频率比较高,建议可以考虑是不是可以写个脚本自动化,应该能提高效率和减少出错。

    2019-03-26
    1
  • 一路向北
    我们目前的开发可以说都是按照一种下意识的流程来做,一个原因是团队小,经常是一个人负责一大块事情,和别人之间的接口大多数情况下就是协议,另外一个原因是,大家心底里遵循的流程是比较固化了。
    这里一个比较大的问题是,随意性比较强,特别是在遇到一些问题的时候,或者时间紧的时候,代码不review了,需求分析也精简了,甚至测试就只做增量部分了……
    学习了老师这一套之后,接下来会和团队分享学习,让大家在原来基础之上形成一种较规范的流程,提升开发的效率。

    作者回复: 磨刀不误砍柴工,有些不能省,比如代码审查,至少要做到心中有数,不然将来也需要还账的。

    时间紧也可以有时间紧的流程。比如说时间紧来不及写测试,代码审查发现的暂时不修改的代码,那么就应该创建一个Ticket后续跟踪,时间不紧的时候把来不及做的事情补回去。

    2019-03-25
    1
  • alva_xu
    我来谈谈对老师讲的几个点的个人看法和实践。
    1,方法和流程规范的区别。
    老师讲的很对,流程规范是在很多经验总结后形成的。从ITIL流程来说,这里的方法实际上可以理解为事件管理的范畴,就是发现了一个incident ,想办法去解决,甚至用work around 的方法去解决。当相同的incident发现次数多了,在review的时候,事件就上升成为问题。问题管理就是用来彻底避免相同事件重复发生的。而规范流程是问题管理的一种手段。问题管理会带来变更管理,规范流程的制定和修改,是可以纳入到变更管理中的,只要纳入到变更管理,就自然会考虑到沟通机制、回退计划等事情。我们也碰到过类似老师提到的该数据库的问题。刚开始数据库该出问题了,我们就处理数据库问题,后来,总结下来,需要严格改数据库的流程,比如增加业务运维和基础运维的经理审批才允许修改数据库。改数据库的流程我们也花了很多时间进行优化才真正固定下来。
    2,流程规范工具化。
    我觉得,除了工具化,还要尽量自动化。举个例子,我们这边最早采用checkstyle和findbug嵌入到IDE的方式进行代码检查,然后规定每个项目必须用这两个工具。但后来发现,这个规定执行的很不好,许多项目组没有自觉执行,增加了QA团队的检查工作量。后来我们采用sonarqube,并把它集成到ci里,就不怕项目组不执行了。
    3,推广执行的问题
    除了前面两个方法,纳入变更管理和纳入自动化流水线之外,还有一个特别重要,那就是考核问题。但这个有很大的难度。有些规范的执行力度很难量化考核,就举个简单的例子,测试用例和需求文档的匹配问题,还有比如压力测试的性能指标问题,如果没有工具和环境,这简直会把QA愁死。所以,流程执行的好坏,还是与人和工具技术有关,三者互相关联,缺一不可。
    关于第三点,我也想问问老师,需求文档和测试用例怎么验收?对于性能测试是否合格问题,你们是怎么解决测试环境和生产环境可比性问题的?

    作者回复: 👍谢谢高质量的补充!

    需求文档验收可以通过需求评审会议,评审时开发和测试都要有代表参加,一个是提出反馈,另一个是及早了解需求。评审会议通常要开几次才能最终定下来。

    测试用例通常是产品经理协助验收或者辅助确认。

    原来我们在飞信时,会有一个模拟生产环境的压力测试环节,从生产环境同步真实数据过去,规模按生产环境比例缩放。

    还有的压力测试是直接在生产环境做的,在半夜人流量少的时候。

    2019-03-25
    1
  • 张驰
    在日常工作中,流程应该由谁来制定呢?普通开发人员还是领导者,亦或者是公司有这种专职专岗的人。往往很多人都能够发现问题,甚至也有一些自己解决问题的方式方法,但是要想具体流程化对公司整体产生作用,往往感觉是有力无门,没有一个好的渠道。

    作者回复: 一个好的流程经常是跟问题切实相关的人员提出来的,或者把问题反馈出来,大家一起想办法,最后由项目经理或者部门负责人帮助落实推广。

    其实像敏捷开发每次迭代结束后的Sprint回顾会议就是一个很好的讨论问题的方式。

    可以考虑参考Sprint回顾会议的做法,定期有专门的会议可以讨论这样的问题。另外如果有组员之间的1-1会议,也是个不错的讨论这样问题和解决方案的途径。也可以通过邮件、聊天工具讨论解决。

    2019-03-25
    1
  • williamcai
    其实公司都有规范,但是执行力有待提高

    作者回复: 反思执行力的同时,也要思考一下规范是不是制订的科学合理,有时候是规则本身的问题导致难以执行的

    2019-03-25
    1
  • 敖天羽
    老师说的很对,目前我在推广中也遇到了一些问题。指正一点,VSC 不是 IDE 哦。

    作者回复: 谢谢指正🤦‍♂️

    2019-04-23
  • Felix
    流程和规范是最好的工作助手!

    作者回复: 是的,也要记住:看是不是可以用工具或自动化替代。

    2019-03-26
  • 小先生
    流程规范,对于个人来说可能会影响效率,但对于整个团队来说,肯定是利大于弊的。

    1 找出需要解决的问题 2 提出解决方案
    3 达成共识和推广 4不断更新,改进

    最好是通过法治而不是人治。
    通过技术进行规范才是王道,比如 Swift 中检查代码规范的 Swiftlint。需要多一些这样的工具。

    作者回复: 总结的不错👍

    2019-03-25
  • alva_xu
    另外,我查了一下,老师引用的那句任总的话,并未出现在他的公开信里,而是编辑的题记。

    作者回复: 🤝谢谢指正,我让编辑同学帮助更正一下

    2019-03-25
收起评论
20
返回
顶部