测试团队工作计划篇1

近两年来，院士专家工作站创新团队（简称：团队）在承担“挖泥船大口径电磁流量计”、“压力变送器自动化标定设备的研制”等国家重大科技成果转化和天津市科技支撑等重点项目的基础上，积极组织、带领团队成员参加“讲理想、比贡献”活动。通过组织开展群众性技术创新活动，为团队成员搭建创新实践平台，将实现团队成员个人价值与企业发展、实现中华民族伟大复兴的中国梦有机结合，为企业发展贡献才智，取得了突出成效。

2013年，在院士专家团队的指导、参与下，团队通过“讲理想、比贡献”活动完成新产品研发15项，形成新产品销售收入11918万元，实施工艺改进改善10项;申请专利27项，其中发明9项，获得专利授权19项，其中发明4项;获得中国仪器仪表学会科技创新奖1项、优秀产品奖1项、天津市技术发明三等奖1项、天津市技术进步三等奖2项，共计5篇。

引进创新要素

院士工作站创新团队通过积极引进创新要素，为中环天仪创新发展提供了有力的支撑。

一是引进院士专家高端人才智力。2012年，中环天仪在以院士专家工作站为平台，先后柔性引进天气动力和数值预报专家、中国工程院李泽椿院士和测试计量技术及仪器专家、中国工程院叶声华院士及各自团队。在长期合作的基础上又引进西门子前高管、国家“”（第三批“外专”）人选、德籍技术专家卡尔海因茨・施密特博士。院士专家带着丰富的技术、产业发展经验和独到的发展思路，为公司中长期发展提供了支持和指导，这也是公司在领军人才、拔尖人才引进上进行的一次新尝试，从而开辟了顶尖、高端（外籍）人才柔性引进和落户企业的“绿色通道”。

二是引进先进技术、成果。伴随院士专家而来的不仅是先进的理念和方法，同时还引进了先进的技术和成果。中环天仪先后引进了德国Thies公司超声波测风传感器技术，通过企业消化吸收已实现国产化，并被广泛应用于气象产品;引进辐射传感器等新技术新产品，在引进该产品基础上，研发了太阳能资源观测站，2014年已用于内蒙光伏电站项目中;引进0.075mm级西门子压力变送器，在引进消化吸收的基础上，研发出具有自主知识产权的国产0.075mm压力变送器，促进了我国压力变送器产品的更新换代，实现了替代进口产品的目标。

促进产学研相结合

中环天仪院士专家工作站充分利用高校科研优势、企业产业化条件优势，加强企业与高校的紧密合作，先后与天津理工大学等多所大学、院所建立产学研合作关系，开展技术交流、项目合作等多层次产学研合作，带动企业的技术创新。团队为天津理工大学搭建实时工业网路设计实验室平台，实现工业以太网、HRAT、WirelessHART三种总线的仪表通信，以满足教学要求。与天津理工大学合作开发天津市“讲理想、比贡献”活动优秀项目―多通道超声波流量计，对标西门子同类产品，拓展了流量计产品门类。目前公司正在与河北工业大学共同承担天津市市级“讲理想、比贡献”活动项目―高端智能压力变送器自动化标定设备的研制，以实现压力变送器的完全自主知识产权和规模化生产。

解决关键技术难题

2013年，团队依托院士专家的指导和帮助，为企业解决关键技术难题7项，在天津市“讲理想、比贡献”活动优秀项目―TRD两线制超声波液位计项目研发中，设计的超声波信号包络跟随技术实现了自动化调整比较器阈值，降低了产品整机功耗。申请发明专利1项，获得授权实用新型专利5项、外观专利1项，成果达到国际先进水平并获得天津市科技进步三等奖、中国仪器仪表学会优秀产品奖，当年产品累计销售1687台，销售收入924万元。

天津市“讲理想、比贡献”活动优秀项目―大口径挖泥船电磁流量计项目，通过建立磁场分布权重函数数学模型，研究磁场分布对信号的影响，具有磨损报警和励磁断线报警功能，填补了国内空白;天津市“讲理想、比贡献”活动优秀项目―ZPD智能阀门定位器项目，通过建立阀门定位器的数学模型，采用模糊控制和PI控制相结合的控制策略，实现了精确的气路控制与快速无超调的控制效果，现已实现自主规模化生产，申请专利10项，获得授权发明专利3项、实用新型专利5项，研究成果达到了国际先进水平，获得天津市技术发明三等奖、中国仪器仪表学会科技创新奖，2013年产品累计销售1160台，销售收入781万元。同时，团队还组织开展了产品质量改进改善类型的“讲理想、比贡献”活动项目。据统计，活动成果在提高劳动效率的同时为企业降低生产成本137万元;天津市“讲理想、比贡献”活动优秀项目―提高电磁流量计打压检验合格率项目，荣获中国电子质量管理协会中国电子信息行业年度优秀质量管理小组一等奖。

提升技术创新能力

团队在院士专家指导下完成了天津市“讲理想、比贡献”活动优秀项目―中环天仪企业创新能力建设项目，项目总投入3324万元，实施完成了基于EPA总线技术的智能仪表控制系统及设备的研发平台、智能仪表可靠性测试平台、高精度流量仪表开发测试平台和调节阀动态性能回路检测平台四大试验平台的建设。其中高精度流量仪表检测平台测试口径齐全、精度达到0.1%～0.2%级，是目前华北地区最大的流量仪表检测平台。动态回路检测平台填补了目前国内控制阀部分参数指标检测的空白，对行业和企业技术进步具有重要意义。

在院士专家的指导帮助下，经过团队的不懈努力，2013年中环天仪获批“部级技术创新示范企业”、“天津市工业自动化仪表技术工程中心”、“天津市工业设计中心”。这不仅为企业自身发展提供了技术支撑，而且还成为行业关键技术和共性技术研究的创新平台。

测试团队工作计划篇2

0引言

如今，软件产品被广泛应用于各个领域，如航空、机械、电子产品等，软件产品质量成为软件开发中重点关注的方向。在一些对于安全性要求较高的领域，对软件产品的质量要求更高。例如，在2011年温州发生的7.23动车追尾事故，导致212人伤亡;1996年阿里亚娜5型火箭发射39秒后爆炸，直接经济损失3.7亿美元;2002年首都机场电脑系统出现故障，导致6000多人滞留机场等。软件中存在的缺陷是造成这些严重后果的根源。因此，软件测试的重要性不言而喻。

传统的软件开发流程越来越无法满足当下软件需求的频繁变动，如传统的瀑布模型，测试人员在一定的控制点之前不能测试，所以在此之前无法找到缺陷。等到所有开发完成，即过了该控制点后再进行测试，缺陷数量会急剧增加，同时任何缺陷的修复都需要对一连串代码进行变动，修复时间难以确定，软件迟迟不能，损失将难以估量。

