2016-01-17 16:23:21 u010208788 阅读数 1996
  • SCRUM敏捷开发视频教程

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

    10428 人正在学习 去看看 CSDN讲师
一、历史背景


20世纪60年代,软件规模小,已作坊式开发为主;
20世纪70年代,硬件快速发展,软件规模和复杂度不同以往,引发软件危机;
20世纪80年代,引入瀑布模型,以过程为中心分阶段控制软件开发;
20世纪90年代,软件开发过程日益变重,开发效率降低,响应速度变慢;
21世纪,为了应对快速变化的需求,缩短交付周期,“敏捷开发”应运而生。


二、敏捷宣言
个体和交互         胜过    过程和工具
可以工作的软件   胜过    面面具到的文档
客户合作            胜过    合同谈判
响应变化            胜过    遵循计划


敏捷开发遵循软件客观规律,不断地进行迭代增量开发,最终交付符合客户价值的产品。
根据一项由DDJ在2008年由Scott Ambler发起的调查结果可知,采取敏捷开发后,82%的项目生产率有提高,78%的项目质量有提高,78%的项目客户满意度有提高,37%的项目成本有降低。


三、对敏捷的常见误解
要深刻的认识敏捷开发,首先要必要对它的很多误解。
1、敏捷开发意味着可以不需要文档、设计和计划;
2、敏捷只是一些优秀实践,或是优秀实践的结合;
3、敏捷只适用于小项目开发;
4、敏捷只会对研发产生改变;
5、管理者不需要亲自了解敏捷,只需要在管理上支持;
6、引入敏捷只需要按照既定的步骤去做就可以了;
7、敏捷是CMM的替代品,是另一种流程;
8、敏捷只注重特性的快速交付,在敏捷下架构不重要了。


正确的认识:敏捷=理念+优秀实践+具体应用。
敏捷核心思想,敏捷的经验积累,并且能够结合自身灵活应用才是真正的敏捷开发。


四、理念
聚焦客户价值,消除浪费。value
激发团队潜能,加强协作。team
不能断调整以适应变化。adapting


五、敏捷转型

绩效、组织、过程、文化、管控、技术和业务对齐、实践。

敏捷开发转型的不同阶段,这7个方面的优先级也不一样。


六、聚焦客户价值,标识和消除浪费

浪费类别:部分完成的工作;未应用特性;再次学习;移交;任务切换;延迟;缺陷


七、团队

1、关于团队激励

当团队自管理时效率最高;

人们对自己作出的承诺比别人要求的承诺更认真;

人们会尽力做到最好

强压会导致人们降低对质量的要求;


2、关于团队绩效

当团队成员不被打扰时,工作效率最高;

当团队解决自我问题时,提升最快;

广泛的面对面的交流是团队工作最高效的方式;


3、关于团队构建

团队生产率大于相同数目的个体生产率总和;

当不同技能领域的人组成团队并聚焦于工作时,产品更健壮;


4、敏捷方式的管理

管理者努力激发团队——

通过目标来牵引团队自主工作;

帮助团队提供资源,排除障碍;

营造团队自我管理的工作氛围;

作为教练辅导团队进步;

基于简单原则的管理,原则简单但必须被遵守;


团队成员是全方位的积极参与者——

共同参与计划制定和任务安排;

团队协作贯穿工作始终;

面对面交流是主要沟通方式;

关注团队目标,共担责任;

能力要求更广,主动学习适应岗位要求;


八、适应

1、客户是逐步发现真正需求的。我们应当通过不断向客户交付可用的产品,启发客户逐步发现真正的需求;

2、适应变化,小批量是快速交付的关键;

3、通过迭代计划不断调整以适应需求变化,在每一轮迭代开始,只详细确定本次的任务并严格执行,对后续迭代内容只做粗略计划;

4、持续保持良好的软件架构,架构应该具有可扩展性、使系统部件处于送耦合状态,通过重构及时维护和优化架构,保持框架的生命力;

5、利用多层次反馈不断调整以逼近目标。

客户验收;

站立会议/回顾会议;

持续集成;

单元测试;

结对编程。


九、敏捷实践概览

以短周期迭代为核心,包含团队、工作件、管理和技术实践。

团队:

敏捷团队角色——Product Owner、Scrum Master、Team

工作件:

