软件开发人员管理(软件开发人员管理 难点)

软件开发 1636
今天给各位分享软件开发人员管理的知识,其中也会对软件开发人员管理 难点进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!本文目录一览: 1、软件开发项目的人力资源管理

今天给各位分享软件开发人员管理的知识,其中也会对软件开发人员管理 难点进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

软件开发项目的人力资源管理

项目的成功离不开人的因素,项目管理十大知识领域中,除去整合管理,范围管理,进度管理,成本管理,质量管理外,其它5个基本都直接与人有关,沟通管理,采购管理,风险管理,干系人管理,还有资源管理,可见人在项目管理中的重要性。而软件开发项目的成功,更是需要倚重高素质的软件开发人员。

和一般人力资源管理类似,项目的人力资源管理,包含有如下四个过程。

1. 人力资源计划编制

第一步,确定需要些什么人。根据项目管理目标和整体计划,识别和记录项目角色、职责、所需技能、报告关系,并编制人员配置管理计划。

2. 组建项目团队

接下来,将人找齐。确认人力资源的可用情况,并为开展项目活动而组建团队。

3. 项目团队建设

人找来之后,想办法让大家相互协作。提高大家工作能力,促进成员互动,改善团队整体氛围,以提高项目绩效。

4. 管理项目团队

最后,让大家持续高效。跟踪团队成员工作表现,提供反馈,解决问题并管理团队变更,以不断优化项目的绩效。

在规划人力资源管理过程中,主要采用组织图和职位描述,以确认所需的人力资源。

在组建项目团队过程中,需要与各职能部门经理谈判或者招募来争取所需要的人员。

在建设项目团队过程中,可以采用培训,举办团建活动,集中办公,认可与奖励的方式来提升项目成员协作效率。

最后在管理项目团队过程中,需要用到观察与交谈,绩效评估,冲突管理,人际关系等技能,以持续优化项目管理绩效。

软件开发人员的管理办法

进度怎么判断呢?其实,归根结底,开发的进度是由人来控制的。一方面可以根据客户的要求,在规定的时间内完成项目;另一方面根据费用来限定开发的时间。当然,这些需要一个项目的核心人物来全程协助完成。

对软件人员的考核,其实大部分都是与其他公司的考核制度是一样的。从在项目中所作的贡献,在一个项目中所发挥的作用,比如协调、组织等。不过,任何一个项目完成时,每一位参加项目的人员都是有精神方面和物质方面的奖励的。

关于开发软件时的加班,现在大部分公司都是实行调休制度。在一个项目完成后,作为软件开发人员,无论是从身体上还是从精神上,都需要经过一段时间的调整,所以公司可以组织软件人员开展活动,比如旅游。对于加班工资,可以每一季度发一次,美其名曰“季度奖金”。如果想将公司规模发展得更大、希望公司的明天更辉煌,从员工的角度出发,多为员工着想。这样,员工也会视公司的明天如自己的明天,公司也将越走越远。

对于控制软件人员编写的源代码外泄问题,如果公司对员工能够像上面所说的一样,然后保密意识再加强一些,应该就不会发生源代码外泄问题了。不过,安全起见,最好与软件人员签订相关的协议,倘若出现问题,可追究相关的法律责任。另外,加强每一个员工的保密意识也很重要。

软件人员的日常管理办法,与其他公司唯一不同的是,开发软件肯定会时常加班,所以在对员工上午上班时间可以适当放宽,要体现公司“以人为本”的原则。作为一个软件人员是辛苦的,作为软件人员的领导者,更应该体谅、关心他们。

软件开发管理如何风险管理

风险管理的达成必须包括三个要素:

首先,在项目开发计划中必须制定风险管理计划;

第二,在项目预算中必须包含解决风险所需的经费;

第三,评估风险时,风险的影响也必须纳入项目计划中。

下面就软件开发过程中经常发生的风险,谈谈我们采取的预防措施。

1、需求不明确

需求不明确是软件开发过程中经常可能遇到的问题,这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中,需求不明确所造成的浪费是最大的,必须尽早尽可能解决。确定用户需求是件非常困难的事情,我们常常从以下几个方面着手处理需求不明确问题:

(1) 让用户参与开发

提供一个协作开发环境,让用户参与开发过程。如果条件不允许,至少应该在每次迭代的需求分析和系统测试阶段,让客户能够参与开发。

在选择参与开发过程的用户时,一方面,要尽可能争取精通业务或计算机技术的用户参与。另一方面,如果开发的产品要在不同规模、不同类型的企业应用,应该选择具有代表性的用户参与。

