敏捷的项目管理范文1
关键词:IT项目管理;敏捷思想;管理框架;柔性团队
中图分类号:F407.67 文献标识码:A 文章编号:1003-5192(2010)02-0032-05
A Heavy Weight IT Project Management Framework Based on Agile Theory
CHEN Jian-bin, FANG De-ying, SHI Tong
(Business College of Beijing Union University, Beijing 100025, China)
Abstract:The heavyweight IT projects have so high complexity and uncertainty that the traditional process management method should be improved. In this paper, the attribute of complexity product system(CoPS) of IT project, the modularity of CoPS and its decompose, the dynamic process of IT product development have been discussed, then a heavyweight IT project management framework based on agile theory was proposed. It contains some models such as the concept model on stochastic Petri net for complex IT product decomposition, the behavior model for flexible team, just enough set of heavyweight method and the core process of agile development base on knowledge transfer. This framework can reflect the trend of traditional IT development method changing to agile method, and can to provide a basic management rule to improve the development efficiency and the quality of IT product.
Key words:IT project management; agile method; management framework; flexible team
1 引言
软件危机推动了软件工程思想成熟,20世纪80、90 年代,软件项目开始使用可重复的规范过程,产生了以质量管理为核心、以软件工程理论为基础的严格有序的过程管理理论体系。软件项目被定义为一个有序的、可重复的、可度量的、可严格控制的过程。SEI的CMM模型是这一阶段过程管理思想的结晶,而且成为一套适用面很广的通用过程实践标准。但是,CMM及与其类似的ISO9000、SPICE等通常被认为是重载(Heavy Weight)过程,其出发点是为使软件项目能应对不可预知的变化,采取繁复的管理工作抵御风险。CMM 重视系统性、制度化、文档化和度量,强调提高过程的可靠性、可见性、可预测性和可管理性,实施CMM要求组织在过程制度化建设上付出大量努力。重载过程的工作集中在防止和跟踪错误上,大量工作流程的制定,是为了保证项目不犯错误,因此,软件过程越来越复杂,越来越庞大,重载过程的繁文缛节、组织臃肿、办事低效、形式主义等等副作用越来越明显[1]。重载方法与IT产品及其开发过程特性的矛盾日益明显,快速变化的外部市场环境也向传统的软件工程管理理论提出挑战。人们对软件过程的认识日渐深刻:软件过程不是混沌的、随机的、即兴的活动,也不只是一个严格有序的因果联系的工作流,软件项目是一个复杂系统,而软件过程是一种处于混沌边缘的非平衡状态下的系统行为。软件敏捷开发方法由此产生。
IT项目敏捷开发方法,具有早期客户参与、快速迭代交付、自组织团队、柔性等典型特征[2],能够提供客户满意的知识产品,非常适用于特定的环境――高风险、不可预测和小规模的探索型软件研发项目[3]。但是,软件产品的规模(size)日益庞大[4],重量级IT项目越来越多。相对而言,重量级IT项目具有较高的复杂性和不确定性,风险性、不可预测性也更高。传统IT项目开发方法及管理过程,导致重量级IT项目周期长、投入大、成果不可预期,较难获得客户的满意认可。重量级IT产品更需要运用敏捷开发方法。其中,重量级IT产品的架构、分解优化及其与柔性团队的匹配,是成功实现敏捷管理的关键。本文针对重量级IT项目敏捷管理的需要,提出一个基于敏捷开发过程的重量级IT项目管理框架,反映传统开发方法的敏捷性改造,为改进重载方法过程、提高开发效率和产品质量提供基本思路。
2 IT复杂产品系统及其模块化
复杂产品系统(Complex Product Systems, CoPS)指高成本的、技术密集型的、用户定制、单件或小批量生产的生产资料、系统、网络、控制单位、软件包、建筑物和服务[5,6]。IT产品复杂性也日益增加,一方面,软件规模的扩展意味着功能扩展,这种扩展不仅仅是相同元素重复添加,而必然是不同元素实体的添加,并且多数情况下它们以非线性递增的方式交互,使整个软件复杂度以更大的非线性增长。另一方面,软件本身的技术复杂性引发了更多的管理复杂性。Ren和Yeo认为[7],IT项目是典型的以人为中心、基于人工的,实质上更富个人主义色彩,因而难以预测、控制和自动化。因此,以ERP系统为代表的大型IT项目属于复杂产品系统范畴[7,8]。
对于复杂产品系统的开发,一般应首先采取模块化方法进行分解,才能有效实现产品目标。Simon等提出了系统的层级特性和可分解特性以便于降低系统的复杂性,并研究了软件结构化设计程度与软件复杂性、多变性和改进(Enhancement)之间的相互关系,系统地提出了复杂产品系统的特性和划分准则[9~11]。IT产品的模块划分是基于对整个产品系统框架以及功能需求分析的基础上,将整个IT产品系统的研发任务按照应用技术类别划分相对独立的模块/子系统进行的,在各模块开发完成后,交给集成商整合为一个完整的复杂产品系统,在这个意义上说,模块化是实施复杂产品系统的前提条件或必要条件。
3 IT产品的动态形成过程
从IT项目复杂性可以看出,IT项目最终交付的软件产品,是多种知识、资源动态结合而成的知识产品。不少学者[12]认为,敏捷产品是知识产品,产品的价值主要产生于它所包含的知识,而非产品的有形部分,同时认为过程也是一种知识产品。Wang[13]认为,ERP实施的关键是组织中系统和过程的相互适应,ERP系统知识必定产生于实施过程,并反映于产品之中。信息系统开发过程中,每一类知识的拥有主体是不同的,信息系统的开发过程就是这些主体之间的知识转移过程,信息系统的最终交付成果是这种动态交互的结果。
ERP系统作为一种典型的IT复杂产品系统,反映了重量级IT项目复杂性的两个方面,一是最终知识产品的高度复杂性,是业务知识、管理模型和软件技术的综合体;二是知识产品生产过程的复杂性,即据以对用户需求的预测,以人为载体的多种知识、资源的相互作用、相互影响、相互结合,由于人的因素,过程管理具有较大的不确定性、不可预见性。实践中,IT复杂产品系统的第二个复杂性,即动态生产过程的复杂度要远远高于第一个复杂性,而项目成败也多决定于此,项目风险的控制也主要存在于此。
4 重量级IT项目的敏捷管理思想
IT项目敏捷开发的需求主要表现为快速适应系统需求的变化、提高软件生产率、突出企业自身特点、支持动态联盟、面向业务目标持续改进和重组等方面。软件敏捷开发不仅仅简单地意味着软件的快速开发,它着重于对软件需求、过程和产品变化的灵活快速反应,是基于统一概念的一整套技术。和传统的软件过程有相当不同,敏捷软件方法是一种轻载的、基于时间的、恰好够用(Just Enough)的、并行的和基于组件的软件开发过程[14]。
但是敏捷方法高度的动态性、灵活性优势也形成了其应用的局限性。对于规模较大的IT项目(重量级项目),强功能、高集成的复杂性,使敏捷方法的适用受到极大的挑战。而重量级IT项目也具备需求快速变化、业务目标实现、提高开发效率等需求,也需要敏捷思想的应用。目前关于敏捷管理的研究仍强调敏捷过程适用于特定的环境――高风险、不可预测和小规模的探索型软件研发项目。有学者意识到了敏捷理念与传统实践的融合,一些CMM 和ISO9000的组织也开始接受部分地应用敏捷方法[15],但是这些同时考虑项目过程的成果,没有引入构建过程的核心要素――知识链,所以显得操作性不强,也缺乏实证。因此,本文提出一种重载过程的敏捷性改造,即基于敏捷思想的重量级IT项目管理方法。
5 基于敏捷过程的重量级IT项目管理框架
基于敏捷过程的重量级IT项目管理框架,力图达到的目标是:依据“敏捷灵活”与“过程规范”相平衡的原则,解决长周期性、高集成性、功能全面性等重量级项目特性下敏捷方法的有效性。框架的核心思想是:(1)建立复杂产品架构及系统动力学模型,实现复杂产品基于动态关系的分解与优化,导出最优知识产品单元划分;(2)构造基于多智能主体的柔性团队,设定团队内部协同的元规则,设定团队功能绩效指标,实现外科手术式团队构建和能力评价;(3)基于能力的柔性团队与知识产品单元匹配,根据团队特性分配开发任务;(4)基于适度规范的过程管理,微观上是柔性团队的自组织迭代,宏观上是过程管理的规范框架,实现重量级IT项目的动态、柔性、规范。框架内容如图1所示。
5.1 IT复杂知识产品的模块化分解
模块化开发方法,首先保证了复杂IT产品的降阶,从分解的角度保证了项目开发的操作性;模块化也可以提高整个产品开发的并行化,大大提高产品开发的效率;同时,通过交叉优化保证各模块的质量,实现“一次达到目的”与传统“反复做直到满意”的有机结合,从而保证产品系统的质量。
传统软件架构理论一般基于产品功能的静态划分[8],主要从信息流角度考虑模块单元的内聚与耦合关系,更多来自于项目初期基于需求的预测和设计;而敏捷方法更关注过程中需求创新,趋于对最终目标的逼近,是一种迭代更替渐进式方式。因此,此种方式下,关于知识产品的模型表述,势必与传统软件架构描述方法有所不同。复杂IT项目的模块化除了考虑最终知识产品的功能特征外,还要考虑开发过程的协同与控制问题。为此可以建立IT产品基于最小完备单元图的随机Petri网模型[16],采用消解规则进行系统分析,静态和动态分析相结合,有效地反映产品结构中任务执行或信息传递的主要特征,反映知识产品单元之间顺序、并行、交叉等多种复杂的网状动态结构关系。
随机Petri网模型中,用变迁表示单元本身,而变迁之间的关系则代表单元之间的关系。根据每个变迁(单元)的内在特征,可形式化定义为一个七元组
即{活动,输入产品,输出产品,前置条件,后置条件,环境,度量指标}。
从最小完备单元图出发,结合已建立的变迁(单元)间基本关系图和建立原理可以得到最小完备单元图对应的Petri网基本模型。直接计算该随机Petri网模型的复杂度很高,可以应用文献[16]中提供的关系度分解技术,考察最小完备单元图的相应矩阵,将单元进行分组。然后,根据不同组内单元之间原来关系的最高出现频次进行组间连接。多层次的分解,可以形成复杂产品的金字塔型模块结构,既包含了静态功能信息,又反映开发过程的动态信息。
5.2 柔性多项目团队
柔性团队是典型的“外科手术式团队”,其内部具有高度的柔性和灵活性,团队成员之间有深入的沟通和密切的协作;对外则呈现高度的开发效率和运行规范,能够进行显性的能力评价和绩效考核。柔性团队的概念模型可以表示为
T=F(Ma, Mr, ST, C, Ms)
其中T指柔性团队(Self Organizing Teams, or Well-Structured Teams),是具有高度适应能力,自组织与他组织相结合的项目开发团队。Ma指多智能主体(Multi-Agents),即团队成员,具备能动性、协作性的知识主体,其中包括用户方的参与。Mr是指元规则(Meta Rules),团队成员相互协作沟通的基本规则集。根据复杂适应理论,该团队系统由一群行动者组成,他们按照一套规则与其他人交流,通过探索实现目标,这其中“元规则”特别重要。它是团队协作的基本依据,其他规则是这些元规则的不同函数。ST是共享的隐性知识(Shared Tacit Knowledge),团队长期协作过程中所共享的默会知识集。C是指情境(Contextual),是柔性团队完成具体任务时所面临的资源、关系、环境、他人协作等状况。Ms是指基于能力的柔性团队度量(Measures),度量的目的一是与模块化的结果――知识产品单元的匹配,为产品单元寻找最佳的开发团队;二是对团队的绩效进行考评,并动态更新团队能力表征,指导团队的成长演化。
柔性团队是重量级IT项目管理的基本组织单元。对于模块化后的开发任务,一般就由多个柔性团队根据自身特质选择相应的开发单元,并纳入动态组织网络进行管理。每个团队的敏捷软件开发过程必须定义每个活动什么时候、谁、在什么地方、采用什么工具协助等等具体的细节场景,同时也要根据项目的目标、团队规模、项目关键程度、风险以及不确定性和客户协作程度这些不同项目的因素对活动进行裁减和调整。除了定义单个活动以外,定义多个活动之间相互的关联和影响,形成一个完整的过程系统也是关键。这需要在开发过程中定义各种场景,来说明各个活动如何结合协作。
5.3 统一产品定义和标准
复杂IT产品系统的开发强调相关模块的兼容性。为了使模块的开发团队一开始就考虑复杂产品各个模块的所有因素,统一的产品定义与技术标准是系统集成研究的关键,是支持各模块开发团队工作的必要条件,使各模块开发的专业人员有共同的语言,使用“同一种语言”进行交流。从而使各团队能相互协作和共享信息,通过彼此及时、有效地通信和交流,尽早地发现问题并予以解决,以达到各项工作协调一致。
复杂IT产品系统统一的产品定义与技术标准包括产品功能、性能、用户要求、开发、质量保证、进度计划等方面,把不同阶段可能出现的问题,先期加以研究制定,对产品的功能、性能、可靠性、可测试性、可维修性、可重用性等预先进行定义和标准化,使IT产品开发一次成功,避免出现大的反复。除了产品定义和标准外,多项目团队还需要共享的知识资源等的支持,如通用的组件、构件、元素等。
5.4 重载过程适度规范集
基于优化模型的IT开发重载方法,其理论假设是过程可以通过持续的改进而提高能力,而过程是能力意味着产出结果是可预测的。以优化和预测为特征的传统过程管理虽然无法解决软件开发难题,但其过程管理模型和框架的规范性,是保证软件质量的重要内容。
敏捷软件过程主张结合企业业务,开发自己的软件过程,这就是“Just Enough”策略。该策略指出,在进行软件过程改进时,应着重领会CMM等过程模型的精神实质和基本原理,建立适合自己的过程框架而不是拘泥于CMM等形式。在实施CMM时,必须考虑过程的多样性,从实际出发做好文档和过程管理,把过程管理与企业的业务目标紧密结合起来,同时探索可满足CMM KPAs的最小关键活动集合。
另外,为了保证敏捷、适应原则下的过程管理,除了传统方法的适度规范集外,更重要的是增加模块化开发的协同机制。这种开发机制,首先是基于传统过程框架下分阶段的敏捷改进,如敏捷建模、敏捷设计、敏捷开发、敏捷测试等;然后是基于敏捷思想的过程框架改进,如基于全局的需求变更管理、模型调配、进程反馈,甚至必要时的全局性迭代重启。
5.5 基于知识转移的敏捷过程
Paulk曾经提出“XP是CMM的一个截面”的理念,指出敏捷方法可以是规范方法的一个环节或微观表现。因此,“基于知识转移的敏捷过程”是基于敏捷过程的重量级IT项目管理框架的核心。其中“知识转移”则强调敏捷开发过程中,多智能主体与知识产品之间多种形式、多种类别的知识转移活动,并且最终的产出是这种转移活动集成的成果。动态结合过程中,知识相互关系的处理,多主体的互动与影响等,都会导致最终成果的不同。
IT项目开发中的知识转移是一个复杂过程,与知识主体的属性、关系、知识本身的属性等密切相关。IT开发过程涉及不同团队的各种知识和技术,专家知识分布于团队之中而不是某一个人,他们必须进行工作联合和知识集成去完成统一的任务。这些知识在软件开发过程中不断在智能主体间、智能主体与产品间传递。敏捷开发过程由于强调人的主动性、适应性,强调团队的自组织特性,对知识转移的高效管理就显得尤为重要。
有别于传统基于规模的软件过程,基于知识转移的敏捷过程由构想、推测、探索、适应、结束等几个阶段组成,其结构和实施是面向时间的,是一种基于时间的软件开发(Time-Based Software Development)[13]。每一次迭代有固定的时间限制,一个复杂的项目可被分为多个迭代和多次发放,需求在迭代开始时被确定,直至下一次迭代开始前才再次修改。
6 管理对策
根据以上管理框架,实践中的管理对策主要应该采用:
(1)建立包括技术接受方和技术提供方在内的联合开发团队,通过培训、交流和组织,提升开发团队的柔性。
其中包括甲乙双方的联合开发团队是本对策的核心,特别在技术提供方对技术接受方的业务比较生疏、业务过程较为复杂的情况下。
(2)测评待开发产品的复杂程度及开发团队的柔性程度,构筑重量级项目敏捷开发基础。
产品复杂程度和开发团队柔性程度是客观的,理想情况下应该有客观的评价尺度,初始阶段可以以较大粒度定性测定。
(3)以实现高效知识转移为出发点,划分产品模块,使之与开发团队的柔性相适应。
产品模型的划分并不唯一依据产品的复杂程度,开发团队的柔性程度是客观的也是相对的。因此本对策的核心是围绕建立高效的知识转移渠道。
(4)积极采用和不断开发、积累辅助工具,提高团队开发效率、降低团队工作强度。
规范和灵活是一对矛盾,利用前人的成果,并不断积累自身的经验,将会使团队以灵活的方式继承规范的过程。
7 结论
本文通过平衡“过程定义”和“灵活性”,既考虑过程对活动的指导,又要保证活动与敏捷价值观的原则一致,提出基于敏捷思想的重量级IT项目的管理框架。该框架中,基于重载方法适度规范集的开发协同机制是关键,其既要规范开发过程的活动、文档、团队行为,又要从全局角度协调多团队多模块的开发活动,还要确保收集到适当的反馈信息,将这些信息融入到新的迭代过程中去,以此实现知识转移与敏捷项目管理的结合,达到传统项目管理与敏捷项目管理的融合,实现:拓宽知识转移的应用深度,拓展敏捷项目管理的应用广度。
该框架反映了重量级IT项目开发的敏捷思想,但更多技术细节尚需解决,如复杂项目的模块化分解方法、柔性团队的构建及行为规则、产品与标准的定义、适度规范集及协同机制等,均需要进一步研究给出具体的模型、方法和机制。这是本文后续研究的主要内容。
参 考 文 献:
[1]Chen J, He K J. The pair-working model for project team development[A]. Proceedings of 2003 International Conference on Management Science & Engineering[C]. Atlanta, 2003. 2520-2524.
[2]Highsmith J. Agile project management[M]. Beijing: Qinghua Publishing House, 2005. 7-10.
[3]Turk D, France R, Rumpe B. Assumptions underlying agile software-development processes[J]. Journal of Database Management, 2005, 16(4): 62-87.
[4]Shaw M, Garlan D. Software architecture: an emerging discipline, upper saddle river[M]. NJ: Prentice-Hall, 10-25.
[5]Hobday M, Brady T. Rational vs. soft management in complex software: lessons from flight simulation[J]. International Journal of Innovation Management, 1998, 2(1): 1-43.
[6]Hansen K, Rush H. Hotspots in complex product systems: emerging issues in innovation management[J].Technovation, 1998, 18(9): 555-561.
[7]Ren Y T, Yeo K T. Research challenges on complex product systems(CoPS)innovation[J]. Journal of the Chinese Institute of Industrial Engineers, 2006, 23(6): 519-529.
[8]MacCormack A, Rusnak J, Baldwin C Y. Exploring the structure of complex software designs: an empirical study of open source and proprietary code[J]. Management Science, 2006, 52(7): 1015-1030.
[9]Simon H A. The architecture of complexity[A]. Proceedings of the American Philosophical Society[C]. Reprinted in E:CO, 2005. 138-154.
[10]Banker R D, Slaughter S A. The moderating effects of structure on volatility and complexity in software enhancement[J]. Information Systems Research, 2000, 11(3): 219-240.
[11]Hobday M. Product complexity, innovation and industrial organization[J]. Research Policy, 1998, 26: 689-710.
[12]杜红,李从东,李晓宇.面向ERP实施的知识转移体系研究[J].管理工程学报,2005,19(2):110-113.
[13]Wang E T G, Lin C C L, Jiang J J, et al.. Improving enterprise resource planning (ERP) fit to organizational process through knowledge transfer[J]. International Journal of Information Management, 2007, 27: 200-212.
[14]沈备军,陈诚,居德华.敏捷软件过程的研究[J].计算机研究与发展,2002,39(11):1456-1463.
敏捷的项目管理范文2
关键字：：敏捷项目管理；敏捷；KANBAN
互联网运维项目专门面向互联网数据中心和云计算服务平台，项目范围包括数据中心容量和性能提升、设备替换、技术改造、产品部署等等。由于互联网运维项目的独特性，很多企业仍然沿用传统瀑布式的项目管理方法，无法快速交付高质量的运维项目。如何提升互联网运维项目管理的整体水平，对敏捷运维项目管理的方法论研究和实践的重要性就不言而喻。
互联网运维项目的敏捷项目管理方法研究
KANBAN（看板）是敏捷的一种方法论，是一种敏捷的变更管理方法。目前它被用于最广泛地管理 IT支持和维护工作。也更适合于有一个恒定的正在进行的工作流程的IT部门或互联网运维中心，而不是项目的可交付成果。
KANBAN的核心是要赋予项目团队管理工作量，定期交付业务价值，团队要提交真正可以交付的工作：不多也不少，KANBAN也是一种时间驱动器，来管理任何点的工作 （WIP，working in process）。如果业务要求解决更高优先级的工作，利益相关者必须确定当前的哪些工作可以腾出足够的人力资源来满足高优先级业务需求。同样在开放 的WIP 队列中，团队和利害关系方可以确定应该专注的下一步的最高优先工作。
KANBAN也是组织和团队解决工作瓶颈，克服障碍，以及持续改善的文化，最大限度地提高他们的生产力。看板让项目团队基于部门的具体要求建立审查周期和释放时间。为了适应敏捷文化，许多从业者也已经开始使用混合的方法，如结合SCRUM的KANBAN，将有效的敏捷实践，如每日站立会议，也吸收进KANBAN。
互联网运维项目的敏捷项目管理方法实践成果
在经过对敏捷KANBAN方法论的研究和多个项目进行实践后，作者本人作为云服务运维项目经理就开始和团队一起进行了实践，成果分享如下：
第一， 敏捷KANBAN项目管理方法最适合互联网运维项目
我们云服务项目团队在KANBAN实践过程中吸收了SCRUM思想。管理方法以KANBAN为主，SCRUM为辅，主要以KANBAN搭载互联网运维工作流程，同时采用SCRUM敏捷框架中的3个角色（PO，Team member，SCRUM Master）。
使用KANBAN方法符合了互联网运维项目的多种特征，完全包容了具有高度依赖性和突发性特征的运维项目工作，是精益现场工作管理方式的又一种行业应用。另外KANBAN所搭载的工作流就如水流一样，要向前不停流动。项目团队所追求的就是水流的速度越来越快，水流的管道越来越粗，其实也就满足了运维项目的业务目标和客户价值需求。同时KANBAN方法里面的工作项有优先级排序，有交付物验收和质量要求，并不仅仅是追求项目速度和交付物数量。
使用SCRUM的思想主要是体现敏捷思想的价值观，期望每个成员在信任、开放、尊重、承诺的意识下积极主动的工作。我们在实践中的KANBAN也有daily standup meeting，每天或适时的进行多个项目的状态同步和问题同步，会后进行问题分析和解决应对。并且项目经理与团队一起确认工作的轻重缓急，实时协调人力资源，把人力集中在优先级最高的任务上。
第二，互联网运维项目使用的敏捷KANBAN工作板
我们知道，吸取了SCRUM敏捷思想的KANBAN项目管理方法，最直接的体现方式就KANBAN工作板，我们云服务项目团队的KANBAN工作板如图所示。
横轴是互联网运维项目工作流，任务从左向右流动，大的流动过程分别是：计划好的项目任务清单，任务文档和设计准备、任务实验室阶段完成、任务在产线阶段实现、 任务Done。竖轴是按照优先级排序的并在进行中的工作任务（WIP）。竖轴的WIP容纳多个运维项目任务便签条，并且用不用的便签条颜色来区分不同的项目。每个便签条有3项内容：任务描述、任务拥有人、交付物开始日期和期望的结束时间。最下面放的是任务库存。右下角是多个项目在一年之内的路线图。
接近1年的敏捷KANBAN项目管理实践后， 团队的凝聚体不断提升，项目效率和质量也明显提高，同时也大大提升了项目交付度和满意度。
结语
互联网运维项目本身具有工作清晰性、变化随时性，协调复杂性的特征。为了能够最大化的避免运维项目的失败，提升项目的效率和质量，让运维项目走上成功之大道，那我们就要未雨绸缪，以正确理念为指导，使用正确的敏捷项目管理方法，正确建立项目团队，恰当使用资源，做好项目监控。只有这样，才是企业互联网运维项目管理良性发展的重要保障。
参考文献：
[1]罗伯特・K・威索基.《有效的项目管理（第五版）》.（美）电子工业出版社，2012
敏捷的项目管理范文3
敏捷开发强调以人为本，认为面对面沟通是软件项目成功的一个重要因素。
当我询问一个研发经理关于敏捷开发所需的工具时，他开玩笑地说，一张白板和两杯咖啡。这也反映出开发人员对于敏捷方法的普遍认知。
事实上，许多开发项目主管虽然认同敏捷开发所强调的快速反应和沟通的理念，却担心它的“杂乱无章”带来的“不安定因素”。因为它极度地强调人的因素，使得人员的素质对敏捷团队的影响，远比对其他团队更大。
举例来说，配对检入是个保证代码质量很好的方法。但编程人员不了解其重要性，可能为了进度，常常一个人草草就检入了。因此，在采用敏捷方法时，若能适当地使用工具来保存累积的知识并固化关键过程，必能使敏捷项目更加成功。我们试以敏捷开发的几个主要特点为例，探讨工具在敏捷开发中扮演的角色。
特点一:测试驱动开发
传统的瀑布方法先编码再测试，等到发现需求和设计上的问题，为了节省费用，常常不了了之。测试驱动开发是在需求产生后，设计模块和其之间的接口，并将单元测试代码完成。在此过程中，需求和设计上的偏差将会被发现。由于编码尚未进行，只需更改需求和设计即可，避免造成太大浪费。
特点二:简单设计
敏捷开发崇尚简单的渐进设计，而不是剧烈的颠覆式设计。其目标是首先只设计我们所了解的那些部分，然后使该设计随着时间的推移而逐渐改进，这有助于提高灵活性并将变化导致的成本最小化。
特点三:配对编程
尽管两人一组的配对编程从理论上看使眼前目标和长远目标都得以保证，这却是敏捷方法中备受争议的做法，反对者普遍认为它会导致耗时加倍。广义的配对编程也包括前面提到的配对检入(Pair Check-in)，也就是由两人一起检验代码的正确性，然后才检入。
特点四:小型
周期短可使对项目的评估提前，进而降低了风险性。但这所带来是大量的可执行文档，造成管理上的困难。
工具所扮演之角色
现在让我们以一个典型的敏捷团队DevAgile为例，看看该如何用工具实现其敏捷过程和设想（图1）。Smart先生是DevAgile团队的项目经理，他被要求在开发过程中体现我们以上所列的几方面特点，在配对编程方面还要求配对检入。
图1 工具对敏捷开发的支持示例
角色1:需求管理的利器
对项目需求和设计文档的管理是DevAgile必须首先面对的问题。他们要完成的，恰恰是一个需求变更很快的项目，这也是他们选择敏捷开发的重要原因。在敏捷开发中，需求的变化常常是为下一次迭代提供信息和进度计划的依据。
因此，DevAgile的大多数成员认为，记录下每一次关键的需求变更很重要，尽管最初有些人坚持敏捷开发并不需要文档。
同时，他们也注意到，要遵循简单设计的原则，并非意味着设计文档不需管理。相反，文档的数量和版本都会比采用其他开发方式更多。这些设计文档及其历史应该被妥善地管理，也要和相对应的配置项链接。
另外，小型意味着整个生命周期中有更多的，如何对这些进行系统化管理也是DevAgile团队必须解决的问题。
综合以上这几点考虑，Smart先生认为，应该找到一种需求管理的武器。DevAgile团队在进行了一番市场调研后，决定尝试TechExcel DevSpec这种需求管理工具。它不仅提出“以知识为核心”的概念，满足需求和设计文档管理的要求，还实现了真正的“功能驱动开发”。
尽管DevAgile目前没有清楚的看到后者如何实现，但DevSpec对产品需求、产品功能及知识文档的系统管理还是吸引了他们。
它成全了设计团队的敏捷性，支持简单设计，并对他们经常修改设计的做法提供了管理上的帮助。一些成员还指出，在敏捷开发的道路上，太多的不确定因素和灵活性难免会影响大家对最终产品的认识，有一个这样的工具能够时时刻刻描绘出要产品的清晰轮廓，记录下产品需求和功能变更的每一步，实在是很令人欣慰。
另外，为了配合数量多的小型，DevSpec还有整理功能点的能力。也就是说，将和某一有关的新功能、功能变更，以及缺陷修复，全都进行统一组织和管理。
例如，要完成6.1的，他们只需把6.1功能文件夹里所有的新功能、功能变更，以及缺陷修复全都做完，6.1版本也就可以了。为了更大程度上提高开发效率，Smart先生还别出心裁的对这些功能及缺陷设定了优先级，优先级低的任务可能被延缓执行。实践证明，这种具灵活性且针对来管理的系统使小型越发容易。
角色2:项目规划的利器
Smart先生发现敏捷的项目管理要能做到随机应变，应付各种可能出现的情况，也是建立在对任务的细分，并对任务的状态采取高频度的探测并及时调整的基础上。DevAgile选择了TechExcel DevPlan作为项目规划工具，因为它能够围绕DevSpec中管理的功能点进行迭代计划，对人力资源进行管理，既把握了正确的宏观方向，又能对任务细分。任务若被耽延，还可以反馈回来。
Smart先生认为，作为敏捷团队的项目经理，他应该从传统项目经理的“工头”身份中解脱出来，发挥他的领导力，去监控和协调开发过程。虽然项目经理还是必须定义和初始化项目，作项目计划，执行计划，监督并控制结果。
但是完成这些步骤的方式却是不同的。具体来说，敏捷项目的计划不再是详细的完整的项目实施步骤和资源分配，而更多的表现为一种迭代计划。在开发人员与客户或其他团队沟通的每一次迭代中，计划和资源分配随时可能被调整，以不断适应项目进展的需要。在DevPlan的帮助下，这种调整变得方向明确、清晰和有据可查。它将每一次迭代的框架确定下来，剩下的工作就是根据这个框架实施了。
角色3:测试管理的利器
有了DevPlan，测试计划和开发计划开始制定，项目在一种既有序又敏捷的机制下运有序地转着。为了实现“测试驱动开发”，DevAgile不可避免的遇到了测试管理的问题。他们注意到，需求管理工具DevSpec内的需求，可被直接导入测试管理工具TechExcel DevTest，并自动生成测试任务。所有测试任务可以遵照既定的工作流执行，保证测试工作的有序开展和管理，并在编码之前发现设计偏差。
另外，他们以往是用光盘来存储可执行版本，文件柜的每一个抽屉里都装满了光盘。在进行敏捷开发以后，光盘的数量更是与日俱增，要找某版本的光盘时，多半是很困难的。
DevTest能够保存和管理的软件版本，而且和DevSpec内的功能及缺陷文件夹相对应。也就是说，若在需求管理工具DevSpec内有个6.1功能文件夹，那么在测试管理工具DevTest中也有个相对应的6.1文件夹。这显然比用其他方式来存储软件版本更加科学和方便。
角色4:任务执行的利器
有了以上这些项目管理的利器之后，DevAgile团队的工作并非一帆风顺，因为新的问题又出现了:一些成员片面的认为敏捷开发是一种松散型开发模式，也就是不需要遵守固定的流程。这直接导致了很多开发任务的执行效果糟糕，有些任务被提出以后就失去了踪迹，就连Smart先生也难以追踪每一个任务的结果。
于是，DevAgile团队又引入了与DevSpec和DevTest可以集成的DevTrack。这是一个开发任务的跟踪管理工具，提供既固化又可灵活更改的流程，对每一个任务的生命周期进行严格管理。它保证该走的过程一定走过;该反馈的一定反馈;该提醒的一定提醒;若任务需被升级，那就一定会被自动升级。更令人兴奋的是，当任务完成之后，其结果会自动返回需求管理工具DevSpec或测试管理工具DevTest。Smart先生可以轻易地由DevSpec看到针对6.1版本的所有功能和开发任务是否全部做完，对的管理省时省事。
直到实施了任务执行管理工具DevTrack，Smart先生才逐渐认识到由DevSpec引导的“功能驱动开发”是如何实现的。DevPlan中的迭代计划、DevTest中的测试任务和DevTrack中的开发任务，都是围绕DevSpec中的功能展开的。这不仅使整个敏捷过程都严格围绕最终产品进行，而且其中的可追溯性和可核查性，也正是敏捷开发思想的有益补充。
现在，当项目成员在会议室和用户讨论得热火朝天的时候，Smart先生可以悠闲地在电脑前喝咖啡了，他知道整个过程都是可以控制的，需求和设计变化再多再大，经历再多的迭代和小型，只要所有功能都按照计划被开发和测试，项目还是会如期完成。
敏捷团队的成功案例总结
毫无疑问，DevAgile团队最终用敏捷开发方式取得了项目成功。让我们再来总结一下，他们是如何具体做到的呢？首先，需求被搜集和整理，产品功能和简单设计产生，将这些结构框架和相关文档存入DevSpec之后，开始制定迭代计划，并定义模块接口。紧跟着，针对接口做出测试代码。这些知识文档全由DevSpec来管理，因此DevSpec中形成了由需求、功能和知识文档组成的“概念产品”。
最后，功能点被导入DevTest而产生一个或多个测试任务，每一个测试任务都能按照DevTrack中定义的工作流（图2）进行。
图2 DevTrack中定义的测试任务工作流示例
图2的工作流被启动之后，编码人员在第一状态负责编写代码、重构和白盒测试。项目经理为了实现配对检入，把第二状态设为需有A和B两人一起检入的“配对检入”。每一个状态都有明确的负责人。A可以是第一状态负责人，而与A配对的人员则可以是跟A 所做的任务有关的人员。第三状态负责人可以是测试人员，在单元测试成功后便完成了整个流程。反之，则重新回到第一状态。
以上的案例中，对所提到的四个敏捷特点都有所注解。当然，这是一个可行的方案，而绝非唯一。
另外，面对面沟通也是个很好的敏捷操作，但是实际上却不易实现。客户或熟知商业逻辑的同事通常是无法长时间和开发设计人员在一起工作的。若一定要面对面，很可能会以高昂的费用为代价。更实际的方式是通过一定的沟通平台（如一些即时语音或视频通讯工具）来达到类似面对面的沟通。
无论采用何种方式，沟通后的结果都要能妥善地记录下来。知识的分类和历史的记录会使清晰度达到最高，进而使后来的一切活动，包括编码、测试、分析等，都变得容易。
敏捷的项目管理范文4
关键词：敏捷开发 Scrum 敏捷测试
中图分类号：TP31 文献标识码：A 文章编号：1674-098X（2014）09（a）-0255-01
随着社会的发展，行业竞争的加剧，原有的螺旋和RUP模型已无法适应企业快速的需求变化。为了解决这个问题，我们引入了敏捷开发和敏捷测试的概念，该文主要阐述了敏捷方法及如何在企业中实施敏捷测试。
1 敏捷开发的概念和构成
1.1 敏捷开发的概念
敏捷开发是一种以人为核心，迭代、循环渐进的开发方法。在敏捷开发中，软件项目的构建被切成多个项目，各个子项目的成果都经过测试，具备集成和可以运行的特征。
1.2 敏捷开发的构成
Scrum是一个敏捷开发框架，是一个增量的，迭代的开发过程。在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品Backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。
Scrum的开发团队总是先开发对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析，讨论和估算，得到一个Sprint的任务列表，我们称它为Sprint Backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
2 敏捷测试开发的特征、原则、及框架
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保及时最终产品。
敏捷测试特征：敏捷测试的成员需要有自发组织能力，敏捷测试需要编写需求备份列表。
敏捷测试原则：敏捷测试的原则是确保所交付的软件满足客户的需求。
敏捷测试的框架：敏捷测试框架主要包括3个角色，5个会议，3个产物，两个过程控制物。三个角色：敏捷测试管理中，角色分为三种，测试经理，测试组长，测试工程师。
3 敏捷测试的管理职责及五个会议
3.1 测试职责
确定测试需求，将测试任务分解成多个task并分发给测试组长。与客户沟通并确定测试优先级。每个Sprint，根据需求调整测试策略及优先级。接受或拒绝测试团队的工作成果；参与Scrumplanning；为项目盈利能力负责。
测试组长职责：保证资源完全被利用并全部是高产出；保证各个角色及职责的良好协作；解决测试过程中的障碍；作为测试团队与外部的接口，屏蔽外界对团队成员的干扰；保证测试过程按计划进行；组织DailyScrum、Sprint Review和Sprint PlanningMeeting。
测试工程师职责：评估工作量，拆分工作量并定义任务，评估资源利用率及工作时间，确保测试质量；改进测试流程。
3.2 敏捷测试的五个会议
（1）Product backlog估算会议：确定具体的测试需求，确定做还是不做。（2）评估storypointSprint计划会议：确定Sprint目标和每日立会的时间地点。任务拆分，工作量和point合计调整。（3）每日站立会：收集障碍，领取或分配任务，更新任务版和燃尽图。（4） Sprint评审会议：向客户提交测试成果并以之创建或变更backlog。（5）Sprint回顾会议：吸取经验教训，改进迭代过程，重点是改进团队和组织的工作流程。
4 敏捷测试的输出
敏捷测试的输出的三个产物：
Product Backlog，Sprint Backlog，
work software；两个过程控制物：燃尽图，障碍backlog。
5 案例分析
目的：为企业提供高效的测试服务，满足企业快速发展的需求。
解决方案：采用敏捷测试方法（图1）。
首先，测试经理将与客户一起参加 Sprint meeting并获取客户的测试需求，然后记录Product Backlog，其中包括待办事项，测试任务的优先级，测试周期等。然后测试经理将测试任务分发给测试组长并记录 Sprint Backlog。其中包括待办事项，测试任务的优先级，测试周期，测试计划等。确定测试任务后测试组长再与测试工程师进行开会讨论，安排测试资源、测试策略、测试周期、每日站立会时间地点。测试工程师明确测试任务后，开始开展测试工作。每天测试组长和测试经理会利用10分钟的每日站立会收集测试障碍信息，测试进度等信息并在Sprint Backlog中记录这些信息。测试任务完成后，向客户提交测试结果。测试结束后测试相关人员要吸取经验教训，改进测试流程。
6 结语
随着敏捷开发Scrum的广泛应用，敏捷测试也并将成为测试领域的发展趋势。我们也可以从敏捷测试中寻找到更多的发展机遇，为企业的快速发展和需求提供更好的解决方法，更好的为企业服务。
参考文献
[1] 王璇.敏捷测试理论与实践[J].软件导刊，2009（1）：38-39.
[2] 陶凌燕.基于Scrum的敏捷软件测试模型研究与应用[D].华中科技大学，2011.
敏捷的项目管理范文5
关键词：敏捷物流企业 建立 运作模式
中图法分类号: F274 文献标识码: A
随着科技迅猛发展和市场竞争日益加剧，现代企业必须不断运用新技术和新管理模式，以增强自身的竞争力和迅速响应市场的应变力。在此趋势下，以敏捷性竞争模式将成为现代物流业竞争的主体。在敏捷竞争中，通过物流企业之间的动态联盟，充分发挥各自的核心优势、优化资源，更好地满足多变的市场需求，达到双赢的目的。
一、敏捷物流与敏捷物流企业
1.敏捷物流与敏捷物流企业的概念
敏捷物流理论来源于敏捷制造AM，敏捷物流是在优化整合企业内外资源的思想上，更多地强调了物流在响应多样化客户需求方面的速度目标。可以说敏捷物流是现代物流发展的高级阶段。敏捷物流其本质是在供应链一体化的基础上，利用合作伙伴间的协同关系和信息的共享，在合适的时间，将合适质量、合适数量的合适产品以合适的方式配送到合适地点，满足合适顾客个性化、大规模定制的准时化需要，从而实现成本与整体效率优化的物流活动。
实现敏捷物流的组织形式是敏捷物流企业或物流动态联盟。敏捷物流企业是一种由多家独立的物流企业为抓住和利用迅速变化的市场机遇，通过信息技术联系起来的临时性的网络结构性的组织。网络中的各伙伴企业充分信任，发挥各自的核心优势，共享各种资源，分担风险与利润，可迅速有效地集成为满足某个特定市场机遇所需的全部资源，从而对市场和顾客要求做出积极快速的反应。
2.敏捷物流企业的特征
敏捷性。敏捷物流企业自身是由多个敏捷企业的经过优化设计与组织的，这可以保证其自身能够通过信息基础设施和灵活的企业组织方式快速重组企业，敏捷地能对市场机遇做出快速的反应；
动态性。敏捷物流企业是临时性的动态企业，是市场多变的产物，其组织结构往往以动态的多功能项目组为其基本组织单位，动态灵活可变；
合作性。物流企业成员间是平等合作的伙伴关系，它们以快速响应市场机遇为目的，根据市场机遇和需求以自己的优势及特长而加入敏捷物流企业，并根据合作协议实现利益共享；
集成性。敏捷物流企业需要由不同企业或企业内不同部门根据市场机遇和需求将人、管理、技术以及其它资源在不同层面上进行有效的优势集成；
互补性。在敏捷物流企业组织中，参与企业均需具备自身的核心优势，也存在缺陷和不足，参与企业只负担本身优势责任，使技能、管理、知识和信息优势得以集成而加强整体竞争优势。
二、敏捷物流企业的建立
1.敏捷物流企业建立过程中的关键要素分析
敏捷物流企业组织的优劣直接影响到敏捷物流企业的敏捷性以及敏捷物流企业能否最终抓住和实现市场机遇，在组建敏捷物流企业过程中必须分析研究与敏捷物流企业组织有关的一些问题，以便建立最优的敏捷物流企业。建立敏捷物流企业应考虑如下关键要素：
(1)市场机遇
市场机遇具有时间性、约束性及效益风险性等特征。机遇的时间性是指机遇具有生命周期；机遇的约束性是指机遇对准备抓住或已经抓住该机遇的企业有一定的约束。机遇的效益风险性是指企业获得成功的概率、企业成功后的收益或失败的损失。由于敏捷物流企业是为了响应市场机遇而建立的，因此对给予的效益风险性与约束的正确评估与分析是决定是否建立的前提。
(2)核心资源
核心资源是物流企业响应市场、参与竞争所依赖的能力。当发现市场机遇时，物流企业应首先考虑自身是否拥有相应的核心资源。如果所缺核心资源只是该机遇所需求的时候，最好建立敏捷物流企业。核心资源是选择联盟伙伴的依据，只有拥有所需核心资源的企业才有可能成为敏捷物流企业的伙伴。因此，在建立敏捷物流企业的过程中，需要对企业自身的核心资源进行分析。
(3)合作伙伴
敏捷物流企业是由盟主和若干伙伴构成的，最先抓住机遇并拥有主要核心资源的企业为盟主，其他参与经营的企业为伙伴。这些伙伴是拥有不同核心资源的一些物流企业。它们根据物流联盟的要求迅速以它们自身的技术、人才和管理参与联盟，因而，伙伴选择是建立敏捷物流企业的关键环节之一，直接关系到敏捷物流企业的最终的成败。
(4)组织方式
多变的市场环境要求敏捷物流企业的组织应该是可重构、可重用、可扩充的动态组织。根据需要，各个物流企业参与敏捷物流企业的方式也多种多样，如供应式、转包加工式、合资经营式、插入兼容式和虚拟合作式等。
(5)利益与风险分配
敏捷物流企业强调的是合作，而合作的基础之一就是有合理公正的利益与风险分配机制。因此敏捷物流企业的利益与风险分配机制应在敏捷物流企业建立阶段得到解决。一般可通过分析每个伙伴企业参与敏捷物流企业过程的重要性、参与的方式、投入的多少等来确立利益与风险的分配。
2.敏捷物流企业组织建立过程
建立敏捷物流企业是一项庞大的系统工程，它涉及多个物流企业、企业间集成和大量的各类信息，因而需要合理的建立过程。敏捷物流企业组织建立过程大致可分为4个阶段：
(1)目标确定
该阶段主要包括市场机遇寻求与评估分析与差距分析。市场机遇寻求与评估分析是指敏捷物流企业组织建立之前，需要对市场机遇的风险性和获利性进行科学评估，以便决定是否响应机遇和确定该机遇所需的核心资源；差距分析即寻找物流企业对自身现有核心资源和能力与机遇要求的核心资源和能力之间的差距进行分析，在此基础上决定响应机遇的方式，并最终确定企业的战略方向和目标。
(2)敏捷物流企业建模与伙伴选择
该阶段主要包括敏捷物流企业过程设计、敏捷物流企业模型设计、伙伴企业的选择与评估、伙伴企业过程重组等。敏捷物流企业过程设计主要是面向机遇物流活动和服务的理想设计，有待进一步优化。敏捷物流企业模型设计是在设计完敏捷物流企业过程之后进行的。经过优化的敏捷物流企业过程与机遇所需的核心资源将作为选择联盟伙伴的主要标准。所有具备机遇所需的核心资源的企业都应视为潜在的合作伙伴。同时，根据潜在伙伴所提供的过程，对理想敏捷物流企业模型进行修改和企业过程重组，并进行仿真优化与评估，以此确定一个最优的合作伙伴及敏捷物流企业构成方案。其中，敏捷性度量是检验过程、模型和伙伴优劣的核心指标。
3．组织设计与利益/风险分配
本阶段主要包括项目定义、敏捷物流企业组织设计、利益/风险分配机制的确定。在敏捷物流企业模型的指导下根据敏捷物流企业物流活动和服务过程可定义敏捷物流企业的项目，并确定伙伴企业的多功能项目组参与形式，建立敏捷物流企业组织机构。根据敏捷物流企业过程和敏捷物流企业模型，基于活动分析的方法确定伙伴企业对敏捷物流企业的贡献大小来建立联盟伙伴间利益/风险分配方案。
4．实施
在完成上述工作后，就可以按照敏捷物流企业过程、敏捷物流企业模型和敏捷物流企业组织的设计方案进行敏捷物流企业的实际组建工作。
三、敏捷物流企业的运作模式
针对现代物流市场竞争的特点，本文提出敏捷物流企业的运作模式为：敏捷性＋信息共享+关系管理＋供应链效力+绩效管理。具体解释如下：
1.市场需求的敏捷性
敏捷物流企业的运作由市场需求驱动的。当客户的物流需求产生以后，通过敏捷企业盟主的集成能力，在协商和友好合作的方式下迅速建立敏捷性协作组织，通过信息系统实现信息与资源共享，并通过建立有效的物流绩效衡量和激励机制，进而提高物流服务整体效益，达到多方共赢。
2.信息共享管理。
在敏捷物流运作中，各物流企业之间通过敏捷物流系统集成平台进行信息共享是敏捷物流实施的前提。敏捷物流系统集成平台的构建是建立在企业现有应用系统基础上，因此要求企业现有应用系统应具有快速响应外部变化的能力，敏捷物流系统应具有重用性、扩展性和对异构平台的支持。
3.敏捷物流客户关系管理
敏捷不只是速度快，而是对时间窗口内的顾客需求的一种响应能力，核心是对顾客需求的快速反应。在敏捷物流企业的管理模式中，客户关系管理成为其核心内容。因此，实现对现有客户的有效关系管理将为物流企业带来更多的利益，同时也会带来成本的降低。有效客户响应（ECR）是一种有效的顾客关系管理模式，其核心是找到对物流企业“有效”的客户，并对他们进行管理。在敏捷物流企业运作模式下，企业的资源始终是有限的，它不可能为所有的客户提供敏捷化服务。因此，每一个企业必须找出最适合自己的客户，有意识地放弃那些耗资大，给企业带来微薄利润的客户。企业可以通过快速引进、快速分类、快速促销、快速补充等策略，在终端POS机与条形码技术，计算机辅助订货CAO，连续补充程序CRP，交接运输等信息技术支持下实行对有效的客户需求实行敏捷的反应。
4.敏捷物流供应链管理
当今的物流市场以比以往任何时候都表现出更高水平的不稳定性，物流市场被分成一个个较小的部分，且客户的需求也朝着个性化的方向发展。捕获用户或消费者需求信息使其尽量接近销售点或使用点应是供应管理的一个主要目的，也是敏捷物流要实现的首要目的。在敏捷物流企业运作模式中，更加强调的是企业之间的供应链与协同商务合作关系，它关注的是物流系统整体价值与协同商务系统融合成为统一的供应链管理系统。因此，在敏捷物流企业运作管理中应采用集成的供应链管理模式。而集成供应链的一个基本的主导因素是基于企业拥有“敏捷性”是对市场做出快速反应的一个主要的前提条件的认识。
5.绩效管理机制
通过合理评价合作机制给合作各方带来的利益，在敏捷物流网络各方之间分享合作带来的共同利益，用定量化的指标使合作各方看到合作的好处和存在的问题，将能够进一步增加合作的动力，降低可能存在的利益冲突，最终实现敏捷化物流管理。
综上所述，敏捷物流企业可以满足了多变的市场环境下客户的动态物流需求，促进处于不同地理位置、具有不同核心技能及资源的物流服务商之间的分工协作、动态交互，进而提高物流服务的质量和效率。
作者单位：河南工业大学管理学院
参考文献
[1]Dove著，张申生编译.敏捷企业[M].北京：中国机械工程.2002.89-95.
[2]周宏.物流战略联盟的组建及运营管理[J].商业研究,2006,4:56-58.
[3]李静.新市场环境下敏捷物流管理模式探讨[J].物流技术,2006,3:22-24.
[4]龙跃.敏捷物流在电子商务中的应用研究[J].铁道运输与经济,2005,6:43-45.
Research on Establishment and Operation Model of
Agile Logistics Enterprises
Han Jiang
（College of Management, Henan University of Technology）
敏捷的项目管理范文6
关键词：敏捷测试；软件测试；测试执行
1 敏捷测试人员的定位
敏捷化开发近年来逐渐引起广泛关注，它是一种递增式的，持续迭代和不断调整的开发模式，它可以应对快速变化的需求。通过不断增量开发和持续集成我们逐渐建立起软件系统，可以看到系统的成长。敏捷测试是适应敏捷开发方法而采用的新的测试流程。在敏捷开发模式中，迭代周期短，需求变化快，敏捷测试总概括起来可以说是对原有功能的回归测试和对新功能的验收测试，根据系统的持续集成持续地对软件质量信息进行反馈。
敏捷中测试人员又叫QA（质量保证）。因此，从项目一开始就需要让全员达成一致：关注质量，随时构建质量，形成零缺陷文化。从用户角度出发关注用户使用，引导开发人员能够从用户的角度去思考、设计和实现软件，测试人员可以通过架构预演等方式，从整体上把握产品，及时提出架构上的问题，以及一些组件化开发的共享。测试人员需要对用户故事及时反馈，以便团队的及时改进以及持续改进，与开发紧密合作，形成技能互补，避免开发老是测试不出问题现象，以及测试不充分的情况。
2 敏捷测试的各个阶段
针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试，在敏捷团队中，测试是整个项目组的指向，它告诉大家现在到哪了，正在往哪个方向走，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标，共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行，并且，敏捷测试人员参与到了更多的敏捷开发活动中，积极的影响了团队做出的决定和计划。
2.1 验证需求和设计
需求和设计具体来说一般包括：（1）由项目经理根据需求文档而编写的功能设计文档；（2）由开发人员根据功能文档而编写设计文档。作为测试人员，审核重点是检查文档对用户需求定义的完整性、严密性和功能设计的可测性。
在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始测试。
2.2 测试计划和测试用例
在敏捷开发的过程中由于是根据每个用户故事来估算时间的。开发人员将对本次迭代所需要的完成的用户故事进行评估。开发人员可以和客户直接沟通，来确定每个用户故事的优先级。测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文档中，功能设计文档是主要依据。测试的这两个文档也要被项目经理和开发人员审核。
为使开发人员能参与到测试用例的审阅中来并让开发人员迅速地了解测试的重点并给出相应的意见和建议，以保证测试用例的质量和可行性，确保测试工作的顺利进行，测试人员在出测试用例的同时，应出一份测试用例映射，其中注明测试用例已覆盖了哪些产品功能，具体每个产品功能对应的测试用例编号，这样在对测试用例进行审阅的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足的地方能够及时给出意见。
2.3 测试执行
在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本给客户之前必须由测试人员进行测试，版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个完成。
为方便衡量项目的进度，测试可每天测试完毕后提供测试的Bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。
在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug，比如从客户报告来的，没有被现有测试用例所覆盖。当产品的功能设计出现更改时，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。
为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期Bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发每天做一个Build，或者按照完成一个功能特性就进行一次Build，针对这个功能特性进行测试，这样就可以有效避免后期Bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。在每次版本之前，测试人员要根据待的版本情况编写版本说明，使客户对的版本情况一目了然。版本说明主要包括三方面的内容：已经修复的上个版本中存在的Bug，新的功能，此版本尚存在哪些比较大的问题。
在每日立会上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的Bug，让开发人员了解当天测试的重点是什么，并提出自己的意见和建议。这样加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。
2.4 需求管理
采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步，方便后期的管理和维护工作。
