软件团队的如何建设和软件开发如何管理
这些素质中,有些我们可以通过考试的方法了解,有些可以询问,也有不少特质需要我们自己去感知。
在我们招聘的过程中,技术人员的笔试是很重要的,必须根据需要设立不同的考题对人员进行考察。
对于人员的能力和经验除了考虑目前他所具备的能力以外,还要考虑他的潜力,有些人具有很强的学习能力,在具备一定基础知识的情况下,可以降低对这种人经验的要求。
除了能力以外,一个人的情商对于我们的组织来说非常重要。
我们可以通过心理测试的方式了解一个人的情商,同时,最重要的是,作为管理者,我们必须要具有感知一个人性格特点的能力。
这样,在招聘过程中,我们才能尽量做到选择出合适的人才。
在选择人才的时候,我们不要一味追求便于管理,不要怕有能力的人。
对于性格过于内向的人我们也要多加考虑,很多内向的人同时也具有执拗、各色、生硬、融合性差的特点,因此内向不等于便于管理。
有了合适的人选,团队建立了,还需要不断提升团队的能力,需要培养具有特色的团队精神。
正如一个球队,有了合适的人选,还必须有高质量的训练,严格的细节要求,才可能在竞争中获得胜利。
一个团队也是一样,需要不断的提升技术能力,提升凝聚力,提升协作能力,提升士气,才能在一个个项目中获得成功。
那么,团队精神的培养,团队能力的提升从何着手呢?首先要确立团队的风格,例如建立这样一种团队风格:分享、透明、责任、协作、团结、激情。
在确立了这个风格以后,要在日常的工作中加以贯彻。
分享,主要是指技术的分享,可以定期举办技术讲座,让每个人都参与进来,领导者可以确立技术方向,然后大家分享彼此的知识和经验,这种方式可以很快地提升团队整体技术能力,分享的过程中也增加了成员间的相互了解和信任。
透明,是指管理上要透明,在我们的团队中没有不能拿出来说的秘密(工资除外),团队成员间秘密的形成也是团队隔阂的开始。
积极的态度、责任心是软件开发必不可少的素质,不同的责任心开发出来的软件可用性、性能、稳定性、出错率可能相差很远,发现由责任心引起的问题一定要坚决处理,提出公开的批评,根据情况作出适当的处罚,确保以后避免类似的错误。
软件工程的过程和软件设计的模块化、分层结构导致了软件组织成员分工的不同,这就要求成员间要有很高的协作性、团结性。
对各项工作多进行讨论,不要怕争论,不要独断专行,最后执行讨论后的结果,多讨论有助于增进协作和团结。
每个人都需要一个舞台,在团队管理中一定要了解每一个团队成员的特点和能力,把最适合的任务分配给他,要为每一个人营造一个舞台,要充分发挥每个人的作用。
软件是一个团队的工作,不是团队中一个明星的工作。
就象篮球是5个人的运动,足球是11个人运动一样。
要让所有的团队成员都参与到工作中来,一同享受工作的乐趣和成功的喜悦。
不要造成忙的忙,闲的闲的现象,那样的话忙的、闲的都会产生不满情绪,最终导致不可调和的矛盾。
除了上述方法可以培养团队的精神,促进团队能力的提升以外,另外一个重要的手段是确立团队不同阶段目标,并讨论采用什么样的手段达到目标。
目标包括项目目标和能力目标,只有有了正确的目标,在团队精神的鼓舞下,团队才会产生激情。
很多时候,激情的迸发可以产生意想不到的力量。
在培养团队精神的时候也要避免一些严重影响团队精神的事情发生。
不要任人唯亲,要唯贤是用;不要独断专行,要群策群力;不要高压强制,要鼓励引导。
在建设了一个好的团队以后,任务已经完成了一半。
软件工程的特殊性要求我们在软件开发上要有一套合理的管理方法。
这在很多软件工程的著作中作了大量的描述,这里我们只是做一个简单的经验介绍。
我们分成一下3点进行阐述: .规范.流程.考核 规范。
无论开发什么软件系统,都必须按照一定的规范进行。
软件开发过程采用规范进行管理的必要性相信任何一个管理者都会有明确的认识,这里我们只谈采用什么规范,怎么样执行规范。
软件工程的规范主要有CMM和ISO9000。
通常我们采用CMM规范,并根据软件组织的具体情况对规范进行相应的裁减。
不管怎么裁减,在开发管理过程中,以下一些关键环节是不可缺少的:需求分析,架构设计,概要设计,编码,测试。
通常,我们可以利用配置管理和版本管理的工具来进行开发过程的管理。
在这些过程中,我们必须按照一定的CMM规范产生相应的过程输出。
我们采用的规范都要形成相应的书面材料或者模版以供员工阅读。
总结一下我们需要的基本模版:需求分析模版、设计模版(架构、模块、数据)、编码规范、测试规范,基本管理工具:版本管理、配置管理、测试流程管理。
流程。
流程涵盖软件组织的内部流程以及软件组织和需求单位之间的外部流程。
外部流程包括需求讨论流程、需求确认流程、系统初审流程、系统终审流程等等。
内部流程包括需求分析流程、设计流程、开发流程、测试流程等等。
每个组织要根据自身特点和项目特点按照CMM规范的要求制定流程,并对流程进行讲解,按照流程严格执行。
在流程的各个环节完成软件项目的输出:需求书...
如何组织软件开发团队
这跟你要开发什么软件、使用什么开发模式、有多少预算、有多少开发时间等很多因素有关,比较复杂。
在软件工程领域,这是一个大问题,相关论文不计其数,有兴趣可以查阅期刊文献。
给你说说最常用的吧,是一种基于纵向管理结构和瀑布开发模式来进行组织的开发团队。
分为:1. 项目负责人:负责统筹项目运营方面的一切事务,预算管理、进度查询、会议组织安排、职能分配、客户对话洽谈等等。
2. 架构师:负责进行需求分析、软件架构构建、概念与逻辑设计、功能细分、系统性能分析等等。
3. 前台/界面设计师:主要负责软件GUI设计。
4. 数据库工程师:负责数据库的搭建、优化和管理。
5. 程序员:负责后台代码编写。
6. 测试员:根据软件测试技术来进行相应的功能测试,比如黑盒、白盒测试、单元测试等等。
7. 客服人员:负责软件到客户的安装、使用、售后、答疑等问题。
根据项目大小和任务量,每一个职能分类可以是一个人或几个人,形成局部纵向上下级负责制,比如项目经理与副经理、界面设计总监与界面设计师、总软件工程师与程序员等等。
软件团队的如何建设和软件开发如何管理
这些素质中,有些我们可以通过考试的方法了解,有些可以询问,也有不少特质需要我们自己去感知。
在我们招聘的过程中,技术人员的笔试是很重要的,必须根据需要设立不同的考题对人员进行考察。
对于人员的能力和经验除了考虑目前他所具备的能力以外,还要考虑他的潜力,有些人具有很强的学习能力,在具备一定基础知识的情况下,可以降低对这种人经验的要求。
除了能力以外,一个人的情商对于我们的组织来说非常重要。
我们可以通过心理测试的方式了解一个人的情商,同时,最重要的是,作为管理者,我们必须要具有感知一个人性格特点的能力。
这样,在招聘过程中,我们才能尽量做到选择出合适的人才。
在选择人才的时候,我们不要一味追求便于管理,不要怕有能力的人。
对于性格过于内向的人我们也要多加考虑,很多内向的人同时也具有执拗、各色、生硬、融合性差的特点,因此内向不等于便于管理。
有了合适的人选,团队建立了,还需要不断提升团队的能力,需要培养具有特色的团队精神。
正如一个球队,有了合适的人选,还必须有高质量的训练,严格的细节要求,才可能在竞争中获得胜利。
一个团队也是一样,需要不断的提升技术能力,提升凝聚力,提升协作能力,提升士气,才能在一个个项目中获得成功。
那么,团队精神的培养,团队能力的提升从何着手呢?首先要确立团队的风格,例如建立这样一种团队风格:分享、透明、责任、协作、团结、激情。
在确立了这个风格以后,要在日常的工作中加以贯彻。
分享,主要是指技术的分享,可以定期举办技术讲座,让每个人都参与进来,领导者可以确立技术方向,然后大家分享彼此的知识和经验,这种方式可以很快地提升团队整体技术能力,分享的过程中也增加了成员间的相互了解和信任。
透明,是指管理上要透明,在我们的团队中没有不能拿出来说的秘密(工资除外),团队成员间秘密的形成也是团队隔阂的开始。
积极的态度、责任心是软件开发必不可少的素质,不同的责任心开发出来的软件可用性、性能、稳定性、出错率可能相差很远,发现由责任心引起的问题一定要坚决处理,提出公开的批评,根据情况作出适当的处罚,确保以后避免类似的错误。
软件工程的过程和软件设计的模块化、分层结构导致了软件组织成员分工的不同,这就要求成员间要有很高的协作性、团结性。
对各项工作多进行讨论,不要怕争论,不要独断专行,最后执行讨论后的结果,多讨论有助于增进协作和团结。
每个人都需要一个舞台,在团队管理中一定要了解每一个团队成员的特点和能力,把最适合的任务分配给他,要为每一个人营造一个舞台,要充分发挥每个人的作用。
软件是一个团队的工作,不是团队中一个明星的工作。
就象篮球是5个人的运动,足球是11个人运动一样。
要让所有的团队成员都参与到工作中来,一同享受工作的乐趣和成功的喜悦。
不要造成忙的忙,闲的闲的现象,那样的话忙的、闲的都会产生不满情绪,最终导致不可调和的矛盾。
除了上述方法可以培养团队的精神,促进团队能力的提升以外,另外一个重要的手段是确立团队不同阶段目标,并讨论采用什么样的手段达到目标。
目标包括项目目标和能力目标,只有有了正确的目标,在团队精神的鼓舞下,团队才会产生激情。
很多时候,激情的迸发可以产生意想不到的力量。
在培养团队精神的时候也要避免一些严重影响团队精神的事情发生。
不要任人唯亲,要唯贤是用;不要独断专行,要群策群力;不要高压强制,要鼓励引导。
在建设了一个好的团队以后,任务已经完成了一半。
软件工程的特殊性要求我们在软件开发上要有一套合理的管理方法。
这在很多软件工程的著作中作了大量的描述,这里我们只是做一个简单的经验介绍。
我们分成一下3点进行阐述: .规范 .流程 .考核 规范。
无论开发什么软件系统,都必须按照一定的规范进行。
软件开发过程采用规范进行管理的必要性相信任何一个管理者都会有明确的认识,这里我们只谈采用什么规范,怎么样执行规范。
软件工程的规范主要有CMM和ISO9000。
通常我们采用CMM规范,并根据软件组织的具体情况对规范进行相应的裁减。
不管怎么裁减,在开发管理过程中,以下一些关键环节是不可缺少的:需求分析,架构设计,概要设计,编码,测试。
通常,我们可以利用配置管理和版本管理的工具来进行开发过程的管理。
在这些过程中,我们必须按照一定的CMM规范产生相应的过程输出。
我们采用的规范都要形成相应的书面材料或者模版以供员工阅读。
总结一下我们需要的基本模版:需求分析模版、设计模版(架构、模块、数据)、编码规范、测试规范,基本管理工具:版本管理、配置管理、测试流程管理。
流程。
流程涵盖软件组织的内部流程以及软件组织和需求单位之间的外部流程。
外部流程包括需求讨论流程、需求确认流程、系统初审流程、系统终审流程等等。
内部流程包括需求分析流程、设计流程、开发流程、测试流程等等。
每个组织要根据自身特点和项目特点按照CMM规范的要求制定流程,并对流程进行讲解,按照流程严格执行。
在流程的各个环节完成软件项目的输出:需求书...
求个软件工程作业
面向对象与结构化方法的比较研究 xxx (xxxxxxxxxx) 摘要:随着计算机的硬件及通讯技术的发展,计算环境发生了深刻的变化。
计算环境的变迁和不断增长的软件需求对程序设计方法学提出了一个又一个的挑战,程序设计方 法学也在挑战中前进。
首先回顾软件工程程序设计方法的发展历史,指出结构化和面向对象是软件工程程序设计方法中的2个核心思想,分析、探讨了结构化程序设 计方法与面向对象的方法的区别,并就如何在实践中正确应用给出了一些建议。
关键字:程序设计方法; 面向对象; 结构化1引言:随着计算机硬件及通讯技术的发展,计算机环境发生了深刻的变化,计算机环境的变迁和不断增长的软件需求对程序设计方法提出了一个有一个挑战,程序设计方法也在挑战中前进。
计算机发展经历了3个主要阶段:大型主机,客户/服务器以及网络计算。
与此相对应,软件工程的设计方法的发展可分为4代。
1.1第一代面向过程的程序设计方法 面向软件系统的信息流程图,采用面向过程的程序设计语言或面向进程的程序设计语言,实现软件设计流程图所描述的信息处理过程的功能,称为面向过程的程序设计方法或面向进程的程序设计方法。
这种方法适用于设计小规模专业软件包,软件的通用性、重用性和扩展性差。
1.2 第二代面向模块的程序设计方法 结构上将软件系统划分为若干功能模块或实体,分别采用模块化程序设计语言,如:pascal 编程实现,再由各模块联结,组合成相应结构的软件系统,称为面向模块的程序设计方法或模块化程序设计方法,也称为面向实体的程序设计方法。
这种方法适用于设计模块化、结构化程序,可提高软件系统的模块化和结构化水平,设计和组装较大规模的软件系统,有助于提高软件的通用性、重用性和扩展性。
1.3 第三代面向对象的程序设计方法 所谓对象是指具有一定结构、属性和功能的实体,采用对象和对象类,以及对象之间的相互通信的消息,描述客观世界中的各种事物及其相互关系,建立面向对象和消息的具有层次结构的世界模型。
面向对象的程序设计方法基于上述面向对象世界模型。
采用面向对象的程序设计语言,如c++、smalltalk 等编程实现。
这种方法具有通用性,适用于广泛应用领域的大规模软件系统设计。
有助于提高软件的重用性、扩展性和移植性,提高编程效率和程序自动化水平。
1.4 第四代面向智体的程序设计方法 面向智体的程序设计方法是面向对象的程序设计方法的发展。
在程序设计方法的发展演变历程中,结构化和面向对象思想是最核心的思想方法。
结构思想体现了人们抽象思维和复杂问题分解的基本原则与要求,而面向对象则反映了客观世界由对象组成这一本质特点。
2 软件工程程序设计方法的出发点 从程序结构来看,每个子问题形成整个程序结构的一个构件,这个构件称为一个模块。
程序的算法结构,就是一个由模块连接成的层次结构。
在软件工程中,把这种设计方法归结为软件工程设计方法学。
该方法学的基本表述为:自顶向下,逐步求精,模块化层次结构设计。
程序设计方法的本质是问题的抽象与分解,各种程序设计方法的区别在于其分解的因子不一样,处理数据对象及相关操作的方法不一样,也就是出发点不一样。
3 结构化程序设计方法 结构化程序设计方法包含以下内容。
3.1 结构化技术 结构化技术包括结构化分析(S A )、结构化设计(SD )、结构化程序设计(SP )3 方面内容,对应于软件开发时期的分析、设计和编码阶段。
3.2 结构化分析 结构化分析是70 年代中期由DeMarco 和Yourdon等倡导的一种基于功能分解的分析方法,即使用数据流程图、决策表、决策树等工具,来建立一种符合用户需求的结构化说明书。
3.3 结构化设计 结构化设计是一种面向数据流的设计方法,也就是采用最佳的可能方法设计系统的各个组成部分以及各成分之间的内部联系的技术,目的在于提出满足系统需求的最佳软件的结构,完成软件层次图或软件结构图。
4 面向对象的方法 面向对象技术:面向对象技术包括面向对象分析(O O A )、面向对象设计(O O D )及面向对象程序设计(O O P )3 部分内容。
O O P 是在结构化程序设计的基础上,于8 0 年代初涌现的一种程序设计方法,但其真正显示力量和被产业界所重视还是最近几年的事。
封装是整个O O P 方法的基础,主要用于在数据段外围构造保护层,以限制外界变化的影响,所有的数据访问都由保护层内的过程间接处理。
应用程序员不必再按照将程序设计语言逐句拼装的方式来构造整个软件,只需组合、重用由系统程序员开发、可供他人用来装配的软件集成块即可。
例如,Visual Basic(VB)是一种面向对象的程序设计语言,与传统DOS 下的Basic 或Quick Basic 最大的差别在于它运用了面向对象的概念。
V B 建立了一个事件驱动的环境,供用户直接调用。
程序设计人员只要专心数据的运算处理,其余诸如W i n d o w s 应用程序下所见的滚动条、按钮、下拉式菜单和对话框等,都已经有对象供用户进行调用,而且每个对象又都有许多事件、属性和方法,供用户填入适当值或程序码,从而形成一个应用程序。
5 结构化程序设计方法与面向对象的程序...
如何组织软件开发团队
这跟你要开发什么软件、使用什么开发模式、有多少预算、有多少开发时间等很多因素有关,比较复杂。
在软件工程领域,这是一个大问题,相关论文不计其数,有兴趣可以查阅期刊文献。
给你说说最常用的吧,是一种基于纵向管理结构和瀑布开发模式来进行组织的开发团队。
分为: 项目负责人:负责统筹项目运营方面的一切事务,预算管理、进度查询、会议组织安排、职能分配、客户对话洽谈等等。
架构师:负责进行需求分析、软件架构构建、概念与逻辑设计、功能细分、系统性能分析等等。
前台/界面设计师:主要负责软件GUI设计。
数据库工程师:负责数据库的搭建、优化和管理。
程序员:负责后台代码编写。
测试员:根据软件测试技术来进行相应的功能测试,比如黑盒、白盒测试、单元测试等等。
客服人员:负责软件到客户的安装、使用、售后、答疑等问题。
根据项目大小和任务量,每一个职能分类可以是一个人或几个人,形成局部纵向上下级负责制,比如项目经理与副经理、界面设计总监与界面设计师、总软件工程师与程序员等等。
...
软件工程专业是做什么的?
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。
在就业方面,可以从事软件开发,软件设计,软件售前,软件售后,QA,项目经理,服务器维护等各种方面的工作。
如何解决软件研发团队管理的问题
软件组织中什么是最重要的呢?团队和开发管理。
今天我们的主要话题就是围绕着团队和开发管理展开的。
在很多场合,我们都听到人们说“人才是最重要的资产”,我想,这不是一句空话。
有了人才就有一切,这是一个真理。
对于软件开发来说更是如此。
当然,对人才的关注并不意味着要人才堆积甚至浪费,人才浪费反而会影响整个团队。
人才只是一个个的点,如果没有形成一个有效的团队,人才再多也毫无意义。
软件开发是一个需要协同作战的工作,团队是软件开发工作的基本组织,因此形成一个有效的团队是软件组织成功的基础。
很多时候,团队作战听起来容易做起来难。
有一次,我和一个大型软件企业的CTO聊起了软件组织的模式,他打了一个比方,说软件开发就象做外科手术,外科主任应该是技术最强的人,熟知每一项技术细节的人,所以软件组织的领导也应该是技术最全面,每个细节都精通的人。
软件开发真的象医生看病做手术吗?我们来看看这里面有什么不同。
医生通常面对的是一个病人,通常处理的是一个个案,当然一个复杂的手术也需要麻醉、影像、护士、助手的配合才能完成。
一个软件项目呢?软件项目也有大小的区别,小的项目一个人处理所有环节,前端、业务逻辑、数据库;大的项目通常有一个团队共同完成,需求分析、结构设计、概要设计、详细设计、编码、测试,中间贯穿配置管理、流程管理等等,可由几人、几十人、几百人的团队共同完成。
当领导几十人、几百人的团队的时候,项目的成功与否不光是领导者的技术能力所能够决定的了,更重要的是领导者的管理能力和领导能力决定的了。
可见,不同软件企业的CTO对软件组织的模式认识也是不同的。
既然我们认识到了团队是一个软件组织的基本作战单位,那么我们应该怎样建立一个样团队呢?我们建立的团队应该包含哪些模块呢?我们可以从一下几个方面入手来对我们面对的问题先进行一个分析: 团队的技术要求是什么?团队要具有哪些功能模块?什么样的员工适合我们的团队? 下面我们来分析一下以上3个问题。
团队的技术要求是什么? 通常,我们需要分析一下我们工作的技术要求。
我们可以把软件系统作一个简单的分类: 基础系统,如操作系统、数据库系统、服务器系统 专业系统,如人工智能、大型索引系统 应用系统,如BOSS、BI系统 在这些系统中,也存在不同的分工。
尤其是应用系统,分工更为繁多,比如:系统分析工程师、架构工程师、核心层开发工程师、业务层开发工程师、表现层工程师、美工、项目管理人员、测试人员,等等。
不同的系统具有不同的技术要求,比如实时系统和信息系统的要求就不一样,常见的实时系统如电信系统,要求任何时候都不能中断,而信息系统,比如简单的OA系统,短暂的停顿造成的影响不是很大。
因此在建立软件组织的时候需要考虑所从事软件项目的技术要求,我们首先要考虑我们开发的是什么系统,它的技术要求是什么,并在此基础上考虑软件组织的构成人员的要求。
这个道理其实很简单,通常没有人为了OA系统的开发去招聘研究算法的博士。
同时,对系统技术要求的过低估计通常会造成很低的客户满意度,也不利于组织的能力的提升。
因此我们要仔细分析组织的技术要求,同时考虑组织未来发展的要求,尽量做到合理估计组织技术能力需求。
团队要具有哪些功能模块? 很多人都看过软件工程方面的书,在实践中我们基本也是按照规范去做的,现在,我们简单总结一下一个软件组织应该具有的能力:需求分析,架构设计、概要设计、详细设计、编码、测试、配置管理、流程管理、过程管理等等。
但并不是任何规模的软件组织都要完全建立独立的组织来完成上述的功能,很多时候软件团队也是可以人员复用的,比如设计和编码通常可以融合。
通常我们需要根据我们项目的实际情况,对组织能力作出适当的裁减,对人员复用作出合理的安排,并在此基础上决定我们的组织规模和构成。
什么样的员工适合我们的团队? 这可能是在建立团队的时候最不确定的因素,也最没有规范的因素。
不同的管理者对人员的筛选会有不同的要求,因而构成的团队也具有不同的气质。
同样是团队,有活泼的,有严肃的,有纪律严明的,有松散的,有喜欢冒险的,有害怕冒险的,有繁文缛节的,有简单明了的,这都跟管理者自身的喜好有关。
这里就我个人的经验,谈谈在选择人员的看法。
我们对人员需要被考察的素质做一个总结: 经验值;能力值;潜力值;洞察力;敏锐值;诚实度;老实度;开朗、 大度、外向值;谦虚度;自知力值;亲和力值;负责度;细致度;抗压度;稳定度;承担责任能力。
这些素质中,有些我们可以通过考试的方法了解,有些可以询问,也有不少特质需要我们自己去感知。
在我们招聘的过程中,技术人员的笔试是很重要的,必须根据需要设立不同的考题对人员进行考察。
对于人员的能力和经验除了考虑目前他所具备的能力以外,还要考虑他的潜力,有些人具有很强的学习能力,在具备一定基础知识的情况下,可以降低对这种人经验的要求。
除了能力以外,一个人的情商对于我们的组织来说非常重要。
我们...
顶级软件工程师需要具备的?
顶级软件工程师,就是指高级软件工程师,需要以下具备的:在目前很多国内软件企业中,如果你是“高级软件工程师”,那么从需求分析,设计,开发,测试,甚至到客户这一条龙都可能由一个人来负责。
软件开发与测试首先,软件开发是软件工程师职责的基本组成部分,这点应该没有问题。
其次,此处的软件测试可分为开发前的驱动测试,和开发过程中的白盒测试。
驱动测试用于分析子系统/模块内部逻辑,用于在开发之前暴露开发过程中可能遇到的大部分问题和对子系统/模块进行更进一步的划分;白盒测试是保证在项目交接到测试团队手中时,能满足基本的项目要求,即能够进行α测试。
子系统/模块分析设计在软件架构师做完系统设计,项目经理进行项目分工后,项目就正式进入开发环节。
这时候每个软件工程师会拿到自己负责的子系统/模块,首先要做的就是进行分析设计,其次才是开发。
开发前进行分析设计,便于从整体上对子系统进行把握,提前隔子系统中的变化点和问题,同时也可以对子系统进行更详细的划分,用于制定个人的工作计划,与项目经理和软件架构师进行具体的沟通。
撰写文档在进行子系统和模块设计的同时,要撰写子系统设计说明书;在开发过程中,要记录技术要点和发现的问题,同时如有需要,要修改子系统设计说明书;在白盒测试时,要记录每个Bug。
定期主动沟通在项目开发过程中,项目经理需要和团队中的每一个人沟通任务进度,其主要职责是从整体上把握和控制项目的进度。
那么作为团队一员的高级软件工程师通常会负责项目中很重要的子系统/模块,这些子系统/模块往往能决定项目的成败。
因此定期主动与项目经理沟通解决遇到问题,与架构师和专家沟通解决技术难题就显得非常重要了。
另外,就对个人而言,定期主动沟通也往往表现为个人的主动积极性,对于个人长远发展非常有益。
持续学习也许有人会觉得学习应该与职责无关,狭义看来确实如此。
然而,不断学习新知识,提高个人技能,于公司而言,能提升工作效率;于个人而言,益于职业发展。
因此,工作之余,不管你职位如何,持续学习就显得非常重要且必要。
带新人这点也许不是硬性要求,但国外有高手带领新手这样一种师徒习惯,也应该学习并发扬。
通常情况下新人会与高级软件工程师协同工作,因此带新人一方面,带领新人可以有重新审视自己知识的机会;另一方面能够让新人更快入手,降低学习成本和提高工作效率;同时也能保持良好的人际关系。
以上是个人对高级软件工程师职责范围的认识,也许有些比较牵强,然而就对职业发展而言,要想做好高级软件工程师,上面几条是平时工作中必须要做的。
什么是软件工程化时代
本文译自著名IT顾问和评论员David M Williams的博客,在这里,他提出了关于软件开发的全新理念。
Tom DeMarco是著名的Peopleware: Productive Projects and Teams一书的合著者,然而在这个月,DeMarco向IEEE的计算机协会提出个人意见:软件工程时代结束了。
大多数计算机软件开发者必读书目中都包含Peopleware一书,它于1987年首次出版,1999年再版。
尽管出版多年,Peopleware依然具有重要参考价值,因为它并不注重软件技术本身,而是关注人的因素。
因此,DeMarco给这本书起了一个带People的名字。
也许并不像Steve Ballmer,Steve Jobs或者Linus Torvalds这些大师们演讲时拥有那么多粉丝听众,但DeMarco依然是全世界高质量软件开发从业者们执着追随的对象。
一个类似的公告出现在今年7月Computing Now杂志(IEEE计算机协会的出版物)的DeMarco视角专栏,标题为《软件工程:一个过时的概念?》。
这在很多层面上都是很吸引眼球的,除了DeMarco的作者身份以外,标题还蕴含着出人意料的观点:软件工程是一个正在消失的概念。
实际上,DeMarco本人就一直引领着软件工程的现代观念,在Peopleware之前,他写了Controlling Software Projects: Management, Measurement and Estimation(《控制软件开发项目:管理,测算和评价》)一书。
这本1982年销量冠军的第一行文字在接下来的27年中被广泛引用,DeMarco在其中写道:一个人无法控制他不能测算的东西。
为了解决这个问题,软件工程师们克服重重困难,勇敢地一次次去分析和揭示一切软件里可能的规律。
可是,随着时间的推移,DeMarco现在显露出对其原先所持观点的不安。
那句引文中(书名也是)暗示了控制是一个重要的方面,他说,也许对任何软件项目来说都是最重要的方面。
但现在不是了。
他说,接着举了Google Earth和Wikipedia这两个典型例子,它们都是在发展中不进行多少控制的软件。
为了说明他已改变了的推理,DeMarco引用了两个假定的项目:最后都要花费大约100万美元,但项目A将产生大约110万美元的效益,项目B将产生超过5000万美元的效益。
很明显项目A会有更严格的控制,如果预算超支或软件发布推迟或质量不达标,项目会冒很大的亏损风险。
相比之下,项目B由于投入和产出差异巨大,控制可以很松。
很明显的是,在这里面成本、期限和质量问题依然存在,但项目最终会赚钱。
如果不赚钱的话,一切都会乱掉。
由此,DeMarco沉思自语道:实际上一位主管越是注重控制,他的团队越是可能在开发一个只能艰难盈利的项目。
接着他说,管理软件开发的问题应该不是关于严格的控制和软件工程所规定的规律,相反,开发团队应当开发产生真正效益的项目,主管应当降低对项目控制的期望。
这是在假设DeMarco以上第一个建议更关注企业领导者或分析师,因为是由他们确定一个软件解决方案是必要的,而不是开发者被指派去编写这些代码。
普通公司里的程序员并没有选择他们开发项目的权利,但显而易见,主管们应该在投入资源开发之前确定一个项目数量上的效益和质量上的效益,他们得在这方面多下功夫。
一个软件工程之父,不停地在告诉人们要放松,不要整天盯着开发项目的成本和时间要求,这听起来让人感到困惑。
为了给他的观点进行辩护,DeMarco拿青少年来做类比。
对于青少年,你怎样在他们身上找到一个人无法控制他不能测算的东西的理论依据?例如,一位称职的家长会如何客观地评价他子女的道德水平、教养和同情心?在这种情况下,你无法控制一个抚养对社会有益成员的育人项目,相反,在软件项目中你管理的是员工,控制的是时间和成本,从根本上说,在这过程中你得尽可能在拥有极少反馈信息的情况下掌控大局。
用同样的方法,一支软件开发团队应当在开发过程中按照相关价值大小、文档和测试结果不断向项目中增加程序块,在项目主管宣布项目完成的任何可能时候都能立刻将产品打包并发布。
DeMarco说,去设计规划一套软件依然有其意义,但那并不是软件工程这个术语所要真正表达的意思,设计策划软件是一整套规则,过程,检视,度量,规划,追踪以及许多其他元素的总和。
几十年来,开发团队们都在成本预算和时间限制上痛苦地挣扎着,但这不该是他们追求的至上目标。
更重要的目标是要转变。
DeMarco现在说,去切实改变这个世界或一家公司或它运作的模式才是更重要的。
几乎是为了向自己推行了几十年将工程化原则应用于软件开发的想法表示忏悔,DeMarco说这场转变是我们一向应该关注实施的。
在我个人看来,DeMarco说设计规划一套软件的做法与词语软件开发是不同的,这毫无疑问,的确,有很多人开始怀疑开发软件到底是不是一种包含度 量控制和管理控制的工程化实务,而事实却是,软件本身并不像物理学那样有着坚实的科学理论基础,而是充满了抽象的概念,虚幻的构想甚至是一次次的试验研 究。
我职业生涯的美好回忆中就有自己提出的解决方案帮助公司进行重大转变的一系列例子,其实谦虚地说,我的这些方案在技术层面上一点也不特别,但它们对公司起到的效果却是立竿见影。
这些直到现...