2019-08-27 00:50:57 seagal890 阅读数 68
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10421 人正在学习 去看看 CSDN讲师

[敏捷开发实践] 敏捷开发的误区

误区之一:人人都有机会,为项目招聘新人组建新团队,采用Scrum过程模型开发

误区之二:敏捷开发不需要写文档

误区之三:敏捷了要拥抱变化,PO(Product Owner)可以随时提出需求变更

误区之四:敏捷了一定要引入自动化测试,否则没有“高大上”的感觉

误区之五:敏捷开发一定可以加快系统/产品发布

误区之六:敏捷开发倡导“个体和交互胜过过程和工具”,过程和工具没有那么重要了

 

(更新中)

 

2016-08-29 15:22:41 myhead756 阅读数 5441
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10421 人正在学习 去看看 CSDN讲师

最适合App的开发模式——敏捷开发

 

传统的软件开发模式需要经历问题评估、计划解决方案、设计系统架构、开发代码、测试、部署和使用系统、维护解决方案等过程,如下图




采用传统软件开发模式的最大问题是开发周期过长,迭代速度慢。移动互联网行业发展速度快,需求不断变化,产品更新迭代的频率高,基于移动互联网的以上特点,就引入了Scrum这个敏捷开发框架。

 

Scrum简介:Scrum是一个敏捷开发框架,是一个增量的,迭代的开发过程。在这个框架中,整个开发周期包括若干个小的迭代周期,每个小的迭代周期成为一个Sprint,每个Sprint的周期建议为2~4周。在Scrum中,使用产品Backlog来管理产品或项目的需求,产品Backlog是一个按照商业价值排序的需求列表。在每个迭代过程中开发团队从产品Backlog挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint会议上的分析、讨论和估算得到一个Sprint的任务列表,称为Sprint Backlog

 

Scrum的流程如下图↓

 

Sprint 计划会议

Sprint计划会议前,产品经理所要实现的产品需求(产品Backlog)以用户故事(即从用户的角度去描述用户所需的功能)的形式确定下来,并画出原型图,UI根据原型图完成设计稿。产品经理同时确定各个产品需求的优先级。

Sprint计划会议期间(一般为2天),开发团队的成员不应该做任何开发工作,要将全部精力放在把产品需求分解成一个个开发任务,并估算开发时间。

估算开发时间需要注意以下几点。

1、对于所需要使用的新技术,要估算学习和调研的时间。

2、根据统计,每个程序员每天的有效工作时间是5个 小时左右,其他时间都被沟通、喝水、休息、上洗手间等琐事占据,如果某个任务估算超过5个小时,那就代表了这个任务完成需要超过一天的时间。

3、开发人员对于开发任务的估算尽可能精细,一般来说,每个任务的估算时间不应该超过5个小时,如果超过5个小时,就应该把这个任务再细分为多个更小的任务。只要尽可能精细地估算任务,总体估算时间是大概精确的,因为有的任务估算的时间比实际完成的多,有的比实际完成的少。

最后根据产品经理的优先级和开发人员的估算时间,确定这个迭代周期最终的开发任务和其对应的优先级,即完成Sprint Backlog

 

日常开发

 

App开发中,App通过APIApp后台交互,后台人员可以先设计好相关的API并让API返回假数据。

开发过程中遇到任何问题,必须及时找相关人员沟通。为了保证沟通的效果,可以采用下面的方法。

1、如果不是非常紧急的问题,可以等相关人员休息的时候再沟通。

2、解决一个问题,先梳理好情绪,沟通的时候对事不对人。

Scrum中有个关键的职位“Scrum master”,Scrum master一般有技术总监担任,团队和外部的沟通必须统一通过Scrum masterScrum master的最大作用是屏蔽外部对开发团队的影响,使开发的进度和开发的效率得到保证。

在开发的过程中需要注意:一个Sprint Backlog中,需求不能变更,UI确定后原则上只能做小修改。产品有新需求,下一个Sprint Backlog再考虑。

 

每日例会

 

