2011-05-11 09:13:51 iteye_1359 阅读数 49
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13660 人正在学习 去看看 张传波
来自于软件开发领域的敏捷开发渐渐的向软件开发之外的领域传播。有金融界、法律界的朋友问我什么是敏捷,本文试图向非软件开发人员来介绍敏捷。

2001年美国17位资深的软件从业人员聚会,选择了Agile这个词作为统称,协商得到了如下的《敏捷软件开发宣言》。

我们致力于身体力行地揭示更好的软件开发方法,并推而广之。经过努力,我们已建立如下价值观:
个体及互动 胜过 流程及工具
可工作软件 胜过 详尽的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
它意味着,尽管右项也有价值,我们认为左项更有价值。

这个会议被称为“雪鸟会议”。
同时他们整理了如下的《敏捷宣言背后的原则》
我们遵循以下原则:
1我们通过尽早且持续地交付有价值的软件,以达到我们的最高目标:让客户满意。
2欢迎需求变化,即使在开发后期也一样。敏捷过程掌控变化,为的是客户的竞争优势。
3经常交付可工作的软件,相隔几星期到几个月,且倾向于使用较短周期。
4项目开发全过程,业务人员和开发人员必须每天都在一起工作。
5围绕积极的个体构建项目。提供所需的环境和支持,并且信赖他们以完成工作。
6在团队内部及团队之间传达信息,面对面交谈的效果最佳且效率最高。
7可工作的软件是最主要的进度度量标准。
8敏捷过程倡导可持续开发。责任人、开发者和用户应共同维持一个长期稳定的步调。
9持续地追求优越技术以及良好设计,以增强敏捷能力。
10简朴——最大化无需完成的工作量的艺术——是根本。
11最好的构架、需求和设计都出自于自组织的团队。
12团队定期反省如何提高成效,并相应地调整及修正其行为表现。

可以看出敏捷的起源是针对于软件开发的。敏捷各流派达成共识的文字就全在上面了。
实际上“敏捷软件开发方法”不是指某一种方法,而是符合以上宣言和原则要求的等等各种方法的统称。
特别值得一提的是XP极限编程是Agile中的一个重要流派,提出了5个基本价值观:沟通、简单,反馈、勇气、尊重

经过多年发展,在ThoughtWorks,IBM等厂商的推动下,业务敏捷也被提上了讲台,使得原只属于软件开发领域的敏捷走向非软件开发领域。

在我看来,对于非软件开发领域,最值得借鉴的首先是敏捷思想。试归纳如下:
1,以人为本,基于信任,相信团队成员是自觉的、主动的。作为管理者,需要采用仆人型管理方式,认为自组织的团队是最好的团队。
2,沟通无极限,各方坦诚,鼓励快速交流。鼓励团队任何成员独立、自由、平等的表达观点
3,拥抱变化,对变化的态度是欢迎的,重视反馈,根据变化快速调整。
4,重视客户价值,以客户带来价值为第一要务。
5,追求简单,缩短中间过程,减少中间产物。

其次值得借鉴的是敏捷的过程。敏捷过程的特点有:
1,短迭代,2周~8周,一般是4周,固定的节奏,明确的预期
2,针对每个迭代收集反馈
3,每个迭代末期进行团队集体反思,做好下个迭代. (对反思,敏捷提供了一些形式化的方法,这可供非软件开发参考的)
4,勇于尝试,在不完备的情况下就开始,不要求针对中间产物的正式讨论评审,追求快速的看到用户价值,或者让用户看到价值。
5,尽可能在过程的前期来识别缺陷和问题
2018-04-22 23:09:48 qq_21791645 阅读数 1248
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13660 人正在学习 去看看 张传波

一、定义:

1.迭代开发:在迭代开发中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代,这叫迭代开发。每一次迭代都包括了定义、需求分析、设计、实现与测试。

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

二、区别:

1.性质不同:迭代开发是软件开发的生命周期模型,是一种开发过程;敏捷开发是多种软件开发项目管理方法的集合,是一种开发方法。这是两者最根本的区别。

2.开发方法模型不同:迭代开发对应的是瀑布模型,螺旋模型等;敏捷开发对应的是Scrum,XP(极限编程),Crystal(水晶编程)等开发方法。

3.对需求要求不同:迭代式开发适合那些需求信息不明确的项目;而敏捷开发是紧紧围绕用户需求,以用户为导向,以快速开发,快速验证,快速修正的迭代式开发打造大量精品。