敏捷软件开发是基于一种更接近人类活动现实情况的方法论，采用以人为本、迭代、增量的开发过程，逐步满足软件不断变更的需求[1]。敏捷主要提倡个人为团队所作的贡献，注重各个职位的权利下发，发挥个人的主观能动性，保证随时都有可供交付的软件产品。敏捷开发更容易在项目早期控制缺陷数目。软件测试是保证软件质量与可靠性的重要手段，敏捷开发能充分发挥软件测试的重要作用。

1敏捷开发思想

敏捷开发是以用户的需求进化为核心，采用逐步迭代、循序渐进的方式进行软件开发。在敏捷开发模式中，软件项目在开发前，先将整体项目切分成多个子项目，迭代过程中根据需要可以对子项目进行拆分或同时进行多个子项目，每一个子项目都要经过测试，保证项目能运行成功。换言之，就是把一个大的软件项目分成许多小项目，每个项目独立完成，但相互之间又有联系，在该过程中软件始终处于可用状态。

敏捷开发本身更多的是一种概念，它是一种循序渐进的迭代开发方式，强调团队成员间的沟通。2001年，敏捷开发创始人了敏捷宣言：个体和交互胜过流程和工具，可用的软件胜过完备的文档，客户协作胜过合同谈判，响应变化胜过遵循计划[2]。也即，虽然后半部分的条目也具有价值，但是更看重前半部分的条目。他们希望这将成为成功的软件开发的基础。敏捷开发的方法很多，主要包括快速应用开发(RAD)[3]、极限编程(XP)[4]、动态系统开发方法(DSDM)[5]与Scrum[6]。本文构建的测试模型借鉴敏捷开发过程中的迭代思想，以渐进的方式完成测试工作，不仅可使测试工作具有更好的灵活性，同时也能更好地适用于现有的敏捷开发过程。

软件是一种非常特殊的产品，开发出的软件通常会存在一些缺陷，而有些缺陷会造成非常严重的损失。软件测试则成为保障软件质量的一种重要手段[7]。根据不同标准有多种测试方式，如集成测试、单元测试、系统测试、验收测试和回归测试。传统的V测试模型和W测试模型成为指导人们进行测试的方法，而不同于这两种测试模型的H模型，则强调测试的独立性。另外目前很多开发团队已经开始使用敏捷开发方式，敏捷开发方式非常注重客户的交互以及团队中的沟通，同时开发过程中会有许多迭代过程。本文提出的测试模型借鉴敏捷开发中的迭代思想，测试流程是一个渐进的过程。然而，即使有成功的敏捷开发方法，开发人员和测试人员依然要寻求最适合的敏捷方法，并将相关技术融入到自己的敏捷方法中。

2敏捷开发中的软件测试

2.1敏捷测试

敏捷测试没有已经确定的唯一定义，原有的测试定义“通过在规定条件下对程序进行操作，发现错误，衡量软件质量”仍然适用，核心思想可以理解为“遵循敏捷开发的宣言，接纳敏捷核心价值观，基于敏捷开发的软件测试”。敏捷开发宣言中提到敏捷开发的4个核心价值观：简明(Simplicity)、沟通(Communication)、反馈(Feedback)、勇气/决断(Courage)。符合敏捷核心价值观的测试实践活动都可以称为敏捷测试，敏捷不仅是一种过程，更多的是一种理念[8]。

2.2敏捷测试方法

图1为敏捷开发测试流程，此流程是一个结合了Scrum和XP方法，并加上一些基于计划性流程原则后的产物。虚线箭头两端是开发过程中与软件测试相关的部分，敏捷开发的测试人员全程参与完整的迭代开发。

(1)需求分析：测试工程师可以根据测试经验以及需求的测试难度对需求列表提出问题或意见，以期团队能共同提供建议或方案，在之后的实际测试过程中有助于提高测试效率。

(2)迭代计划：包括对需求的详细分析以及任务表等，软件工程师和测试工程师对需求进行讨论。

(3)迭代启动会议：项目经理、产品经理、软件工程师、测试工程师对此代计划进行讨论、完善。

(4)测试计划：测试工程师根据需求以及测试经验完成详细的测试计划书，团队对测试计划进行研讨并确认验收测试。

(5)测试驱动开发：测试工程师相当于软件的第一批用户，测试过程中要重视反馈，这也是敏捷开发的原则之一。

(6)验收测试：测试工程师对此次迭代的所有功能进行演示，测试产品功能是否合格。如果产品合格，则此次验收通过，可以进入下一环;如果产品不合格，则此次验收失败，重新返回开发阶段，找出失败的原因及bug并解决，并确认下一次验收测试。

(7)提交与验证：由测试工程师为产品负责人与参与项目的人进行演示，包括此次迭代的主要功能、产生的未解决bug，然后由产品负责人核准迭代成功。

(8)迭代后的研讨：对此次迭代过程中产生的问题进行讨论，对于亮点可以进行表扬，错误要分析原因。

从流程图和测试人员参与项目的简单描述中，可以总结出敏捷测试的方法主要有两种：与传统软件测试相似的测试和测试驱动开发(TDD，Test-DrivenDevelopment)。

图2展示的是测试驱动开发流程，开发人员在编写产品代码之前，要先编写单元测试代码，在进行单元测试后才能进行产品代码的编写，以保证产品代码能完全符合要求。产品代码编写完成后进行单元测试和集成测试，测试代码和产品代码都要进行代码审查，保证代码的简洁、统一，方便以后维护。在敏捷测试中，测试驱动开发的重要目的不仅仅是测试软件，同时在开发过程中帮助客户和程序员确定需求。测试驱动开发应该运用于每一个迭代中，逐步开发完成所有软件功能。

传统软件测试的种类非常多，在敏捷测试中应当根据当前迭代的需求进行测试[9]。某车削软件有这样一个需求，能支持直径40mm的刀具路径生成。该需求一定配备了相应的刀具路径生成方法，然后只需确定刀路生成中的一些参数，然后设计数量足够的不同表面形态的圆面即可。由于TestPart数量过多，可能会用到自动化测试，也有可能会用到一些特殊的TestPart，如圆面面型变化大，甚至不是圆面等。迭代最后一定有整体的性能测试，在整个项目进行过程中，传统的软件测试方法同样适用于敏捷开发。

2.3敏捷测试特点

在瀑布开发模式中，要求流程规范、文档齐全，测试进行时再根据软件需求总结、测试所有功能点，直到软件中没有明显bug。在传统的软件测试开始时，软件的缺陷会达到顶点，同时如果有需求变化，则需要重新编写文档，可能必须将之前的工作推翻重来，费时费力。而在敏捷测试中，一切都发生了改变。