产品需求清单、迭代需求清单、完成标准

管理实践:

迭代计划会议、每日站立会议、可视化管理、迭代验收、迭代回顾会议

技术实践:

用户故事、结对编程、测试驱动开发、持续集成、系统解剖


敏捷软件开发典型场景:

Peter和开发团队对产品业务目标形成共识;Peter建立和维护产品需求列表,并进行优先级排序;Peter每轮迭代前,Review需求列表,并筛选高优先级需求进入本轮迭代开发;开发团队细化本轮迭代需求,并按照需求优先级,依次在本轮迭代完成;开发团队每日站立会议、特性开发、持续集成,使开发进度真正透明;Peter每轮迭代(2-4周)交付的可工作软件进行现场验收和反馈;开始下一轮迭代。

2019-03-05 10:57:48 weixin_39835036 阅读数 232
  • SCRUM敏捷开发视频教程

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

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

广义而言,精益与敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益和敏捷软件开发里轻度重叠的三种不同风格。

精益与敏捷软件开发概述

 

Scrum、XP和看板都有很具体的技术,如Sprint规划会议(Scrum)、结对编程(XP)和限定在制品(看板)。这些技术都可视作流程工具。这三种工具的功能都有相当程度的重叠,例如,三种工具都建议使用真实的任务板将当前工作以可视化方式展现出来。

1、敏捷软件开发(Agile Software Development)

出现于2001年。当时,来自软件开发界的十七位思想领袖聚集在美国犹他州的一个滑雪度假胜地,探讨软件开发如何取得成功。研讨会期间,他们总结出一些强大的共同观点,形成了软件开发如何成功的共有愿景,即后来人们熟知的《敏捷宣言》 。

精益与敏捷软件开发概述

 

《敏捷宣言》内容如下:

我们正在通过亲身实践以及帮助他人实践,探寻更好的软件开发方法。通过这项工作,我们建立了如下价值观:

  • 个体和互动胜过流程和工具。
  • 可以工作的软件胜过详尽的文档。
  • 客户合作胜过合同谈判。
  • 响应变化胜过遵循计划。

也就是说,虽然右项也具有其价值,但我们认为左项具有更大的价值。

研讨会结束后,他们就支撑这些价值观的以下十二条原则达成共识:

  1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,要通过敏捷过程掌控变化。
  3. 经常地交付可工作的软件,比如相隔几星期或一两个月就交付,倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  6. 不论团队内外,传递信息效果最好、效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  10. 以简洁为本,它是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自自组织团队。
  12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

虽然敏捷一词正式出现于2001年,但多数敏捷方法都是在20世纪80年代到90年代形成的。敏捷只是一个描述了共同特征的统称。凡遵循上述价值观和原则的方法或方式都可视为敏捷方法。

2、精益概述

精益起源于日本丰田公司的“TPS”(丰田生产方式),即助力丰田成为全球最成功汽车制造商的生产方式。实践证明,TPS的基本原则“丰田之道”几乎适用于所有行业,包括软件开发。

敏捷与精益可以看作是一对拥有共同价值观但起源不同的兄弟。精益起源于制造业,敏捷起源于软件开发。两组原则都能与对方完美契合,而且适用范围都非常广泛。越来越多的软件开发组织在探索如何将两组原则完美结合,从而应用于从产品创意到交付的完整开发链。

1)全局优化

局部的优化长期来说,会对系统整体优化不利。

  • 专注于整体价值流:从概念到现金。从客户需求到软件部署。
  • 交付完整产品:客户不要软件产品,他们要解决问题。完整的解决方案是由完整的团队构建的。
  • 着眼长期:警惕导致短期思维和优化局部业绩的治理和激励体系。

2)消灭浪费

浪费指所有那些不能增加客户价值的事项。软件开发中的三大浪费如下:

  • 构建错误的功能:“没有什么比高效完成根本不应做的工作更无用。”
  • 拒绝学习:我们有很多策略都干扰了我们学习,例如,只按计划行事、频繁移交、决策与工作分离等,而学习则是开发的精髓。
  • 辗转现象:那些干扰价值顺利流动的做法,例如,任务切换、请求清单冗长、大堆未完成的工作等等,都只能达到事倍功半的效果。

3)品质为先