三、联系:

1.开发方法:敏捷开发和迭代开发都有采用迭代的方法进行软件开发。

2.实际应用中的联系

a.敏捷开发的核心原则是拥抱变化,递增变化。迭代式开发适合那些需求信息不明确的项目,这样在开发过程中遇到需求的变化时,所带来的影响要比其他模型小。而现在的很多项目中,需求在项目进行中变化的事儿经常见,所以显得迭代式开发的优势更明显一些,这正符合敏捷开发的拥抱变化。而且迭代开发是不要求每一个阶段的任务做的都是最完美的,明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交,然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善,这正符合敏捷开发的递增变化。

b.敏捷开发只是一个总体概念,而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外,还包含了其他许多管理与工程技术实践,如演进式架构设计、敏捷建模、重构、自动回归测试(ART)等等。总而言之,就是敏捷开发与迭代开发是整体与局部的关系,前者就像大家庭,而后者是大家庭中的一员

c敏捷迭代开发是对用户反馈的核心功能进行规划,从最小化可用产品 的用户试用反馈,到每个功能用户参与的反馈,形成 开发 、测试、 验证的快速循环。





2019-11-20 09:34:20 qq_44614026 阅读数 43
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13660 人正在学习 去看看 张传波

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

在这里插入图片描述

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中,测试人员的职责有三个主要方面:

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。

交流缺陷(Communication)

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

在这里插入图片描述

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在这里插入图片描述

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

在这里插入图片描述

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认

  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算

  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷

  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈

  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试

  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

在这里插入图片描述

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。
    作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。
    通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
    另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。

  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;
    一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。
    比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。

  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。

  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。

  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解

  • 对不同系统和数据库所用到的技术知识的了解

  • 和不同角色以及客户进行有效沟通

  • 主动验证质量目标并及时说出自己的想法

  • 编写测试计划,列出需要执行的活动并进行估算

  • 自动化测试的能力和对测试工具的基本了解

  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来

  • 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试、提bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题,但缺点是:

  • 测试过程是在一定时间间隔内发生的,测试人员必须等待产品完全构建才能找到错误和故障。不可否认,花费的时间超过了可以商定的时间;
  • 测试同学非常被动:当需求质量、开发质量差的时候,你只能被动接受,结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期;
  • Bug的成本在后期是非常高的,需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布,导致很大的损失。
  • 很有可能一个线上问题裸奔了几个月,最后是业务方先发现才排查到是Bug导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。
2019-03-09 07:49:28 u013464787 阅读数 31
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13660 人正在学习 去看看 张传波

敏捷实践

敏捷原则

捷软件开发宣言
  我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,我们认为:
  * 个体和交互    胜过   过程和文档
  * 可以工作的软件  胜过   面面俱到的文档
  * 客户合作     胜过   合同谈判
  * 响应变化     胜过   遵循计划
  虽然右项也有价值,但是我们认为左项具有更大的价值。

从上述的价值观引出了下面12条原则,它们是敏捷实践区别于重型过程的特征所在。

  1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

  2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

  3. 经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。

  4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

  5. 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

  6. 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。

  7. 工作的软件是首要的进度度量标准。

  8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

  9. 不断的关注优秀的技能和好的设计会增强敏捷能力。

  10. 简单—使未完成的工作最大化的艺术—是根本的。

  11. 最好的架构、需求和设计出自于自组织的团队。

  12. 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

    每一位软件开发人员、每一个开发团队的职业目标,都是给他们的雇主和客户交付最大可能的价值。可是,我们的项目以令人沮丧的速度失败,或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的,但是膨胀的过程方法对于我们的失败至少是应该付一些责任的。敏捷軟件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法,这个方法关注的是可以达到团队目标的一些简单的技术。

最重要的敏捷过程—极限编程

极限编程实践

  1. 客户作为团队成员

  2. 用户素材

  3. 短交付周期
    3.1 迭代计划
    3.2 发布计划

  4. 验收测试

  5. 结对编程

  6. 测试驱动的开发方法

  7. 集体所有权

  8. 持续集成

  9. 可持续的开发速度

  10. 开放的工作区间

  11. 计划游戏

  12. 简单的设计
    1) 考虑能够工作的最简单的事情
    2) 你将不需要它。
    3) 一次,并且只有一次。

  13. 重构

  14. 隐喻
    极限编程是一组简单、具体的实践,这些实践结合在一起形成了一个敏捷开发过程。该过程已经被许多团队使用过,并且取得了好的效果。极限编程是一种优良的、通用的软件开发方法。项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。