每日例会前,团队成员应该整理各自的任务列表,包括:

1、昨天完成了哪些任务,每个任务使用了多少时间,没完成的任务估算还要多少时间。

2、剩余的开发时间

例会中产品经理和开发团队的成员都要参加,如果可以的话,让运营人员和市场人员也参与进来,这样可以使团队每个成员都对公司的产品有个整体的了解。

每个人在例会上报告一下3方面的事情。

1、昨天做了哪些工作?

2、今天准备做哪些工作?

3、有什么工作需要其他同事配合?

注意避免在会议上讨论问题,如果真的需要讨论,请在会议后和同事讨论,不要浪费整个团队的时间。

 

测试和修复BUG

 

产品开发完成就进入测试和修复BUG的阶段。

测试人员把测试得到的问题提交到BUG管理软件,每个BUG应该包含3个部分。

1、问题描述和重新步骤

2、测试人员

3、负责解决这个问题的人员,如果测试人员不知道具体负责人,把这个问题提交给技术总监,由技术总监指定解决问题的研发人员。

 

评审会议

 

在测试和修复BUG完成后全体人员开评审会议。相关开发人员在评审会议中向全体人员演示APP的功能。

 

回顾会议

 

研发完成后开回顾会议,每个成员都在会议中提两点。

1、这轮迭代过程中做得好的地方。

2、这轮迭代过程中做得不好的地方。

这个过程走两轮,即每个成员都要提两点做得好和不好的地方。注意当一个成员提出自己的意见时,其他成员不做任何的评论。

 

及时反馈

 

可以通过建立相关QQ群收集意见,在APP中可以增加一个意见反馈的功能。

 

总结

 

敏捷开发不是万能的,敏捷开发更适用于需求多变,开发周期端的项目。


2019-01-22 19:56:09 KamRoseLee 阅读数 221
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10421 人正在学习 去看看 CSDN讲师

软件开发遇到重要问题:

  • 学习  是软件开发中一大瓶颈
  • 如何让成员积极主动,负有责任感,能解决问题,并凝聚成一支高效的团队?

敏捷开发历史:

  • 敏捷开发并不现代   起源于20世纪30年代的一些项目(美国航天局水星计划)
  • 最早记载使用在20世纪70年代  最早的有记载的使用迭代和增量开发的主要项目之一,是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码,进行得非常成功。
  • 1976年,第一部阐述敏捷方法的书籍    Tom Gilb在他的著作《软件度量》(“Software Metrics”)一书中阐述了他的迭代和增量开发实践
  • 20世纪80年代正式定义迭代开发螺旋模型  20世纪80年代在1895年,巴里贝母(Barry Boehm)正式定义了使用迭代开发的螺旋模型
  • 20世纪90年代推荐使用迭代和增量开发的出版物和文献显著增加
  • 2001年二月敏捷开发宣言后形成敏捷联盟  一组由17位在DSDM,XP,Scrum,FSD等领域的专家组成的代表团齐聚美国犹他州,寻找这些方法的共同点。最终,这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所认识的敏捷开发和后来的敏捷联盟

敏捷开发介绍:

敏捷开发(agile development)

     是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,

但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发由几种轻量级的软件开发方法组成

   它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等

敏捷开发原则和方法

1)迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

 

  1. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
  2. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。
  3. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成, 有些项目则每天都在这么做。

5)开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

