2012-06-25 18:21:54 iteye_14109 阅读数 319
  • SCRUM敏捷开发视频教程

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

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

     软件开发方法一直处在不断发展过程中。在诸多方法中,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升势头明显。那么,敏捷开发有什么好处呢?

 

    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然,其最大的推动力是采用这种方法所能带来的受益。相关统计表明,敏捷开发可以将效率提高3~10倍,软件的质量也有更加可靠的保证; 同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然,敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。
 
    敏捷开发由几种轻量级的软件开发方法组成,包括极限编程、Scrum、精益开发(Lean Development)、动态系统开发方法、特征驱动开发(Feature Driver Development)、水晶开发(Cristal Clear)等等。所有这些方法都具有以下共同特征,它们也是敏捷开发的原则:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期持续的时间一般较短,通常为1到6周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。有些是在每个迭代周期结束的时候集成, 有些则每天都在这么做。

    5. 开发团队自我管理。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。
 
    敏捷开发的优势:

    满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。
 
    敏捷开发方式能给企业和用户带来以下好处:

    1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

    2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

    3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

    4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

    5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
 
    主要的敏捷方法:

    敏捷开发方法是一组开发方法的统称,主要包括以下几种:

    极限编程其主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致,结对编程(pair-programming)就是其中比较知名的方法之一。除此之外, 其核心做法还有小规模、频繁的版本发布、短迭代周期、测试驱动开发、持续集成、每日站立会议、共同拥有代码、系统隐喻等。

    Scrum Scrum是一个敏捷开发框架,它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中,产品需求被定义为产品需求积压(product backlogs)。所有的产品需求积压都是从一个简单的想法开始,并逐步被细化,直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期,每个Sprint代表一个2~4周的开发周期,有固定的时间长度。

    精益开发精益开发的核心思想是查明和消除浪费。在软件开发过程中bug、没用的功能、等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明,然后设法消除。精益开发的其他原则包括强调学习、在最后时刻做决定、用最快的速度交付用户等。

    其他敏捷方法还包括动态系统开发方法(DSDM)、特征驱动开发(FDD)、Crystal Clear等,各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷开发,并且了解更多的最佳应用。
 
 
如何选择一种敏捷方法:

    选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:

    1. 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

    2. 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。

    3. 实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。

    4. 对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

    5. 你的团队规模。较小规模的团队最好从简单的方式入手。

    6. 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。

 

2019-09-11 23:44:18 fox_bert 阅读数 16
  • SCRUM敏捷开发视频教程

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

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

此文章为个人培训理解总结,如有错误望及时指出,谢谢

一、敏捷开发是什么

敏捷开发是一种管理模式或者说是管理者对员工的开发模式制定一种开发规则,从而使用敏捷的方式将产品开发出来。

不是所有项目都适合敏捷开发,敏捷开发适合需求会不断产生变化的项目

敏捷开发分为多种

团队性敏捷

项目性敏捷

fas(集团性敏捷)

敏捷开发与传统开发的区别

传统:指令试管理【leader向团队人员分配任务】

敏捷:团队自我管理【leader发布所有任务,团队人员根据自己的兴趣选择任务,提高主动性】

scrum(迭代计划会议)/xp【Extreme Programming(极限编程)】

 

二、敏捷的价值观


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

可以工作的软件 胜过  面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

 

三、怎样实现敏捷

 

难点:敏捷开发的难点在于敏捷开发的转型过程

1.有效沟通【包含与客户的沟通和团队成员的沟通(目的:明确真实的业务,避免开发与需求发生偏差)】

 

团队自我管理【leader发布所有任务,团队人员根据自己的兴趣选择任务,提高主动性】

怎样实团队自我管理

使团队所有人价值观一致【我的理解利益一致】

 


是否要制定计划,应该怎样制定计划

项目中一个详细的计划,在开发中会经常会出现改变。

因此没有必要耗费大量时间做,一份会不断改变的计划。【客户永远不知道自己想要什么,客户只会在开发过程中,才会知道自己想要什么(用户的需求是靠不断挖掘和引导的,不要替客户做决定)】

那么还需要计划吗?当然需要,需要制定一个有效的计划,周期迭代性的计划

 

敏捷开发核心:迭代开发

敏捷迭代周期为两周

分析两周内的计划需求,一个周期完后,再更改过研究下一个周期【在周期内不要进行对业务的改变(最好和客户协议此规定)】

敏捷是‘小模块’的,要有规定时间约束,不要出现普遍性延期的现象【用时间压力,抵抗人性】

 


不要过度设计
减少圈复杂度,嵌套太多(嵌套层不要超过三个)
引入新技术时结队编程效率最高





单元测试用例:能被测试的就说明代码结构没有问题,可以扩展,可以重构,是相对解偶的
单元测试用例(jtest)

 

2013-05-21 23:24:47 jfkidear 阅读数 3077
  • SCRUM敏捷开发视频教程

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

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

