软件开发管理方法论之我见

自打兄弟我成为了一个高大上的码农之后,就难免接触到各种软件开发的方法论。什么CMM啦,敏捷啦,测试驱动啦,不一而足。
  咱们码农其实是很单纯的,说白了搬砖怎么搬不是搬啊对不对?所以老板让咋搬咱们就怎么搬,大部分人也没搞明白这些玩意儿背后到底是个什么思路。
  但是兄弟我和其他码农不一样,我是个爱思考的人。所以在搬砖之余,我就会去找一些书来看,比如经济学、心理学、业务流程管理、销售管理之类的,一来可以涨涨姿势,二来也尝试站在老板的角度来观察一下咱们搬砖的情况。
  一开始吧,我也看不出啥门道。各种方法论看上去都挺客观的,据说有的可以准确控制搬砖的进度,有的能统一砖块的质量,还有的能让咱们搬砖的时候既高效又开心。
  这样问题就来了,搬砖技术到底哪家强呢?
  哥思考了很久,后来站在老板的角度终于想明白了:之所以有各种不同的方法论,是因为对于软件开发有不同的假设前提(assumption — 顺带说一句,这个单词厉害了,做过科研的同学们都知道,所有的科学理论都是基于一套assumption的。一般的科学家对前人的成果修修补补,牛叉的科学家发现新的方法和领域,而传奇的科学家都是推翻前人的assumption,直接颠覆或创立一整套理论。啊,跑题了…)。不同的假设前提意思是说,在老板眼里码农是个啥角色?不同角色对应的就是不同的管理思路,就会导致不同的管理方法论。
  历史的轮回总是惊人的相似。其实软件开发是一个行业,也难免经历其他行业的发展历程。我们先来看看工业界:工业革命之前,日用品都是手工作坊生产出来的,工匠的手艺差别很大,这种差别就体现在产品和工匠的收入上,比如普通鞋匠花五天做一双鞋卖给村民,一个月能挣3个银币,而顶级鞋匠花三个月给贵族订制一双鞋,挣30个金币。那个时候,衡量工匠工作效率的核心指标不是工作时间,而是手艺。
  这个阶段如果有管理方法的话,主要也是针对学徒的。学徒一直跟着师傅学习,直到手艺也达到师傅的标准,可以独当一面。这时候的管理方法,主要是让学徒尽可能掌握师傅的手艺,提高技术水平。
  后来工业革命了,有聪明人做出了蒸汽机以及各种自动机器,实现了流水线生产,根据某些顶级工艺师设计好的模具进行自动化生产,流水线上的工人只是负责某个环节的装配和质检等简单工作,就不需要有太高的手艺了,只要具备基本知识,经过流水线操作培训就可以上岗。这时候,衡量工人工作效率的核心指标就不是手艺,而是工作时间。
  这是为什么呢?因为,流水线的生产速度是固定的,质量也是标准的,所以一个工人每天能做出多少产品和他站在流水线旁的时间长短成正比。所以这个阶段的管理方法也不再看重工人提高手艺,而是关注出勤情况,所以相应的考勤打卡、病事假管理等等制度就一步步完善起来。
  其实说白了,现在的软件开发行业就正在经历从作坊到工厂的转变,有些公司转变得比较快,有的转变得慢一些。越来越多的开发框架、开发工具、库、模板就构成了很多的自动化流水线,让程序员这个职业的门槛越来越低。作为软件工程师,在老板的眼里,也有偏工人和偏工匠的不同,所以就会有不同的管理方法出来。
  再说到管理方法论和相应的假设前提,比如CMM是什么?就是软件行业的富士康管理方法。在实施CMM的公司老板眼里,他关注的其实是开发的流程。只要流程执行好了,每个码农都是无差别的,就像流水线上的一个个工人一样,今天走一个,明天就能招来一个,要求也不高,基本上会写if…else…就行了,对整体工作完全没有影响。考核员工的标准也比较容易量化,比如代码行数、出勤时间之类。
  敏捷开发呢?老板对工程师创造力的期望要高很多,希望每个团队成员能独当一面,这种模式下的工程师更像一个工匠,做事的自由度也会大一些。这种管理方式下,绩效考核的复杂度就要大一些了,不能简单地看写了多少代码,可能是看功能点数,或者结合其他成员的主观评价。当然,这种方式下对工程师水平的要求也会比较高,作坊里总不能随便找个人就开始干活吧?
  其他种种管理方法,其实都可以从这个角度去分析。不一定要看到它的开发方法论,从公司的外部表现就能大概齐看出来了。比如一家公司说福利好管三餐,上班要打卡甚至是996模式,办公室里还免费提供睡袋,薪水也不高,那么你基本就是去做工人的。反之,如果某公司不用打卡不记考勤,只管午饭但很好吃,没有老板天天盯着你写了多少代码,身边都是高手,而且薪水又很高……呃,国内真有这样的公司?假如有,那其他的就不用管了,赶紧去吧。
  大部分公司其实都是介乎两个极端之间的,你可以具体分析,是离工人近一点呢,还是离工匠近一点。
  为啥要从这个角度去看呢?因为对自己的成长影响是不一样的,工人讲究的是熟练,工作中钻研的方向也不是大的技术创新(老板不需要你钻研这个,而且你也没有时间没有条件去钻研工作中用不到的东西),而是如何优化模板等特别细节上的改进,一旦失去这个工作,你的经验可能在别的地方用处不大。工厂适合踏实、肯吃苦、执行力强、能干脏活累活的人,在这种人员流动大的地方能坚持下来,其实也会有很好的职业发展机会。
  如果你是那种喜欢新鲜感、爱钻研新技术、对于重复性的劳动兴趣不大的人,最好还是尽量去那种强调巧干胜过苦干的地方。一般那里高人比较多,学习的条件好,提升空间比较大,但是前提是你要聪明、勤快、自学能力强。在这种地方呆上几年,就能积累很多东西。
  不过现在行业里也有让人看不懂的公司,没办法用这个套路分析,或者说,它们是一种奇怪的混合变异体。比如有的互联网公司强调以人为本,取消了一线管理职位,实行扁平化的管理,又实行996严格考勤制度下的敏捷开发,对程序员主要考核代码量和bug数等等……
  这种思路大概是想把高水平的工匠们集中到工厂里进行流水线化的管理,类似中西医结合,先拍片子再抓方子。老码农在此无奈地表示,这种变异体的管理方式太有创意,无法评价,我只能承认搬砖技术最强的就是他们家了。

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2025-01-10 02:31:25