敏捷开发实践都基于一个简单的周期

  1. 测试先行开发1)写一个失败的测试2)编写代码让测试通过3)运行测试---通过了吗?4)如果测试仍然失败,回到步骤2
  2. 日常工作流程1)在每日的站立会议中,设置团队需要完成的任务2)执行这些任务3)第二条对任务的执行情况和遇到问题进行沟通4)总结经验教训,调整第二天的工作计划
  3. 测试驱动需求1)将需求转变为测试 2)进行软件开发 3)运行这些测试,如果测试通过,任务完成,如果没有回到2
  4. 迭代 1)设定一个 完成状态 2)找到一系列需求,构成迭代待办事项,并承诺完成3)一一解决待办事项4)迭代结束,一一检查每个事项是否达到,“完成状态”,如果是,标记完成,否则将他们放回待办事项中,以待日后处理。
  5. 演示 通常在迭代末进行演示,客户可以利用这个机会,验证针对预期需求的实现是否真正地解决了当前的问题 1)确定需求的业务价值  2)定义需求 3)实现需求 4)验证实现的功能是否满足业务需要
  6. 回顾1)确定团队的工作方法 2)在迭代中应用这方法 3)反思总结实践过程中的好坏方面 4)找到一些更加有效的方法,确定什么时间,谁负责实行
  7. 版本发布 1)创建该版本的远景,并设定需要达到的业务目标2)创建该版本的待办事项3)通过多次迭代来发布该版本4)为部署,并为下一个版本收集反馈信息
  8. Scrums的Scrum会议  会议来进行信息同步,通过沟通和讨论来展示自己的进度和解决遇到的问题,这能提高大家感知整个企业的变化,从而积极应变
  9. 管理检验 1)与那些产品所有者或者项目负责人一起,定义项目或者是某个版本的验收标准 2)在团队开发过程中,保证这些验收标准随时可见,使项目始终朝着期望的方向发展3)回忆会议中,一起评估标准4)让产品所有者或项目负责人和团队一起工作,保证在每一个迭代中针对这些验收标准进行检验

几种敏捷实践:

  1. 自组织团队  整个团队紧密合作,同心协力,主动承担责任,竭尽所能去完成工作,响应各种变化
  2. “联合驻扎”团队  团队成员在一起工作,经常进行小组讨论,随时可以听到各种谈话,潜移默化中就了解到发生的事情
  3. 跨职能团队  来自不同背景的人组成一个团队,自始至终地进行开发来解决一个问题。因为大家在一起紧密协作,各自的专长就会得到分享和传播
  4. 结对编程   两个人一起,齐心协力完成一些任务,这个是共享经验和专长的极致体现
  5. 信息辐射器  这种大幅图表存在的唯一目的就是把重要的信息传达给每一个人
  6. 唤醒式文档  为了更好的沟通,敏捷团队成员共同撰写文档,日后每次阅读这些文档,都可以唤起大家对讨论内容和相关背景的记忆。
  7. 站立会议 在敏捷团队中,大家每天都会彼此交流自己完成什么,遇到了什么问题,明天计划如何,这就保证了所以成员步调协调一致

敏捷实践的主要动力来源:

主要动力来源:带给客户价值

  1. 缩短上市时间
  2. 增加产品使用行(市场价值)
  3. 提高产品质量
  4. 提高灵活性
  5. 增强透明度
  6. 降低成本
  7. 延迟产品生命周期
2010-07-20 15:36:00 alvanchen 阅读数 113219
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10421 人正在学习 去看看 CSDN讲师

Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。

敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值,但是我们认为左项具有更大的价值。

以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
Iteration
迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
IterationPlanningMeeting
迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
Story Card/Story Wall/Feature List
在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
Standup Meeting
站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
Pair Programming
结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
Retrospect
总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
ShowCase
演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
Refactoring
重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
TDD
测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

敏捷方法反思:
自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

2019-01-04 16:15:59 weixin_43918437 阅读数 293
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10421 人正在学习 去看看 CSDN讲师

一、什么是敏捷开发?

敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

二、敏捷开发的特点

敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能模块。正如敏捷宣言所提到的那样。

敏捷宣言强调的敏捷软件开发的四大宣言是: 
1.个体与交互高于流程和工具 
2·工作软件高于理解文档 
3·客户协作高于合同协商 
4·变化响应高于计划遵循 

结合软件研发实际,四大宣言可以这样理解:

个体与交互胜过过程与工具

       方法和工具是死的,人是活的,如何没有优秀个人和团队协作,再强大的方法和工具都是摆设。一个使用普通工具的优秀人员会比使用优秀工具的普通人员做得更好,一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷中每个成员都需要定时和团队的其他成员一起查看团队的整体进度,计划下一步工作,并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力,可以自发的通过各种途径解决开发过程中遇到的问题。

       虽然我们致力于个体和交互,但并不代表就不需要过程与工具了。Scrum、XP等方法本身也有一些方法和过程,每日构造等敏捷实践也需要工具的支持,需要哪些过程和工具由自组织团队制定,而不是由领导制定。

工作软件高于理解文档 

       在合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档,支付多少金额等内容,而这些文档对用户来说是不是真的有价值呢?冗长文档对客户来说并不重要,其重要程度比不上一个可以工作的软件。冗长的文档对开发也不重要,没有人有时间去读,而且也不符合敏捷开发的特性,对研发团队来说最好的文档就是代码和团队,通过频繁的提供可以工作的软件,不断地搜集市场反馈,保证软件的市场时效性。

       虽然我们致力于提供可供做的软件,但并不是不要文档。我们在开发过程中仍然需要进行内部交流, 也需要和客户交流,我们仍旧可能需要制作原型,书写一些主要需求和算法,只要可以满足研发团队需求就行。

客户协作高于合同协商 

       寻求客户合作的价值重于对合同的谈判。软件开发的最终目标是提供给客户满意的软件,而只有客户才更清楚怎么样才能满意,敏捷开发提倡客户和开发团队密切的在一起工作,经常性的根据市场需求对软件提供反馈。各种不同的敏捷方法都会利用短期迭代,通过尽早提供软件来达到与客户频繁沟通和反馈的,这也可以把问题及早暴露出来,以免隐藏的问题在后期造成更大的影响。

       虽然我们致力于客户协作,但为了双方利益和需要仍旧需要进行合同谈判。

变化响应高于计划遵循  

       敏捷项目承认开发过程中的不确定性,所以不会在开发中制定长时间的复杂计划,它们的成功都是建立在现实反馈的基础上的。每次迭代都是基于上一迭代的完善基础之上进行的,通过不断的响应变化来消除开发中的不确定性。

       在敏捷开发时,我们不应该为了让自己的项目看起来像是按照计划好的样子循序渐进,而花费大量的时间让研发团队去附和计划。相反,敏捷需要的不是计划,而是规划。

       敏捷开发方法是“规划-执行-调整”、“规划-执行-调整”。一个项目的不确定性越高,敏捷开发方法对取得成功就越是至关重要,不断学习和调整是敏捷开发的核心。

       像3355中5会那样,计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。阶段性的召开会议,提出当前阶段的问题,根据昨天完成的情况来做出新的调整,根据上一个迭代对新的迭代功能等进行规划。在sprint评审会上,团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理,可以让团队有机会去回顾和识别版本发布的风险。

敏捷开发的12条原则包括: 
1.通过早期和连续型的高价值工作交付满足“客户”。 
2.大工作分成可以迅速完成的较小组成部门。 
3.识别最好的工作是从自我组织的团队中出现的, 
4.为积极员工提供他们需要的环境和支持,并相信他们可以完成工作。 
5.创建可以改善可持续工作的流程。 
6.维持完整工作的不变的步调。 
7.欢迎改变的需求,即时是在项目后期。 
8.在项目期间每天与项目团队和业务所有者开会。 
9.在定期修正期,让团队反映如何能高效,然后进行相应地行为调整。 
10.通过完成的工作量计量工作进度。 
11.不断地追求完善。 
12.利用调整获得竞争优势。

大致来讲,12宣言的核心内容就是将一个软件分成多个迭代去完成,在每个迭代开发时,坚持以人为本的原则,在研发过程中坚持人比工具更重要。在研发中坚持完善工作,拥抱市场拥抱变化,根据市场来调整软件的功能。快速变化,高效的做出响应。不断地调整软件,保持市场时效性。

       

       

 

敏捷开发

阅读数 2946

敏捷开发简介

阅读数 5081

没有更多推荐了,返回首页