哪种项目最适合敏捷开发?

 (2011-07-29 15:47:18)
标签: 

敏捷开发

 

agile

 

scrum

 

适合程度

 

it

分类: IT翻译

        译者:高小皋   作者:迈克科恩

最近有人问我,哪种项目最适合敏捷开发。我将在本文给出答案。在我看来,那些期限紧迫、具有高度复杂性和新颖性的项目最适合敏捷开发。

当我们开发一个新项目、起码对开发团队而言是个新项目的时候,我们愿意采用敏捷开发。如果之前团队已屡次开发过此类项目,那么基本不会采用敏捷开发的方式。我认为,这跟某些制造业很类似。比如我们生产轿车,日复一日,自然就会非常迅速地掌握所有生产轿车的奥妙之处。这种情况下,对创新的要求很低,就用不着敏捷开发。

单有对创新的要求,并不意味着就要采用敏捷开发。今天,我去了自己最爱的中餐馆吃午饭,点了一个“超级辣味胡椒”开胃菜。很可能是饭店首次用这种方式烧这道特色菜,具有一定的创新性或者说独特性。厨师虽然做了充分的准备,但因为我能看到厨房里面,我确信他们不需要每日即时讨论甚至是TDD(技术资料文摘)来准备我的午餐。(也许我应该注意到那里有个看板。)因此除了有新颖性的要求,项目还需要有一定的复杂程度。 

    适合敏捷开发的项目,其最后一个必要因素我认为是紧迫性。敏捷开发的时间限制和迭代性用来确保对项目的集中强度。如果项目不紧急,就用不着时间限制和迭代性。

那么我们先了解一下这三个因素——紧迫性、复杂性和新颖性——是如何交织在各种项目中的。当然是先以软件项目为例,没有其他更合适的了。软件项目的复杂性众所周知。每个软件项目基本上都是一次新的冒险。而且,在当今世界常常有一种紧迫感。

让我们再看看另外一种通常会用到Scrum(专业术语)的情况:结婚。我在一年内起码有两三次听到有情侣用Scrum敏捷开发策划了婚礼。婚礼前总是会积压一大堆事情——买蛋糕、接摄影师、发邀请函、拿礼服,等等。策划婚礼跟我所提议的三个因素是如何关联的呢,紧迫感?对,婚礼一般会有个最后期限,而且通常是确定好的日期。复杂性?嗯,虽然它没有软件项目那么复杂,但也因为一些非功能性要求而提高了其复杂程度。比如,它有固定的预算、坐席的安排、供餐的类型、让Cousin Ira乐队在接待会表演,等等。要别出心裁、有所创新?当然。大多数人应该不会结很多次婚、每次又都大张旗鼓地举办婚礼吧!婚礼当然不能与他人雷同了。

因此,敏捷开发最适合复杂程度高、要求新颖的紧急项目,包括软件开发和婚礼的策划。它确实会碰到这样的问题,比如结婚新人是否要在庆典结束时以初吻作为压轴戏,或者作为整个项目的部分评价标准。

2016-11-03 17:37:57 buding_pmp 阅读数 4088
  • SCRUM敏捷开发视频教程

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

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

[摘要]  
敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。以下分享产品项目里的九个敏捷开发实战经验。

  敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。
  在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者最后也提到过,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
  其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。
  对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。
  并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。
  运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。
  对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。
  但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:
  一、敏捷开发最少需要维护哪些文档?
  软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。
  实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。
  但文档宜少且精炼,一般情况下建议维护三份文档:
  《产品需求规格说明书》
  也即PRD:定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;
  《系统设计说明书》
  开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;
  《测试用例和测试报告》
  由测试人员编写:记录所有功能点的测试计划、过程和测试结果;
  二、敏捷开发是否需要系统设计?
  前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。
  小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。
  因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。
  传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。
  三、敏捷开发是否需要项目计划?
  敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。
  它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。
  但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;
  四、敏捷开发的迭代周期大概多长?
  敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。
产品项目里的九个敏捷开发实战经验
  对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;
  五、敏捷开发为何提倡小版本?小版本有哪些优势?
  小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:
  1、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;
  2、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;
  3、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;
  六、敏捷开发与重构的关系如何?
  敏捷开发以重构为基础,时时刻刻处于重构过程中;
  七、敏捷开发为何强调团队人员的参与、用户的参与?
  敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。
  由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。