软件开发管理方法论之我见的相关文章

谈在软件开发管理中的误区及对策

软件行业在现在的众多行业里是一个极具挑战性和创造性的行业,体现了软件开发者的智慧和汗水,同时软件开发是一项复杂的系统工程,牵涉到许多方面的因素,在实际工作中,经常会出现各种各样的问题,甚至会面临失败.如何总结.分析失败的原因,得出有益的教训,对于项目开发人员来说,是在今后的项目中取得成功的关键. 一.软件开发中实行项目管理的意义 项目管理就是在项目活动中运用一系列的知识.技能.工具和技术,以满足或超过相关利益者对项目的要求,实际上就是通过项目各方干系人的合作,把各种资源应用于项目,以实现项目的目

《告别失控:软件开发团队管理必读》一一2.5 工作地点与关系

2.5 工作地点与关系 近年来,软件开发管理的复杂度比以前大了很多.也许你很幸运,仍然保持在简单的环境中,但这样的日子很快就不会再有了.即使现在不受影响,早晚都会受到影响的:否则,你的企业将不再具备竞争力. 以前,听到的问题都是:"去哪里找一个程序员来做项目?"后来逐渐开始思考是招聘现场全职雇员还是招聘合同工的问题.现在,在哪里完成工作.怎样完成工作往往涉及大量的决策,需要仔细考虑. 通常,这些决策不由你来做出,它们可能是由你的领导或者项目情况而定的.无论如何,要想取得成功,必须解决好

基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET - 5.0 简介

AgileEAS.NET简介  AgileEAS.NET平台(简称EAS.NET平台)是以"敏捷并行开发方法"为其过程指导思想.基于Microsoft .Net构件技术和模型驱动架构的企业级快速开发平台,AgileEAS.NET使的构建企业级分布式应用系统变得简单,它提供了可灵活扩展应用架构,并且革命性的改变了软件的生产方式,用于帮助中小型软件企业建立一条适合快速变化的开发团队,以达到节省开发成本.缩短开发时间,快速适应市场变化的目的. AgileEAS.NET介绍 AgileEAS.