敏捷开发模式中测试不是一个单独阶段，它和编码一样是软件开发的重要组成部分。敏捷开发使用一个“完整团队”的方法来保证软件产品质量。敏捷团队中的测试人员从客户需求中提炼要求，然后与开发团队合作，把这些要求变成可执行的规范，用于指导代码编写。随着测试和编码的逐渐进行与交互，将建立一些产品特性，直到提供足够的产品价值。

敏捷测试包括以下几个主要特点：①周期性的迭代开发方式。不同于传统测试的一次性集成或功能测试，敏捷测试在迭代进行过程中要通过及时响应客户反馈来修正软件测试策略，以此修正软件的质量指标;②每日立会，密切沟通。传统测试提供了大量文档描述产品需求，并通过文档进行测试。敏捷测试则需要团队每天进行交流，测试人员与客户持续沟通，以保证产品质量符合客户预期，并与开发人员沟通来确定需求认识的统一;③测试方法多样，贯穿整个项目开发过程。敏捷测试包括测试人员对软件的自动化测试、集成测试、功能测试等，还包括开发人员对代码的单元测试、代码评审等工作，从最底层和基础的测试来保证软件整体质量;④确保客户需求圆满实现。客户需求是敏捷开发中最核心的内容，敏捷测试同样需围绕客户需求实现。

2.4敏捷测试优势

目前大多数软件项目的共同特点是用户需求变化快、风险高，同时还能快速抢占市场，这刚好是敏捷开发能够解决的。

(1)良好的持续沟通可减少缺陷产生，降低风险。在敏捷开发模式下，测试人员的沟通尤为重要。一个迭代从开始到结束，测试人员都需要参与。迭代开始时，所有人都要对该阶段软件的成型有统一认识，满足用户需求的同时还要符合一次迭代的时间要求;迭代进行中，测试对开发人员的反馈非常重要，软件开发初期，测试工具十分缺乏，对测试工作的进行造成很大阻碍，这时需要和开发人员持续沟通，必要时可共同开发一些辅助测试工具，在此期间要把握好迭代进行的时间;迭代后期，也可以作为bug反馈期，测试人员不但要站在用户角度考虑需求，同时能和开发人员站在技术角度讨论问题，达到沟通的目的。

(2)合理的测试用例。敏捷最直接的特点就是快速，如果涉及的用例粒度太细，很难开展敏捷测试。一个合理的测试用例不仅能包含所有可能产生缺陷的地方，同时还能快速地响应需求变化。

(3)更多人参与测试。敏捷测试中的测试人员不再是一个独立的测试个体，研发人员、产品负责人、用户都可以参与测试。研发人员的测试可以减少编程中的bug，产品负责人的测试可以更好、更全面地把握产品现状，用户的测试则可以提供来自真正用户的反馈，以更好地促进软件开发。

3敏捷开发中的软件测试实例

本章结合一个具体的软件项目，详细介绍项目中的敏捷测试。

3.1项目介绍

针对3轴超精密加工车床，提供针对光学自由曲面进行加工的刀路轨迹计算的CAM(ComputerAidedManufacturing，计算机辅助制造)软件。该软件的目标是比UGNX中的相同功能有更快的计算速度和更高的精度。

3.2需求分析和项目规划阶段

项目经理和产品经理根据客户给定的需求进行分类，包括框架、加工方式、加工质量、刀具选择、仿真等需求，并对项目可能产生的需求进行判断和规划，形成项目计划书。项目计划书包括项目背景、、需求以及预期完成时间。项目计划书完成之后即可开始进行第一个迭代，并以第一个迭代为基础不断进行下去，直到完成所有需求。由于整体项目过于庞大，这里只对第一个迭代进行介绍。

项目实例：第一个迭代中有2个需求，同时根据工作量分配任务天数以及每个需求的参与人员，如表1所示。

3.3迭代进行阶段

迭代开始时，项目经理制定迭代的具体开发任务和测试任务。在迭代启动会议中，每个人都要对此次迭代任务有统一认识，并且能够承载相应的任务量，在需求确定完毕后进行任务分配。

.

开发人员进行编码时，测试人员的工作重点包括：编写测试计划、测试用例、验收测试以及提交和验证。测试计划和测试用例的编写同时完成，且在迭代初期完成。验收测试一般是在迭代后期进行集成测试，迭代过程中也可以协助开发人员进行单独的功能测试。

3.3.1编写测试计划和测试用例

测试计划需要具体的操作步骤以及相对完善的测试用例来涵盖需求，因此需要测试人员有比较丰富的测试经验。

项目实例如下：

表2和表3中的TestParts需要填写测试工件名称。测试计划编写完成后要经过开发人员和项目经理确认，保证开发人员认同并能够达到计划的目标。敏捷开发是不断迭代的过程，对于一些比较简单的功能，尽量设计简洁的测试用例。如果TestParts比较多，可以采用自动化测试，而对于一些比较复杂的功能，可以先采用手动测试，在功能更加完善后再考虑自动化测试。

3.3.2验收测试

验收测试要严格按照迭代前期写好的测试计划进行，在开发人员开发完此次迭代所有功能后，测试人员对所有功能进行集成测试、功能测试、自动化测试等，完成所有测试工作后形成测试报告。报告内容包括此次迭代基本功能完成情况、缺陷产生情况以及测试过程中的一些详细数据。

3.3.3提交和验证

团队全体成员参加验收会议，由测试工程师对迭代成果进行演示，产品经理和项目经理进行验收，项目需求全部完成则此次迭代成功，然后再对此次迭代中的不足之处进行讨论和改进，或者提出创新之处。如果项目需求未达标，或产生了过多缺陷，则此次迭代不予通过，全员讨论延后验收或将缺陷完善延后到下一个迭代。

项目实例：针对需求R1、R2的基本功能测试达到了计划的标准，框架的视图操作和显示功能以及CAD模型输入功能均正常运行且无缺陷。虽然框架本身存在一些缺陷，仍能满足迭代的基本需求。经过讨论此次迭代成功，产生的bug在下一个迭代进行完善。

3.4迭代后研讨和下一次迭代讨论

迭代完成后要对迭代过程进行回顾，测试人员需要对bug进行总结，包括测试过程中产生的问题，以及需要改进的地方，然后对下一次迭代的需求进行初步讨论，决定下一个周期的工作内容。

4结语