仅仅让用户参与是不够的,应该采取一定的激励措施,提高用户参与的积极性。

(2) 开发用户界面原型

用户通常不善于精确描述自己的业务需求,系统分析员需要借助白板、白纸等沟通方式,帮助用户清楚表述需求。然后,开发一个用户界面原型,以便用户确认需求。用户界面原型的作用仅仅是收集用户需求,不应该再作它用,也不要给用户造成系统快要实现的错觉。

(3) 需求讨论会议

对于用户分布广、用户量大的项目,要全面收集用户需求,往往很困难,通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见,然后集中各地或各部门的用户代表,举办一次需求研讨会,通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。

(4) 强化需求分析与评审

首先,需求分析是项目成功的基础,需要引起足够的重视,并分配充足的时间和人力,要让有经验的系统分析员负责,切忌让项目新手或程序员负责。其次,要进行需求评审,尽可能让用户参与需求评审,不要让需求评审流于行式。第三,也是最重要的一点,通过评审的需求规格说明书,要让用户方签字,并作为项目合同的附件,对双方都具有约束力。在公司内部要将通过评审的需求规格说明书,纳入配置管理。

2、项目缺少可见性

当一个项目经理或一名开发者说已经完成了80%的任务,您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间,甚至永远都不能完成[1]。软件开发项目,往往在项目进度和软件质量方面缺少可见性,项目越缺少可见性,项目就越难以控制,项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。

(1) 迭代开发

采用迭代的开发模型,将产品的交付过程分为多个阶段,按照功能递增式交付。以下是一些典型的迭代:

一次简短的先期迭代,以建立规模和前景并确定商业理由;

一次精化迭代,其间将为稳定的构架划定基线;

一次构建迭代,其间将实现用例并充实构架;

几次产品化迭代,将产品转移到用户群。

每次迭代,都要充分接收用户的评审意见,以便为自我纠正。渐近式的功能交付,有利于降低开发人员的压力,增加用户的满意度,有利于增强项目的可见性,是最好的进展报告。

(2) 技术评审

技术评审是确保软件质量的重要环节,技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交叉审查,或者是高级开发人员对普通开发人员的审查;会议评审一般应至少每两周进行一次,每次评审时间不宜太长;同行专家评审包括技术和业务两个方面的专家,经常性地让精通业务的用户专家参与项目评审,是项目成功的重要保证。

另外,充分利用质量审查的工具软件,也有利于提高代码质量。例如:在Eclipse开发环境中,可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。

(3) 持续集成

持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度,并迅速发现集成过程中出现的问题并进行解决[1]。

开发小组应制定持续集成的制度,一般情况下每日构建一次,可以利用Ant等构建工具进行Java应用程序的构建。小组成员应在每个功能开发完成后,及时向版本控制系统(如CVS)提交代码,而且不应该向版本控制系统提交有问题(编译通不过)的代码。

每日构建、持续集成,让项目进度跟踪工作更加容易。当项目小组每天重新编译系统时,已完成与未完成的功能清楚可见,小组成员能够简单地从软件的表现知道距离整体完成还有多远。

3、新技术引入

技术创新是一种具有探索性、创造性的技术经济活动。在开发过程中引入新技术,不可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。

(1) T形软件开发

在项目开发早期,开发小组应该建立系统的架构,解决关键技术难题、开发系统的基础构件,并对系统所需要应用的技术做深度探索。例如:基于JavaEE5构建全国联网售票系统,涉及到分布式事务处理、海量数据存储、异构平台互连等关键问题,应该优先处理这些问题;对开发所涉及到的EJB3、JSF、 JBoss Seam、Eclipse RCP等技术,要做深度探索。

越是技术复杂度高的项目,就越应该早地处理技术难题。如果在项目开发的中期或后期才发现架构有问题或是关键技术难题不能解决,则为时已晚。

(2) 充分论证

新技术开发是探索性很强的工作,潜在着许多失败的风险。在可行性分析阶段,要广泛搜集相关信息,设计多种可行方案,进行充分论证。在制定决策时,情报的数量和质量致关重要。掌握的信息越多、越准确,才能作出正确的的决策,项目失败的风险也就相对减少;反之,承担的风险就会增大。

(3) 同行经验

针对新技术,由于没有经验可借鉴,因此在探索过程中要充分利用互联网,通过搜索同行经验,往往事半功倍。要充分利用世界日益平坦化的优势,对于不能尽快解决的问题,可以先放一放,可能过不了几天,网上就有相类似问题的解决方案了。

4、技术兼容性风险