产品项目里的九个敏捷开发实战经验
  用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:
  “是的,就是这样的”
  “这正是我想要的……”
  “这里需要修改一下……”
  “我的想法是这样的……”
  这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!
  八、怎么才能评估团队是否已经敏捷了?
  由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:
  • 团队有共同的愿景,并且对这个愿景充满信心;
  • 团队有明确的阶段目标并且为每个成员所知晓;
  • 团队知晓当前计划:做什么、何时完成、预期效果等;
  • 团队任务是低耦合的,并且紧密协作;
  发布过程是轻松愉快的,构建版本并不断测试是常态行为之一。
  九、敏捷开发能缩短项目时间并提高质量吗?
  从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:
  • 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;
  • 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;
  • 过程目标导向,使团队高度集中于项目目标,提高了生产力;
  • 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;
  以上是一些敏捷开发过程当中的疑问,其实还有很多,目前我这边还只是主推让开发和测试团队敏捷,PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计,去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起,这样才能最大限度的发挥敏捷的效用

2015-06-12 16:35:55 leangoo_cooperation 阅读数 373
  • SCRUM敏捷开发视频教程

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

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

敏捷开发流程及敏捷工具

敏捷开发,要求在开发过程中不断增强,从而提高软件质量,以达到提高商业收入的目的。它是一个迭代的过程,一个不断提高企业投资回报率和服务质量的过程。值得注意的是,成功的敏捷开发,单纯依附于活跃的开发过程和理解敏捷所带来的效益并对此有浓厚兴趣的企业用户。本文将介绍敏捷开发的五大过程及这些过程中所要用到的工具。

敏捷计划

典型的敏捷开发将整体工作分为一系列的发布过程,每个发布过程都是一个迭代循环,每个迭代循环都会发布一组功能特性。

敏捷计划规定了每个循环中所需要完成的工作(发布/迭代)。在该阶段,产品所有者将描述每个循环过程中他希望看到的产品样子。

敏捷计划包含发布计划与迭代计划,两者的内容及执行者不同。

发布计划:包含每次发布的功能组。产品所有者负责在产品发布之前制定发布计划。

迭代计划:开发团队需要在开发工作及迭代开始前确定需要完成的工作。可以通过每天的站立会议来实现。

工具:制定敏捷计划,有很多工具可以使用,如:

创建用户故事

用户故事,是对功能、特性的简单描述。每个特性也可能由很多故事组成。用户故事要简单且容易理解,能在几分钟内通过几行字表述清楚。请注意,用户故事是由项目所有者或主要用户群体来定义的,而非开发者。

正如Mike Cohnrn所建议的,用户故事应该遵循下面的格式:

作为一个(某种角色),我需要(某事)如此如此。

例如,作为一个用户,我希望通过姓名来查找我的客户。

工具:最好的方法是使用索引卡片来记录各个故事。有很多种工具可以帮助完成故事图谱与故事追踪,如

  • SilverStories
  • Pivotaltracker

注意:故事并不是一次性完成的,它循环往复,且贯穿于整个项目开发周期中。

评估你的工作

在敏捷中,评估用于预测功能实现的复杂程度,并根据以前完成相似复杂度功能的经验预估所需要的完成时间。它是一个持续的过程,基于之前的经验和模式学习,不断提高评估的准确性。

通常,评估故事的复杂程度多基于故事要点,而非所耗费的时间。要点解释了故事的复杂性,并通过数据1,2,3……来体现。

评估有助于做出更好的商业决策,定义发布/迭代的范围。例如,我们可以很容易地为每次迭代/发布中的所有故事分配同样的数字。

工具: Planning Poker(估算扑克,scrum中文网微信就有,Scrum_CN,关注即可使用)是定义和改善你评估的最好技术。

站立会议

站立会议是开发团队每天进行的简短会议。会上每个人需要说明昨天所完成的事,及今天的计划和被分配任务现在的状态。商业用户和领域专家偶尔也会参加,这将给他们更多关于项目的信息。

它不是例行会议,仅仅对项目实施情况给出粗略的描述,而是要提供更多关于项目的可视性内容,增强团队间的协作,对当天的计划给出正确指导。

工具:在站立会议中,白板是非常有效的工具,比如Leangoo。

项目监控技术

速率:

通过速率,可以精确地测量开发团队发布商业价值的速度。速率是对生产力的测量。通过计算一定间隔内完成工作的单元数来计算速率。

在每次迭代的最后,为了计算速率,敏捷团队会查看该过程所完成的工作要求,并累加与这些要求相关联的故事点。所完成故事点的总数便是团队的速率。首次小小的迭代之后,你会逐渐发现某种趋势,且能计算出平均速率。

下面一些工具可以帮助追踪速率。

  • TargetProcess
  • Pivotaltracker
  • Timetracking
  • VersionOne

Burndown Reports:

Burndown Report是追踪项目进度的另一个标尺。它用来追踪完成故事点的个数,监控简单的迭代、发布和整个项目积压的工作。它可以显示进度,反映产品交付的价值和团队的速率。

以下一些工具可用于测量Burndown Reports:

  • TargetProcess
  • XPlanner
  • Pivotal Tracker
  • ScrumWorks

来源:Infoq

英文原文:http://techmytalk.com/2013/07/14/agile-software-development-process/

敏捷开发思想

阅读数 560

敏捷开发

阅读数 278

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