敏捷开发中的软件测试应当遵循敏捷开发的基本原则，面对不同的开发方法和应用环境，软件测试方法也不同。敏捷测试作为从敏捷开发中成长起来的测试方法，与敏捷过程密不可分，本文对敏捷开发中的软件测试特点和方法进行了详细描述。然而，真正在面对软件测试时，测试用例的生成与覆盖标准、测试的充分性和有效性、不同阶段的测试关系等，以及如何将传统测试中的一些方法应用到敏捷测试中，需要探讨的问题及方法仍然很多。

测试团队工作计划篇3

【关键词】Scrum敏捷开发方法软件开发实训教学应用

【中图分类号】G【文献标识码】A

【文章编号】0450-9889（2014）12C-0059-03

一、问题的提出

1970年温斯顿・罗伊斯在软件开发中提出了著名的“瀑布模型”。该模型将软件生命周期划分为制订计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本阶段，各阶段工作必须按次序自上而下开展，每个阶段要撰写大量文档，并对工作结果进行严格验证，只有上一阶段工作结束，才能开启下一阶段工作。这种开发模式应对上世纪60年代出现的软件危机问题，是一种很好的解决方案，成为了软件开发模型的经典。

当前，随着软件开发技术的进步，人们发现“瀑布模型”灵活性差，不适用于需求不明确的软件项目，很多软件企业已不再使用“瀑布模型”，但它作为软件开发模型的经典仍广泛应用在高校软件开发实训课堂中。实际上，应用“瀑布模型”进行教学的高校计算机软件开发相关专业学生毕业时的动手能力远远达不到企业的要求，这说明该教学方法和实训模式存在问题。为了提高学生实践能力，很多高校与计算机软件开发培训机构或企业进行联合办学，以弥补学校实训教学能力的不足。

二、“瀑布模型”实训教学存在的问题

应用“瀑布模型”进行的实训教学中主要存在如下问题：

首先，学生把握项目需求的能力差，难以达到“瀑布模型”对开发者的要求。“瀑布模型”适用于需求明确的项目，要求开发者具有很强的整体把握能力和前瞻性。但是对于初学开发的学生来说，需求再明确的项目，他们也不能很准确地把握细节，导致实训进程不能按计划正常开展，影响了实训效果。在实际教学中，虽然很多实训项目在以往的教材中有类似的解决方案，但是区别还是存在的，学生看不到软件在实际应用中可能出现的问题，到了项目开发后期才发现错误，导致实训项目失败。

其次，在“瀑布模型”开发的每一个阶段，都要求撰写细致准确的文档，这大大占用了学生的实训时间。据统计，如果严格按瀑布模型的要求来撰写文档，消耗的时间至少是整个实训时间的1/5。本来实训课堂留给学生实训的时间就不多，对一些效率低的学生来说，文档还没写完实训期就结束了，整个实训过程变成了纸上谈兵的演练。

最后，“瀑布模型”实训方式过时，学生不能学以致用，实训技能与企业要求脱节。当今的软件开发中，已经很难看见完全实施“瀑布模型”的企业，大家都已对“瀑布模型”进行了改进或者实施其他更先进的开发方法。教育部曾多次指出，高校教育应服务地方和行业，密切与行业、企业合作，为企业提供人才培养和技术服务支撑。这要求我们必须改革过时的实训模式，使教学与行业结合，与企业接轨。

三、Scrum敏捷开发方法概述

近年来，很多先进的软件开发模型在实际应用中得到了推广，这里要特别提出的是敏捷开发。著名IT组织VersionOne在2013年进行的敏捷现状调查结果显示，在全世界收集的3501份调查报告中，使用敏捷开发方法的占88%，其中使用Scrum敏捷开发方法或Scrum变种开发方法的占73%。这个调查数据充分说明了敏捷开发方法在行业中的主导地位。

敏捷开发（Agiledevelopment）是一种以人为核心、迭代、循序渐进的开发方法，它把项目分割分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。敏捷开发方法包括Scrum、Crystal和极限编程（XP）等，是一组开发方法的总称。它也是软件开发的一个过程管理框架，遵循了敏捷开发的主要价值观：个人与交互重于开发过程与工具;可用的软件重于面面俱到的文档;与客户的合作重于对合同的谈判;响应变化胜过遵循计划。

Scrum敏捷开发过程是迭代的增量开发，整个开发过程由若干个短周期的迭代组成，每一个迭代周期称为Sprint（冲刺），每个迭代实现不同的特性，迭代中重大的、优先级高或风险高的特性优先实现。Scrum敏捷开发方法重视软件的可用性，强调与客户的沟通，开发过程能够快速响应用户需求变更，尽早处理风险问题。

四、Scrum敏捷开发方法在软件开发实训教学中的优势

相对于“瀑布模型”，Scrum敏捷开发方法具有更多适合软件开发实训教学的优势，主要表现在如下方面：

第一，能够快速响应需求变更。与实际开发相似，学生的实训项目都是在重复多次的修正需求、修改设计后才交付实现的。Scrum敏捷开发方法中的Sprint都很小，即使需求变更很大，也可以在短时间内修改设计完成开发。而“瀑布模型”希望需求是稳定的，但不变只是愿望，变化才是永恒。如果在软件设计后期提出需求变更，那会是一种灾难。这种影响小则使实训进度不可控，重则导致实训项目失败。

第二，Scrum敏捷开发方法要求尽早编码，尽快开发出系统原型，尽早使客户见到可运行的软件，暴露项目的技术风险，从而提出优化意见。这恰好迎合了学生开发实训时急切渴望进行编程实现的心理，激发了学生学习的积极性。而“瀑布模型”要求推迟实现，要尽可能把需求分析透彻，设计完整，完成文档编写后才能进行编码实现。这个过程对急切渴望编程的学生无疑是一种打击。

第三，Scrum敏捷开发方法不要求文档面面俱到，更注重于软件可用性设计。在敏捷开发中，很多文档只是一个草图，大部分文档在集成测试阶段产生，而且只写有必要的文档。所以实训团队不需要安排专人撰写完备的开发文档，从而使学生有时间专注于开发实训工作。

第四，Scrum敏捷开发方法能更全面地培养学生的软件开发技能。在Scrum项目中，每个开发成员主动认领开发任务，开发过程涉及的设计、编码和单元测试全部是个人独立完成，实际上一个人承担了传统开发模式中系统架构师、程序员、测试员和产品构建经理等角色工作。这种实训方式有助于提升学生软件开发的单兵作战能力，从而快速适应企业软件开发工作的各个环节。

五、Scrum敏捷开发方法在软件开发实训教学中的实施

综上所述，在软件开发实训教学中使用Scrum敏捷开发方法，可以更好地促进教学，提高学生实践能力，实现教学与行业结合，与企业接轨。具体实施方法如下：

（一）组建开发团队，实行双教师教学