硬件产品之间、系统软件(操作系统、中间件、数据库管理系统)与主机设备之间、系统软件之间、应用软件与系统软件之间以及应用软件之间,都可能存在兼容性问题。往往系统集成的项目越复杂,兼容性问题就越有可能存在。

(1) 设计先行

在做系统的总体设计方案时,务必把好相关产品的选型关,确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。在网络平台建设方案中,明确相关设备的技术参数和配置要求。

(2) 售前产品测试

在做项目招投标工作时,要求投标方在售前提供产品兼容性测试,以避免在项目实施过程中才暴露技术兼容性问题。涉及应用软件开发的集成项目,要在开发工作的早期,做技术兼容性测试,以避免在项目开发后期才暴露技术兼容性问题。

例如,我们在开发深圳市汽车客运站售票及站务联网调度系统时,为了确保技术兼容,在做硬件招标时要求小型机设备厂商提供售前技术兼容性测试工作,并将测试结果做为评标指标。在深圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时,暴露了许多应用软件、应用服务器、数据库和操作系统之间的技术兼容性问题,如果这些问题在系统实施时才暴露或处理,势必会拖延项目进度。

5、性能问题

由于先期设计不足,性能问题往往在系统切换或新系统使用一段时间后暴露。出现性能问题往往要进行大量的优化工作,甚至局部的或全面的重新设计。无论是用户还是开发者,谁都不希望出现性能问题。

(1) 性能规划

在系统设计时,应做好前期做性能规划,对可能出现性能问题的环节做到充足的估计。在做数据库设计时,应争取DBA参与。

另外,在技术方法方面,尽可能采取一些性能优化模式,如DTO、AJAX、延迟加载等,尽可能在开发过程中解决了性能问题。不至于到了项目后期才解决性能问题,既费钱又费时。

(2) 性能测试

在开发过程中,要重视性能测试和压力测试,尽可能模拟现实使用环境,搭建测试平台。另外,由于开发环境的计算机往往比生产环境的计算机配置高,在做测试时应尽量找一些配置低的机器、较小的网络带宽进行测试。

(3) 充足的调试时间

在项目开发计划中,为后期性能优化留有余地。在对系统进行性能优化后,要进行性能测试和压力测试,可能还要做几次回归测试。因此,应该留有充足的时间和人力。

6、仓促上线

在项目实施过程中,系统切换上线环节最容易出纰漏。项目好不容易开发完成了,却在最后最后时刻功溃一匮。如果项目小,影响面窄倒不怎么重要;如果是影响面大的项目,则千万不可出现问题。在系统切换前,应充分考虑各种可能出现的问题,做好风险对策。

(1) 应急预案

面对各种不可预知的风险,要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周,都会做好应急预案。新系统切换时,更应该做好应急预案。应急预案中应做好最坏的打算,售票系统不能正常工作时,准备手工票就是最坏的打算。

(2) 分步切换

为了减少风险的影响,可以做系统分步切换的方案。例如:售票系统在切换时,往往用新系统售预售票,或者是用新系统售长途车站,用旧系统暂时售短程票。待新系统运行稳定后,再全面切换到新系统。针对多个用户单位的系统切换,也可分单位进行。

(3) 交叉培训

新旧系统切换过程中,用户都存在适应过程。除了在切换前做好操作培训外,还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班,让早班的用户在交班时培训中班的用户,中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。

7、可用性问题

软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差,导致用户不满意,甚至被市场淘汰。在项目开发中应注意可用性问题,避免软件出现可用性方面的风险。

(1) 了解用户

到用户工作现场,了解目标用户使用软件的真实目的,从用户的角度、从用户的立场出发,了解如何通过软件系统替代用户的业务处理流程中,最繁琐、最容易出问题、或者是大量重复劳动的环节,让软件提高用户的工作效能和效率。例如:售票系统中,使用频度最高的界面是售票界面,售票员最关心的是钱不要出错(多了没收、少了要赔),因此,应收款和找余字体的显示应该突出、醒目;同样,票价和到达站也应该较为突出显示。通过快捷键、一键复位、数字小键盘等设计,尽量减少售票员敲击键盘的次数。否则,在日发旅客流量达七、八万人次的大型客运站,如果用户界面设计得不好,售票员一天工作下来,手指都会敲麻木。

(2) 参与型设计

与用户协作,让用户参与用户界面的设计、评审与测试,确保用户能够全面地、及早地发现可用性等方面的问题,并及时纠正。

让客户参与设计,而不要让客户设计,项目经理或高级设计人员应该主导设计。

(3) 竞争性分析