如果在验证过程中总是能发现缺陷,那流程就有问题。

  • 最终验证不应发现缺陷:所有软件开发流程的根本目的都是尽早在开发阶段发现并修复缺陷。
  • 采用测试先行的开发模式让流程具有防误机制:测试(包括单元测试、端对端测试和集成测试)必不可少,以此建立信心,保证系统在任何层次、在开发阶段任何时间点都始终正确无误。
  • 打破依赖:系统架构应当支持随时添加功能。

4)不断学习

规划工作非常有用。学习则必不可少。

  • 可预测的性能来自于反馈:可预测的组织不会猜测未来并称之为计划;反之,他们会培养能力对未来做出响应。
  • 保持选择方案:视代码为实验——使其具有容变性。
  • 最后可靠时刻:在做出不可逆转的决策之前尽可能学习。不要提前做出纠正代价高昂的决策,也不要事后才做出决定!

5)尽快交付

从一开始就深入了解所有干系人看重的价值。然后基于这样深入了解的价值观,创建稳定、连贯的工作流。

  • 快速交付、高质量和低成本是完全相互兼容的:以速度竞争见长的公司拥有很高的成本优势,他们可以交付优质的产品,而且对客户需求更为敏感。
  • 排队理论同样适用于开发,而不仅仅是服务行业:专注于使用性会造成交通堵塞,反而降低了使用性。以较小的批量、限制同时进行的工作数来缩短周期时间。大力限制等待清单和队列的长度。
  • 管理工作流比管理进度表要容易得多:建立可靠、可预测交付物的最佳方式是通过迭代和看板建立可靠、可重复的工作流。

6)人人参与

聪明、有创造力的人员的时间与精力,是当代经济的稀有资源和竞争优势的基础。

获得公正薪资的人员在自主性、成长性和使命感等方面受到激励。

  • 自主性:最有效的工作小组是半自治团队,有一个内部主管从头到尾负责完整、有意义的任务。
  • 成长性:对人员的尊重意味着提供挑战、反馈和让所有人都能够发挥潜能、表现卓越的良好环境。
  • 使命感:将工作与价值挂钩。只有相信自己工作的意义,团队成员才会全心投入工作,实现这种使命。

7)不断提高

结果不是重点——重点是培养人、发展体制,使之能够交付结果。

  • 失败是个学习机会:即使是非常小的失败都会被深入调查并纠正的,做到一丝不苟的时候,才可能获得最可靠的性能。
  • 标准存在的目的就是要被质疑和提高的:将现行的、最知名的做法纳入人人都遵循的标准,与此同时鼓励所有人质疑并改变标准。
  • 使用科学方法:教团队建立假设、开展大量快速实验、创建简明文档并实施最佳方案。

3、Scrum概述

Scrum是由杰夫•萨瑟兰(Jeff Sutherland)和肯•施瓦伯(Ken Schwaber)于20世纪90年代早期共同创建的一种软件开发过程。Scrum核心内容如下:

1)按优先顺序排列的产品需求清单

将产品分割成一组小而具体的可交付物,即产品需求清单。产品负责人对产品愿景进行定义,并按商业价值以及风险和依赖关系等其他因素对需求清单进行排序。

精益与敏捷软件开发概述

 

2)跨职能团队

将产品所有人员划分为多个小规模、跨职能、自组织的开发团队。每个团队都有一位产品负责人负责定义愿景和总体的业务优先顺序,以及一位Scrum大师专注于改进团队、消除障碍。

精益与敏捷软件开发概述

 

3)Sprint

将整个开发时间划分成多个短小的、固定的迭代周期或Sprint(通常为两周或三周)。开发团队自行决定每个迭代周期要完成多少个产品需求清单项。每个迭代周期最后都要演示已通过测试、能够发布的版本。

精益与敏捷软件开发概述

 

4)持续调整版本发布计划

产品负责人与客户一起合作,在每个迭代周期之后仔细检查发布版本,根据所得的结果,不断优化版本发布计划,并更新优先排序。

5)持续调整流程

开发团队通过每个迭代周期之后的回顾会议不断优化开发流程。所以,Scrum开发模式意味着:不是由一个大团队用很长的时间来开发一个大产品……而是由一个小团队用很短的时间来开发一个小功能。但定期集成,以构成整体。Scrum模式不会硬性规定任何具体的工程实践——这些都由团队自行决定。不过,在实践中,不纳入XP的核心工程实践而通过Scrum模式取得成功是非常困难的。