在实训中，可将教师和学生按Scrum敏捷团队角色分组，主要有以下三类角色：一是ProductOwner（产品负责人）。该角色可安排熟悉产品需求的教师承担，负责产品需求的提炼、条目化和优先级排序。二是ScrumMaster（团队负责人）。该角色可安排熟悉Scrum开发流程的教师承担，负责整个Scrum团队的协作运行，并协作解决非技术问题。三是Team团队成员。Team团队由Team小组长和3～5名小组成员组成。小组长由开发能力较强的学生担任，其他成员根据开发能力强弱穿插分配。每班学生可分为若干个Team团队，每个开发实训项目由一个或多个开发小组的学生在老师指导下完成开发任务。

在实训开发课堂中，之所以要实行双教师教学，一是开发团队角色需要，二是为了让教师能在实训过程中相互讨论，取长补短，弥补高校教师在实践经验上的不足，提高实训教学的整体质量。

（二）约定开发规范，精简开发流程

实训开始前，开发团队应约定统一的开发规范和流程，以便学生掌握团队开发方法，并养成良好的编码习惯。图1为经过精简的Scrum实训开发过程模型。

图1Scrum开发过程模型

图1是Scrum开发的一个迭代周期。其中，ProductBacklog为软件产品总的需求条目，这些需求多以用户故事（Userstory）的形式展现，ProductOwned负责维护;SprintBacklog是ProductBacklog的一部分，通过计划会议（PlanningMeeting）讨论选定，是需要在当前迭代（Sprint）中完成的需求条目;圆环为迭代开发（Sprint）的过程，一般周期为2～4周，迭代过程包含分析―设计―实现―测试等工作。迭代开发过程中，Team成员每天进行15分钟的站立会议（Dailymeeting），主要汇报昨天做了什么、今天要做什么和遇到了什么问题。Scrummaster每天负责绘制任务燃尽图（BurnDownChart），以曲线展现当前Sprint任务的剩余量，这对团队开发有很大的鼓舞作用。每一次迭代开发完成后，教师要组织Team团队成员召开评审会议（ReviewMeeting），一个可执行的软件版本（Release），并让相关人员和团队成员提出优化意见。

（三）结对编程，以强带弱，相互促进

学生的学习能力和实践能力是强弱不一的。在实训过程中，教师的指导作用固然重要，但师生间的沟通往往没有学生间的沟通那么自如。因此，可以安排一个能力强的学生与一个能力弱的学生结对编程，充分发挥先进学生的带头作用，让后进学生有机会学习别人优秀的学习方法和实践经验，互相监督，互相促进，最终实现实训目标。

（四）持续集成，交换测试

在我们的实训中，并没有设立专门的软件测试小组，开发团队只是对软件进行了简单的单元测试。如果整个项目都要等到软件开发后期才进行集成测试，项目失败的风险就会很高。Scrum要求团队开发要尽可能频繁地进行集成测试，也就是持续集成。持续集成可以尽可能快地发现集成错误，通常每个成员每天至少集成一次，也可能进行多次集成。每次集成都通过自动化的构建（包括编译、、自动化测试）来验证，减少开发团队进行集成测试的时间消耗。实践基础好的团队可尝试实施测试驱动开发（TDD），即先编写测试代码，后编写功能代码，用测试代码驱动功能开发，这可以降低自动化测试的出错率，提高软件运行质量。如要进行人工测试，可安排各个开发团队进行交换测试，因为他人测试比自己测试更容易发现软件存在的错误。（下转第87页）（上接第60页）

总之，Scrum敏捷开发方法是一种新兴的软件开发方法，很多实践方法和理论还在不断地研究中。实训教学终究是以传授技能为主，不需要拘泥于Scrum开发的全部形式，教师可对Scrum开发方法进行修剪和优化，从而更好地实现教学目标。自2013年起，柳州师范高等专科学校在软件开发实训教学中实施Scrum敏捷开发方法，现已成功开发了教学质量监控系统、科研工作管理系统两个真实项目，用户对软件的满意度很高，实训教学取得了良好的效果，但相关管理制度和实训措施还需要进一步探索和优化。

【参考文献】

[1]VersionOneInc.8thAnnualStateofAgile[R].VersionOneInc，2013

[2]MikeCohn.Scrum敏捷软件开发[M].北京：清华大学出版社，2010

[3]FrederickP.Brooks，Jr.人月神话[M].北京：清华大学出版社，2007

[4]陈国栋，罗省贤.Scrum敏捷软件开发方法实践中的改进和应用[J].计算机技术与发展，2011（12）

[5]HenrikKniberg.ScrumandXPfromtheTrenches[M].C4MediaInc，2007

[6]商惠华.计划驱动下敏捷开发过程的软件质量管理[J].汕头大学学报（自然科学版），2011（4）

【基金项目】广西高等教育教学改革工程项目（2013JGB301）

测试团队工作计划篇4

关键词Scrum框架大学生科研训练计划项目管理

中图分类号：G644文献标识码：ADOI：10.16400/ki.kjdkz.2016.01.009

AppliedCollegeScientificTrainingProjectManagement

BasedonScrumFramework

WANGYishu，JIANGDongqing，LISanyan

（JinchengCollegeofSichuanUniversity，Chengdu，Sichuan611731）

AbstractResearchTrainingProgramforUniversityStudentspresenceofthecurrentstudentbodyisnotclear，inadequateschoolmanagementissues，proposedScrumagiledevelopmenttoolformanagingScienceResearchTrainingPrograminorderto"JinchengMary"welcomerobotprojectapplicationobjects，fromteambuilding，Scrumplanningprocess，taskanduserstoriesframe，standupandacceptancetestingandotheraspects，intheprojectimplementationprocesstofullyplaythemaincharacterofcollegestudents，tostrengthenandimprovethemanagementoftheproject，madeaverygoodeffectforthefuturemanagementofcollegestudents'researchtrainingprojectprovidesanewwayofthinking.

KeywordsScrumframework;collegestudents'scientifictrainingprogram;projectmanagement

0引言

根据《教育部财政部关于“十二五”期间实施“高等学校本科教学质量与教学改革工程”的意见》和《教育部关于批准实施“十二五”期间“高等学校本科教学质量与教学改革工程”2012年建设项目的通知》，教育部决定在“十二五”期间，通过实施部级大学生创新创业训练计划，促进高等学校转变教育思想观念，改革人才培养模式，强化创新创业能力训练，增强高校学生的创新能力和在创新基础上的创业能力，培养适应创新型国家建设需要的高水平创新人才。每年中央和地方财政拿出大量经费资助在校大学生开展各类大学生创新创业训练计划项目（StudentResearchTrainingProgram，简称SRTP）。在科研创新、实践和独立工作能力方面锻炼学生，使其尽早在科研项目中扮演不同角色并达成与工作岗位的衔接。

