敏捷开发系列之旅 第五站_深入敏捷测试:整个敏捷团队的学习之旅pdf - CSDN
  • 敏捷开发之旅,我想要和大家一起分享FDD特征驱动开发方法。 特征驱动开发——Feature Driven Development 还是老规矩,讨论之前,我们先了解一下什么是Feature?什么是FDD? Feature ...
    上篇文章中,我们探讨了什么是XP极限编程,以及极限编程的管理思想、核心价值观等等。在敏捷开发之旅的第三站,我想要和大家一起分享FDD特征驱动开发方法。

    特征驱动开发——Feature Driven Development

    还是老规矩,讨论之前,我们先了解一下什么是Feature?什么是FDD?

    Feature


    在FDD中,Feature(特征)是一个基本的开发单位,是(FDD)项目中的一个增量,是指用户眼中最小的有用的功能,可以在很短时间内实现(一般在两周之内)。
    • 特征是小的
    特征之所以是小的,是因为他可以在两周之内实现,任何一个过于复杂而无法在两周之内完成的功能,可进一步呗分解小到足以被称为一个特征。使特征小一些也意味着客户能经常看到可测量的进度。
    • 特征是具有客户价值的
    在业务系统中,一个特征映射到业务过程中某些活动的一个步骤。在其他系统中,特征等同于由用户完成的一项任务中的一个步骤。

    FDD


    特征驱动开发(FDD),是敏捷开发方法中的一种,他来源与新加坡的一个大型软件开发项目,由著名软件专家Jeff de Luca 、Eric Lefebvre、Peter Coad共同提出的。它强调特征驱动,快速迭代,即能保证快速开发,又能保证适当文档和质量。

    他提出的每个功能开发时间不超过两周,为每个用例user case限定了粒度,具有良好可执行性,也可以对项目的开发进程进行精确及时地监控。他抓住了软件开发的核心问题领域,即正确和及时地构造软件。

    FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来,直接参与到开发人员和用户所从事的系统构造工作中。

    开发过程


    FDD方法包括5个过程,其中的按照功能设计和构建是反复的迭代过程。



    • 开发整体模型
    这是FDD开始一个项目的初始工作,在主设计师的指导下,带领领域专家和开发小组成员一起工作。主要是收集系统的功能需求,然后使用四色原型进行域建模。我个人认为,在此阶段中,能够得出系统的架构设计图。
    • 构建功能列表
    这个过程确定所有用于支持需求的功能。由领域专家和开发小组进行功能分解。根据领域专家对领域的划分,将整个领域分成一定数量的区域(主要功能集),每个区域再细化为一定数量的活动。活动中的每一步被划分称为一个功能。形成了具有层次结构的分类功能列表。个人认为,在此阶段中,能够形成系统的概要设计。
    • 计划功能开发
    项目经理、开发经理和开发小组根据功能的依赖性、开发小组的工作负荷以及要实现的功能的复杂性,计划实现功能的顺序,完成一个功能开发计划。它提供了对项目的高层视图,让业务代表了解功能开发、测试和发布日期,以便业务代表和部署小组能够计划交付哪些功能的日期。本阶段的主要成果是,能够形成项目开发计划。
    • 按照功能设计
    项目经理和上一阶段指定的各个功能集的主要程序员一起对功能进行详细设计。同时在域模型的基础上进行分析、设计,得出分析模型、设计模型。由于一次设计并不全面,因此也可以直接进入设计模型。根据设计的结果制定出项目的里程碑。这里会有一个设计评审的环节。本阶段的成果应该包括了:详细设计、项目里程碑计划等。
    • 按照功能构建
    按照设计进行编码实现,由程序员实现各自负责的类。在代码完成后有必要的组织代码复查、评审。在测试和检查通过后检入到配置管理库中进行构建。第5和第4 阶段是一个迭代的过程,迭代周期一般为2个星期。这样经过不断的迭代,不断的实现功能集中的功能。每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑 的继续,直到最后项目的完成。

    最佳实践

    • 领域对象建模
    是对象分解的一种形式,主要包括构造类图,用于描述问题领域中重要对象的类型及其相互关系,为系统设计提供了一种整体框架,使得系统可以按照特征迭代增量地进行开发。
    • 按照特征开发
    按照一组小功能、对客户有价值的功能列表进行开发并跟踪过程。FDD将需求问题分解成可以解决的小问题,对每个问题分解为分层列表的功能需求,即特征。然后,开始设计并实现每一个特征。一旦系统的功能特征被标识以后,它们通常在FDD方法中用于驱动和跟踪开发过程。
    • 类(代码)拥有权
    FDD规定每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。FDD方法采用的开发技术是面向对象,类定义一个单一的概念和实体,最合适作为最小的代码分配要素,代码的所有权即为类的所有权。
    • 特征小组
    FDD把类即特征分配给一个确定的开发者。由于一个特征的实现会涉及到多个类及其所有者,因此,特征的所有者(特征组长)需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别:特征小组的组长更像是教练而不是超级程序员。
    • 审查
    指的是检查软件错误的复审方法,这是FDD确保软件设计和代码质量的一个关键技术。审查将开发小组和FDD以主程序元为主的结构完美地结合起来,这种混合是一种新型的开发方式。
    • 定期构建
    定期地取出已完成功能的全部源代码和它所依赖的库、组件,组成完整的可以运行的系统。构建增加功能的基线,确保总是有一个可以运行、向客户演示的软件系统,可以使客户观察到系统开发的进度和实现的功能是否是需要的。
    • 配置管理
    一个FDD项目只需要保证对完成的代码文件最新版本的确认和历史追踪。根据开发软件的复杂性,分析制品、设计制品以及测试用例、测试脚本等也应该受控于版本控制。
    • 可视性进度报告
    项目成员应该根据完成的工作向各级管理报告工作进度,FDD提供了一个简单、低开销地收集准确和可靠项目信息的方法,提供了大量直观、直接的报告样式,向项目所有相关人员报告项目进度。

    与XP的比较

    • 隐寓和模型
    XP过程以在卡片上记录故事开始业务分析。每个故事就是系统要做的事情。整个项目在“每个人——客户、程序员和经历——能够讲出系统如何工作的整体故事”隐寓的指导下进行的。

    FDD使用特征,执行领域走查,同时要建立一个全面的领域对象模型,以便特征小组对每一组特征产生更好的设计。
    • 开发团队
    在开发队伍规模上,XP通常不超过10人;FDD的理想团队成员数在16~20人,也有更大团队的实际经验。
    • 代码拥有权
    XP鼓励集体拥有代码,任何人都可以在需要时添加或修改代码。与之相反,在FDD中,整个开发团队拥有代码的集体所有权。当需要集体验证譬如说软件架构的设计或用户界面构造的时候,FDD就将类所有者与特征小组和审查结合起来满足需要。
    • 测试
    XP利用双人结对编程来不断地在设计和代码层执行走查和非形式化审查。FDD则提倡采用结构化的形式化审查技术。

    XP中的正确性是由运行单元和功能测试来定义的。在FDD中,单元测试是“按照功能构建”过程的一个部分。FDD没有定义参与测试的形式化等级,由主程序员决定做什么更适合。
    • 项目追踪
    XP让项目经理决定项目追踪方法,鼓励减少数据搜集的工作量,鼓励使用大型图表。在FDD中的按特征追踪项目的方法,描述了工作量小、准确度量项目进度的手段,提供了用数据构造多种使用的进度图表。

    结束语


    作为敏捷开发的方法之一,特征驱动开发很好的实现了敏捷的思想,它强调的是整体模型,是从全局观的角度考虑问题的。同时,我们也要认识到一点,特征驱动开发相对于其他的方法,还是比较复杂的。其方法的精致和结构的规整,很容易让使用者在本身固有的重型思维方式的引导下,走入于agile背道而驰的泥坑。这本身也是其复杂性的一个表现。

    因此,要想使用FDD并不容易,但不可否认的一点,FDD的确是一种非常好的敏捷开发方法论。而它具体的实施效果最终还是要看领导者以及实施者、使用者的具体实践。


    展开全文
  • RUP,统一软件开发过程,是一个面向对象且基于网络的程序开发方法论。根据Rational的说法,RUP就好像一个在线的指导者,他可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。 生命周期 对于...

    概述

     
    RUP,统一软件开发过程,是一个面向对象且基于网络的程序开发方法论。根据Rational的说法,RUP就好像一个在线的指导者,他可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。
     
     

    生命周期

     
    对于RUP过程,其开发模型由软件生命周期(四个阶段)和RUP的核心工作流构成一个二维空间。横轴表示项目的时间维,包括四个阶段,纵轴表示工作流(活动)。
     
     

    六个特点

    • 迭代式开发
    在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上,我们经常遇到的问题是需求在整个软件开发工程中经常会改变。传统的开发方式对于这种需求的变更是很难应对的。
     
    迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险,而且每个迭代过程都可以执行版本结束,这无疑给开发人员增加了很大的成就感和自信心。
    • 管理需求
    确定系统的需求是一个连续的过程,开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化,用例和脚本的使用以呗证明是捕获功能性需求的有效方法。
    • 基于组件的体系结构
    组件使重用性成为可能,系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性,提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
    • 可视化建模
    RUP往往和UML联系在一起,对软件系统建立可视化模型,帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化地对软件系统建模,获取有关体系结构和组件的结构和行为信息。
    • 验证软件质量
    在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动,而是内建于过程中的所有活动,这样可以及早发现软件中的缺陷。
    • 控制软件变更
    迭代式开发中如果没有严格的控制和协调,整个软件开发过程很快就陷入混乱之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品,隔离来自其他工作空间的变更,以此为每个开发人员建立安全的工作空间。
     
     

    核心工作流

     
    RUP中有9个核心工作流,分为6个核心过程工作流(Core Process Workflows)和3个核心辅助工作流(Core Supporting Workflows)。尽管6个核心工作流可能使人想起传统瀑布模型中的几个阶段,但应注意迭代过程中的阶段是完全不同的,这些工作流在整个生命周期中一次又一次被访问。9个工作流在项目中轮流被使用,在每一次迭代中以不同的重点和强度重复。
     
     

    核心过程工作流

    • 商业建模(Business Modeling)
    商业建模工作流描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用例模型和商业对象模型中定义组织的过程,角色和责任。
    • 需求(Requirements)
    需求工作流的目标是描述系统应该做什么,并使开发人员和用户就这一描述达成共识。为了达到该目标,要对需要的功能和约束进行提取、组织、文档化;最重要的是理解系统所解决问题的定义和范围。
    • 分析和设计(Analysis & Design)
    分析和设计工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。
    • 实现(Implementation)
    实现工作流的目的包括以层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。
    • 测试(Test)
    测试工作流要验收对象间的交互作用,验证软件中所有组件的正确集成,检验所有的需求已被正确的实现,识别并确认缺陷在软件部署之前被提出并处理。
    • 部署(Deployment)
    部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动,包括:软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。
     
     

    核心辅助工作流

    • 配置和变更管理(Configuragion & Change Management)
    配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体,跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。
    • 项目管理(Project Management)
    软件项目管理平衡各种可能产生冲突的目标,管理风险,克服各种约束并成功交付使用户满意的产品。其目标包括:为项目的管理提供框架,为计划、人员配备、执行和监控项目提供实用的准则,为管理风险提供框架等。
    • 环境(Environment)
    环境工作流的目的是想软件开发组织提供软件开发环境,包括过程和工具。环境工作流集中于配置项目过程中所需要的活动,同样也支持开发项目规范的活动,提供了逐步的指导手册并介绍了如何在组织中实现过程。

    转载于:https://www.cnblogs.com/shizhiyi/p/7745658.html

    展开全文
  • 敏捷开发系列中,把一种开发流程命名为Scrum,其实就意味着,这种敏捷开发的流程,就像是大家在一起打橄榄球,敏捷的动作、富有战斗的激情、人人你争我抢的拼搏精神。这些无一不是现在开发中迫切需要的东西。

    由来


    为什么是Scrum?Scrum原本的意思是橄榄球运动的一个专业术语,指:“在橄榄球比赛中,双方前锋站在一起紧密相连,当球在他们之间投掷时他们奋力争球”。在敏捷开发系列中,把一种开发流程命名为Scrum,其实就意味着,这种敏捷开发的流程,就像是大家在一起打橄榄球,敏捷的动作、富有战斗的激情、人人你争我抢的拼搏精神。这些无一不是现在开发中迫切需要的东西。




    概念


    什么是Scrum?Scrum是一种灵活的软件管理过程,它可以帮助驾驭迭代、递增的软件开发过程,主要用于产品开发或工作管理。Scrum于1995年提出,并在2001年同其他方法论一起组成“敏捷联盟(Agile Alliance)” 。Scrum提供了一种经验方法,它使得团队成员能够独立地,集中地在创造性的环境下工作。


    特点

    • 敏捷的流程,可用于管控研发工作
    • 现有设计流程的总结
    • 以团队为基础,是一种在需求迅速变化情况下迭代的、增量的开发系统和产品的方法
    • 控制由利益和需求冲突导致混乱的流程
    • 改善交流、协调合作的最优方式
    • 检测产品开发和生产过程中障碍并将其去除的方式
    • 最大化生产率的一种方法
    • 适用于单一的项目到整个组织。Scrum可以控制并组织多件具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。 
    • 让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲,并让他们发挥到最佳水平。 


    Sprint(迭代)

    • Scrum的项目过程由一系列的Sprint组成
    • Sprint的长度一般控制在2~4周
    • 通过固定的周期保持良好的节奏
    • 产品的设计、开发、测试都在Sprint期间完成
    • Sprint结束时交付可以工作的软件
    • 在Sprint过程中不允许发生变更


    开发流程


    Scrum敏捷开发,是对流程控制比较严格的。每个环节都有一套完整的过程和严格的时间控制,我们项目组的主要开发过程如下图所示:



    角色


    ScrumMaster

    • 保证Scrum团队可以遵守Scrum的价值,实践和规范
    • 帮助Scrum团队和组织采用Scrum模式进行项目流程组织
    • 指导并带领团队变得更加高效,实现更高质量
    • 保护团队不要受到外界因素的干扰
    • 保证各个不同角色之间的良好协作,消除障碍
    • 帮助PO更好的利用团队的能力
    • 不要管理团队

    产品负责人PO(Product Owner)

    • PO是一个人并只能由一个人来担任
    • 负责管理产品待办事项表(Product Backlog)并保证其对于客户和团队保持透明度
    • 对产品待办事项表进行优先级排序
    • 与团队一起来进行工作量估算
    • 对于项目的成功负责并保证投资回报率(ROI)

    团队Team

    • 最佳团队大小:5~9人
    • 多功能团队:程序员,测试人员,设计师,数据库管理员和架构师
    • 保证团队成员全职参与开发
    • 自我管理,没有头衔之分,不组建子团队
    • 成员更替只能在迭代之间进行,更佳方式是在发布之间进行
    需要注意的是,第三点提到的全职参加是指完成了分配到的任务额即为全职参加。并不是指全程参加。


    迭代会议


    每日站立会议

    • 站立进行
    • 在固定的时间,固定的地点
    • 问题:你昨天完成了哪些工作?今天要完成哪些工作?遇到了什么困难?
    • 仅仅作为信息沟通用途,不解决任何问题
    • 不向任何人汇报
    • 15分钟

    迭代计划会议

    • 进行迭代规划
    • PO向团队介绍Product Backlog
    • 团队在PO的协助下充分了解Product Backlog
    • 确定迭代目标和迭代合约
    • 对Product Backlog进行细分并创建Story(一个具体的任务)

    迭代评审会议

    • 团队展示完成的功能并收集反馈
    • 对未完成的功能进行描述并说明原因
    • PO接受/不接受当前迭代
    • 邀请所有人,包括客户参与
    • 4小时

    迭代回顾会议

    • 哪些做的好
    • 哪些做的不好
    • 哪些可以改进
    • 进团队成员参与
    • 4小时

    项目管理工具

    • 禅道
    • JIRA
    • 其他。。。

    在项目初期,我们用到的管理工具是国内的一款开源软件——禅道,在项目初期,这款软件还是很强大的。开发团队在迭代计划会议中细化Product Backlog中的任务,生成一个个小的Story,然后由PO把这些Story更新到项目管理工具上(禅道)。

    然后组员登录该系统,根据喜好选择并领取任务,需要注意的是,每个成员可以领取多个任务,但每天只能有一个任务是“处理中”状态,这能确保组员能够专心完成某一个任务,而不用三心二意。如果这个任务和其他任务有依赖,则可以与PO协商之后,把该任务先改为“挂起”状态,开始另一个任务。

    随着开发的进行,我们的管理工具由禅道换成了JIRA,对于Scrum来说,JIRA更加的适合一些,因为JIRA在设计理念中就已经包括了Product Backlog、Sprint、Story等这些元素。同样的,由PO建立Story,组员去自由选择领取喜欢的Story进行开发。



    适用的项目 


    刚刚了解Scrum的朋友,经常会有这样的疑问:到底什么样的项目适合使用Scrum呢?我们也一直在探讨。首先,我们来看一下关于过程的定义。过程控制通常有两种形式,一种是预定义过程,另一种则是经验性过程。

    预定义过程

    • 每一项工作都可以被完全理解
    • 给予合理的输入定义,每次便可以得到相同的输出
    • 过程启动后,允许运行直到结束,每次运行产生相同的结果
    预定义过程的示例比如:生产混凝土的过程,只要原料配比确定,加入的顺序以及搅拌动作、搅拌时间确定,那么产出的结果将完全一样。

    传统的瀑布开发模式是基于预定义过程来设计的。

    经验性过程

    • 过程是不能够完全预定义好
    • 结果是不可预知的
    • 生产过程是不可重复的
    • 通过不断的检查和调整使得过程能够产出我们需要的结果
    经验性过程的示例比如:一场足球赛,我们不可能规定好每个人的动作,我们也不能预测比赛的结果,我们只能通过激励,通过不断检视和调整团队,让他们发挥到更好的水平,以达成战胜对手的目标。

    Scrum是一个经验性过程,它的核心是在项目的整个过程中提供给项目的参与者以及干系人高度的透明性,基于透明性来进行不断的检查和调整,通过不断的检查和调整持续的优化过程和产出结果,提升团队交付能力,以此达到按时交付高质量的,客户真正需要的产品。

    适合管理复杂的项目


    基于上述的对比,显而易见的是管理这种复杂的项目,我们不可能在一开始把整个的过程预先定义好,项目的结果如何,我们也很难再一开始就完全预知,项目存在很多的不确定性,整个项目过程也是不可能重复进行的。所以,管理这样的项目需要使用Scrum这样的经验性的过程来达到更好的效果。


    一点经验


    关于迭代计划会议


    在Scrum敏捷开发中,迭代计划会议是项目开始之前很重要的一个会议,它决定了项目能否顺利的执行下去。而且,在迭代计划会议上,PO、架构师、开发小组成员要对Product Backlog中的需求进行细化分解,分解成最小的任务,最好是彼此没有依赖(期望值,一般这个很难实现)。任务越小,完成每一个任务花费的时间也就会越少。在分解任务时,需要小组成员给该任务评估开发时间,即用多长时间能够完成该任务(Story)。

    开发中的沟通问题


    在开发中,组员之间、组员与ScrumMaster之间、以及组员与客户之间的沟通是相当重要的,如果在开发中,遇到什么不确定的需求或者问题,要及时的与ScrumMaster反应,以免做一些无用之功,时间对于Scrum成员来说是很宝贵的。ScrumMaster应该确保每个成员每天的有效工作时间,为每一个成员排除一切阻碍他们开发的困难,及时发现,及时沟通,及时解决。


    结语


    最后,说一点别的东西。就目前软件开发的现状来说,需求的变更是很平常的事情,初期客户由于不了解自己具体所要的系统,而描述的不清楚,但随着开发的进行,随着沟通的增多,客户会越来越清楚想要开发的系统,因此在开发中经常会变更需求。

    对于变更需求,传统的开发方式已经很难应对这种情况了。而敏捷开发就是应对这种需求变更最好的方式,以最小的核心需求进行开发,同时每一个迭代之后,都会以最新的需求作为目标,因此每一个迭代都会与客户的目标很接近,最终会完美的交付客户需求的系统。这就是敏捷开发的魅力所在,以最小的代价,完成最伟大的作品。

    展开全文
  • 敏捷之旅(http://agiletour.cn)是一个全球性的非赢利组织,目的在于提供一个高效有趣的敏捷开发学习途径,在全球范围内推广敏捷的思想。敏捷之旅北京是国内主要的举办城市之一,下面就简单回顾一下今年敏捷之旅...

    敏捷之旅(http://agiletour.cn)是一个全球性的非赢利组织,目的在于提供一个高效有趣的敏捷开发学习途径,在全球范围内推广敏捷的思想。敏捷之旅北京站是国内主要的举办城市之一,下面就简单回顾一下今年敏捷之旅活动。

    众筹过程

    一次偶然的机会 @王立杰 在群里分享了“黑马运动会的众筹思维与粉丝经济”的文章,小伙伴们觉得可以尝试用这种方式举办今年的敏捷之旅北京站活动,于是10月10日当天开始组建敏捷之旅北京众筹微信群,不到一天的时间,聚齐了400多人。随后我们发起了众筹讲师,众筹场地,众筹大会主题等活动,最终众筹活动通过众筹网上线。

    大会主题是“敏于思、捷于行,众享之旅”,是来自胡莱科技的曾著提出的,也是从30多个提出主题中,由参会者选出的。

    大会的场地,由参会者主动联系各自公司,友情支持。最终参会者选择了广联达的会议室。

    11月2号晚上在众筹网发起了“史上最不靠谱的敏捷聚会”项目,目标筹资¥30,000RMB,在小伙伴们和参会者一起在朋友圈转发活动,宣传这次敏捷之旅北京站活动的新玩法,截至到11月24号早上到达了目标,筹资到了¥30,757RMB,用20多天完成了这次的众筹项目,要感谢所有参与者对这次活动的支持。

    活动讲师

    10月15号发起了“敏捷之旅北京众筹”讲师征集,先后有20多位讲师报名参与,经过小伙伴的筛选与讲师的线下、线上的试讲,最终有13位讲师入选,还邀请了东北亚研发中心精益敏捷转型项目总监Evelyn Tian作为特邀讲师。

    金牌赞助

    我们联系了去年的金牌赞助商 Unlimax(安迈无限),JIRA软件中国代理,他们表示今年仍然会赞助今年的敏捷之旅北京站活动。还联系到一家做数字营销以及客户关系管理的服务商BoldSeas(彪洋科技),作为活动第二个金牌赞助商。

    图书赞助

    每次活动我们都会为参会者准备很多图书,这次我们联系了好几家出版社,包括:图灵出版社、清华大学出版社、人民邮电出版社、博文视点,还有个人要主动为我们的活动提供图书,特别感谢为本次活动提供赞助图书的出版社及个人。

    礼品赞助

    除了图书,我们还为参会者提高很多礼品,这里也要感谢提供礼品的赞助商。
    1、ShineScrum提供了CSM的认证课名额一个;
    2、互动出版网提供的水杯、图书以及代金券等;
    3、七牛云存储提高的充电宝和小玩偶;
    4、亿家净水提供的净水器3个;
    5、麦思博(msup)提供的笔记本和笔;

    场地赞助

    最后特别感谢为本次活动提供场地赞助的广联达公司,主会场可以容纳200多人,以及不同的分会场,场地非常的赞,午餐也有多种选择,很丰盛。

     

    活动当天

    11月29日活动当天约300多人参会,整个大厅都坐满了,后面来的只能站在后排。还为参会者准备了各种礼品、茶歇零食以及大量的图书,最后还有CSM认证课大奖一名。


    为支持千元的参会者赠送了“荣誉资深敏捷驴友”水晶奖杯和北京敏捷社区2016全年活动通行证一本。


    为支持五百元的参会者赠送了北京敏捷社区2016全年活动通行证一本。


    还请到了国内做视觉引导的VTC团队,他们用绘画的艺术纪录下了整个大会的过程。

    组织者/志愿者

    8月29号组织者们齐聚北辰世纪中心,开展了北京敏捷社区未来规划研讨会,用一整天的时间产出了北京敏捷社区的核心、目标、使命、愿景以及行动计划,这里要特别感谢@Willa(王薇)老师的引导和付出。


    最后感谢所有的参会者、VTC团队、讲师和组织者,特别感谢所有的赞助商。

    北京敏捷社区

    社区的朋友圈大都集中在微信群中,我另外开了一个QQ群,欢迎敏捷爱好者以及敏捷实践者加入。

    本次活动的相关资料已在群内共享。

    北京敏捷社区QQ群:364053442

    转载于:https://www.cnblogs.com/jetlian/p/agiletour-2015-beijing.html

    展开全文
  • 初识敏捷,接触到下面这些这些新词汇。...Scrum来自英式橄榄球,敏捷开发的团队就好比一只橄榄球队,他们拥有明确的最高目标,而且每时每刻都朝着目标努力,他们熟悉最佳实践,高度自我管理,高度协作...
  • 记2015深圳敏捷之旅

    千次阅读 2016-01-10 20:55:44
    深圳敏捷之旅这次是第5次举办了,也是我第三次参加,本来买不到门票的,还好ShineScrum的朋友帮忙又弄了些票,这才有幸与深圳近300位敏捷爱好者共享了这次敏捷盛宴。  这次到会的嘉宾都特别给力,一天的分享让我...
  • 而成都是敏捷之旅进入中国的首,在2009年一次率先举办,到2013年已经连续举办了5届。2013年敏捷之旅成都于12月21日在天府软件园C1会议室举行。当天正值寒冬,寒风凛冽,细雨蒙蒙,2013敏捷之旅成都如期举行。...
  • 什么是敏捷开发

    2019-10-31 15:50:18
    本篇分享的是:【什么是敏捷开发 】 目录: 1.几种开发方法 1.1瀑布式开发 1.2迭代式开发 1.3螺旋式开发 2.敏捷开发 2.1 敏捷开发的诞生 2.2敏捷开发宣言 2.3 敏捷开发 3.敏捷开发方法 ...
  • 敏捷开发--(1)敏捷开发入门谈

    千次阅读 2012-07-31 13:31:52
    发版后,有一段空闲期,闲来无事,看到同事桌上有本《轻松Scrum之旅--敏捷开发故事》,就借过来读了一下,通篇就是一个产品的敏捷开发过程,从概念和使用方法上看,能有不小收获。这次就写一下自己初次体验敏捷的...
  • 这是敏捷开发般若敏捷系列七篇。(一,二,三,四,之五六,七,八,九) 重新认识CMMICMMI其实是一种敏捷开发方法,何以见得?CMMI是由美国军方的甲乙双方密切配合产生的国防部招标标准,在...
  • 敏捷之旅2013北京的总结

    千次阅读 2013-12-23 09:49:51
    从2010年开始,国内敏捷社区的一批先行者,包括知名的敏捷培训师和教练,开始在全国范围内组织敏捷之旅系列活动,以让更多的城市和更多的朋友借此平台,了解敏捷,结交朋友,交流互动,从而形成一个全国范围内的社区...
  • 敏捷开发之XP

    万次阅读 2015-09-25 11:15:11
    XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比,其最大的不同在于: 在更短的周期内,更早地提供具体、持续的反馈信息。 在迭代的进行计划编制,首先在...
  • 敏捷软件开发 敏捷是世界上使用最广泛,最受认可的软件开发框架之一。...我们将逐步引导您完成敏捷之旅,直到您了解使用敏捷背后的理念,优势以及如何实践它。本系列旨在使读者能够将敏捷和Scrum学习应用到他们的工...
  • 相约深圳~敏捷之旅

    2019-06-30 17:27:50
    一、相识敏捷开发 敏捷之旅 203年深圳,活动组织130人左右,大家来自不同的公司,来自不同的职能岗位,来自不同的人生阅历背景,来自对敏捷开发的不同认知,来自对敏捷开发的不同实践,大家坐在一起学习、探讨敏捷...
  • 2013深圳敏捷之旅

    千次阅读 2014-01-14 19:04:36
    今天刚参加完2013深圳敏捷之旅,有幸在一天收获那么多敏捷知识,听那么多大牛分享管理经验,真是非常不错。  今天的议题比较多,吴穹老师的自动化测试,华为胡伟分享的打造自组织的敏捷团队,李小波的coding dojo,...
  • 时值Scrum诞生25年及敏捷宣言诞生17年,中文原创敏捷类书籍如雨后春笋般冒出,这标志着敏捷这一工作方式在中国已跨越雪山草地。《猎豹行动》以小说体拔类其中。能够以一本小说把敏捷写出来,值得钦佩。作者@刘华...
1 2 3 4 5 ... 20
收藏数 3,845
精华内容 1,538
关键字:

敏捷开发系列之旅 第五站