重构

在不改变代码外在行为的前提下对代码做出修改,以改进代码的内部结构的过程。

可是我们为什么要改进已经能够工作的代码的结构呢?不是还有句古老的谚语:如果它没有坏,就不要去修理它 !

每一个软件模块都具有三项职责。第一个职责是它运行起来所完成的功能。这也是该模块得以存在的原因。第二个职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化,开发者有责任保证这种改变应该尽可能地简单。一个难以改变的模块是拙劣的,即使能够工作,也需要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员应该能够比较容易的阅读并理解它。一个无法进行沟通的模块也是拙劣的。同样需要对它进行修正。

2018-06-04 16:58:05 iblade 阅读数 1217
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13660 人正在学习 去看看 张传波

 软件市场发展越来越迅速和成熟,传统瀑布式开发模式存在一定的限制,敏捷从而有了更广阔的的平台与机遇。Scrum作为在敏捷中使用最常用的一种方案,受到众多的关注。

定义:

敏捷开发(Agile Development)不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。

理解:

  • 首先,敏捷并不是一门具体的技术,而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。
  • 其次,敏捷开发都具有以下共同的特征:

    1.    迭代式开发

    2.    增量交付

    3.    开发团队和用户反馈推动产品开发

    4.    持续集成

    5.    开发团队自我管理

  • 最后,相比于“传统”的瀑布开发模式,敏捷开发是一种“现代”的开发模式。

具体方式:

上面说了敏捷是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而具体的开发方式有哪些呢?

Scrum,极限编程(XP)精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。

除了Scrum和XP,对于上面的其他开发方式,我也只是简单了解,大家可以多查查相关的资料。

我们可以简单的对比一下Scrum和XP: 
1. 在开发的过程中,你可以采用Scrum方式也可以采用XP方式; 
2. Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的。

敏捷宣言:

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

个体与交互 重于 过程和工具

可用的软件 重于 完备的文档

客户协作 重于 合同谈判

响应变化 重于 遵循计划

在每对比对中,后者并非全无价值,但我们更看重前者

敏捷开发的12准则:

在敏捷开发中,我们遵循以下准则:

1.    我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

2.    欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

3.    要不断交付可用的软件,周期从几周到几个月不等,且越短越好

4.    项目过程中,业务人员与开发人员必须在一起工作。

5.    要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

6.    无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

7.    可用的软件是衡量进度的主要指标。

8.    敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9.    对技术的精益求精以及对设计的不断完善将提升敏捷性。

10.   要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

11.   最佳的架构、需求和设计出自于自组织的团队。

12.   团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

什么是Scrum?

Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程,通常用于敏捷软件开发。。原词来自于橄榄球中“带球过人”。在橄榄球比赛的每次冲刺前,都将有一个计划安排的过程,但冲刺开始后则由队员在原计划的基础上随机应发。


评价:

很多觉得Scrum并没什么实质性作用,原因有这么几点:

1.    对于没有接触过Scrum的程序员来说,很难做到敏捷。

2.    用户故事的划分以及产品列表挑选最高优先级有点困难

3.    开发的过程中,团队中所有程序能够一直保持积极主动性很难把握

4.    Scrum对于自组织的团队要求很高

5.    对于在实施Scrum的过程中,对于把握全局的master以及产品负责人的要求更高。

6.    能否在实施的过程中及时发现问题,及时解决问题

不可忽视Scrum作用:

1.    Scrum团队总是先开发对客户具有较高价值的需求。

2.    更好的管理软件开发项目,它同样可以用于管理运行软件维护团队,或者作为计划管理,或者作为计划管理方法。

3.    提高团队的开发效率,降低项目的开发周期,最大限度的发挥团队的作用,更好的满足用户的需求。

优缺点:

Scrum的优点就是敏捷的优点,很注重实效,能更好的应对变化。

   缺点是,他过于强调了人的自我管理。 有的观点认为,Scrum适用于一帮资深程序员组成的团队,每个人都是牛人,每个人都有激情干活,这样才work。在国内大家缺乏能动性,没什么激情,很不适合Scrum。

   还有一个问题,就是很容易不停的因为目标变化而重新设计,最终导致不能交付。

   Scrum并不能保证项目成功,它只是给你更多的反馈,更多的可控性,让你更灵活的应对变化。在实际项目中我们应该对Scrum进行可适应性调整。