但是，段徐等人的研究结果表明学生在参与项目的过程中对指导教师依赖过度，而科研要求的独立思考和团队协作的能力不足。其中项目来源于教师的占比为60.6%;遇到问题优先向教师求助比例为45.7%，选择独立思考的只占28%;在处理教师意见方面，思考后完全或部分接纳的比例高达85.7%。与此同时，学校在SRTP实施各个环节的管理并不能学生满意，尤其是推广成果和落实中期检查两个环节，仅有3.4%和6.9%的学生认为学校对这两个环节的管理工作做得好。以上两点造成的结果是学生的主动性无法发挥，难以对科研成果进行实质性的推广，很多项目都是答辩或参赛之后就匆匆画上句号，没有推广和应用科研项目中的优秀成果。

针对目前SRTP实施过程中存在的问题，白文苑等人提出了“2355”管理运行模式，来激发学生的创新意识和创造性思维，从而提高其创新能力和综合素质。吴江等人提出项目全程跟踪和全部项目全程管理相结合的矩阵式科创训练项目管理模式，在创新人才培养和卓越工程师培养计划过程中发挥了重要作用。然而，在应用型大学，人才培养的目标为培养应用型创新人才。同一般普通高等教育相比，应用型高等教育培养的不是研究型、学术型、学科型人才，而是能够适应现代社会的管理、建设、服务、生产等第一线工作岗位需要的，掌握并能熟练运用高新技术的高级专门人才。因此，在实行大学生科研训练计划时，必须结合社会的需求，并体现应用型本科教育行业性、应用性、实践性和专门性四大特点。因此，本文提出在大学生科训计划项目管理中引入目前国内外企业高频使用的敏捷开发工具Scrum框架，从团队组建、Scrum计划计划流程、任务框架及用户故事、站立会议和验收测试等方面入手，探索提高SRTP项目管理水平的方法。

1敏捷开发工具Scrum的基本框架

Scrum本来的含义是指次要犯规时英式橄榄球在犯规的地点进行对阵争球。Scrum这个词汇于1986年首次应用于产品开发，1993年JeffSutherland首次将Scrum用于软件开发。这是一种基于管理为主的敏捷项目开发框架。在该框架中，将每个开发过程分割成若干小的迭代周期，一个小的迭代周期即一个Sprint（百米冲刺），一个Sprint的长度建议2到4周。

Scrum框架包括3个角色（产品负责人、Scrum专家、Scrum团队）、3个工件（产品订单、Sprint订单、燃尽图）、5个活动（Sprint计划会议、每日站立会议、Sprint评审会议及回顾会议、产品订单梳理会议）、5个价值（承诺、专注、开放、尊重、勇气）。Scrum框架在管理产品或项目的需求一般使用产品订单（Productbacklog）这项工具。根据商业价值排序的需求列表，产品订单将列表条目拟为多项用户故事。在Sprint中根据用户需求的优先次序来确定开发的顺序，形成Sprint订单。在一个迭代周期结束时，完成可交付的阶段性产品是Scrum团队的定期工作。

2Scrum在大学生科创训练项目管理中的应用

文章提出基于Scrum的开发框架，综合大学生科研训练项目学生实践和管理中出现的种种弊病，对学生科研训练项目进行管理和运作。在试点项目中，每个Sprint的时间周期为1周，每两天一次站立会议。

2.1理想试点项目的选择

理想的试点项目要综合考虑项目规模、项目持续时间、项目重要性和资金投入程度等因素。在我系机器人实验室建立初期，笔者团队共同承担了多项大学生科研训练项目，如大学生挑战杯参赛作品以及中美创客大赛作品等。基于Scrum框架中对理想试点项目的要求，笔者最终确定以“锦城小丽”迎宾机器人项目作为Scrum框架的应用对象，初步确定的项目时间为2个月。

2.2用户故事

“敏捷开发法”强调沟通的重要性，而轻冗余文档。但“敏捷开发法”并不意味着没有文档，在“敏捷开发法”的实施过程中，应该有适量的文档，维护工作量小，且有助于加快整理思路、沟通及讨论。在项目初期，通过讨论确定粗略的项目需求及时间节点，并加以记录。

2.3团队组建

5～12人是Scrum团队的理想规模。少于5人的团队，队员之间的相互交流直接减少，从而导致团队产出下降，团队可实现的技能在迭代周期中被限制，从而难以完成预定可的阶段性产品。如果多于9人，协调沟通工作会成倍增加。经长期实践验证，5～7人的团队效率最高，完成相同项目所需的时间最少。

在企业中，团队成员必须具备交付产品增量所需要的各种技能。而学生团队则需要花费更多的时间在学习掌握项目所需的专业技能，在制定项目的时间节点时，需要将这部分时间考虑进去。同时，敏捷宣言要求团队为自组织，这能最大程度地提高学生团队自主协调以及合作能力。最终团队由7人组成，其中两位指导教师担任产品负责人，确定订单及其权重。笔者兼任Scrum专家角色，着重分配任务和时间规划。

2.4任务框架及Scrum计划会议

产品订单包括产品或项目排列好优先级和预定功能的列表。优先级由风险、必要性决定和商业价值共同权衡决定。产品负责人决定产品订单的可用性、优先级和内容。

在“锦城小丽”的项目中，团队经过数次讨论，初步确定了产品订单的清单。Scrum是以Sprint为单位前进的，用户的需求在迭代过程中会逐步清晰。最初计划为制作两个迎宾机器人，分别有一只手臂能够动作，经过数轮Sprint，由4月上旬改为一个机器人双手均可动作，以配合完成更为复杂的任务。学校的校庆为5月初期，设定4月底为验收项目的最后期限。其中，通过在线管理工具对项目进程进行实时监测及梳理。用户故事所需工作量由团队讨论后经Scrum专家进行记录。

2.5站立会议

每日站立会议为团队每天15分钟的清查和调整。要求在同一地点，同一时间进行。参会时间只有15分钟左右，一般在贴有sprint目标的展板前进行。由于学生并不是实验室全职的研究人员，配合课程时间安排每周二、四、五召开3次站立会议。会议上，每个团队成员需要回答以下3个问题，并把问题写在即时贴，粘在会议白板上。3个问题分别是：到本次会议为止，本人完成了哪些工作？在下次站立会议之前预定完成的工作有哪些？什么样的障碍使工作难以进展，需要什么样的帮助？