4、XP概述

极限编程(XP)是肯特•贝克(Kent Beck)于20世纪90年代中期创立的软件开发方法。该方法以简洁、沟通、反馈、勇气和尊重等价值观为基础。XP方法是与Scrum并行发展的,实际上包含了大多数相同要素。例如,XP中的现场客户(on-site customer)就大致等同于Scrum中的产品负责人(product owner)。

精益与敏捷软件开发概述

 

从这个意义上而言,Scrum可被视作XP的“包装纸”,专注于结构问题和外部沟通。而XP除多数理念都与Scrum相同以外,还增加了一些团队内部的工程实践,包括以下内容:

  • 持续集成:拥有一个随着团队的开发可自动编译、集成并测试代码的系统。这样就能尽早为开发团队提供有关产品质量方面的反馈。
  • 结对编程:在一台工作站上进行结对编程,从而使学习效果最大化、设计质量最大化、缺陷最小化。
  • 测试驱动开发:采用测试代码驱动系统的设计。编写自动化测试脚本,然后编写刚刚足够的代码以使其通过测试,然后从根本上重构代码,提高其可读性,移除重复代码。清理并重复这一过程。
  • 集体代码所有权:允许(实际上是鼓励)开发团队的任何人编辑代码库的任何部分。这样可营造出团队所有权的意识,确保整个系统的设计都一致、易于理解。
  • 增量式设计改进:从最简单的设计开始,然后运用重构等技术持续不断地改进设计,而不是从一开始就做好完整的设计。

上述许多实践都互为基础。例如,如果系统的自动化测试覆盖范围不足,那增量式设计改进就很难实现、令人生畏且风险很高,而若要测试覆盖范围足够,则需要通过测试驱动开发和结对编程才可实现。不过,如果所有的测试都必须手动触发,而且只能在开发人员的本地工作站上运行,问题就会让人更头痛,所以,我们就需要一个持续集成系统在后台自动完成上述工作,等等。

5、看板概述

看板是敏捷软件开发的精益方法。实际上,看板有着多方面的意义。从字面上看,看板是日语单词,是“可视卡片”(或标志)的意思。在丰田,看板专指将整个精益生产系统连接在一起的可视化物理信号系统。看板的规则很简单。不过,跟象棋一样,规则简单并不意味着游戏简单。

可视化工作流:把产品切分成小块,将每一块写在一张卡片上,然后将卡片贴到墙上。墙上的每一栏都有名称,以此显示每张卡片在工作流中所处的位置。

精益与敏捷软件开发概述

 

这就基本上直接实施了精益拉式生产调度系统。Scrum专注于结构和沟通,XP增加了工程实践,看板则专注于将工作流可视化,并对瓶颈进行管理。

2014-03-13 14:23:03 u014033119 阅读数 364
  • SCRUM敏捷开发视频教程

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

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

 敏捷已成为当今使用最广泛的开发方法。值得一提的是,敏捷方法的流行性并不是因为它取代了其他开发方法,相反是与这些开发方法进行了更好地融合。现实中众多敏捷项目的成功,也印证了敏捷将走向混合化的未来。


 SpecDD是由周铁人博士创立的一种以需求为核心的混合敏捷开发方法。它基于同时支持敏捷开发和非敏捷开发流程而设计。

SpecDD过程模型

在SpecDD过程中,开发过程由一组连续的迭代组成,这些迭代过程通常也被称为Sprint。一个迭代周期通常持续2-4周,但也可以根据实际情况或长或短。在迭代内,团队对规划的新开发工作做出承诺,并完成开发实现及测试,同时将这些过程记录在案。

 通过在SpecDD项目过程中,为每个开发Sprint周期引入敏捷QA测试,同时与独立的QA团队相整合并完成回归测试,来实现高质量的项目交付。具体来说,在开发Sprint内,流动的QA和敏捷团队共同合作,并确保每个开发任务完成的时候都是经过质量验证的。而回归测试团队负责为多个完成的Sprints建立产品集成测试(这些Sprints常常是由多个团队分别完成的),来实现期望的质量标准。伴随开发Sprints的进展需要,建立并执行QA测试计划和测试周期。

              SpecDD_1.gif

 如上图所示,一个SpecDD项目从需求管理开始,需求驱动并建立产品Backlog和Sprint backlog等开发工作。基于这些相同的需求,生成相应的QA测试用例。定义好的测试用例存放在测试用例库中,并作为需求的质量标准。然后回归测试团队创建测试计划,并执行多次测试周期。

