想学习软件研发,南京有什么培训机构比较靠谱?
做在线教育平台的公司目前有很多,可以参考一下这张图,其中以格子匠为代表的第三方支持工具,都是能搭建在线教育平台的。
格子匠能帮助有教育资源的企业和个人独立部署一套基于移动端完整的平台系统,实现公众号、小程序、PC端同步独立部署。
还有课程推广、学员招生、学员学习管理、课程评价等功能。
...
软件研发项目需求变更如何管理?
变化并不是人们最害怕的,最怕的是跟不上变化的步伐。
同样,在软件研发过程中需求的变更会给研发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件研发的进度、成本和质量也就有了"安全"的基础。
需求变更管理的需求 需求变更是因为需求发生变化。
根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。
需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么。
用户常常以为自己清晰,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改动他们的工作方式;或要研发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。
随着研发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。
于是,他们可能会想到各种新的功能和特色,或对以前提出的需求进行改动。
他们了解得越多,新的需求也就越多,需求变更因此不可避免地一次又一次出现。
这时,如果研发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来管理需求变更,那么非常可能造成项目进度拖延、成本不足、人力紧缺,甚至导致整个项目失败。
当然,即使按照需求变更控制流程进行管理,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。
但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更管理的目的所在。
六大原则 实施需求变更管理需要遵循如下原则: 1.建立需求基线。
需求基线是需求变更的依据。
在研发过程中,需求确定并经过评审后(用户参和评审),能建立第一个需求基线。
此后每次变更并经过评审后,都要重新确定新的需求基线。
2.制订简单、有效的变更控制流程,并形成文件。
在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。
同时,这个流程具有一定的普遍性,对以后的项目研发和其他项目都有借鉴作用。
3.成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。
CCB由项目所涉及的多方人员一起组成,应该包括用户方和研发方的决策人员在内。
4.需求变更一定要先申请然后再评估,最后经过和变更大小相当级别的评审确认。
5.需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。
6.妥善保存变更产生的相关文件。
应对之道 需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。
如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。
变更控制流程如图所示。
针对变更控制流程,笔者在实际工作中总结出了软件研发人员在需求变更管理实践中的几点对策: 相互协作 非常难想像遭到用户抵制的项目能够成功。
在讨论需求时,研发人员和用户应该尽量采取相互理解、相互协作的态度,对能解决的问题尽量解决。
即使用户提出了在研发人员看来"过分"的需求,也应该仔细分析原因,积极提出可行的替代方案。
充分交流 需求变更管理的过程非常大程度上就是用户和研发人员的交流过程。
软件研发人员必须学会认真听取用户的需求、考虑和设想,并加以分析和整理。
同时,软件研发人员应该向用户说明,进入设计阶段以后,再提出需求变更会给整个研发工作带来什么样的冲击和不良后果。
安排专职人员负责需求变更管理 有时研发任务较重,研发人员容易陷入研发工作中而忽略了和用户的随时沟通,因此需要一名专职的需求变更管理人员负责和用户及时交流。
合同约束 需求变更给软件研发带来的影响有目共睹,所以在和用户签订合同时,能增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更能接受、拒绝接受或部分接受,还能规定发生需求变更时必须执行变更控制流程。
差别对待 随着研发进展,有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。
遇见这种情况,研发人员能向用户说明,项目的启动是以最初的基本需求作为研发前提的,如果大量增加新的需求(虽然用户认为是细化需求,但实际上是增加了工作量的新需求),会使项目不能按时完成。
如果用户坚持实施新需求,能建议用户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。
同时,还要注意控制新需求提出的频率。
选用适当的研发模型 采用建立原型的研发模型比较适合需求不明确的研发项目。
研发人员先根据用户对需求的说明建立一个系统原型,再和用户沟通。
一般用户看到一些实际的东西后,对需求会有更为周详的解释,研发人员可根据用户的说明进一步完善系统原型。
这个过程重复几次后,系统原型逐渐向最终的用户需求靠拢,从根本上减少需求变更的出现。
目前业界较为流行的叠代式研发方法对工期紧迫的项目的需求变更控制非常有成效。
项目管理论坛 用户参和需求评审 作为需求的提出者,用户理所当然是最具权威的发言人...
进行软件研发人员考核的基本原则有哪些?
◆要体现公司的价值观 公司的价值观体现了公司认可什么类型的人员?要挽留哪些人?提倡做什么?对这些人员的认可可以通过具体的考核办法落实下来。
比如企业鼓励在某一个业务领域内积累丰富的领域经验,鼓励在某个技术方向上进行深入钻研等,对于提倡的这些行为,要有具体的奖励措施。
所以在定义考核办法时,需要首先考虑清楚要体现企业的哪些价值观。
◆要体现多劳多得,质与量并重 不能让那些完成了大量艰苦工作的人员吃亏,否则就会打击真正努力工作的人员的积极性。
多劳多得原则的实现,基于对工作量的计算。
规范的管理都是“以人为本、以过程为核心、以度量为基础”的。
要做到多劳多得就需要做好对工作量的度量,如果仅仅注重工作量而不关注工作质量,显然是不对的,而对于质量的考核,可以通过多个渠道来获得数据,如发现的缺陷个数、客户的反馈等等。
当然多劳多得的前提是团队的目标达成了,如果目标未完成,多劳未必多得。
◆要鼓励创新与规范管理 管理与创新是软件企业发展的2个轮子,通过规范管理可以确保企业的常规发展,[考试大提供]通过创新实现企业的跳跃式发展,管理为创新提供了转化为生产力的基础,创新可以快速地提高企业的竞争能力,因此在考核办法中要体现出来对这2者的认可。
有的企业设立了创新基金,专门用来奖励那些技术创新、管理创新等,有的企业在研发人员的考核指标中加入了对过程改进工作的支持等指标。
◆要鼓励技术复用 成功的软件企业必须在人员、技术、过程三个方面加大投入。
软件复用是目前软件公司提高软件生产率的最有效的手段之一,为了在企业内建立组织级的技术复用体系,首先就要鼓励大家主动去提取可复用的各种构件,主动贡献可复用的构件。
对于这种提取可复用构件的行为,应根据其可能带来的收益,适当给予奖励。
◆要因时而变,但要尽可能保持连续性 考核办法的制定都有一定的针对性,具有一定时限性,随着公司内外部环境的变化,随着公司文化的逐步稳定,对考核办法要逐步调整,在改变考核办法时,要注意保持考核办法的连续性,不要变化太大,否则就会让被考核人无所适从,产生观望的心态,或者在研究考核办法上花费很多时间,造成不必要的生产效率的下降。
◆要量化与非量化结合 如果没有量化的考核指标,全靠非量化的指标,对于开发人员来讲,很难体现多劳多得的原则,很容易走向“吃大锅饭”的模式,无法调动开发人员的积极性。
如果全量化也很难,在开发过程中,有很多工作难以量化,比如需求开发的工作,就很难定量的计算工作量。
因此在考核时,在尽可能量化的基础上,也允许有一些非量化的指标的存在。
至于2者的比重,可以根据当前企业的管理水平来确定。
对于管理比较规范的企业,成熟度比较高的企业,可以采用量化的指标多一些,量化的比重大一些。
◆要区分不同的岗位,不能一刀切 对于项目经理、需求分析人员、设计人员、程序员、测试人员、质量管理人员等,工作性质、能力要求、绩效表现的特征都有比较大的差别,因此要区别对待。
这样便于体现考核办法的内部公平性与外部公平性。
比如对于质量管理人员,大部分是日常的事务性的工作,其工作业绩的体现是长期的,他们的工作重心是预防缺陷的产生,采用量化的数据就比较困难,可以考虑采用改进率等指标来考核,而程序员的主要工作是实现设计,[考试大收集]任务的规模与他们的工作效率、质量是可以量化的,这2种类型的考核办法就应该是不同的。
◆要保证被考核人的及时知情权 事先要将考核办法告知被考核人,考核结果要及时通知被考核人。
考核的目的是为了发现改进工作业绩的方法,激励员工更加努力地工作,考核办法也代表了公司的价值观,因此要让被考核人对考核办法很清楚,让他们知道什么是应该努力去做好的,这样才能起到激励作用。
考核的结果应及时通知被考核人,这样能够给他们一个及时的肯定或者否定的刺激信号。
◆不以被考核人自己提供的数据为考核依据 如果以被考核人自己提供的数据作为考核依据,则会造成数据的失真。
在软件企业中推行开发人员的个人日志时,遇到的最大的问题就是日志的失真问题,为什么呢?因为开发人员担心自己填写的日志会成为自己的考核依据,会成为评价自己的工作努力程度的依据,因此本能地会倾向于满负荷地填写自己的工作量。
◆考核指标要和被考核人直接相关,被考核人对考核指标的达成能发挥重要的作用 在很多软件公司中,经常发现员工的考核与公司的利润、部门的利润或者项目的利润挂钩,对于销售部门、事业部或者其他直接与市场相关部门,这种考核是有激励作用的,对于研发人员来讲,这种办法的激励作用就不那么明显了。