敏捷开发(XP, SCRUM)-阿里云开发者社区

开发者社区> 开发与运维> 正文

敏捷开发(XP, SCRUM)

简介: 敏捷方法的核心思想 敏捷方法是适应型(Adaptive),而非可预测型(Predictive)。与传统方法不同,敏捷方法拥抱变化,利用变化来发展,甚至改变自己,最后完善自己。也就是要用重构(Refactoring)  敏捷方法是以人为本(people-oriented),而非过程为本(process-oriented)。传统方法把开发者看作一个生产要素(分析员,测试员,程序员)

敏捷方法的核心思想

  • 敏捷方法是适应型(Adaptive),而非可预测型(Predictive)。与传统方法不同,敏捷方法拥抱变化,利用变化来发展,甚至改变自己,最后完善自己。也就是要用重构(Refactoring)

  •  敏捷方法是以人为本(people-oriented),而非过程为本(process-oriented)。传统方法把开发者看作一个生产要素(分析员,测试员,程序员),拥有大量的中间产品(需求规约,设计模型等),而忽视了作为决定因素的人的特殊性。敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

  • 迭代增量式的开发过程。敏捷方法以原型开发思想为基础。迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

关于Scrum和XP(Extreme Programming)

前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的.


XP的12条实践规则

XP是偏重于实践的,这些实践中有些已大量运用于现代软件开发中。无论你的开发过程是SCRUM还是CMMI,CMMI?是的,这些优秀的软件工程实践并不是敏捷的专享,即使你的开发过程是CMMI,也不影响你使用这些实践。例如TDD,CI(Continues Integration),Agile 和 CMMI 并不是水火不容的对立关系,而是在某种程度上可以有机的结合。

XP的核心价值观是沟通、简单、反馈和勇气。

12条实践规则:

     细粒度反馈(Fine Scale Feedback)
  • 1. 结对编程(Pair Programming),即任何代码都有两个人合作完成,一个人coding,一个人review code然后提供反馈。现实中一般不会采用此实践,一种替代方式是定期开code review meeting。
  • 2. 规划工作(Planning Game),每个迭代周期开一次计划会议,对此工作周期进行回顾和总结,以及对下个迭代(通常2星期)的开发和发布进行规划。
  • 3.测试驱动(Test Driver Development),程序员在实现功能前应该写好单元测试代码,因为功能代码还没有实现,运行测试的结果可想而知,肯定会失败,程序员的工作就是恰当的代码能使此测试用例通过。这个功能实现的过程也是循序渐进、迭代的,每次实现功能的一小部分,然后运行测试,这样在出现问题时,我们可以很快的定位到问题所在,并很快的解决问题。因为如果你和我一样不是足够聪明的人,我们大脑通常只能记住刚刚发生此的事情。概念同样适用于CI里,对每次Checkin的Regression Test,因为如果你的Checkin造成了对现有功能的破坏,因为问题时你刚刚修改代码造成的,你也能比较容易的定位问题,修复它。
  • 4.完整团队(Whole Team),有时也叫客户现场,即客户并不是需求分析后,就万事大吉了,应该驻扎在开发现场,这样开发团队可以获取最新,最准确的客服反馈,确保开发没有偏离客户需求。
     可持续发展(Continues Process)
  • 5.可持续集成(Continues Integration),项目应该有一套自动编译,自动化测试,自动部署的工具(hudson),程序员应该在最新的代码版本上工作,对于多人并行开发,应该及时的checkin你对代码修改,并保证编译、测试通过。若有问题可以尽早的被暴露,修复。对于减少bug,降低软件风险都有积极作用。
  • 6.代码重构(Refactoring),软件随着需求的变化和技术的革新是不断演化的,容易产生代码堆砌,代码冗余等代码中的“坏味道”,用代码重构技术的代码进行及时的清理、调整、重组。有助于提高软件质量和可维护性。
  • 7.小版本发布(Small Release),怎样吃掉大象?将一个大的问题域分解成小的,可操作的问题,是解决复杂问题的自然之道。将软件需求分解成小的功能模块,在每个迭代周期中完成预定的部分模块,并形成一个可发布的版本,在Demo此版本时,可以快速都获得来自stakeholders的反馈,而不用将风险延迟到项目的最后。
  • 8. 40小时工作制(Sustainable Pace),可持续发展,不要加班,该打篮球打球。
    共识(Shared Understanding)
  • 9.代码规范(Coding Standard),统一的代码风格和格式
  • 10.集体所有制(Collective Code Ownership), 每个人对所有代码负责
  • 11.简单设计(Simple Design),简单是王道,不要over-design
  • 12.系统隐喻(System metaphor),系统隐喻是每个人(客户,程序员,经理)都能理解系统是如何工作的,涉及到如何对Class/Method进行命名,使得团队成员仅从名称上就能想到起功能,例如一个产品过期,那么在Catalog(Class)上有makeOverdue的Method。


如何运用Scrum作为开发过程: http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章