在美国学习和工作期间,我注意比较了中美两国软件公司在软件开发管理和技术方面
的不同之处。下面以我在硅谷一家从事企业语音识别平台软件开发的公司工作的经历为例, 介绍我的一些观点。
第一,软件工程师年龄和经验的反差。我工作过的是一家NASDAQ上市公司,公司 只有5年时间,但是近一半的软件工程师、软件项目经理和软件设计师都不算很年轻,并
有着5年以上的软件开发经验(不包括在校期间的经验)。其中部分软件设计师(software architect)更是年龄在35岁以上(有的甚至已经45岁),有着15年以上的软件开发经验。
在开发过程中,这些软件设计师的经验成为公司的宝贵财富。他们在多年开发过程中积累 的大量经验、教训能够让系统在设计阶段就避免许多后来让人走弯路的事情。权威的软件 工程专家RogerS.Pressman在他的SoftwareEngineering:口practitioner approach一书中指 出,软件质量保证体系最重要的是软件项目刚刚开始的需求和设计阶段。反观国内的软件
工程师,绝大部分是刚从学校毕业不久,而且多半的软件工程师都定位在将来做管理者, 这样,经验无法积累,低水平重复的现象就在所难免了。
第二,软件开发管理职位设置的差异。在国内,软件公司通常只指派一位项目经理, 由他全面负责单个项目的开发和管理工作。如果项目经理不是技术高手,手下的软件工程
师们就会有牢骚,如“凭什么你没我水平高,却坐着比我高的职位,拿着比我高的薪水?” 这使得许多软件公司雇佣技术高手担任项目经理。他们中许多人缺乏管理方面的能力和意 识,由他们领导的软件开发难以实现规范化和工程化。实际上,项目管理更多的是需要管 理技能而并非开发经验,而管理水平高的人大多数并不擅长技术,更有一些管理人员原来 不是受高等计算机专业教育出身,而是半路出家。在美国,我接触过的所有软件公司(或 者有软件研发部门的计算机、通信技术公司)的软件项目小组都设有两个管理者的职位: 软件项目经理(proiectmanager)和软件设计师(softwarearchitect)。软件项目经理负责小 组人力资源、激励、非技术方面的管理,并向上级负责。软件设计师负责项目的规划设计、
技术方案选择等并为此负责。就像项目经理有一个职业发展道路,从项目经理到部门经理, 再到总经理,甚至总裁一样,软件设计师也有其职业发展道路,从软件项目小组的软件设 计师到软件部的软件设计师,再到公司的首席软件设计师。我想大多数人都注意到比尔·盖 茨的头衔,是微软公司chairman和chiefsoftwarearchitect,也就是微软公司董事长兼首席
软件设计师。可以想见,首席软件设计师的地位也是很高的。在更大规模的软件项目中, 系统工程师(systemengineer)和测试部门是单独设置的。
第三,开发管理应用软件水平的差异。美国绝大多数软件公司的软件开发管理应用了 大量的先进软件,而国内的软件开发管理几乎是纯手工操作。本来,软件公司是为所有需
要软件应用技术和解决方案的行业提供软件,其中也包括软件行业自身。具有讽刺意味的 是,国内许多从事软件开发的公司为别人提供了非常有价值的软件,创造了很高的效益, 却没有意识到(或者没有决心)自己也需要投资购买或者自行开发用于管理软件开发过程 的软件。许多美国公司根据自己的实际需要,开发用于辅助软件项目管理的软件,例如,
著名的电信设备制造商朗讯公司的大型软件工程管理软件(Sablime)就是自己开发的;许 多软件工程师自己用脚本语言写小工具,优化工作流程,提高工作效率。本书的主题CVS 系统正是从一些软件工程师在自己工作过程中写的一些脚本程序起源的。在美国,流行的 脚本语言,如Perl、BournShell/CShell、Python、TCL/TK等应用非常广泛:而在国内,这 些语言应用十分有限。
第四,软件开发流程的差异。美国水平比较高的软件公司软件开发流程十分规范,技 术文档和使用文档非常细致,量非常大。在大项目的开发过程中,各种各样的表格更是数
不胜数。按照一位经理的说法,是“所有的事情都有文档记录”。不仅如此,美国更有technical writer(技术写作师)这个职业,许多公司聘用专门的技术写作师完成部分技术文档和使用
文档,尤其是给最终用户使用的使用指南一类的文档,更需要专业水平才能达到实用和易 用。国内这方面的差距较大:软件工程师视文档为负担:项目经理本身是软件工程师出身, 更加没有动力实施这些规范;公司老总可能又不懂软件开发管理。于是低水平现状是想躲 都躲不掉了。
可喜的是,目前CMM认证正逐渐地在国内流行起来,有越来越多的软件公司重视流 程。更重要的是,不把通过CMM认证作为目的,而是真正贯彻规范和经过实践证实有效 的软件流程。不过,对于许多规模小、实力不强的公司而言,CMM认证负担太重,而且 不一定实用。记得有一位中型软件公司的老总对我说,“CMM那些东西全都是文档,不管 用。”这件事情可以得出三个结论:一是CMM这种先进管理技术真正得到认同还有一个过 程,二是CMM的实用价值在一些管理阶段还不是太大,三是CMM可能的确需要进行适 当的改造以适合中国的国情。
我接触过国内许多软件公司,这些公司中的绝大部分其开发管理的混乱状况让我非常
吃惊。我也一直听到这样的议论,“国内绝大部分的软件公司都是软件作坊,基础不行,软 件业怎么发展壮大?”我相信造成国内软件业落后的原因是多方面的,但是,我们的确需 要认真思考如何补上提高软件开发管理水平这一课。
有人说,中国的软件工程技术水平低下和中国人的特点有关系。我认为这是无稽之谈,
是为管理水平过于低下找借口。在国外,同样是中国人做软件工程师,同样是中国人做软 件研发管理,为什么他们做得那么出色,赢得同事们的尊敬?
我接触到的中小型软件公司大部分都抱着提高开发管理水平的美好愿望,也有些公司
在进行着各种努力。例如,CMM正在一些中、大型软件企业中兴起。但是,CMM流程模 型引入的代价很高,而且在水平很低的情况下过分强调CMM中的模型恐怕也没有太大价 值。CMM的有效实施实际上是建立在强大的CASE工具基础之上的。
我在美国软件公司的工作经历告诉我,有一些非常有价值,,实施起来代价相对较低的
技术,能够帮助国内许许多多的软件公司走出作坊时代,进入软件开发流程化的阶段。这 就是我们准备写作出版“软件研发管理技术丛书”的主要目的。真切地希望这套丛书能够 为广大软件工程师和软件公司带来实实在在的变化。
相关推荐
YOLOv8作物病害检测实战源码
这是一套基于YOLOv8n的农田病虫害目标检测系统,对叶片照片做目标检测,识别健康叶片、褐斑病、白粉病、锈病四类,并给出对应防治建议。全流程纯CPU可跑,配套交付完整Python源码、9章实战教程(md/html/pdf三种格式)、100张自造样本及YOLO标签、训练曲线与混淆矩阵截图、Tkinter界面和答辩PPT。 系统围绕五项功能展开:同一套推理逻辑覆盖图像、视频、摄像头三种来源;图形界面选文件即检测,画面叠彩色框标注病名与置信度,右侧面板同步给出症状与防治措施;检测记录自动写入CSV,统计页一键生成四类病害占比饼图;训练结束自动产出损失与精度曲线;内置防治建议文案库,检测命中即回填面板。 选型用YOLOv8n nano档,参数量约320万、权重约6.2MB,CPU单帧几十毫秒,小样本训练5到8分钟完成。数据由data_gen.py程序化绘制100张叶片图,固定随机种子,重跑分布一致,不依赖公开数据集。依赖全部锁版本,教程第7章整理了19条真实报错及排查方法,第8章给出换模型档、换PlantVillage数据集的迁移路径。 适合做计算机视觉方向课程设计或毕业设计的学生,也适合智慧农业方向想了解检测模型如何落进业务面板的学习者。不需要GPU,不需要系统学过目标检测,教程第3章会按需补齐原理。 使用时先pip install -r requirements.txt装好依赖,download_data.py下载预训练权重,data_gen.py生成样本后train.py训练,完成后用main.py infer批量检测或main.py gui启动界面。
中美两国软件开发管理的比较与启示
目前国内软件业中充斥着对模式、创意的顶礼膜拜,对流程、管理、量化的无视;认为软件工程师也是吃青春饭的,持续做技术没有出息,稍有成绩就考虑向管理转,非要弄一个Manager头衔才显得牛X;实际发现无论美国、还是中国,真正成功的软件企业都是关注创意的同时,也非常关注创意的实现过程的规范化,因为只有过程规范,才能真正保证创意的实现; 推荐一本配置管理的好书:《CVS和Nightly Build技术》,
数据挖掘实战:决策树 + 聚类 + 关联规则,零 Key 离线可跑(Python 源码)
数据挖掘实战包。用 Python 标准库实现 CART 风格决策树、K-Means 聚类与 Apriori 关联规则,在虚构「星河便利店」会员表和购物篮上跑通分类、分群与购物篮分析,并给出准确率、轮廓系数、支持度/置信度/提升度。零第三方依赖、零 API Key 即可离线跑通。含 4 个样例、离线冒烟、中文 README(含「使用方法」)。均为作者原创可运行源码。MIT。作者 blog.youkuaiyun.com/mtl1994
国内外比较
中美两国软件开发管理的比较与启示 杨锦方 在美国学习和工作期间,我注意比较了中美两国软件公司在软件开发管理和技术方面 的不同之处。下面以我在硅谷一家从事企业语音识别平台软件开发的公司工作的经历为例, 介绍我的一些观点。 第一,软件工程师年龄和经验的反差。我工作过的是一家NASDAQ上市公司,公司 只有5年时间,但是近一半的软件工程师、软件项目经理和软件设计师都不算
科技中介服务机构在技术供需对接中如何实现服务流程的自动化与标准化?.docx
科技中介服务机构在技术供需对接中如何实现服务流程的自动化与标准化?
产业园区如何高效对接企业技术需求与高校科研成果?.docx
科易网基于AI模型+行业大数据,在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,推出科技创新领域的AI+工具与数智化解决方案,推动科技创新与产业创新智能化发展。
做测试是否有前途
前半句话我认同,国内的确有这种情况;但我觉得具体跟国内大多公司软件水平还比较低有关系,他们对软件工程的理解还是浮于表面,没有真正理解软件工程实质。而且我觉得国内对软件开发的理解还是停留在上世纪八十年代九十年代初的时候。尤其是软件观念上的落后。很多人即使读过软件工程,读过中文英文版的,但若没有正规经历过大型项目,对软件工程还是理解很浅的。软件开发是实践性的,不是教出来的,不是看书看出来的,而是动手做
国央企创新负责人如何快速掌握本地科技资源分布与匹配情况?.docx
科易网基于AI模型+行业大数据,在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,推出科技创新领域的AI+工具与数智化解决方案,推动科技创新与产业创新智能化发展。
微软中的软件测试
在微软,测试人员可以说是团队前进的最大动力,可以说是测试人员在不断推动着整个团队朝着既定目标前进。 在微软,测试人员和开发人员在一个团队中的比率差不多,而且开发人员和测试人员的联系非常紧密,有点儿部分彼此的感觉。测试人员随时可以访问团队的代码库,开发人员也可以运行一些测试脚本来验证自己的开发,而且开发中的许多问题也都是双方共同努力解决的。 在微软,软件测试的自动化水平非常高,许多测
国央企创新负责人如何实现科技成果的精准识别与高效筛选?.docx
科易网基于AI模型+行业大数据,在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,推出科技创新领域的AI+工具与数智化解决方案,推动科技创新与产业创新智能化发展。
高校技术转移办公室人员如何系统化管理科技成果信息?.docx
科易网基于AI模型+行业大数据,在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,推出科技创新领域的AI+工具与数智化解决方案,推动科技创新与产业创新智能化发展。
微软的软件开发管理哲学和spec文化
微软的软件开发管理一直是实用主义至上,检验一个项目管理人员水平高低或者软件开发方法优劣的唯一标准就是看团队是否能够在规定的时间内开发出高质量的软件产品。 在微软,对项目管理的要求非常细致,也积累了很多的经验,看得出微软十分重视经验的累积,成功的经验往往能够得到非常多的重复使用,所以很多时候对某些做法他们也讲不出一个所以然来,只是说这是通过实践经验得到的。比如office开发团队的朱
SLAM算法的优缺点
SLAM(Simultaneous Localization and Mapping,同时定位与地图构建)算法是一种通过传感器数据实时估计机器人自身位置和构建环境地图的技术。
Best Practices in Software Test Automation
1: Know your objective2: Test Automation requires a manual test process3: The earlier the involvement in the Software Development Life Cycle (SDLC) the greater the benefits4: Test Automation is
【AI落地】AI生成测试用例,claude or gpt?(提效至少 50%)
gpt生成测试用例?当然好使啦,用好了提效50%+,用不好就让他变好!
从零开始安装 Windows 11 和 Ubuntu 22.04 双系统
本文详解Windows与Ubuntu 22.04双系统安装流程:需提前确认BIOS模式(UEFI/GPT或Legacy/MBR),关闭BitLocker加密、设备加密及快速启动;推荐Rufus/Ventoy制作启动盘。安装时需规划分区方案(建议单独划分EFI系统分区),注意引导器安装位置选择。双系统启动通过BIOS引导顺序管理,安装后需同步Windows与Linux系统时间。教程适配主流UEFI+GPT设备,强调操作前数据备份及Windows更新策略调整,避免兼容性问题。
脚本语言:21世纪的高级编程语言
1.简介 在过去的十五年里,人们编写计算机程序的方法发生了根本的转变。这种转变是从c或c++等系统程序设计语言到Perl或Tcl等脚本语言的过渡。虽然很多人参与了转变,却很少有人意识到它的发生,更不用说知道为什么会发生。这篇文章是我关于为什么在下个世纪脚本语言可以比系统程序设计语言更好的处理许多编程工作的一点看法。 与系统程序设计语言相
手把手教你搭建硬件在回路(HIL)仿真系统:从Simulink建模到实时测试
本文详细介绍了如何从零开始搭建硬件在回路(HIL)仿真系统,涵盖Simulink建模、实时仿真、代码生成及调试等关键步骤。通过具体配置示例和优化技巧,帮助开发者解决复杂控制系统验证中的技术难题,提升半实物仿真的效率和可靠性。
软件工程过程
GB、CMM、RUP、XP一、 GB二、 CMM三、 RUP(rational unified process)------软件3.1 RUP项目生命周期的四个阶段 初始 细化 构造 提交3.2 RUP的九个核心工作流程1) 业务建模2) 需求3) 分析设计4) 实现5) 测试6) 部署 7) 配置管理8) 项目管理
从选型到阵列:基于ESP32-S3的智能硬件麦克风系统设计实战
本文详细介绍了基于ESP32-S3芯片设计智能硬件麦克风阵列的完整实战方案。从核心芯片选型、数字MEMS麦克风的参数解读与电路设计,到关键的声学结构密封、阵列布局策略,再到利用ESP-ADF框架构建音频处理流水线并集成回声消除、噪声抑制等算法,提供了从硬件到软件的全链路设计指南与避坑要点,旨在实现清晰、稳定的远场语音交互。
oracle合并行---解决listagg 拼接字段返回过长 (Ora-01489 result of String concatenation is too long)
oracle合并行---解决listagg 拼接字段返回过长 (Ora-01489 result of String concatenation is too long)
关于软件开发管理的一些思考
几个概念1 项目与产品项目只是一次性验收,不投入实际的使用,不必过多考虑质量问题产品要投入市场,质量是其生命,一切必须以质量为首要因素开发项目跟开发产品是不同的。开发项目,就是要在最少的资源之下,提供给客户一个可以接受的烂货。可以花100万就让客户愿意结案,绝对不要花101万,让客户拥有一个比较好用的系统。越好用的东西越难做,出槌的机率也越高,为什么要这样做呢?一、 软
Scale-up,scale-out技术概述
本文系统分析了Scale-up与Scale-out两种扩展技术在现代计算中的应用与发展。Scale-up通过增强单节点性能,适用于高耦合任务,而Scale-out通过横向扩展节点,实现高可用性和无限扩展。在芯片层面,Chiplet技术推动Scale-up发展;在数据中心层面,二者协同工作构建强大集群。光模块在长距离高带宽传输中发挥关键作用。文章对比了NVIDIA、AMD和Broadcom三家公司的技术路线,指出NVIDIA采用封闭生态,AMD选择开放标准,Broadcom则主导底层连接技术。未来发展方向将聚
系统分析员基本功
系统分析员思想全局观念是系统分析员必须具备的观念。如果系统分析员设计时太注重细节,往往会陷入在某个问题上纠缠不清的泥潭。(93年,我论文指导老师的一席话影响了我随后几年对软件开发的理解——今后计算机会越来越快,多写几行代码少写代码无关紧要,最重要的是整体;一开始就错了,某个部份编得再好,也是没有用的) 系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户,来了解要交付的项目看起来想
ANSYS专题-利用ANSYS SIwave进行PCB板的EMS仿真
本文详细描述了使用ANSYSSIwave进行电路板电磁敏感度(EMS)仿真的完整流程。主要步骤包括:导入AD软件生成的IPC2581文件,检查PCB叠层和电路参数,为敏感网络设置50欧姆端口并指定GND为参考网络,进行验证检查后设置频段范围和入射波类型(单/多入射、极化方式等),最后启动仿真并查看选定网络的EMS感应电压曲线。该过程提供了从文件准备到结果分析的全套操作指南,适用于评估电路板在电磁干扰环境下的性能表现。
C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片
基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正
1717



被折叠的 条评论
为什么被折叠?



