xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-09-17 08:46:40 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
master
learn.lianglianglee.com/专栏/软件工程之美/12 流程和规范：红绿灯不是约束，而是用来提高效率.md.html
周伟 0f006e4e9b add
2022-05-11 18:57:05 +08:00

1211 lines
34 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
<link rel="icon" href="/static/favicon.png">
<title>12 流程和规范：红绿灯不是约束，而是用来提高效率.md.html</title>
<!-- Spectre.css framework -->
<link rel="stylesheet" href="/static/index.css">
<!-- theme css & js -->
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
<div class="book-brand">
<a href="/">
<img src="/static/favicon.png">
<span>技术文章摘抄</span>
</a>
</div>
<div class="book-menu uncollapsible">
<ul class="uncollapsible">
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/软件工程之美/00 开篇词 你为什么应该学好软件工程？.md.html">00 开篇词 你为什么应该学好软件工程？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/01 到底应该怎样理解软件工程？.md.html">01 到底应该怎样理解软件工程？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/02 工程思维：把每件事都当作一个项目来推进.md.html">02 工程思维：把每件事都当作一个项目来推进.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/03 瀑布模型：像工厂流水线一样把软件开发分层化.md.html">03 瀑布模型：像工厂流水线一样把软件开发分层化.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/04 瀑布模型之外，还有哪些开发模型？.md.html">04 瀑布模型之外，还有哪些开发模型？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/05 敏捷开发到底是想解决什么问题？.md.html">05 敏捷开发到底是想解决什么问题？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/06 大厂都在用哪些敏捷方法？（上）.md.html">06 大厂都在用哪些敏捷方法？（上）.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/07 大厂都在用哪些敏捷方法？（下）.md.html">07 大厂都在用哪些敏捷方法？（下）.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/08 怎样平衡软件质量与时间成本范围的关系？.md.html">08 怎样平衡软件质量与时间成本范围的关系？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/09 为什么软件工程项目普遍不重视可行性分析？.md.html">09 为什么软件工程项目普遍不重视可行性分析？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/10 如果你想技术转管理，先来试试管好一个项目.md.html">10 如果你想技术转管理，先来试试管好一个项目.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/11 项目计划：代码未动，计划先行.md.html">11 项目计划：代码未动，计划先行.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/软件工程之美/12 流程和规范：红绿灯不是约束，而是用来提高效率.md.html">12 流程和规范：红绿灯不是约束，而是用来提高效率.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/13 白天开会，加班写代码的节奏怎么破？.md.html">13 白天开会，加班写代码的节奏怎么破？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/14 项目管理工具：一切管理问题，都应思考能否通过工具解决.md.html">14 项目管理工具：一切管理问题，都应思考能否通过工具解决.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/15 风险管理：不能盲目乐观，凡事都应该有B计划.md.html">15 风险管理：不能盲目乐观，凡事都应该有B计划.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/16 怎样才能写好项目文档？.md.html">16 怎样才能写好项目文档？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/17 需求分析到底要分析什么？怎么分析？.md.html">17 需求分析到底要分析什么？怎么分析？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/18 原型设计：如何用最小的代价完成产品特性？.md.html">18 原型设计：如何用最小的代价完成产品特性？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/19 作为程序员，你应该有产品意识.md.html">19 作为程序员，你应该有产品意识.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/20 如何应对让人头疼的需求变更问题？.md.html">20 如何应对让人头疼的需求变更问题？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/21 架构设计：普通程序员也能实现复杂系统？.md.html">21 架构设计：普通程序员也能实现复杂系统？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/22 如何为项目做好技术选型？.md.html">22 如何为项目做好技术选型？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/23 架构师：不想当架构师的程序员不是好程序员.md.html">23 架构师：不想当架构师的程序员不是好程序员.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/24 技术债务：是继续修修补补凑合着用，还是推翻重来？.md.html">24 技术债务：是继续修修补补凑合着用，还是推翻重来？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/25 有哪些方法可以提高开发效率？.md.html">25 有哪些方法可以提高开发效率？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/26 持续交付：如何做到随时发布新版本到生产环境？.md.html">26 持续交付：如何做到随时发布新版本到生产环境？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/27 软件工程师的核心竞争力是什么？（上）.md.html">27 软件工程师的核心竞争力是什么？（上）.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/28 软件工程师的核心竞争力是什么？（下）.md.html">28 软件工程师的核心竞争力是什么？（下）.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/29 自动化测试：如何把Bug杀死在摇篮里？.md.html">29 自动化测试：如何把Bug杀死在摇篮里？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/30 用好源代码管理工具，让你的协作更高效.md.html">30 用好源代码管理工具，让你的协作更高效.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/31 软件测试要为产品质量负责吗？.md.html">31 软件测试要为产品质量负责吗？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/32 软件测试：什么样的公司需要专职测试？.md.html">32 软件测试：什么样的公司需要专职测试？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/33 测试工具：为什么不应该通过QQ微信邮件报Bug？.md.html">33 测试工具：为什么不应该通过QQ微信邮件报Bug？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/34 账号密码泄露成灾，应该怎样预防？.md.html">34 账号密码泄露成灾，应该怎样预防？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/35 版本发布：软件上线只是新的开始.md.html">35 版本发布：软件上线只是新的开始.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/36 DevOps工程师到底要做什么事情？.md.html">36 DevOps工程师到底要做什么事情？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/37 遇到线上故障，你和高手的差距在哪里？.md.html">37 遇到线上故障，你和高手的差距在哪里？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/38 日志管理：如何借助工具快速发现和定位产品问题 ？.md.html">38 日志管理：如何借助工具快速发现和定位产品问题 ？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/39 项目总结：做好项目复盘，把经验变成能力.md.html">39 项目总结：做好项目复盘，把经验变成能力.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/40 最佳实践：小团队如何应用软件工程？.md.html">40 最佳实践：小团队如何应用软件工程？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/41 为什么程序员的业余项目大多都死了？.md.html">41 为什么程序员的业余项目大多都死了？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/42 反面案例：盘点那些失败的软件项目.md.html">42 反面案例：盘点那些失败的软件项目.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/43 以VS Code为例，看大型开源项目是如何应用软件工程的？.md.html">43 以VS Code为例，看大型开源项目是如何应用软件工程的？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/44 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的？.md.html">44 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/45 从软件工程的角度看微服务、云计算、人工智能这些新技术.md.html">45 从软件工程的角度看微服务、云计算、人工智能这些新技术.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/一问一答第1期 30个软件开发常见问题解决策略.md.html">一问一答第1期 30个软件开发常见问题解决策略.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/一问一答第2期 30个软件开发常见问题解决策略.md.html">一问一答第2期 30个软件开发常见问题解决策略.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/一问一答第3期 18个软件开发常见问题解决策略.md.html">一问一答第3期 18个软件开发常见问题解决策略.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/一问一答第4期 14个软件开发常见问题解决策略.md.html">一问一答第4期 14个软件开发常见问题解决策略.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/一问一答第5期 22个软件开发常见问题解决策略.md.html">一问一答第5期 22个软件开发常见问题解决策略.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/学习攻略 怎样学好软件工程？.md.html">学习攻略 怎样学好软件工程？.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/特别放送 从软件工程的角度解读任正非的新年公开信.md.html">特别放送 从软件工程的角度解读任正非的新年公开信.md.html</a>
</li>
<li>
<a href="/专栏/软件工程之美/结束语 万事皆项目，软件工程无处不在.md.html">结束语 万事皆项目，软件工程无处不在.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
let sidebar = document.querySelector('.book-sidebar')
let content = document.querySelector('.off-canvas-content')
if (sidebar_toggle.classList.contains('extend')) { // show
sidebar_toggle.classList.remove('extend')
sidebar.classList.remove('hide')
content.classList.remove('extend')
} else { // hide
sidebar_toggle.classList.add('extend')
sidebar.classList.add('hide')
content.classList.add('extend')
}
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.add('show')
overlay.classList.add('show')
}
function hide_canvas() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.remove('show')
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
<div class="column col-12 col-lg-12">
<div class="book-navbar">
<!-- For Responsive Layout -->
<header class="navbar">
<section class="navbar-section">
<a onclick="open_sidebar()">
<i class="icon icon-menu"></i>
</a>
</section>
</header>
</div>
<div class="book-content" style="max-width: 960px; margin: 0 auto;
overflow-x: auto;
overflow-y: hidden;">
<div class="book-post">
<p id="tip" align="center"></p>
<div><h1>12 流程和规范：红绿灯不是约束，而是用来提高效率</h1>
<p>你好，我是宝玉，我今天想与你讨论流程和规范的价值，以及如何参与制定好的流程规范。</p>
<p>不知道你所在的软件项目中是不是也有各种流程规范，例如：</p>
<ul>
<li>
<p>开发人员不能直接在生产环境修改代码操作数据库，必须在本地先测试验证后，由运维操作；</p>
</li>
<li>
<p>代码需要 Review 通过才能合并主分支；</p>
</li>
<li>
<p>代码需要遵守各种规范，像命名、格式，还有缩进用几个空格还是 tab 的细节问题；</p>
</li>
<li>
<p>遇到 Bug，先提交到 Bug 跟踪系统。</p>
</li>
</ul>
<p>在我经历的项目中，或多或少都会有各种各样的流程规范，而且越是大的、正规的项目团队，流程规范越是多。</p>
<p>然而很多人对于流程规范并不是很理解，甚至觉得是一种约束。</p>
<h2>为什么要有流程规范？</h2>
<p>从某种程度上来说，流程规范确实是一种约束：约束了我们如何做一件事，约束了我们用什么标准做事，约束了我们用特定的顺序做事。</p>
<p>既然如此约束我们，为什么还要有流程规范呢？</p>
<h3>提升团队效率</h3>
<p><strong>从个体来看，因为流程规范的存在，确实可能存在效率降低的情况，但从团队的角度来看，好的流程规范反而是提升效率的</strong>。</p>
<p>这其实很像我们生活中的红绿灯，用一个简单的规则：红灯停绿灯行，来约束车辆行人按照指示灯行进。</p>
<p>从单个车辆来看，看似是因为红绿灯的存在而影响了效率，但是从整体来看，因为红绿灯的存在，有效避免了拥堵，反而是提升了大家出行的效率。</p>
<p>其实红绿灯除了能提高效率，还有其他好处：</p>
<ul>
<li>
<p>红绿灯这样好的管理交通的经验，形成流程规范后，就可以全世界共享这种先进的经验；</p>
</li>
<li>
<p>红绿灯不再处处依赖于人指挥交通，而变成了让红绿灯的规则来指挥交通。</p>
</li>
</ul>
<p>软件项目中的流程规范是不是也有这样的效果呢？</p>
<p>以代码审查的规范为例，对于技术高的程序员来说，代码审查可能会耽误一点时间，但对整个团队来讲：</p>
<ul>
<li>
<p>即使是水平高的程序员，也可能会被发现有错误，代码审查可以降低出错的概率，保障质量；</p>
</li>
<li>
<p>对于水平低的程序员，可以通过代码审查学习和成长，代码被高水平程序员审查后，可以有效提高质量。</p>
</li>
</ul>
<p>软件项目中这样的例子还有很多，类似的还有像遇到 Bug 要提交到 Bug 跟踪系统，还需要配合重现步骤说明，看起来繁琐，但是却让 Bug 可以有效跟踪，让开发人员可以重现和定位，从而高效的修复 Bug。</p>
<h3>将好的实践标准化流程化，让大家可以共享经验</h3>
<p>我们知道，在运动项目上，有些运动员特别有天分，总能拿好的成绩，而这些运动员的动作，会被反复的研究学习，最终形成标准化动作。而其他天分一般的运动员，按照研究出来的标准动作练习，也能取得非常好的成绩。</p>
<p>软件工程也是这样，早些年的软件项目，就是个人英雄主义盛行的时代，项目的成败极其依赖于个别厉害的项目经理或者技术高手，而这种牛人，总是稀缺的存在。</p>
<p>所以后来很多编程高手写代码的方式，甚至写代码的格式，也会被研究，最终形成一套套的代码规范。其他水平一般的程序员，按照代码规范，也能写出不错的代码。</p>
<p>代码规范还有个好处，就是大家写出来的代码看起来差不多，换个人接手别人的代码，也能很快上手。</p>
<p>如果我们站在流程规范的角度看软件工程的开发模式，它也是源自实践过程中，有些厉害的项目经理发现了好的、可以提升软件质量的开发实践，不断总结改进，最后变成了流程，让普通的项目经理按照这一套流程，也能做出不错的软件。</p>
<p>你看瀑布模型也好，敏捷开发也好，最后落实下来，不就是开发过程中一个个的流程规范么？所以瀑布模型我们需要各种阶段评审，敏捷开发需要每天开站立会议，需要每个 Sprint 有计划会、评审会。</p>
<h3>借助流程规范，让项目管理从人治到“法治”</h3>
<p>在《10 如果你想技术转管理，先来试试管好一个项目》这篇文章中我就提到过，管理就是管人和管事，而管人，就要借助流程规范来管理。</p>
<p>因为如果在项目管理中，过于依赖人的管理，项目经理就会成为瓶颈，大事小事都需要项目经理来决策。再说项目经理也不能保证每次决策的正确性，如果决策失误，会很可能导致一些冲突。</p>
<p><strong>而好的项目管理，不需要直接管人管事，而是管理好计划和流程规范；项目成员不需要按照项目经理的指令做事，而是遵循计划和流程规范。</strong></p>
<p>我以前工作过的一个项目组，一个项目持续了好多年，中间人换了一批又一批，甚至有时候连项目经理都空缺，而项目一直井然有序的进行着，没有出什么问题，靠的就是多年积累下来的适合项目组的流程规范。</p>
<p>就像在《06 大厂都在用哪些敏捷方法？（上）》这篇文章中描述的那样：项目成员日常从看板就可以知道要做什么任务，代码审查、自动化测试可以有效保证质量，项目文档可以保证新人加入时能快速上手，结对编程可以保证新人遇到问题可以得到直接的帮助。</p>
<p>还有一个常见场景就是需求变更，产品经理想加一个紧急需求，这通常是让项目经理为难的事情：加吧，影响项目进度，开发人员有意见；不加呢，可能客户或者产品经理有意见。一个不小心就两边都得罪了。</p>
<p>如果你有一个大家认可的需求变更流程，就不再需要靠项目经理一个人决定该不该加需求，而是通过流程，来大家一起决策是不是要加这个流程。</p>
<p>所以你看，<strong>流程规范，看起来是约束，实际上你用的好的话，不仅可以提高团队效率，还可以将好的实践标准化流程化，让大家可以共享经验，还可以有效的管理项目。</strong></p>
<h2>如何制定好流程规范？</h2>
<p>在项目管理中，难免要去制定流程规范。即使你不是管理者，也可以提出合理的流程规范，帮助把项目管理好。</p>
<p>有一个科学的制定流程规范的方法，可以让你更好地制定出好的流程规范。</p>
<h3>制定流程规范的四个步骤</h3>
<p>对于流程规范的制定，可以通过四个步骤来开展。</p>
<p><strong>第一步：明确要解决的问题</strong></p>
<p>要制定一个流程规范，第一步就是明确你是要解决什么样的问题。项目中很多问题，都可以思考是不是能通过流程解决。</p>
<p>比如说有程序员在生产环境操作，误删了数据表，造成了严重问题。如果只是对程序员进行处罚，寄希望于小心谨慎避免类似问题，那么下一次还有可能会有类似的事情发生。</p>
<p>如果说在流程上规范起来，例如：数据库操作之前先备份数据库，事先写好 SQL 语句，需要有人审查，测试环境先测试通过，最后再生产环境执行，那么就可以避免以后再出现不小心删除数据表的事情发生。</p>
<p><strong>第二步：提出解决方案</strong></p>
<p>对于问题，也不用着急马上就想着用流程规范，可以先思考解决的方法，有了方法后再进一步思考是否能提炼流程规范。</p>
<p>那么方法和流程规范有什么区别呢？</p>
<p>相对来说，方法更有针对性，可能只适用于特定场景或者特定人，而要将方法上升到流程规范，则需要有一定的普适性，能变成具体的步骤或者标准，让每个人都能执行。</p>
<p>比如说服务器部署后出现问题，高手可能就直接上服务器操作，直接修改代码编译解决，这是一个解决方法，但这不能成为一个流程规范，因为换一个水平不行或者对代码不熟悉的人来做，可能会搞出更大的问题。这时候回滚操作就是一个相对普适的方法，可以变成一个部署后出现问题的流程。</p>
<p>在提出解决方案，制定开发流程时，可以参考借鉴软件工程中，大家公认的好的实践。比如说：</p>
<ul>
<li>
<p>**敏捷开发的流程：**虽然你的项目不一定采用敏捷开发的方式，但是敏捷开发中一些好的流程是可以借鉴的，例如参考我之前文章提到的像看板、站立会议、持续集成，这些好的工作流程，都可以借鉴。</p>
</li>
<li>
<p>**代码规范：**其实很多公司都公开了他们的代码规范，可以直接基于这些规范制定团队的规范。例如说前端的有 Airbnb 的代码规范 <a href="https://github.com/airbnb/javascript">Airbnb JavaScript Style Guide</a>，Java 的有 <a href="https://google.github.io/styleguide/javaguide.html">Google Java Style Guide </a>，.Net 的有<a href="http://docs.microsoft.com/en-us/dotnet/standard/index">.NET Guide</a>，等等。</p>
</li>
<li>
<p>**源代码管理流程：**现在的源代码主流是 git，而基于 Git 的代码管理已经有很多成熟的流程规范可以参考。例如阮一峰老师写过的<a href="https://www.ruanyifeng.com/blog/2015/08/git-use-process.html">Git 使用规范流程</a>，<a href="https://www.ruanyifeng.com/blog/2015/12/git-workflow.html">Git 工作流程</a>和<a href="https://www.ruanyifeng.com/blog/2012/07/git.html">Git 分支管理策略</a>，或者 Github 官方出品的<a href="https://guides.github.com/introduction/flow/index.html">Understanding the GitHub flow</a>，Gitlab 官方推荐的<a href="https://docs.gitlab.com/ee/topics/gitlab_flow.html#introduction-to-gitlab-flow">Introduction to GitLab Flow</a>。</p>
</li>
<li>
<p>**部署流程：**十年前，每日定时构建还是很时髦的部署流程，而现在，主流的部署流程已经变成了持续部署，每次代码合并到主分支都可以触发一次自动部署，这样一有问题，就能马上知道发生在哪个环节。</p>
</li>
</ul>
<p>像这样的好的流程还有很多，在我们专栏会介绍一些。如果平时多留心，你也可以学到很多。</p>
<p><strong>第三步：达成共识，推广执行</strong></p>
<p>在流程规范提出后，还需要得到大家认可，只有大家认可，达成共识，才能共同遵守，保障制度的执行。</p>
<p>对于大家都认可、很重要的流程规范，一定要让大家严格遵守，必要的时候需要配合一些奖惩制度，以保障其执行。</p>
<p>比如说流程规范的执行和绩效考评挂钩，对于没有执行的需要私下沟通提醒，严重的需要批评教育。否则流程规范会形同虚设，没有太大的意义。</p>
<p><strong>第四步： 持续优化，不断改进</strong></p>
<p>流程制定后，在实际执行的时候，难免发现一些不合理或者不科学的地方，这时候就需要对其进行调整。</p>
<p>还有一些流程规范，随着时间推移，可能已经不能符合要求了，也需要考虑改进甚至放弃，不然反而会成为一种阻碍。</p>
<p>比如说以前采用瀑布模型开发时，项目经理因为需要了解进度，所以每个项目成员要写日报，如果有站立会议了，日报这种形式就可以完全被站立会议替代，没有再存在的必要。</p>
<p>通过以上四个步骤，你就可以将日常项目中遇到的一些问题，用流程规范的方式逐步管理起来，在实施的过程中再不断优化改进，淘汰不合适的流程规范。</p>
<h3>将流程规范工具化</h3>
<p>如果说，以前我还是人为去推动一些流程规范的执行，近些年，我越来越感觉到，<strong>应该尽可能借助技术手段来推动甚至替代流程规范。</strong></p>
<p>例如说代码规范，以前代码规范的执行，主要靠反复的教育宣传和代码审查中一个个去检查。而现在，借助 VSCode 这种强大的 IDE，以及 ESLint 这种代码检查工具，可以方便的检测出不符合规范的代码，甚至于可以帮你直接格式化成满足代码规范的格式。</p>
<p>还有像保证代码质量的问题，早些年必须依赖测试人员大量手工的测试，而现在借助 CI（Continuous Integration，持续集成）、自动化测试和 Git，可以保证代码必须在通过测试以后，才会合并到主分支，从而很好的保证了代码的质量。</p>
<p>就像任正非的《全面提升软件工程能力与实践，打造可信的高质量产品》公开信中题记的这一段话说的：</p>
<blockquote>
<p>“软件工程”和“质量工程”需要依靠架构技术，而不是依靠 CMM 和 QA 管理流程。一切工程问题，首先要思考能否通过技术解决，当前技术无法解决的问题，暂时由管理手段代劳，同时不停止寻找技术手段。</p>
</blockquote>
<p>“软件工程”不要过于依赖流程和管理手段，要思考怎么通过技术手段去解决问题。</p>
<h2>总结</h2>
<p>流程和规范，就像红绿灯一样，不是一种约束，而是牺牲一点个体利益，提高团队效率；流程和规范将好的实践标准化流程化，让大家可以共享经验；流程和规范，让项目管理从人治变成“法治”。</p>
<p>要制定好项目规范，先明确要解决的问题，然后提出解决方案，看是否可以通过流程规范来解决，有了方案后需要团队成员一起达成一致，最后再推广执行。在执行过程中需要持续的优化，不断改进。</p>
<p>对于需要手动操作的流程，可以思考是不是能采用技术手段自动化，通过技术手段去解决。</p>
</div>
</div>
<div>
<div style="float: left">
<a href="/专栏/软件工程之美/11 项目计划：代码未动，计划先行.md.html">上一页</a>
</div>
<div style="float: right">
<a href="/专栏/软件工程之美/13 白天开会，加班写代码的节奏怎么破？.md.html">下一页</a>
</div>
</div>
</div>
</div>
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"70997c46efb53cfa","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
</body>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
var path = window.location.pathname
var cookie = getCookie("lastPath");
console.log(path)
if (path.replace("/", "") === "") {
if (cookie.replace("/", "") !== "") {
console.log(cookie)
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
}
} else {
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
var expires = "expires=" + d.toGMTString();
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i].trim();
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
}
return "";
}
</script>
</html>
Reference in New Issue View Git Blame Copy Permalink