如图1所示为项目中机器人控制系统模块开发过程中站立会议贴纸。学生通过站立会议，清晰向团队表达本人目前的工作状态，通过互相交流和讨论，及时反馈和解决问题。当贴纸上陈述的障碍在会后得以解决，在下次站立会议中，学生把贴纸撕下，交由Scrum专家整理上传在线管理工具核实项目进度;若该障碍没有进展，则在白板上保留贴纸，并由团队进行讨论，寻求解决办法或新的可行方案。在项目进行过程中，白板上只保留当前状态和待解决问题，产品负责人和Scrum专家根据Sprint产品订单对项目进程进行规划。

3试点项目效果分析

试点项目中，产品负责人2人（两名指导教师），Scrum专家1人，Scrum团队5人（其中大三学生3人;大二学生2人）。项目进行中Sprint数量为7个，完成包括控制系统开发、语音识别、语音触发、移动方案、驱动测试等9个产品订单（productbacklog）。项目中需要用到的电子元器件，均为学生线下讨论，站立会议中交流之后自行购买。通过Scrum的开发框架，学生能在项目的进行过程中，主动尝试解决问题，通过站立会议的工作模式，极大地提高了项目的进展速度，也使组员间相互讨论，实现知识和经验的交流，由Sprint迭代式的工作框架保证了项目进行的节奏和效率，并先于初期设定的时间节点实现项目验收。

测试团队工作计划篇5

我首先尝试的是如何与工程师团队进行头脑风暴专题讨论会。团队头脑风暴乐趣多多，每个人都会踊跃提出自己的想法。在会议室待上几个小时后，我们会写满一大摞便利贴，而且每个人都像打了鸡血一样情绪激昂。

但是事实令人尴尬：我调查过参与者是否喜欢这种讨论形式，却从来没有评估过实际的效果。接下来我审查了我组织过的每一场头脑风暴的成果，发现真正付诸实践并且获得成功的想法并不是来自大喊大叫的头脑风暴。

那些更棒的点子来自个体依然用过去习惯的方式思考创意时――坐在办公桌前时、在咖啡店等咖啡时、洗澡时。这些由人们独自想出的点子更胜一筹。

我重新思考了团队讨论会的形式。如果我把这些神奇的元素――专注于个人工作，制作原型的时间，无法避免的最后期限――加进来，会怎么样呢？我决定把这叫做“设计冲刺”（DesignSprint），并在不断验证这一方法的过程中逐渐组建了四人团队。

“设计冲刺”是谷歌风投独特的五天式流程，可以通过原型设计和用户测试来解决关键问题。它是商业战略、发明创新、行为科学、设计等领域的“超级精选专辑”，而且还被改造成了一个循序渐进的过程，任何团队都可以参照实施。

“设计冲刺”

好的想法来之不易。即使是最妙的想法要在现实中取得成功，也面对着种种不确定因素。无论你是在管理初创公司、教授一门课程还是在一家大企业任职，都是一样的。

为了帮助迅速解决问题，自给自足，我们优化了“设计冲刺”的流程。这个流程避免了无休止的争论，并将几个月的任务压缩进了短短一周内。我们不需要等到做出一个最小可行产品才能确定我们的点子是否够好，初创公司只需要用一个看起来真实的原型就能得到清晰的答案。

它给我们的初创公司带来了一种超能力：可以在付出昂贵的代价之前，就穿越到未来，了解他们的产品以及用户反馈。如果一个冒险的想法能够在“设计冲刺”中获得成功，那么真正实践的回报更会好到不可思议。当然那些痛苦的惨败经历也会给我们带来最大的投资回报。仅用五天时间就能找到关键性的不足之处，这是非常高效的，又不需要承受真的栽个大跟头的痛苦。

我们已经与多家公司合作实践过“设计冲刺”，试验各种流程，并检验结果，寻找改进的方法，在谷歌风投投资的各类型初创公司进行了100多场实践，提供了解决大难题、尝试新创意、增加新成果、获得高效率的捷径。

实施前的准备

开始“设计冲刺”之前，你需要确定正确的挑战，组建合适的团队。你还需要订好进行的时间和地点。

挑战越大，效果越好。“设计冲刺”能够解决三种挑战和困难：一是风险高的。你面临着一个重大问题，而解决方案可能会耗费大量的时间或资金。此刻你就是船长，“设计冲刺”能够帮助你在马力全开之前看清航海图。二是时间紧的，你面临着严格的最后期限，需要好而且快的解决方案。“设计冲刺”正是为速度而生。三是起步难的，有些重要的项目很难启动，有些则在中途失去动力。在这种情况下，“设计冲刺”就像一个火箭加速器，带来新方法和新视角，帮助你摆脱地心引力的束缚，顺利找到解决方案。

“设计冲刺”就像一场精心策划的大劫案。你和你的团队成员将你们的才能、时间和精力发挥到极致。首先你需要一个有权威、能够做决定的人，这个人是决策者。在我们合作过的很多初创公司，这个人是创始人或首席执行官。在大一点儿的公司，可能会是副总裁、产品经理或者其他团队领导。这些决策者通常对问题理解得很深刻，而且通常具有很强的观点和原则，这样他们才能协助团队找到正确的解决方案。

团队最理想的人数是七人或更少，人更多进程就会减缓，而且要维持所有人的专注和高效也需要更多的努力。你肯定需要那些设计产品或者运营服务的家伙――工程师、设计师、产品经理等等。毕竟他们更了解公司的产品和服务如何运行，知道如何找到解决方案，而且他们很有可能对问题已经有一些想法。

“团队”这个词已经泛滥，但是在“设计冲刺”中，团队是真正意义上的团队。连续五天，你们将会并肩战斗。到了星期五，你们会凝聚成一台解决问题的机器，并且在挑战及可能的解决方案上达成深刻的共识。“设计冲刺”的合作氛围非常适合把平时经常与你意见不合的人拉进来。

还要选一个引导者，负责控制时间、组织谈话以及整个过程。他应该对组织会议有信心，既能总结讨论要点，又能在恰当的时机结束争论，进入下一个环节。引导者需要对各种决定保持中立。一般来说，让一个之前没有和团队成员合作过的人担任引导者，效果不错。

为什么定成五天？我们试过更短的时间，但是那样搞得大家都精疲力竭，而且没有时间来制作原型、进行测试。我们也试过六周冲刺、一个月冲刺，还有十天冲刺，最终都没有超出一周冲刺的成果。五天时间带来的紧迫性让人们更容易集中注意力、打断不必要的争论，同时又有喘息的空间来制作原型、进行测试，不至于忙到吐血。而且由于大部分公司都实行五天工作制，把“设计冲刺”安排到现有的日程规划中切实可行。

如何实施五日计划