量化需求,以驱动开发

 SpecDD使用Epic和Spec来管理需求。Epic表示一个大概的想法,一般来说往往过于笼统,范围也比较大,因此需要进一步分解为Spec。Spec表示一个新功能或者功能改进,可能需要进一步分解为一个或多个开发任务进行实现。一个Spec,不需要在充分理解需求,或者需求被完整文档化的情况下,才开始实现。随着Spec的开发实现,可执行的软件本身将帮助团队更好地理解原始需求。并常常会为需求添加新的和改进后的文档及附件,包括新的业务逻辑模型、更新后的用户图形界面、以及新的技术设计文档等。

    当Spec被分配到产品Backlog时,Story将被创建,用来作为对Spec实现分配的承诺。实际项目中,单个Spec的实现,可能需要生成多个Story,经过多次实现分配才最终完成。

    下面的图说明了Spec、Story和任务之间的关系。Spec被分配到开发空间中,生成一个或多个Story。每个Story可以进一步分解为一个或多个开发任务。每个开发任务可能含有一个或多个QA测试子任务。

                SpecDD_2.gif

 在SpecDD模型中,需求“驱动”并不意味着需求在驱动开发和质量实践前,需要被完整的定义。Spec 是以客户价值角度,表达的某个产品功能,可能并不包含最初需求的细节。需求Spec的实现过程,与需求Spec的重定义过程,常常并行发生。SpecDD提倡团队使用需求作为交流的标准,并使用文档记录改进后的需求理解,以保存团队在需求决策过程中所做的“智慧”。

SpecDD开发迭代

 Sprint工作量来源于产品负责人选定的一组候选功能和缺陷列表。功能以Story的形式分配到Sprint,每个Story包含一些细分的开发任务。缺陷通常以独立存在的开发任务(不与Story相关联)分配到Sprint。

随着任务负责人对各自工作进展的推动,一个个开发任务从初始状态,经过中间状态,并且最终到达完成状态。使用一个简单的敏捷工作流,常常能够帮助团队管理任务的生命周期。SpecDD框架下的任务工作流,往往包含以下几个状态:待分配,处理中,QAFloater验证和完成任务。随着任务负责人每天的进展,剩余工作时间理想情况下,将从最初的估计值不断减少直至为零。伴随开发团队自我管理,自我驱动地完成所有承诺的开发任务,生成的燃尽图报表(例如下图)最佳地展现了团队Sprint工作量的进展。

                SpecDD_3.gif
 
SpecDD Sprint质量模型

 SpecDD框架中,Sprint工作量由一组待实现的Story,开发任务和缺陷组成。在Sprint开始的时候,为开发人员估计每个工作项的工作量,可以使用剩余时间或点数。这里有一个问题:是否需要创建与开发任务同级别的QA测试任务,并作为工作量的一部分?

  一个常用的,但不合理的做法是为所有的开发任务创建同级别的QA测试任务,使用同样的办法,为QA测试任务也设定具体的剩余时间,从而驱动QA测试任务的进展。对于一个开发任务,估计剩余时间是可能的,并且能很好地激励任务负责人,在估计的时间内努力完成工作。

 然而对于QA测试工作来说,在Sprint开始的时候,将所有可能需要的各种测试任务创建完毕,并且估计剩余时间,实际上是不可能的。更为重要的是,对QA测试总时间的估计,阻碍了建设一个自我驱动的团队。不包含QA测试时间,对于Sprint的总剩余时间,团队总是可以自我驱动的,并将它作为要达成的动态目标。而包含QA测试时间,它只会损害一个自我驱动的开发团队,在他们估计的时间内,努力完成所有开发工作的积极性。