《精益软件度量——实践者的观察与思考》—第1章1.1节精益软件开发的度量体系

第1章 度量谜题 精益软件度量--实践者的观察与思考 "我们所能拥有的最美好的经历是感受到神秘,它是触发所有真正艺术和科学起源的基本情感." 艾尔伯特·爱因斯坦(1879-1955) 按照IEEE的定义,"软件工程是将系统化.规则,以及可控的体系方法,应用于软件设计.开发.操作和维护:换言之,即工程理念在软件中的贯彻."1看上去很美,不是吗?当我们看到一个又一个软件开发组织,特别是大型的组织,特别是拥有辉煌历史的组织,把过程可控作为主要的管理目标时,一次又一次地惊讶

软件开发质量控制研究

[摘要]本文指出了软件开发过程中质量控制的重要性,通过分析开发过程中存在的问题,提出了一些提高软件开发质量的方法的对策措施. [关键词]软件开发:软件工程:质量控制 软件质量是指开发出来的软件不仅可以满足客户明确提出来的要求还要满足某些没有明确提出来的要求,软件质量越高,客户需求满足度就越高.软件项目质量控 制不仅仅是控制软件设计的最终结果,它其实要求贯穿于软件设计项目的全过程,从软件开发初期的客户需求调查,到最终的软件交付评审,每个阶段都要进行仔细 的控制,才能提高软件开发的质量. 一.软件开

基于CruiseControl和Rational统一变更管理实现的软件开发中的自动化持续构建

基于CruiseControl和Rational统一变更管理实现的软件开发中的自动化持续构建 简介:本文介绍了持续构建工具 CruiseControl 和 IBM Rational 统一变更管理集成的解决方案.通 过本文中的解决方案,可以尽早的发现和规避代码中存在的风险,遵守统一的流程及时获取可发布的软件 ,确保敏捷开发的速度和质量. 统一变更管理系统中持续集成的必要性 使用 IBM Rational ClearCase 和 IBM Rational ClearQuest 实现的统一变更管理软件

关于“软件开发”,“工程师文化”,“团队管理”

 分享一下 weibo@左耳朵耗子 陈皓的"建一支强大的小团队"报告内容,挑选了几点. 人物介绍 行业背景 :金融行业(Thomson Reuters) ,计算平台(Platform),电子商务(Amazon)  技术背景 : C/C++/Java,Unix/Linux/Windows ,Web  个性:码农兼包工头 ,敏捷恐怖分子 ,Unix/Linux/C/C++脑残粉 ,"技术部门无技术种族"歧视者 ,程序员文化民族主义者  陈皓是酷壳coolshell的博客

软件开发外包管理的“一二四”

本文讲的是软件开发外包管理的"一二四",[IT168 资讯]在信息化整个生命周期中,企业都越来越依赖于外部供应商,从需求分析到系统选型,再到项目实施乃至最后的运行维护,IT供应商始终与企业如影随形.尤其在核心竞争力理论的指导下,"把包括IT在内的不能直接创造价值的部分外包出去"成为了很多企业的选择,外部供应商逐步成了企业IT管理的延续.但是,在企业获得便利的同时也不得不面对供应商选择.评估.管理带来的难题. 在众多的IT外包中,软件开发外包是企业信息化建设过程中接触

小型软件开发更需要制度化管理

负责一个小型软件开发项目就跟掉层皮似的,其需要花费的心力不亚于负责一个大型的软件开发项目.近期公司让我做一个小型软件开发项目的主管,由于在资源.人力.管理水平等各种方面都有所欠缺,使我所负责的小型开发项目走了很多的弯路.为什么小型软件开发也有那么多的麻烦事情,到底问题在哪里呢? 初期的开发失败给我很大的打击,对此我做了许多反思和总结.后来,我终于明白到是由于缺乏切实可行的开发制度来为开发过程保驾护航,致使开发人员和测试人员不知项目该如何稳步地往下走,对于出现的异常情况也不知如何预防和规避,而且在