下面是《启示录》的作者Marty Cagan对敏捷开发的态度:P156,159


Scrum的详解【3355】

3角色

Product Owner:决定每个冲刺的任务,决定选择做什么和为什么做这些。

Scrum Master:Scrum团队教练和带头人,扫除实施障碍。

Team:是任务执行团队,可以是研发团队,也可以是跨职能团队,能够切实提供一个可用产品的团队。


3工件

Product Backlog:产品待办事项集合,我理解也是 用户故事,相当于当前版本所要做的所有需求。

Sprint Backlog:迭代功能开发列表,理解为一个冲刺目标阶段内的需求列表。例举如,当前版本总共要完成40需求,是我们的Product Backlog;我们把当前版本拆分4个冲刺阶段,即是4个Sprint。第一个Sprint需要完成10个需求,则这10个需求为当前Sprint的Sprint Backlog。

Burndown chart:燃尽图,确定需求实现阶段后,随时间往后推进,时间剩余消耗,同时任务列表也随工作的推进而消耗。即是,迭代显示剩余工作时间和任务的完成情况。

 

5价值观

Focus 专注:将故事拆解为冲刺阶段,目标细化,同时也是集中绝对的团队能力,解决既定目标,体现当前的专注,也排除其他插入时间的消耗。

Courage 勇气:在整个敏捷过程中,需要效率的提升,同时,面临的技术、环境、团队等一系列的问题并不会变少,就需要有勇气,有决断的阔步向前,用最优势的精力、资源解决当前最迫切的问题。

Openness 公开:团队内信息的完全公开,让问题无所隐藏,同时也让优秀和战绩能够很好地展示及引导,公开,从而大家平等,从而大家尊重。

Respect 尊重:在敏捷过程中,因为公开我们搭建了尊重的基础;同时因为效率的要求和冲刺任务的明确性,我们做自己最擅长的事情,从而让整体效率最大化。尊重他人,信任他人。

Commitment 承诺:构筑团队内部共同解决问题,最高效率突击任务环境,是因为我们信守承诺,敢于给出承诺;同时,也因为我们为别人为团队的承诺,我们必须是最好的处理我们的任务,对于我们承担的责任敢于承诺,也直面承诺的责任。

 

5工作

sprint planningmeeting:冲刺前计划会议,决定并生成sprint Backlog。---类似需求评审

sprint:冲刺,由冲刺会议决定了我们的目标,从而确定了冲刺的阶段,人员及任务安排。---类似于计划

daily standupdomeeting:每日站会,主要用于跟进进度,确定当前任务的情形,同时沟通是否有异常情况。要将异常在开始阶段进行良好控制。

sprint review:冲刺回顾。一个冲刺完成,对冲刺进行回顾,整理有益处,执行良好的部分;规划检查不好的地方,可以做的更好的方面。优化中不断前行。

retrospectivemeeting:回顾会议。完成当前版本,需要对整体进行回顾,对经历经验进行整理归档,形成有效的成长型文档,便于团队更好的成长。

Scrum过程

   在我看来Scrum是一种轻量级的软件过程,它是一个项目管理框架。它是由一套关于项目的开发流程,开发维护人员沟通方法,各种最佳实践组成的。 一个完整的Scrum流程包括很多个Sprint(就是迭代),每个sprint在2到4周不等。

   在项目开始时,将所有需要完成的工作列在一个Product Backlog中。

   每次Sprint时:

       1.        召开Sprint计划会议,在会议上产品负责人(Product owner)为Product Backlog中各项功能需求确定优先级。

       2.        随后,开发团队“认领任务”,并把这些任务从Product Backlog中挪到Sprint Backlog中去。

       3.        每天举行站立会议,参加人员Team Leader和Scrum团队,时间尽量短,15分钟即可。每个人回答3个问题:

           a)        你已经做了什么?

           b)        你即将做什么?

           c)        你遇到了什么困难?

           会议完后,相关人员可讨论遇到的问题。

       4.        一个Sprint结束之后召开Sprint评审会议。会议主要展示本次迭代完成的原型,主要参与者包括所有对该产品感兴趣的人,可以是产品负责人,开发团队,客户等等,时间控制在两小时以内。

       5.        召开Sprint回顾会议。会议由产品负责人、团队开发人员和Team Leader参加,总结本次迭代哪些做得好,哪些做得不好,团队在下一次sprint中要如何改进。


Scrum详解见下一篇文章


敏捷开发

阅读数 11

敏捷开发实践

阅读数 1258

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