在SpecDD模型中,通过为开发任务建立子任务来表示QA测试工作。对于功能性开发任务,可以基于开发任务所对应的父级需求,生成相应地测试标准。随着需求被充分理解并文档化,团队可以为需求Spec和Story创建测试用例,来准确表达质量标准。对于缺陷修复任务,测试子任务可能并不会与测试用例相关联,因为缺陷描述本身往往就保留了QA测试的标准。下图说明了基于QA测试子任务的SpecDD Sprint质量模型。

               SpecDD_4.gif
 
 SpecDD Sprint质量模型创造了一种“平衡”的质量控制概念。可执行软件的创造人员,自我驱动并努力将Story和开发任务转化为可执行的软件。QA Floater是可执行软件的保护者,他们为开发任务创建QA测试子任务,以确保开发任务完成之前进行充分的测试。可执行软件的创造者想要燃尽图走的更快,总是主动积极并达成剩余时间估计目标。而保护者则是减缓剩余时间的进展,有时,他们甚至因为发现新的缺陷,而增加了开发任务的剩余时间。SpecDD Sprint质量模型为这两个关注面创造了一种动态的平衡,优化了开发产生力和质量保障。

对于每个SpecDD的敏捷开发团队,推荐1-2名测试人员加入开发团队,加入的测试成员称为QA floater。QA floater主导测试,并促进最佳测试实践,同时帮助每个敏捷团队成员成为更好的测试人员。建立并完善测试用例,是敏捷Sprint测试实践中的主要产物,以确保高质量的Sprint。测试用例将被保存于测试用例库中,完整的测试用例库未来会进一步指导测试团队的全面回归测试。

SpecDD回归测试模型

在QA floater和测试子任务模型下,一个理想的SpecDD Sprint将能够交付一个没有缺陷的可执行软件。但现实中往往是,在多个Sprint迭代后,相互集成的产品,势必会有一些缺陷。没有一个稳固的回归测试实践,多团队参与的大型项目,无疑将缺乏质量控制和可扩展性。

SpecDD使用测试用例,并与运行时的环境变量相结合,正规化表达并量化产品的质量。QA测试计划为产品的发布指定了测试标准。为了更加灵活高效地执行测试计划,常常使用测试周期来表示较小的测试迭代,一个测试周期可用于覆盖QA测试计划可能产生的所有任务的一个子集。

一个测试周期包含一组测试任务,测试任务是基于测试用例与运行环境变量排列组合下产生的具体实例。可以手动或使用自动化测试工具,来执行这些测试任务。下图反映了开发迭代周期与QA 测试周期的关系。

             SpecDD_5.gif
 
 正如您所看到的,QA测试周期的规划和执行,不一定同步于开发迭代周期。当您想将新发现的缺陷分配到当前进展中的Sprint时,敏捷开发方法会要求测试团队只能将缺陷提交到产品Backlog中。QA回归测试团队负责提交缺陷,但是他们并没有权利决定何时修复这些缺陷。拥有一个独立的测试团队,更早地发现缺陷,并在产品Backlog中对缺陷进行优先级排序,实际上有助于创造一个更加灵活的敏捷过程。

结论

敏捷技术,正成为一个个构建基石,嵌入到其他开发方法。有了这样的信念,SpecDD为团队提供了指引,将敏捷技术与团队现有实践进行最佳的融合。

对于使用瀑布模型的团队,SpecDD帮助他们扩展了需求管理,并支持产品Backlog。随着产品Backlog的优先级排序,团队可以开始尝试较短的迭代开发,同时通过燃尽图和每日敏捷练习,创造自我驱动的团队。伴随需求驱动的开发和质量的实践,他们很快就会看到生产率的提高。

对于已经实践敏捷开发的团队,SpecDD有助于全面整合需求管理与产品Backlog,实现需求完整可追溯。通过引入敏捷Sprint QA测试,并建立一个独立的QA团队来执行回归测试,使得多团队参与的敏捷项目变得更具有扩展性。



2011-01-30 15:04:00 wolf_linn 阅读数 350
  • SCRUM敏捷开发视频教程

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

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

 

敏捷软件开发概述

如同前文所述,可以把敏捷看做一种问题解决方式。下面我们就从敏捷问题解决方式的角度解读敏捷软件开发。

敏捷软件开发

软件开发是问题本身和问题解决能力不确定的一种典型情况。软件项目起源于人的构想,随着时间不断变化。项目团队对项目的认识随时间不断加深,成员能力不断提升,工作方式和过程改变导致团队开发能力不断变化。

敏捷软件开发分为3个层次。

产品层

1.         问题与问题参与者