通过对市场上同类竞争性产品进行分析,或者对这些产品进行实验性测试,了解这些产品的用户界面问题,从而对新系统的开发提供启发。竞争性分析并不意味着可以剽窃别人的设计,而是通过分析竞争产品的优势和弱点,能够比以前的设计做得更好[5]。

(4) 一致性

如果用户知道同样的命令或同样的操作总会产生同样的效果,那么他们在使用系统时就会更加自信,同时也鼓励他们进行探索性学习,因为他们已经具备了使用系统新部分的基础知识[Lewis er al。1989]。

开发团队应遵循公司或小组制定的用户界面标准,就可以在很多方面保持一致性,切忌不要一个系统存在多种不同的界面风格。

郑州观致电子商务,拥有有效资源, 多起成功案例, 专业制作水平, 提供微期货平台搭建、分销系统开发、捕鱼游戏开发、第三方支付软件开发、商城网站建设、电商网站建设、网站定制开发、手机app软件开发、微信小程序开发、电商系统开发、办公系统软件开发一系列服务。精英团队为您以后保驾护航!

8、结论

在信息系统集成项目中,风险是多种多样的,是无处不在的。在项目管理活动中,要积极面对风险,要培养。越早识别风险、越早管理风险,就越有可能规避风险,或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目,应加强风险管理。如果不主动驾驭风险,就会面临风险。

怎样管理软件开发团队

高效软件开发团队的特征

高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作的基础之上的,成员共同的迎接挑战、有效的计划、协调和管理各自的工作以至完成明确的目标,高效的开发团队具有如下特征:

1、 具有明确且有挑战性的共同目标 一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多,通常技术人员往往会因为完成了某个明确的任务,而且这个任务的完成具有挑战性的意义而感到自豪,反过来团队成员为了获取这种自豪的感觉而更加积极的工作从而带来团队开发的高效率,如作为系统设计人员很清楚的知道在什么时候要做到什么,什么时候开始做,什么时候必须完成,为了完成工作必须面临哪些挑战,怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证,而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的,而且会为此付出高昂代价,因此高效的软件开发团队具有挑战性的共同目标。

2、 团队具有很强的凝聚力 在一个高效的软件开发团队中,成员们凝聚为一个整体共同进行工作,他们是相互支持、互相交流、互相尊重的,而不是相互推卸责任、保守、相互指责的,在一些散乱的开发团队中往往存在这样的问题,一些程序员是比较保守的,明明知道另外的模块中需要用到一段与自己已经编写完成但有些难度的程序代码,他也不愿拿出来给其它程序员共享,不愿与系统设计人员交流,这样给项目的进度造成了些不可度量的因素。

3、 具有融洽的交流环境 在一个开发团队中,每个人行使自己的职责,如需求分析人员制定需求规格说明、系统设计人员做系统概要设计和详细设计、项目经理配置项目开发环境并且制定项目计划等,但每个人的工作不可能做到完美的,如系统概要设计的文档可能有个别地方词不达意,做详细设计的时候就可能会造成误解,项目经理制定计划时可能忽略了某种风险的存在而造成执行者过于紧张的压力等等情况都需要大家通过交流、反馈的手段然后协商解决的,因此高效的软件开发团队是具有融洽的交流环境的,而不是那种简单的命令执行式的。

4、 具有共同的工作规范和框架 高效软件开发团队具有规范性及共同框架的工作,对于项目管理具有规范的项目开发计划,对于分析设计具有规范和统一框架的文档及审评标准,对于代码具有程序规范条例,对于测试有规范且可推理的测试计划及测试报告等等。并且所有成员都明白自己的职责,知道必须完成什么计划?由谁来完成?什么时候开始?什么时候结束?按什么顺序?等,总之一个高效的开发团队无论是工作内容还是工作流程都具有不同程度的规范性和标准风格的框架。

5、 采用合理的开发过程 软件的开发不同于一般商品的研发和生产,开发过程中会面临着各种难以预测的风险,比如需求的变化、人员的异动、技术的瓶颈、同行的竞争等,高效的软件开发团队往往是采用了合理的开发过程去控制开发过程中的风险、提高软件的质量、降低开发费用,这样的团队会根据自身的必要程度决定要执行哪些工作?如配置管理、资源管理、版本控制、代码控制等,团队还合理的分划并定义开发过程的里程碑,决定每项活动内容的底线和审评标准,决定各项活动的先后关系或迭代的关系等。总之高效的软件开发团队的开发过程的原则是高效率、高质量、低成本。

软件开发人员管理的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于软件开发人员管理 难点、软件开发人员管理的信息别忘了在本站进行查找喔。

扫码二维码