前言：中文期刊网精心挑选了敏捷的项目管理范文供你参考和学习，希望我们的参考范文能激发你的文章创作灵感，欢迎阅读。
敏捷的项目管理范文1
【关键词】 敏捷 Scrum
1 引言
在20世纪80年代，敏捷化产品开发方法在日本汽车制造公司兴起，紧接着这一年年底敏捷概念传播到北美汽车制造商和IT部门，然后敏捷方法作为软件开发方法被其他行业迅速采纳。在传统方法中，产品开发过程中的需求变更很容易导致项目产生混乱，而敏捷方法不仅能接受项目中的任何变更，并且能以一定方式控制项目中的变更带来的风险。
2 不确定需求的项目管理
在项目开发的过程中，应对不断变化的客户需求对开发人员来说是一个很大的挑战，这使得开发人员在开发过程中把项目分成很多个小步骤，可以接受不断变化的需求。根据2000年议会科学与技术办公室的报告中的内容，其中提到把项目分解成为小模块能灵活应对项目中产生的需求变更，分解出来的一部分包含明确的需求和固定的价格，另一部分用来应对变更的需求和价格，从而确保项目能够更安全和容易地进行。同时，软件公司在与政府IT部门工作时应该提供优秀的领导能力，更广泛的部门目标，与供应商良好的关系，适当的风险管理以及考虑到尽可能多的用户标准。
赛迪监理通过对众多大型项目的管理研究发现，6到12个月短时间的项目比一年以上的项目成功率要高。持续时间长的项目失败原因是由于过时的技术导致用户需求变化。软件公司把时间为一年以上的项目分解为小模块来应对项目中的变更。在20世纪90年代后期，敏捷方法就有能力应对客户的需求变更和不断变化的技术。目前，有一种常用称之极限编程（XP）的敏捷方法，它与传统方法相比较可以应付不断变化的客户需求和技术，在客户有系统需求时，给予及时满意的可执行程序。这些要求不一定需要在项目的初始阶段实施，但随着项目的发展这些要求是被包括在哪一个阶段要取决于项目的环境，客户的需求可以通过原型法来确定。
E-type模块在实施过程中通常存在不稳定的需求。这些模块必须在整个项目中经常使用，以适应不断变化的环境获得更好的效果来提高客户满意度，软件公司更新管理技术来适应需求的新变化。由于需求是经常发生变化的，开发人员往往对敏捷过程要进行不断的验证，确保整个项目是以正确的方式在进行在每一个开发周期，开发人员通过检测测试结果，如果有错误，则对项目文件进行修正。客户和开发团队之间的有效沟通，能够在不破坏计划的前提下应对各种变更，并尽快在指定时间内完成项目。此外，开发人员应该对任何可能会影响项目的风险提高警惕。
Scrum是软件公司用来应对不确定需求的另一种敏捷开发过程。Scrum过程中产生的产品backlog对需求变更具有重要的作用，产品backlog包含了项目中的各类要求和问题，在开发过程中，产品backlog中的要求可以在任何时候做出改变且不会影响该项目。产品负责人确定客户需求的优先级，然后将确定优先级的需求分配给冲刺backlog。只有是客户提出的需求才可以对产品backlog进行更改，这避免了软件公司在项目发生变更时发生混乱。
软件公司也常使用一些需求管理工具，一般来说，分为两大类，一类是面向内容的需求管理被称作为以文档为中心的工具；另一类是面向过程的管理工具，用来解决结构化信息项目的需求。这些工具能够与其它系统工程、软件工具、分类需求，以及其它查询和搜索关键字设备进行接口集成。HERMES是一种可以对需求进行概括的需求管理软件，它自带的XML技术可以把需求从文本转化为对象，而且可以供其它模块共享。这种管理系统一般应用于需求编制易修改的项目，此系统会检测需求概括后的关键字，有助于开发团队和设计者把需求考虑到系统及其开发过程中。
3 Scrum方法
Scrum是一种迭代式增量软件开发过程。整个开发周期包括若干个小的跌代周期，每个小的跌代周期称为一个Sprint，每个Sprint周期一般为30天。每天有15分钟的Scrum站会，团队的成员在会议中轮流回答以下3个问题：昨天我完成了哪些工作？今天我将完成哪些工作？我在工作中遇到了什么困难？团队成员从产品backlog中自已挑选任务创建冲刺backlog，每天项目的冲刺backlog会提交给管理者，将客户需求确定优先级顺序经过分析得到冲刺任务列表，同时团队中产生的任何问题或进一步发展的需求管理者都能够快速提出来。Scrum适用于不确定需求产品的开发，只要使用Scrum在开发过程中发生的任何问题都可以得到快速解决，项目开发中的需求变更会在产品订单中得到即时更改。每个Sprint周期的产品订单和团队人员在一个周期30天内是不变的，以确保迭代结束时能获得预期的结果。
Scrum Master主持Scrum会议，管理每日Scrum流程，负责为成员解决障碍和问题。在每个迭代周期结束时那些未完成工作量的需求将移到下个月的产品backlog中，下个月团队成员参考第一个Scrum过程的反馈内容。回顾会议由开发团队与Scrum负责人共同讨论这个迭代过程中哪些地方做得好，哪些需要改进，使团队持续成长。下图详细说明Scrum过程。（图1）
敏捷开发是一种开发方法学，可以快速应对客户变更的需求。它强调以人为本，采用迭代的方式，循序渐进地开发软件。一般来说，迭代周期为1到4周，短期迭代允许项目需求频繁的变更，产品是在每个迭代周期结束时被逐步交付使用的。在应对不断变更的需求问题上敏捷开发是最适用的方法，所有由需求变更导致的困难和风险都会在迭代周期中得到有利的控制，并使得客户利益最大化，团队成员面对面的交流使得制定决策计划比通过文档交流要快速得多。图2表示了整个敏捷开发过程。
从上论讨论中我们可以得出Scrum过程方法和敏捷开发的优缺点比较如下：
1）短期迭代：Scrum过程的短期迭代周期为30天，每天15分钟的Scrum例会，每个迭代过程必须在30天期限内交付。敏捷开发的迭代周期为1到4周。这两种短期迭代都适应于需求更改频繁的项目开发。
2）增量式开发：Scrum过程的迭代周期结束时新增了交付功能，交付的需求进入下个月的迭代周期订单进行解决，每个Scrum迭代过程的结果可以看作是项目开发中的增量开发。同样的，敏捷开发也在每个迭代周期产生一个已通过测试的交付软件。
3）管理团队：scrum Master管理整个scrum流程，主持scrum每日例会，并帮助团队成员解决在项目开发中遇到的问题，这样避免了迭代结束时的交付延迟的问题。敏捷方法中的团队成员都拥有解决问题的专业知识。两种方法都有助于项目在开发过程中避免出现混乱。
4）降低风险：短期迭代使得scrum方法和敏捷过程降低了需求变更带来的风险。在迭代周期结束时产生的需求变更可能会导致混乱，在下一个迭代周期中会改变技术以及规则来进行调整，使得项目没有风险的进行最终交付。这样会使整个项目处于正确的进程上。
5）改进控制：Scrum的每日例会允许利益相关方（一般指产品负责人）参加并对项目开发提出意见，项目开发者在下一步的开发过程中参考客户提出的意见确认更明确的用户需求，有益于项目的发展。敏捷开发是由管理者进行控制，它的改进有以下几种机制：（a）敏捷方法的设计，开发，测试迭代周期为企业带来了有商业价值的小幅增量。（b）在每次迭代结束时，利益相关者审查项目已完成的工作，如果有任何变化或问题可以直接反馈到下一周期的计划安排中。（c）越早反馈有助于项目越顺利正常进行。（d）每次迭代的测试确保开发商在项目中的赢利。
6）有益的交流：Scrum和敏捷方法都提倡面对面的交流方式，每个成员都对整个项目有很好的了解，这有益于他们进行下一步工作。
7）及时交付：Scrum和敏捷方法都按时交付项目增量，这样能保证整个项目的最终按时交付。
Scrum和敏捷开发的缺点列举如下：
1）只适合6至12个月周期的项目。
2）开发人员40以上不适用于此类方法，因为它是否适用于40以上人员是还值得商榷。
3）这两种方法合适于软件开发项目，核心是人而不是过程。
4）采用Scrum是昂贵的。
5）Scrum需要培训。
4 SCRUM和PRINCE2
受控环境中的项目（Prince2）是一种广泛应用于公共和私人部门的项目管理方法，它是英国项目管理的标准，英国政府项目都实施此方法。 PRINCE2是基于过程的结构化的项目管理方法，在赛迪监理的四控三管一协调理论中也有所体现，它一般包括：项目准备（SU），项目启动（IP），控制阶段（CS），产品交付物管理（MP），阶段边界管理（SB），项目收尾（CP），项目指导（DP）和项目计划（PL）的过程。由项目委员会来控制项目系统是否值得，计划是否合理等要点，项目经理来确认项目如何来进行，小组经理来进行工作具体实施。PRINCE2的项目计划是以产品导向的，也就是说项目计划强调项目按预期交付结果，而不是简简单单计划在何时该做何事。换句话说，PRINCE2使用产品分解结构。
小组经理和项目经理都与产品交付物管理（MP）过程相关联。小组经理负责受理，执行及分派工作包，而项目经理授权，评估取得的进展，并回顾已完成的工作包。这一过程包括小组经理和项目经理分别管理的三个子项目。左边的每个子项目直接与右边相连，用于通知子项目结束时的进度、质量和其他问题的子项目。图3显示了在Prince2产品交付管理的步骤。（图3）
从上面的图可以看出，MP1，MP2，MP3是由小组经理完成，而CS1，CS2，CS9过程是由项目经理完成。这整个过程可以在交付工作包的时候与Scrum相结合，Scrum可以在MP2阶段帮助团队进行项目控制，从而在这个过程结束的时候交付一个高质量的工作包。Scrum过程的产品backlog相当于这里的CS1过程中从DP过程中由项目委员会编制的计划单，Scrum过程的需求优先级排序特征和Prince2中的将工作包授权分配类似。Scrum和MP在团队中都是交付项目的成品。MP2过程中的工作包都要执行Scrum过程的每一个工作包，在每个验收点报告给项目经理。同时，小组经理更新质量记录和时间表给项目经理，不同的是，在Scrum过程中这些情况会在Scrum主管主持的Scrum例会中被反馈。在Scrum过程结束时的潜在的交付增量可以比作MP3过程，双方都提供一个完成的工作包。Scrum与Prince2的整合是由图4表示。
同样的，Scrum可以结合到CS过程中。Scrum可以结合到Prince2的每个工作过程中，并且将每个过程结束时的已完成工作包交付到下一个过程。在结合Scrum之前Prince2过程中的需求是可以进行任意更改的，而一旦结合了Scrum就得对需求变更提高警惕，因为Scrum过程中需求只允许在产品backlog中进行变更，只要产品backlog发展成为冲刺backlog就不再容许任何改变，这也就是为什么要根据客户需求来对产品订单进行需求优化级排序，最重要的需求将在第一个迭代周期解决。（图4）
综上所述，我们可以得到Scrum和Prince2的相同点与不同点表格如下：（如表1）
5 结语
敏捷方法是一种适用于短期的、需求变更频繁的项目管理方法，同时，敏捷项目管理对软件项目开发有着不同的方法，每种方法都有自己的优点和缺点，Scrum和敏捷方法的优缺点也在上文中有进行讨论。每个项目团队要针对不同的项目自身的特点来选择合适的项目管理方法，给项目提供合适的方法是项目成功的必要前提。
参考文献：
[1]Reed.K，Damiani.E，Gianini.G and Colombo.A（2004）Agile management of uncertain requirements via generalizations：a case study，in：Proceedings of the 2004 workshop on Quantitative techniques for software agile process，ACM Press，NY，USA，pp40-45.
[2]Parliamentary Office of Science and Technology（2000） Government IT projects，Report 200 - [Blackboard Material].
[3]Taylor.A（2001）IT projects sink or swim，British Computer Society-[Blackboard Material].
[4]Mahnic.V and Drnovscek.S（2004）Agile Software Project Management with Scrum，at http：///scrum/FirstScrum2004.pdf/[accessed 05/05/2007].
[5]Mikneus.S and Akinde.A （2003） SCRUM an agile software development methodology，at http：//facweb.cti.depaul.edu/jnowotarski/se470/akinde-mikneus pres scrum.ppt/ [accessed 10/05/2007].
敏捷的项目管理范文2
“敏捷”是时下的IT圈子里一个非常吸引眼球的词汇。很多人误认为敏捷就是一种软件开发的流程或者实践，而其实敏捷是一组开发流程和实践的方法论。这种方法论的背后是2001年由17位资深软件开发专家在美国犹他州的一个会议上总结出的敏捷思想。时至今日，敏捷思想激活逐渐成为了软件开发业的主流。全球不同规模、模式的IT组织已经从实施敏捷开发流程及实践中取得了巨大的成功。而我国不少的IT组织也开始了解、学习敏捷思想，希望自己的组织能从实施敏捷中获益。
然而，一个组织要接受一种新的开发模式并不容易。笔者对近期参与的一些敏捷项目进行了总结，在此与大家分享组织实施敏捷的方法以及组织实施敏捷过程中需要注意的一些问题。
为帮助大家理解，文中使用的敏捷词汇简单解释如下。
故事: 描述一个有价值的需求的文档。
迭代: 一个开发周期，往往是一组故事完成的周期。
XP: 敏捷倡导者Kent Beck提出的一组软件开发的方法。
Scrum: 一种敏捷项目管理方法
组织保证
在谈论怎样在一个IT组织、企业实施敏捷之前，首先从组织架构上予以保证。那么，什么样的组织架构最适合敏捷？
很多IT企业采用矩阵式组织结构，其中既有按职能划分的垂直领导系统，又有按产品（项目）划分的横向领导关系。一个项目团队的成员来自不同部门，隶属关系仍在原单位。很多时候一人同时参加数个项目，其中尤以质量管理人员（质量分析师、测试员等）最为普遍。这样的组织结构下，每个项目成员一般受双重管理（所在项目及隶属部门），这种组织结构存在的问题是明显的: 首先，双重管理容易破坏项目团队的整体性，部门领导和项目管理者容易产生步调上的不一致; 其次，由于团队管理的复杂化，项目透明度不高，很少有融入客户（业务部门）的机制，其后果是不能围绕客户和市场的真实需求来展开开发工作。
对比上面提到的矩阵式组织结构，敏捷组织需要弱化职能部门的划分，更多由跨职能、面向价值交付的团队构成。大家可能会立刻问: 这样的组织结构价值在哪里？下面我们就从三个方面来分析其价值。
敏捷组织价值一:
统一的团队
在传统结构下，团队采取“会战”方式组成，人员之间很容易因职能隔离，导致团队内垂直划分，从而不能成为一个统一团队。各职能成员容易各自为政、目标不一。一个典型的现象是，开发人员常常在内心抵触质量管理人员提出的要求，而质量管理人员又总是对开发的系统缺乏信心，项目管理者很多时候感到力不从心，不能激励团队成员，更无法谈到融入客户、拥抱变化了。
由于敏捷组织弱化了职能部门，敏捷团队成员全职投入到项目组中，增加了每人的团队归属感。原来一个人同时被分派多个项目的做法显然是不利于团队建设的，与之相反，敏捷组织要求员工积极参加到自己团队的日常活动中，鼓励员工参与不同职能的工作。
图1简单展示了一个迭代过程中业务分析人员、开发人员、质量管理人员及项目管理人员的日常工作。我们可以看到，除了每个职能例行的工作之外（如质量管理人员要完成上个迭代的故事测试，然后投入到这个迭代新故事的测试工作中），作为一个团队，大家要共同参与如“迭代开题”、“上迭代回顾”等集体活动。以“下个迭代计划”为例，项目管理人员需要安排组织会议、控制会议时间; 业务分析人员要解释下一个迭代故事的选择; 开发人员及质量管理人员则要了解相关需求，同时提出可能要进一步细化或要求重新评估的故事。通过这样一系列的活动，项目管理达到了高度的透明。同时我们可以看到客户（客户代表）被融入到团队中。远离客户的团队不可能是一个敏捷的团队，客户的参与是保证最终价值交付的关键。
从上面的讨论中，不难想象如果不是具有高度自组织能力、统一的团队，是无法贯彻敏捷开发思想的。这样的参与度，也让每一个团队成员很快拥有项目的主人翁精神。一言以蔽之，敏捷组织通过强调集体共有及发挥每个成员主观能动性来打造统一团队。
敏捷组织价值二:
价值驱动
谈到价值，首先就要明确什么是价值。对于软件开发项目而言，答案其实就在下面这个问题里。
假设在两个项目开发过程中市场都在不停变化: 项目A按时、按预算交付所有计划功能，不幸的是项目本身未能给客户带来任何帮助; 项目B因为响应变化，所以延时、超出预算交付了部分功能，但却帮助客户取得了盈利。传统项目管理方式下我们说项目A是成功的，项目组完成了计划。现实却恰恰相反，项目A没有带来任何的价值，因为它对使用者没有帮助。在现今IT市场需求快速变化的时代，按时、按预算交付已经不能成为衡量项目成败的唯一标准。
然而，要用价值作为驱动力就必须先有感知价值变化的能力。一个团队要有感知价值变化的能力就必须是一个有高度协作精神、步调统一的团队。正如GE前总裁韦尔奇所说: “如果我们穿着四件毛衣，那么我们就感觉不到寒冷了。”传统组织下的团队就像穿上了一件件“职能”的“毛衣”，很难感受到价值的所在。更无从谈起将客户（或业务部门）的需求转换为团队共识的价值、拥抱需求的变化了。
敏捷团队在项目管理上的高度透明及全程的客户融入实际是将最终的客户需求植入到了每一个成员的心里，让不同职能的团队成员都能用价值来衡量自己的工作，从而使价值成为我们各种开发活动的驱动力。
敏捷组织价值三:
减少浪费
时下很流行把敏捷与精益制造相对比，这里我们无意讨论精益，但精益的一个重要原则“减少浪费”在敏捷的组织结构里却得到了体现。
韦尔奇在20世纪80年代曾经用“零管理层”、“无边界行动”等理念将GE打造成美国最伟大的公司之一。在GE一个8000名员工的航空发动机工厂，只有一个厂长和全厂职工两个阶层，没有任何中间管理层。一般工厂常见的车间、工段、班组、工会、人事、财务、计划、技术、材料、供销等所有部门全部取消。在生产过程中所必需的管理职务由工人轮流担任。而一些临时性的工作，如招收新工人，就由各岗位老工人临时组成人事部门，完成之后即解散。这种扁平组织的思想与敏捷组织结构不谋而合！当我们弱化职能划分的时候，相应地那些为职能部门设立的各种烦琐的管理细节也被同时精简; 当我们打造一个统一的敏捷团队时，相应地按职能来管理人员的机制也就不再需要了。
在参与的敏捷项目中，我们经常听到传统组织团队中资深开发领导者这样说: “我很喜欢技术，真想跟大家一起开发。可惜日常的上下汇报、文档邮件占去了我所有的时间。根本没法参与开发！”我们不由得慨叹这种人员上的双重浪费。由于烦琐的管理细节，扼杀了团队宝贵技术资源的使用，同时也扼杀了资深人员进一步学习的可能。要消除烦琐的管理工作就必须打造有自组织能力的统一团队，这正是敏捷思想所追求的。
敏捷实施路线图
实施敏捷是一个组织长期自我改善的过程。根据实际情况往往可以分为三个阶段来帮助一个组织实施敏捷（参见图2）。
实施敏捷的过程中，组织管理者往往非常关心怎样去评估一个组织的敏捷程度。由于IT企业的多样性，评估一个组织的“敏捷成熟度”不能用一刀切的标准。图3展示了我们评估一个企业敏捷实施情况的一系列维度。红条为现状，蓝条为设定的目标。每一个维度实际又从不同的角度来考查。比如“测试质量”，我们考查使用测试的种类、测试环境、自动化程度、测试运行频率及测试用户。到达尺标5则要求各种层级的测试（单元、功能、集成等）都被分级自动化，并且融入到一个故事的开发周期中由不同人员（开发、测试、客户等）实施。
这里值得提起大家注意的是: 我们的目标是不是要所有维度都达到最优化（即到达尺度5）？或者说是不是只有各个维度最优化才能说敏捷实施成功了？答案是否定的。首先，要提高一个维度的指标必然需要一定的投入，比如想要更多地自动化测试，就会涉及选用或购买新工具，对相关人员进行培训。运用敏捷思想，衡量是否需要的标准就是价值，如果我们开发一个简单的网络应用，自动化所有测试带来的质量提高也许就远远小于我们的投入。所以，评估一个组织的敏捷程度绝对不能一概而论，一定要结合开发项目的实际情况。
下面让我们看看这三个阶段实施过程中需要做些什么。
敏捷激活第一步:
让大家了解敏捷
敏捷在软件开发业界已经成为主流。我们经常听到不少组织说我们用Scrum了，我们“敏捷”了。事实上Scrum也仅仅是敏捷思想下的一种比较流行的采用迭代式开发方式的管理实践。这样的说法暴露出不少人对敏捷的误解。敏捷是一种思想，有着很强的包容性。如何定义敏捷是一个比较困难的问题。笔者倾向于用敏捷宣言及原则来衡量一个流程、一个实践是否敏捷。
第一步是要争取组织领导者对实施敏捷的支持，我们必须认识到敏捷的全面实施是会涉及到部分组织变革的，而组织变革要求上下一心方能成功。
在了解过程中，我们希望给组织的成员传达正确的敏捷思想，让大家了解敏捷的思维方式，学会用价值来衡量日常开发工作。当思想得到统一后，即进入分角色培训阶段，一般情况会分为三组: 项目管理人员、业务分析人员组; 开发人员组; 质量管理人员组。项目管理和业务分析在敏捷中其实是分开的两个职能，但很多时候我们发现传统IT企业或小型开发团队中一般业务分析是由项目经理来完成的，项目经理因此对这两类活动负责。
培训过程中我们常展示一张“敏捷生态图”（见图4），它包含了敏捷常见的一些实践。生态图大致按三圈（即个人、团队、组织）来绘制。个人实践主要还是面向开发人员，吸取了XP的精华。团队和组织实践结合了不少Scrum的实践，并且强调了客户及统一团队的重要性。
敏捷激活第二步:
让大家相信敏捷
支持是建立在了解的基础上的。怎样让组织的成员相信敏捷的应用能够帮助大家提高工作效率、保证工作质量是这个阶段的重点。比较成熟的实践是由一个较为资深的敏捷组织和准备实施敏捷的组织共同组建一个项目团队，并且拿出一个试点的项目由这个联合团队开发。联合团队将采用结对的工作方式，即每个团队角色都由资深敏捷组织出人与新实施敏捷组织中同职能人员一起工作。试点项目一般要求是一个全新或相对独立的系统以避免遗留系统带来的技术难题分散了我们实施敏捷的主题。试点项目的选取一般会有两种形式: 假想一个相关系统或一个真实的项目系统。
使用假想的系统好处是可以方便地隔离很多外部干扰，比如对其他没有实施敏捷团队的依赖。缺点是真实性不足，不是很容易让人员全身心投入，而且不能充分暴露出真实开发过程中可能出现的问题。另一方面，采用真实项目团队很可能要承受交付压力，对一个在学习敏捷实施的团队，压力会产生很多负面作用。
联合团队开发过程中我们一般会采用各种物理手段来增加项目的可视性。这里最值得一提的是故事墙（在一面墙上以一些小纸条展示各个部分的进度及相关问题）。通过使用故事墙，我们可以很好地达到统一团队的目的。人员的日常工作通过故事墙展现出来，项目管理者及客户可以通过故事墙来了解一个团队的进度及表现。围绕故事墙，还可以使用各种辅助图表来跟踪整个项目、一个迭代或一个功能的进度并快速发现可能的问题。
敏捷激活第三步:
让大家用敏捷思考
通过试点项目，整个团队应该对敏捷开发过程有了实际的理解。这个时候需要用敏捷思想来总结项目中的各个环节，找出适合组织、团队的敏捷实践。这个阶段大家往往会希望回顾一下试点项目是否是成功的。这时一个不可避免的问题就是怎样来衡量成功呢？
本文开始我们探讨价值时对比了两个项目，那么试点项目的价值是什么？项目按时、高质量交付固然是有价值的，然而，更重要的应该是试点的目的: 我们希望通过实际操作来找到适合组织、团队的开发方式，我们希望学会用敏捷的方式来思考和判断问题。一般在提高软件质量和提高团队凝聚力上，大家都能达成共识。但常见的结论中也有敏捷开发方法加大了工作量，开发中的结对编程增加了人力成本，或是拖长了开发周期等。这些结论的得出很大程度上忘记了我们试点的目的。工作量的加大是必然的，因为团队在学习新的流程、新的方法。结对实际是最有效的学习手段，在2008年全球网上发起的开发人员就测试驱动开发学习方法有效性的投票中，与有经验的开发者结对学习被选为最有效的学习手段。在我们推行“结对”的过程中，也惊喜地发现不少组织成员已经开始将“结对”灵活使用到日常工作中，比如两个团队人员共同的技术问题很快就由双方的技术人员结对进行了统一解决。因此，衡量试点项目的成功更多的是要从团队成员能否通过项目实战学会从用敏捷思想考虑问题入手。
这个阶段很多的组织会尝试推广敏捷，各个组织的做法更多的是根据自己的实际情况出发。值得一提的是，敏捷的组织应该向一个知识型、自组织型的组织努力。打造这样的组织我们需要提供多方面的支持，比如，对相关人员，特别是各项目管理者的培训; 尽量让项目组能够集中办公，增强人员的团队意识; 成立敏捷学习兴趣小组，鼓励大家互相学习分享经验等等。
敏捷的项目管理范文3
软件项目开发通常会遇到这样的困难：即使写入了合同，客户的需求总在变化，尤其是项目后期，使开发一再陷入被动；设计一再修改，跟最初的想法相去万里；加班加点终于完成可却不是客户想要的；历尽千辛万苦，软件最终通过验收，客户却把它束之高阁，根本没有实际上线运行……
如果你深受这些情形的困扰，而且想走出这些困境，敏捷就是最好的工具。
通过一系列独立而又相互联系的实践，敏捷可改善代码质量，提高软件交付的成功率。然而敏捷并非“拿来就用，用之就行”的万能工具。对敏捷的错误认识、不正确的实施方法，都会造成实施的失败。
面对敏捷，应该持一种什么样的心态?你觉得这是领导向你压下来的任务，你不过是完成任务而已?或者你认为敏捷只不过是另外一种形式的CMMI?抱有这种敷衍了事、甚至反对的心态，敏捷成功的可能性很低。
敏捷，让我们起步
你可能对敏捷的基础知识有所了解。不过在实施前，还有一些问题你可能会遇到。错误的选择，会使你遇到更大的阻力，带来高风险。
自上而下还是自下而上?顾名思义，自上而下指的是由公司高层发起，逐步向下推进实施敏捷的过程。因为能够得到公司高层各种资源的支持，你对团队所做的各种改革遇到的阻力会较小，成功的几率也较高。
而自下而上是指由员工发起，再逐渐影响上层实施敏捷的一种方法。这种方法只能从一些小的实践开始，收到良好的效果之后，再逐渐说服上级实施更广范围的敏捷。我们强烈建议您采用自上而下的方法，所以，先说服你的领导吧。
小团队开始还是大团队开始?初次实施敏捷，我们建议从小团队开始。因为小团队的交流更简单，更容易在许多问题上取得一致。而且敏捷中的许多实践，都曾经强调了自己合适于小型团队。所以首先在小团队尝试敏捷，让每个人都熟悉了敏捷实践，让每个敏捷实践都成为习惯之后，再考虑大型团队、甚至分布式团队的敏捷实施。大型团队和分布式团队的敏捷，会遇到跨小组交流不便、时差问题、甚至语言不同等多个问题，这也是敏捷领域研究的活跃课题。
全面还是逐步改进?你可能很想立即把所有的敏捷实践用到团队中去，但一旦这么做，你会不断受到团队成员的质疑，为什么要这样呢?或有人直接反对：原来的方法已经很好了，为什么非要推倒重来呢?这给敏捷实施带来了很大的阻力。
敏捷强调自己是一种适应性的方法，你可以根据自己团队的实际情况，找出哪些方面的问题最严重，使用敏捷的方式替代。收到一定效果之后，再逐步采取其它的实践。这种逐渐改善、小步前进的方式，更容易受到团队成员的支持。
我们需要培训吗?关于培训，有两种截然不同的观点，一些人认为培训搞定一切。比如参加Scrum认证，通过2天的培训，拿到ScrumMaster证书，我们就可以敏捷了。这是部分初学者的误区，源于对敏捷的认识太少。事实上，敏捷社区对于Scrum认证也多有诟病。正确的实施来自于不断的实践。
另外一种观点认为培训毫无作用。其实这种观点也不正确。根据经验，一个新人加入到敏捷团队，在很短的时间内就可以适应敏捷的方法；而对敏捷一无所知的团队，实施敏捷困难最大。有了一定的实践经验，难免会遇到种种困难和疑惑，带着这些疑惑参加相关的培训，或在团队中引入经验丰富的敏捷实施专家，效果非常显著。
敏捷，在路上
你的团队已经开始实施敏捷，已经在采用每日站立会议、回顾会议这样的敏捷实践，也把需求划分解成用户故事，根据故事的业务价值迭代开发，但这其中仍然充满了种种陷阱，及时发现这些陷阱可以避免许多不必要的损失。
不要让敏捷实践成为形式。拿每日站立会议来说，这是一个简单易学的敏捷实践。但曾有人提出，我们的团队每天早晨开站立会议，但不久大家感觉无聊且烦人，因为成了每天向PM报告工作的例行公事，这种形式为上的实践，还需要吗?
每日站立会议的主要目的是使每个人知晓项目的最新进展，分享已有的成就，提出自己遇到的困难以寻求解决。如果觉得形式重复无聊，可以想一些点子使每日站立会议更有趣味。曾有一个团队是这样做的：不要讲那些重复、无趣的话题，如果有人觉得内容无聊，可以随时举手。超过3个人举手，发言者必须转换话题或干脆取消发言。其实敏捷有个重要的实践，回顾会议。大家可以在回顾会议上把这个问题提出来，没准能找到更好的解决办法。
依赖整个团队而不是一两个关键人。在估计用户故事点数时，找一两个技术骨干估计就行了吗?或者有些问题需要决定，PM或者团队负责人直接拍板?敏捷强调发挥每个人的主观能动性。估计用户故事点数时，让所有开发人员参加。一些需要决策的问题，也让团队成员一块参与。这些看似不起眼的地方，能让团队成员感觉到自己参与其中而不是被置之不理，并逐渐形成正向的激励，能进一步激发每个团队成员更大的潜能。
Scrum和极限编程并重。Serum是最近敏捷社区讨论的热点，很多团队使用敏捷时就是在使用Serum。造成这种问题的原因在于Scrum是项目管理相关的，很容易被负责人接受，而极限编程相关的实践是与编程相关的实践，容易遭到忽视。
极限编程的实践如结对编程、测试驱动开发、持续集成等，可以大大提高代码质量，减少项目集成的风险。考虑到Scrum支持迭代开发，不同迭代逐渐增加功能，同时敏捷拥抱变化，功能变化务必会修改代码。如果没有自动化的测试做保障，难免会对已有的功能造成影响。所以极限编程是敏捷实践中必不可少的部分。
如何坚持测试驱动开发等比较难的实践?与每日站立会议相比，测试驱动开发这样的实践并不是很好坚持，很多团队实行了一段时间就放弃了。
根据调查，造成难以坚持的原因有不少：没人指导，靠自己摸索比较困难；即使有了相关培训，培训的例子与实际应用差别很大，项目进度有压力，必须抓紧时间写代码……面对这样的困难，测试驱动开发仍然需要坚持。可以从其它团队找一些经验丰富的人指导，团队内部也必须不断提醒坚持。
充分发挥BA和客户的作用。与传统软件开发的瀑布模型相比，BA或客户不再是写完需求说明书就万事大吉，开发人员也不是只拿需求说明书照本宣科。
BA或客户应该与开发人员时刻保持联系：开发人员从backlog中拿到一个新的故事时，先阅读故事描述和验收条件，最好能让BA或者客户进行讲解。因为BA或客户对项目的整体理解更为深刻，开发人员一旦理解有所偏差，可以立即发现。
用户故事开发完成，要先让BA或客户现场验收。现场验收，不需专门部署验收环境，也不需准备复杂的测试用例，可以就在开发现场简单快速的进行。一旦发现没有完成的验收条件，开发人员立即修改。这种验收的时间很短，一般5到15分钟之内就能解决。把它与QA的测试结合起来，具有良好的效果。
另外每个sprint迭代周期结束后要向用户演示，现场听取客户最直接的意见，看做出来的软件是否他们真正需要的，及哪些需要做出修改。此时的反馈可以尽早发现问题，避免你在岔路上越走越远。
敏捷，我们成功了吗
你已经使用敏捷开发了―个项目，怎样判断是否成功了?除了软件成功交付这样的指标，还有什么其它条件吗?你需要看你的团队是否成长为了一个成功的敏捷团队。
一个成功的敏捷团队，是一个可持续发展的有自管理能力的团队，具有很高的项目交付能力。
敏捷的项目管理范文4
从上世纪50年代软件出现开始至今，软件开发方法先后经历了无规则的编码和测试、结构化方法、面向对象的方法、能力成熟度模型CMM和轻量级开发方法等各个阶段。纵观软件开发的发展史，软件开发方法的演变是有规律可循的，遵循着一条从“计划和预测”到“反馈和适应”的历程。造成这一演变过程的原因如下：
1）软件使用者的主体从大型尖端领域逐渐向广泛的企业应用领域转变；
2）人们对软件系统需求的认识提高；
3）市场经济的发展，以及市场需求的频繁变化；
4）面向对象技术的应用和普及。
而今，企业面对的是快速变化的市场，在这样的市场环境下，收集用户完整的、稳定不变的系统需求是不可能的。面对无法预知和不断变化的需求，传统的软件开发流程明显已无法适应，而敏捷过程将程序代码和系统需求紧密的联系在一起，将系统需求视作流动和变化的需求的思想，则正符合现今软件开发的现状。
1 敏捷开发的兴起
敏捷方法诞生于2001年，由J.Highsmith和R.C.Martin发起，由一批业界专家参与成立了敏捷联盟，并概括出了一系列让软件开发团队具有快速工作、相应变化能力的价值观和原则。
在敏捷联盟的官方网站上，可看到敏捷宣言的完整内容：
1）个人与沟通胜过过程与工具；
2）可工作的软件胜过面面俱到的文档；
3）客户协作胜过合同谈判；
4）相应变化胜过遵循计划。
具体来说，传统的顺序开发模型（瀑布模型、V模型、W模型）的一个重要的特点就是所有的活动都是有顺序的。顺序开发模型成功使用的一个前提是软件系统具备完善和明确的需求。如果在项目开始阶段无法进行完善的需求分析和设计，则顺序开发模型就很难被成功的使用。为了解决顺序模型的不足，出现了增量迭代模型。从本质上说，敏捷开发就是一种迭代的增量的开发模型。这种模型的优点如下：能很好的适应需求的变化；早期的迭代可以降低风险；集成是持续的而不是在项目后期进行的“大动作”；在每次迭代中发现和更正缺陷并能不断反馈并改进开发过程[1]。
如果要用一句话来描述敏捷开发，那么敏捷开发应该是：以人为本、轻载、基于时间、just Enough、并行并基于构件的迭代和增量的软件开发过程。
2 敏捷开发的原则
敏捷联盟成立后，又陆续形成了敏捷的十二项原则（本文不在详细展开，详细描述见敏捷联盟官方网站），其主旨思想大体如下：敏捷开发中需求是逐渐展开的，在项目初期不提倡过渡的需求分析，对需求变化的响应是动态的；敏捷项目应该分成从几周到几个月间隔的迭代周期，每一个迭代周期尽量产出潜在可交付的软件产品，用户的反馈作为下次迭代的基础；可工作的软件是衡量项目进展的主要依据；敏捷开发整个过程是持续的，带有反馈的和自我完善的轻量级的过程。
基于敏捷指导思想，形成了不少敏捷软件开发方法(例如XP、scrum等)，它们大都强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注。以XP（extreme programming）方法为例，它消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。并且它作为一种面向客户的开发模型，开发过程中对需求改变的适应能力较高，即使在开发的后期，也可较高程度地适应用户的改变。XP开发模型与传统模型最大的不同是其核心思想是交流（Communication）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）[2]。这种开发模型的主要优点如下：
1）采用简单计划策略，不需要长期计划和复杂模型，开发周期短；
2）在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证；
3）能够适应用户经常变化的需求，提供用户满意的高质量软件。
纵观所有敏捷开发方法，其基本都具备轻载、基于时间、Just Enough、并行并基于构件的迭代和增量的特点，而且具有类似的敏捷项目交付模型。
3 敏捷项目交付模型
敏捷项目交付模型是一种敏捷软件项目管理的生命周期模型，它是基于敏捷开发迭代和增量特点的过程模型[3]。该模型把敏捷软件项目的生命周期大体可分成项目规划、项目启动、迭代开发与三个阶段。各个阶段分别介绍如下：
1）项目规划阶段
敏捷开发中的项目规划阶段类似于传统开发过程中的项目可行性分析和早期的需求收集阶段，该阶段的主要工作如下：
（1）就要开发系统的战略目标、业务愿景和初始项目需求等与关键涉众达成共识；
（2）根据收集到的资料，设计与决策系统开发的关键技术架构问题；
（3）评估项目的工作量与成本，辅助客户决策项目的可行性；
（4）进行项目的初始计划制定。
2）项目启动阶段
该阶段是一过度阶段，处于项目规划后正式开发前，主要工作是为项目开启准备各种所需资源，包括开发场地布置、软硬件环境的准备和项目团队的组建等。另外，通常为了使此后的迭代开发阶段能够顺利进行，还有为第一次迭代进行详细的需求分析工作。
3）迭代开发与阶段
该阶段是敏捷项目交付模型的核心部分，基本上所有的开发工作都在该阶段展开与实现。在迭代开发与阶段，项目组会根据目标系统的正式版本将该阶段分解成多个重复的过程，并且每次过程基本上都是一次目标系统的增量在开发环境中实现，并从开发环境到生产环境的迁移。每次迭代开发与又可细分为迭代开发、用户验收测试（UAT）和三个小阶段。各阶段的介绍如下：
（1）迭代开发是一个有固定时间周期的、在开发和测试环境上完成系统增量的过程，增量流程大体由需求分析活动、设计实现活动、集成测试活动、客户测试活动组成。每次迭代都会产生潜在可交付的产品；
（2）多次迭代开发对应一次，多次迭代后每次前，会根据项目需要进行用户验收测试。目标是让客户代表从系统最终运营的角度测试系统行为，另外，该阶段也可作为项目团队完成目标的缓冲区；
（3） 过程在敏捷开发中有里程碑的作用，其业务意义大于技术意义。使用敏捷软件交付模型，第一次会在较早的时间发生，这对于提升客户投资收益，根据市场反馈调整项目走向都有帮助。
4 敏捷开发中的测试
对于敏捷的理解，一般认为最为关键的是需要注意两个方面，即“高速迭代”和“持续不断的客户反馈”[4]。而要达到这样的要求，传统的注重流程的规范，文档的齐备，走完整的bug处理流程的测试过程，明显已不符合敏捷的初衷。
那么敏捷开发中测试有何特点？，简要来说，如下所述：
首先，就测试的阶段来说，敏捷开发中的测试贯穿于整个软件开发生命周期中（传统软件开发模型中，测试只是作为编码后的一个独立阶段出现）。其次，敏捷开发是迭代和增量的过程，这就意味着测试人员在每个代码增量完成时，都要测试它，测试工作也是迭代的展开，并且时间更紧，压力更大。开发和测试是并行进行的，程序员从来不超前于测试人员（在传统软件开发模型中，编码和测试过程是串行的，先编码后测试）。再次，敏捷开发中，测试人员需要紧密的与客户合作来定义每一个需求的接收标准；而且测试过程还可以向项目组随时反馈开发中遇到的问题。而不像传统测试中，测试由详细的需求驱动，并且发生在编码之后。最后，敏捷测试中，提倡持续集成和构建，集成的频率较高，并且可为开发提供持续的反馈。
5 结论
其实，不管正在使用的是哪种开发模式，都会经历几乎同样的软件开发生命周期元素。敏捷的不同之处在于时间段明显变短，而且活动同步进行。因此，参与者、测试和工具都需要适应这一变化。同时，也应该看到没有哪种开发模式可以放之四海而皆准，只有不断的被实践和验证才能持续完善[5]。目前，敏捷还在不断发展，更多的项目在实践敏捷，应用的普及和成功的案例正在不断扩大。
参考文献
[1]郑文强，马均飞.软件测试管理[M].电子工业出版社，2010.
[2]张友生，李雄.常用软件开发模型比较分析.中国系统分析员，2005(1).
[3]桑大勇，王英，吴丽华.敏捷软件开发方法与实践[M].西安：西安电子科技大学出版社，2010，5.
敏捷的项目管理范文5
关键词 跨国企业 采购 多项目管理
中图分类号：F275 文献标识码：A
随着全球经济一体化之风日盛，其中一种应运而生的商业活动就是“全球采购”。 全球采购是指利用全球的资源，在全世界范围内去寻找供应商，寻找质量最好，价格合理的产品（货物与服务）。自从亚当・斯密发现分工能够提升工作效率之后，产业组织内的企业一直在不断扩展着分工的范围，但是长期以来，分工都是在一个国家的内部进行的，直到经济发展出现全球化的趋势，跨国企业才纷纷制定了全球发展战略，也正是在这种战略的指导之下，成功实现跨国范围的产业分工，并且由于具备了先发优势，跨国公司已经成为当前全球产业分工价值链的核心，通过这些跨国巨头，成功的将散布在世界各地的企业联系起来，并最终为一种产品生产各个所需的零配件，并随着分工的不断细化，已经形成了围绕跨 国公司的高速运转的企业网络。也正是因为这种趋势的不断深化，跨国公司之间的竞争也由单体之间转变为企业网络和供应链的竞争。
一、跨国企业采购中的特点
随着经济全球化的发展，跨国公司纷纷制定了全球发展战略。在这样的竞争方式转变的背景下，跨国公司才愈发的有动力去整和全球范围的优质资源，积极构建范围更广、成本更低的采购环节就是其中重要的一个组成部分，从某种程度上来说，跨国企业的全球采购策略成功与否直接影响着其竞争优势的得失。采购活动作为生产的第一道环节，是大多数企业成本中比例最高的部分，原材料的好坏及价格高低直接决定了企业最终品的市场竞争力，因此，如今的跨国公司都将采购供应链的全球化整合作为非常重要的战略组成 。
二、在跨国企业采购中多项目管理手段的应用
关于跨国企业采购中的多项目管理手段应用，国内学者的研究也主要集中在项目组合管理和项目群管理，但还不够深入细致，尚未完全形成体系。黄有亮等认为，多项目管理的重要工作是如何有效协调多项目之间的冲突、优化调配多项目间的资源，并指出多项目管理需要建立管理信息系统，有效加强多项目参建主体之间的信息传递、共享，避免项目之间、部门之间信息孤立，提高多项目组合的价值。白思从多项目管理的概念、特点等方面系统地介绍了多项目管理，并分析了多项目管理的类型。程铁信对项目组合管理、项目群管理、项目群的形式、项目群的生命周期进行了系统的总结和分析，认为多项目管理的核心是多项目之间利益的均衡、多项目的目标与组织战略目标的协调、项目之间的资源的优化调配三方面。
跨国企业对于中间投入品的来源可使用内部生产和外部收购的方法。20世纪90年代以来，因贸易与和投资自由化的发展，多数国家市场联系日益密切，企业间的竞争更为激烈，为了更好的生存和发展，欧美的跨国企业做了大规模的业务调整，将资源集中在业务领域的竞争优势和联系上，将一些做的不佳的业务剥离去除。此外，技术的进步，特别是信息技术和通讯网络等的高度发展，大大降低了交易成本。最终，业务外包与资源外取的优势更加突出，成为跨国公司生产策略改变的重要趋势。目前一些跨国企业已不做最基本的生产活动，而是专注在新品的研发、设计与销售上。
随着全球采购这一大趋势的推进，一些跨国企业开始寻找新的管理模式，即当地化策略。这种策略也是全球化采购的一部分，是跨国企业随着目前的总体趋势做出的选择，这是一种权衡多方利弊后的选择。因为即使不存在贸易障碍，本土化采购仍然具优势。在上述行业，产品的生命周期短，呈现出多元化的市场环境，消费者对产品的个性化需求的追求，要求生产过程不仅要有高度的灵敏性和调节性，还需要有敏捷的供货体系，对订货到最终交货的时间、生产商与供应商的距离也同样有很高要求。具有高效率的采购供货体系是美国Dell公司成功的关键因素，它们根据客户的需求向供应商下订单，对供应商的供货时间有更细化的要求，有些是一两天以内，更有甚者为几个小时，这种情况下供应商必须要调整相关产品的生产情况才能满足这一变化。跨国企业的业务重组与采购策略的优化，为国内公司提供了更多参与国际分工的契机，国内企业将会有更多的机会与跨国企业进行合作，这种合作主要是以成为中间投入品的全球供应商的形式出现；但随着国内贸易保护的取消，跨国企业会重新选择，选择的条件主要是看价格是否合理、技术是否先进以及产品的质量是不是过硬，只有以上条件都满足的才会入选。这种筛选是对国内企业配套能力的一次严格检阅。行业因素、产品的特点、东道国经营环境条件以及政策因素等多个方面会影响跨国企业在华的采购策略。这其中行业因素主要指市场结构、中间投入品的贸易性等，而产品的特点则指所需投入品的重要性和标准化程度等。在此我们需要重视当地的配套能力，是否能够提供符合要求、质优的零部件或中间服务至关重要，如果国内供应商在交货期和产品质量方面存在瑕疵，或国内供应商的零部件产品达不到跨国企业的采购标准，那么即使市场竞争性大的跨国企业也会绕道选择国外同类产品。
（作者：苏州大学东吴商学院工商管理专业2011春季班，战略采购方向）
参考文献：
[1]王长峰，林则夫，马蒙蒙.现代项目管理前沿[M].北京：机械工业出版社，2008：23-25.
敏捷的项目管理范文6
多元化教材
任课教师除了《软件工程》以外，选用《UML基础、案例与应用》和《轻松SCRUM之旅》为教辅材料，《UML基础、案例与应用》系统的讲授了UML基本知识和应用技术，培养学生软件开发和设计建模的能力。《轻松SCRUM之旅》将复杂的项目知识写成有趣的故事，可读性强，能吸引学生兴趣，作为课外读物，能够加深学生对于敏捷的思想、Scrum的概念和Scrum的实施方法的理解。教学内容整合了UML建模语言，SCRUM敏捷软件开发工程，EA建模工具的使用，Project软件工具的使用等，丰富了教学内容，加深了教学的深度，突出了实践的重要性。
面向对象案例教学
课程采用案例式、讨论式、团队式的授课方法。教学案例以面形对象为主。团队合作，教师层面负责相关的决策、技术方案的决定；在实验环节以教学团队为中心，按照企业的实际开发环境和要求开设实验课。用SCRUM理论为指导，熟练使用软件建模工具EA，以团队协作的方式进行软件项目开发和管理。案例式：课程开始之前：由教学团队收集、编写案例，包括软件项目中若干成功和失败的案例、以及软件项目过程中的若干实际的项目文档，建立课程的资产库。讨论式：课程教学过程中：由任课老师提供给学生，在学生中以头脑风暴、群体创新和群体决策等技术方式进行案例的讨论和分析。团队式：教师层面，以课程负责人为中心，教研室其他专业能力强的老师和企业资深项目管理人员作为该课程的专家小组，是该课程教学的人力资源库，负责相关的决策、技术方案的决定；学生层面：根据学生的专业能力，成立若干能力相当的团队。所有的案例讨论、项目活动以团队为单位执行和绩效。传统团队中成员往往分为项目经理，程序员，测试员等角色，在实践中，我们发现这种分组方式下，学生往往会绕开自己的弱点选择角色，达不到课程的目的，同时软件工程的实验课时为16个学时，只适合一些轻量级项目的开发，因此，目前团队采用SCRUM的方式进行。教师作为产品负责人ProductOwner：负责维护产品订单。每组学生作为一个Team选出一人作为ScrumMaster。一个冲刺Sprint通常在2周左右，开发团队会在此期间内完成所承诺的一组订单项的开发。在项目的进行中，每日站会，任务看板，计划扑克牌等都引起了学生的极大兴趣，使得软件工程不再停留在书本上，而是内化在真实的项目中。
结构化考核方式
在课程的考核过程中，结合课程理论与实践的特性，制定详细的课程教学和考核里程碑计划，在各里程碑以不同考核形式进行验收。不同里程碑根据课程内容性质采用不同的考核形式，采用理论研究、技术运用、实践应用、论文写作四种形式对学生进行考核。考核计划：1.理论研究部分：通过案例材料分析，提交ppt和相关材料。2.技术应用部分：通过期末闭卷考试，对核心的技术和工具进行笔试考核。3.实践应用部分：通过三性实验的验收进行考核。成绩积分计划：总成绩=平时绩效积分+理论研究积分+技术应用积分+实践应用积分说明：1.平时绩效积分（30分）：出勤抽样10次、每次1分；实验抽样验收5次，每次2分。分数从第一周至第十二周累计产生。2.理论研究积分（20分）：根据任课教师提供的SCRUN材料，撰写ppt。3.技术应用积分（40分）：对课程的主要工具和技术进行卷面考核，即期末考试。分数在期末考试结束后一周之内产生。4.实践应用积分（10分）：对课程第二个实验“需求分析”，即综合实验以三性实验验收标准进行考核，评估学生建模工具实际应用的能力。分数在课程结束之后两周之内产生。
成果