问题是产品构想。问题提出者是客户(业务负责人),问题解决者是特性团队。

2.         问题分解与检验

a)         问题分解

将问题从产品构想分解到业务特性。业务特性是问题提出者客户可检验的单位问题。

b)        问题检验

在可工作的软件中检验完成的业务特性。可工作的软件是客户检验问题完整性的基础。

3.         迭代

迭代的大小从1周到4周不等,这是一个客户可接受的频率(节奏)。

业务特性层

1.         问题与问题参与者

问题是业务特性。问题提出者是特性团队,问题解决者是特性团队或负责业务特性的相关人员。

2.         问题分解与检验

a)         问题分解

将问题从业务特性分解到单元。单元是特性团队可检验的单位问题。

b)        问题检验

在可工作的业务特性中检验单元的完成情况。

3.         迭代

迭代的大小从小时到天,这是一个特性团队可接受的频率(节奏)。

单元层

1.         问题与问题参与者

问题是单元。问题提出者是开发人员,问题解决者是开发人员自身或另一个开发人员(结对编程)。

2.         问题分解与检验

a)         问题分解

将问题从单元分解到单元职责。

b)        问题检验

在预期的单元测试中检验单元职责的完成情况。

3.         迭代

迭代的大小从分到小时,这是一个开发人员可接受的频率(节奏)。

常见敏捷软件开发方法学

Scrum

Scrum和敏捷软件卡发有很多共同点。而对比敏捷软件开发,可以看到Scrum的敏捷实践侧重于高层,而缺乏低层的敏捷实践。

极限编程XP

XP与敏捷软件开发的吻合度更高。它是由一系列简单却互相依赖的实践组成,这些实践结合在一起形成了一个胜于部分结合的整体。

 

2019-12-22 19:38:17 u012605629 阅读数 6
  • SCRUM敏捷开发视频教程

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

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

本文是个人总结摘记,部分文字摘自其他大神博文等,如有雷同,未列参考文献,请见谅;

什么是敏捷开发?

  • 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。敏捷开发一种开发方法,也就是一种软件开发的流程,这种开发方式的主要驱动核心是人;它采用的是迭代式开发;敏捷开发的核心就是在一个高度协作的环境下,不断的通过反馈来进行自我调整和完善。重点强调的是协作和反馈,协作体现在团队与客户之间的协作,团队成员之间的协作。反馈则是在开发中的任何环节,包括代码质量、自动化测试、部署、项目进度、需求变更、客户验收等,而且反馈越快越好。 以人为核心、迭代,协作、反馈;

  • 传统的瀑布开发模型,它是以文档为驱动的,在整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

敏捷宣言

  • 个体和互动高于流程和工具
  • 工作的软件高于详尽的文档
  • 客户合作高于合同谈判
  • 响应变化高于遵循计划

名词

  • PM:Project Manager 项目经理,负责沟通协调,保证项目进度,维护团队等。
  • PO:Project Owner 即甲方熟悉业务的人,验收软件的人,因为TW是外包公司。
  • BA:Business Analyst 业务分析师,思维敏捷,英语流畅,负责与客户沟通,整理需求,拆成故事卡。
  • UX:User Experience 用户体验设计,传统的UI升级版,不仅要会做图,还要考虑用户体验如何。
  • TL:Technical Leader,技术领导
  • DEV:Developer 前端后端的程序猿/媛们。
  • QA:Quality Analyst 质量分析师,即测试工程师
  • AC:Acceptance Criteria,验收条件
  • UAT:User Acceptance Test,用户验收测试
  • Retro:Retrospective,回顾会议
  • TB: Team building,团队建设

为什么要有固定的迭代周期

  1. 建立团队的节奏感:有预期的节奏,容易让团队形成习惯,团队生产效率更规律。
  2. 降低协同成本:能够并行的去安排多个迭代的规划,评审等活动,减低沟通和协同成本。
  3. 简化规划活动:如果固定的迭代长度,当团队人力固定的时候,团队的生产率理论上也是固定的,有利于规划的合理性。
  4. 此外,长周期从需求完整性、频率、工作强度上优势明显,短周期从产品规划、交付效率、质量以及试错成本上优先明显。