星期一：描述问题，选出集中解决的着力点结构化讨论为整个星期确定方向。上午从结果出发，并在长远目标上达成一致。接下来描绘挑战的全貌。下午邀请公司的专家分享他们的观点和看法。最后选择着手点：要解决问题的哪一个方面？这个方面既富有抱负又可管理，并且能在一周内解决。

星期二：回顾已经存在的点子，并进行重组和改进。然后到了下午，每个人都要拟定方案，按照四步流程，重思考轻技巧。这有点儿像玩乐高积木：先收集有用的部件，然后把它们改造成原创又新鲜的东西。下午画方案，把抽象概念变成具体方案。

星期三：做出艰难的抉择，并将选中的方案转化为可测试的猜想上午评估每一个解决方案，然后决定哪一些最有可能助你实现长期目标。下午在草图中选出优胜者，编进原型分镜脚本中：形成一个步步为营的原型制作计划。

测试团队工作计划篇6

关键词：机械产品研发控制类型原则阶段

机械产品的研发是以市场需求为目标的，其过程分别为：市场调研、整体计划、研发计划、草案图、计划图、工程图等。机械产品的研发是通过市场调查，以及对社会变化的洞察和对技术发展的预测而开展的一项产品研发过程。而机械产品研发包括了前期对社会变化的洞察、对技术发展的预测、技术研发、加工生产、市场销售、售后服务等过程，做好研发过程的控制相当重要。

1、明确机械产品研发控制的类型

第一，循序渐进式。机械产品创意可能数量极多，但只有极少数能通过筛选，而评估的重点在于竞争力、获利率、市场销售量、技术可行性、企业资源能力等。在形成共同的产品概念之前，往往需要经过反覆的讨论与评估，因此步骤一至叁是反覆的循环进行。产品概念形成后，要进行市场机会分析、销售量预测、财务预测，目的是进一步明确机械产品的市场机会与检测机械产品开发有关的决策。完成产品原型开发后，要先进行试产与市场测试，以便在正式上市前有修订与弥补的机会，并且为量产与上市做最充分的准备。循序渐进的机械产品开发模式的优点是，可以确保有关机械产品开发可能面临的议题或困难，均在事前经过详细的评估，因此可以降低产品开发的风险；不过因此可能也要付出相当的时间与成本的代价，尤其这种模式的弹性与灵活应变的程度相对较低。一般在市场情况变化不大，企业组织较结构化、产品开发有充足的时间与资源支持、以及面对不确定高的全机械产品开发案时，较常采用这种循序渐进的开发模式。

第二，同步并行式。循序渐进式主要的缺点是部门间的联系与沟通，每一个部门都必须要花费许多时间来试着去了解上一部门移转过来的研发成果。经常由于部门间认知差距与沟通障碍，造成时间拖延与成本上升，尤其严重的是无人需要为产品开发的成败负起全责。为了克服这些问题，因此产生所谓同步并行式的机械产品开发程序，又称为同步工程。同步并行的模式采用专案研发的方式，将与机械产品开发有关部门的人员整合起来，并以团队合作方式来运作。

第三，机动团队式。由于市场环境的快速变迁，企业对于机械产品开发活动与相关决策，要求更高的弹性与应变速度。如果将循序渐进式视为大队接力，那么所谓机动团队式就如同篮球团队一般。机动团队式的机械产品研发，强调授权与学习的组织特色，并以独立专案团队的方式来运作。在这个专案团队中，虽然没有明确的作业程序或作业规范，但非常重视成员共识的建立，产品各发展阶段机动的同步进行，独立、自主、创新、学习是机动团队的主要特色。一般企业为克服机械产品创新的阻力，经常会采取这种组织模式，企业主要以预算与绩效做为控制与评量这类专案团队的主要手段。

2、遵循机械产品研发控制的重要原则

无论采用上述何种的机械产品开发程序，企业都必须要掌握以下五项基本原则。第一，建立与企业目标一致的机械产品开发策略。将经营目标、策略与机械产品开发策略两者相结合，如此机械产品开发可以长远的规划，获得充分的组织配合，发展最适合的开发程序，并成为企业的经营策略中重要的一部分。第二，对于机械产品开发资源配置，应重视弹性运用的原则。过去许多研究证明，充分的资源配置与弹性的运用空间，对于机械产品开发绩效发挥将有很大的帮助，这是企业投入机械产品开发活动必须要有的认知。第三，在机械产品开发过程中，要重视企业关系人间的互动与充分沟通。尤其在产品概念产生的初期，良好的沟通与互动，是产品开发成败的关键因素。第四，要发展整合性的专案团队，来进行机械产品开发。由于产品开发涉及到许多部门的业务与功能，因此形成团队将是最佳的运作方式。第五，以永续发展的观点来看待机械产品开发有关的业务。每一项机械产品开发都不是独立的计划个案，而是企业在追寻永续发展过程中的持续创新行为。

3、把握好机械产品研发控制的阶段

机械产品研发由抽象意念而致具体产品，大致可分为创意产生、产品概念、产品雏形、最终产品、营销计划等五个过程阶段，而对于研发的有效控制也有必要对这五大阶段加以重视。

第一，产品创意。产品创意是机械产品开发的源头，若能有效管理产品创意的来源，对于机械产品开发绩效会有很大的帮助。机械产品创意主要来源于与产品开发利益相关的企业关系人，包括顾客、制造商、供应商、竞争对手、组织成员等。据了解，在科学仪器产品创新行为中，有77%的创意来自于客户的意见，而车辆工程产品创意来源，则有94%是制造商所提供的。获得大量机械产品创意后，必须进行筛选评估，只有少数的创意可能具体发展成为产品概念，评估的一项主要因素是未来市场潜力的大小。

第二，产品概念。产品概念是综合各组织成员与企业关系人需求与意见而成，对于机械产品的各项特征给予具体的说明，做为未来开发产品的具体指引与沟通基础。产品概念也需要经过较详细的市场机会分析与销售预测的考验，以确保产品开发成功的机会。

第三，产品雏形。产品雏形是产品概念具体化的结果，较多由研发人员、制造工程人员与营销人员共同参与发展，主要做为机械产品试产与试销的工具。

第四，最终产品。机械产品经反覆修正后，终于完成最终产品，展开大规模的量产投入与市场营销计划。

第五，营销计划。营销计划的内容包括：定价、通路规划、促销手段、产品定位、人员训练、后勤服务支援规划等，虽然营销计划早在产品概念阶段即已着手进行，但必须产品实际完成后，才能具体的定案执行。

4、结语

无论做什么样的工作，总结和分析永远是有效而必须的。机械产品研发的反馈可以通过销售部门和售后服务部门来获取，也可以通过小范围的市场调查来获取，具体使用什么样的方法则取决于产品的重要性，以及当时具体的情况。

参考文献