PMI-ACP敏捷项目管理中的极限编程( Extreme Programming,xP)是由肯特·贝克( Kent Beck)在199年提出的。肯特·贝克在20世纪90年代初期与沃德·库宁汉姆( Ward Cunningham)共事时就一直共同探索着新的软件开发方法,希望能使软件开发更加简单有效。肯特·贝克仔细地观察和分析了各种简化软件开发的前提条件、可能性以及面临的困难。1996年3月,肯特贝克终于在为 Daimler Chrysler所做的一个项目中引人了新的软件开发观念—XP。
XP适用于小团队开发
1、XP的核心价值
XP是敏捷方法中的一种软件开发方法。如果说Scm更加关注项目管理工作的话那么XP更加关注软件开发的良好实践。因此,作为敏捷宣言和原则,能想到在实践的背后XP的价值和理念还能用到非软件的项目工作中吗?
XP这种方法的核心价值是简单、沟通、反馈、勇气、尊重,这些价值体现在XP的整个生命周期中。
(1)简单。xP鼓励从最简单的解决方式入手,再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于,它只关注于对当前的需求来进行设计、编码而不去理会明天、下周或者下个月会出现的需求。XP的拥护者承认这样的考虑是有缺陷的,即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求投入精力”所得到的好处可以弥补这一点,因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码,意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看,设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易地被小组中的每个程序员所理解。
(2)沟通。构建一个软件系统的基本任务之一,就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中,这一任务是通过文档来完成的。XP技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角,而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标,XP支持设计、抽象,还有用户与程序员间交流的简单化,鼓励经常性的口头交流与反馈
(3)反馈。在XP中,“反馈”是和系统开发的很多不同方面相关联的。
1)来自系统的反馈。通过编写单元测试,程序员能够很直观地得到经过修改后系统的状态。
2)来自客户的反馈。功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划两三周进行一次,这样客户可以非常容易地了解掌控开发的进度
3)来自小组的反馈。当客户带着新需求来参加项目计划会议时,小组可以直接对实现新需求所需要的时间进行评估,然后反馈给客户。反馈是与“交流”“简单”这两条价值紧密联系的。为了沟通系统中的缺陷,可以通过编写单元测试,简单地证明某一段代码存在问题。来自系统的直接反馈信息将提醒开发人员注意这一部分。用户可以定义好的功能需求为依据,对系统进行周期性的测试。用Kent Beck的话来说:“编程中的乐观主义是危险的,而及时反馈则是解决它的方法。”
(4)勇气。XP理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码,不要考虑明天”这条戒律。这是为了努力避免陷入设计的泥潭而在其他问题上花费太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个开发人员都有这样的经历:花了一整天的时间纠缠于自己的设计和代码中的一个复杂的难题却无所得,而第二天回来以一个全新而清醒的角度来考虑,在半小时内就轻松解决了问题。
(5)尊重。尊重的价值体现在很多方面。在XP中,团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过,或者导致现有的测试用例失败,抑或者以其他方式导致工作延期。团队成员对于工作的尊重体现在他们总是坚持追求高质量,坚持通过重构的手段来为手头的工作找到最好的解决设计方案。XP的生命周期如图2-13所示,在XP中,轻量级的需求被叫作“用户故事”,它通常被用于发布和冲刺计划中。典型的冲刺通常会有2周时间,在这些冲刺期间开发人员会以结对编程的方式编写代码。所有开发了的软件都会进行严格和频繁的测试。然后,在获得客户的认可后,才会小规模的发布。
(XP生命周期图)
“架构探针”是在冲刺中用于证明的一种技术方法,“探针”的工作是减少风险。探针会在整个发布中使用到。
下一篇衔接内容 《XP极限编辑的核心实践方法》
广州慧翔企业管理咨询有限公司 专注,所以我们更专业!
优培东方官网 http://www.hxtdpx.com