INTERATION

  • IPM -> STAND UP -> STORY KO -> CODING -> CODE REVIEW -> TESTING -> SHOW CASE -> RELEASE -> RETRO;
  • (SESSION -> TEA PARTY -> CATCH UP WITH CLIENT/PD/DEV/UX)
  • (FEEDBACK LOOPS / CONTINUOUS INTEGRATION / STORY BOARD)
  1. IPM
  2. Stand Up
  3. Story Board
  4. Code Review
  5. TDD
  6. Refactoring
  7. Simple Design
  8. Show Case
  9. Continuous Integration
  10. 360/daily FeedBack
  11. Regular catch up with client
  12. Story kick-off
  13. Pair

https://www.infoq.cn/article/my-agile-practice-in-thoughtworks

传统项目和敏捷项目管理区别

  • 价值理念,流程框架,实践方法

价值理念

  • 项目管理的三要素:时间(进度)、范围(需求和特性)、成本(资源)
  • 传统项目管理,是先确定产品的范围,然后评估这些需求要花费多少时间,协调花费多少人力,然后形成各种计划,如排期计划、沟通计划、人力分配计划、风险计划等等,然后按照既定的计划来推进,计划驱动。(范围固定,时间和成本可调整,计划驱动)
  • 敏捷项目管理,是先固定了成本、和时间,如一个团队就10个人,迭代周期两周,那我们先做哪些有价值的需求和特性。(时间和成本固定,范围可调整,价值驱动)

研发模式

  • 传统项目管理,通常用瀑布的研发模型,瀑布模型是最典型的预见性方法,什么叫预见性方法呢,就是做之前先严密的分析计划,严格遵守预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序化进行。为了后期的执行过程中不会有太大的风险和偏差,所以前期会花大块的时间准备繁重的各种文档,并且会有很严格的评审流程。通过预见性的方法来保证有个好的研发过程。这样的研发模型是不接受变更的,因为变更的代价会较大。

  • 敏捷项目管理,通常用迭代的研发模型,在初步分析后,产品就以小的增量进行开发。先小布快跑起来,然后实现小部分功能找到用户做验证反馈,在一步步的完善产品方案,最终交付完成产品。迭代的研发模型的好处是,一直围绕这用户变化的需求适应调整,保证最终交互的是用户满意的成果。

  • 通常这两种研发模型,第一种通常是保证了有一个“好过程”,而第二种通常是有一个“好结果”,而“好过程”不一定等于“好结果”,所以尽量选择能产生好结果的研发模式。

实践方法

  • 传统项目管理用到的实践方法,如waterfall、PMBOK、RUP;敏捷方法,如XP、scrum、kanban等。

  • XP:极限编程,XP是偏工程实践和方法,缺乏对项目管理的指导方法。但它里面提到结对编程,持续集成等很好的实践方法。持续集成的核心就是快速试错,提前发现问题,而不是把问题放到集成之后。

  • Scurm:提供一套基于团队运作的敏捷方法,scrum引入了“backlog”、优先级、迭代例会等;scrum优势是简单,易于使用,所以很多互联网团队都在参考和实践。

  • KANBAN:最初是制造业应用的方法,后来被敏捷相关管理进行改良事件,变成故事板。KANBAN能将现有的管理可视化,透明化,有利于管理工作的有效推进。

  • 传统项目管理方法更像是计划经济体制,更注重规划和过程把控的方法实践;而敏捷管理方法更像是市场经济体制,更多的是适应环境,小步快跑,灵活变化的方法实践。

参考文档:https://www.tapd.cn/forum/view/23641

极限编程(XP)和Scrum区别

  • 区别之一: 迭代长度的不同(XP1-2周,scrum 2-4周)
    • XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。
  • 区别之二: 在迭代中, 是否允许修改需求;(XP可替换,scrum严格要求,不允许)
    • XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。
    • 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队受到干扰。
  • 区别之三: 在迭代中,User Story是否严格按照优先级别来实现;(XP严格按优先级,scrum灵活)
    • XP是务必要遵守优先级别的。
    • 但Scrum在这点做得很灵活,可以不按照优先级别来做,Scrum这样处理的理由是:如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10。
  • 区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量;(XP严格流程方法,scrum不定义,自觉)
    • Scrum没有对软件的整个实施过程开出工程实践的处方,要求开发者自觉保证。
    • XP对整个流程方法定义非常严格,规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。
没有更多推荐了,返回首页