敏捷开发中fdd什么意思_fdd敏捷开发 - CSDN
  • 敏捷开发

    2020-03-18 17:38:13
    敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此...

    敏捷开发是一种以用户的需求进化为核心,迭代,循序渐进的开发方法。

    在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    敏捷开发模式的分类
    敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

    XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程等,关键要看具体的应用场景。

    SCRUM 则是一种开发流程框架,也可以说是一种套路。SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。在这里我们重点讨论的是 SCRUM。

    SCRUM

    Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
    User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
    Task:由 User Story 拆分成的具体开发任务。
    Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
    Daily meeting:每天的站立会议,用于监控项目进度。有些公司直接称其为 Scrum。
    Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
    Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
    Release:开发周期完成,项目发布新的可用版本。

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由产品负责人(Product owner)负责的;

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

    7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

     

    https://blog.csdn.net/xiajun2356033/article/details/81513957

    https://blog.csdn.net/csdn15556927540/article/details/90712308

     


     

     

     

    展开全文
  • 敏捷开发方法学及应用

    千次阅读 多人点赞 2013-12-13 00:20:54
    敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...

    敏捷开发方法学及应用


    简介


    本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也适用于团队领导人,项目经理,产品经理,开发经理,测试人员,质量保证经理,质量保证工程师,技术作者,用户体验设计者,以及任何与制做发布软件相关的人员。本文着重于技术团队怎么很好的合作去计划,开发并发布软件。本文不着重于编码,技术细节或微软工具。希望本文能改善你的专业生活和团队效率。


    背景

    下图是Winston Royce的瀑布式开发模型:

    ( "Managing the Development of Large Software Systems",1970 IEE paper)


    无论项目有多大有多复杂,有两个关键的步骤常用于所有的计算机程序开发:1) 分析 2) 编码。

    接下来,Winston Royce介绍了最重要的五步:

    第一步:程序设计


    分配任务处理流程,功能,数据库处理,明确数据库流程,分配执行时间,明确操作系统间的接口与处理流程模块,描述输入与输出流程,并且明确初步的操作流程。撰写容易理解的,信息量大的,当前时新的概要文档。

    第二步:撰写设计文档


    管理软件开发的第一条规则就是无条件服从的执行文档需求。

    第三步:重复两次


    第二个非常重要的成功标准以产品是否完全原始为重中之重。如果把还有疑问的计算机程序开发为第一版,考虑到严格的设计/操作领域,那么给客户正式部署的版本实际上是第二版本。

    第四步:计划,控制,监控测试


    在成本和计划方面上,这是最有风险的一步。当备选方案几乎或一点不可用时,它会出现在日程安排的最近时间点上。

    第五步:让客户参与


    让客户参与到项目中是非常重要的,因为客户可能在最终发布之前较早的认可项目工作。



    仔细阅读Royce的文章后发现:
    1. 每一阶段都应该迭代式地传递到下一阶段。
    2. 软件发布前对软件整体流程实践两次。
    3. 简单单一的阶段传递会造成项目失败。

    不幸地是,上面列出的步骤当中,设计迭代从来没被限制成连续的步骤。



    下面这些东西都是什么?



    答案是:





    敏捷开发并不意味着只是一种方法。上面雨伞下的术语代表着不同的敏捷开发方法。

    敏捷软件开发宣言


    我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:


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


    也就是说,上面右侧(蓝色字体)内容有其价值,但我们更重视左侧(红色字体)产生的价值。

    敏捷宣言的十二条原则


    我们遵循以下原则:

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

    很多开发者都经过这样的噩梦:没有任何实践可以辅佐的项目。由于缺乏有效的实践,项目变得不可预测,重复出现错误,还有白白浪费的辛苦。计划延期,超出预算,质量低下使客户感到失望。开发者也由于更长时间的工作而换来更糟糕的软件而心灰意冷。

    DSDM


    DSDM(Dynamic Software Development Method),动态软件开发方法,通过提供一个负责整体开发周期的框架来弥补RAD(Rapid Application Development)快速程序开发的不足。下面是DSDM的主要功能:
    1. 用户参与
    2. 迭代和递增开发
    3. 提高了发布频率
    4. 集成测式于每一阶段
    5. 已发布产品的可接受程度直接取决于需求的实现

    FDD

    FDD(Feature Driven Development),功能驱动开发,是一种包装方法学。它允许你在非常高的级别上应用一个方法来管理项目,但它也允许你在较低的级别上应用其它方法学。FDD的着重点是能够把估算,日程计划,项目状态汇报作为一个整体或放到颗粒级别上,但是FDD不会规定一个非常细节化的方法让你应用去创建日程计划,相反FDD让你去觉决定该用什么方法。FDD的观点是你可以查看一下你的项目,陈术一下项目的确切状态,如项目进度是否及时,延时或过早等等。

    Lean


    Lean思想是一种进行系统优化的途径,它关注于减少浪费,提高整个系统总体流程。Lean在制造业上有着丰富的历史,近几年在在软件开发行业也越来越流行。Lean来源于制造业中的Lean(Lean Manufacturing: http://www.mindtools.com/pages/article/newSTR_44.htm),它是一组为满足质量,速度和客户需求而定制的原则。

    七大Lean软件开发原则:

    1. 估算浪费
    2. 构建质量
    3. 创建知识
    4. 延迟承诺
    5. 快速交付
    6. 尊重人
    7. 优化整体

    软件产品的交付工作应用这些原则并不是我们的最终目的。我们并不是说让我们用Lean吧,而是把Lean原则做为决策的向导或参考去选择可以改善整体系统的技术。比如,TDD测试驱动开发,通过在每一个功能点上创建功能自我测试从而构建软件的完整性和完善性。

    Plan(译外话:指瀑布式开发Waterfall Development)


    在计划驱动开发中,如果一个项目确切的按照计划执行,那么它就是成功的。因此,在软件开发中计划驱动开发依赖于需求的稳定性,明确性和固定性。你或许知道这些奢侈的性质是在大多数软件项目中不存在的。

    计划驱动方法学,在初期的设计阶段的需求变更中成本花费较低,但是一旦到了开发阶段需求变更将会花费昂贵的代价。所以,很多的工作被要求在初期计划设计阶段完成。然而,软件开发不同于普通的项目,我们不能保证将来的开发阶段会完全按照初期的设计进行,无论你的设计有多么出色。

    "Walking on water and developing software from a specification are easy if both are frozen."- Edward V. Berard
    在水上行走和开发软件都只有当它们被冻结时才会变得容易。

    敏捷开发打破了对需求稳定性的依赖,它有一个专门的流程用于负责需求变化,主要体现在它的自适应计划和进化式设计。

    自适应计划,意思是多次的仔细检查整体项目流程,经常会再次制定计划并再次适应。
    进化式设计,有一些实践对它很有帮助,如自我测试代码,持续集成,重构,简易设计等。

    敏捷开发是价值驱动,传统的瀑布式开发是计划驱动。这并不是说计划驱动就没有价值,在特定的实际情况下它们都有各自的有优缺点。关键是怎么平衡使用两种方法,在特定情况下采取它们的长处而回避它们的短处。

    Plan VS Agile

    计划驱动开发模式和敏捷驱动开发模式在基本原理差异上有两大不同。
    第一大不同:计划驱动模型中只能在项目完成时才能部署一个新模块,而且是较大的模块。敏捷驱动模型中可以频繁的部署新模块,甚至较小的模块。
    第二大不同:计划驱动是序列化的,敏捷驱动是并发的。在计划驱动模型中,一个流程的开始必须在前一个流程完全成功结束的前提下进行。在敏捷驱动模型中,任何时候都可能在做计划,流程是并发的或互相穿插的。


    “Plan your work, then work your Plan” by Martin Fowler and Neal Ford
    先计划你的工作,后工作你的计划。
         

          


    敏捷开发和计划驱动开发(瀑布式开发):
    • 都提供了操作流程,操作工具和操作技术。
    • 都需要严格的有条不紊的方法进行软件开发。
    • 都各自有优缺点。
    • 敏捷开发适合的情况,计划驱动模型不一定适应。
    • 敏捷开发强调流程上的不同。
    • 计划驱动模型强调正式的沟通与控制。
    • 敏捷开发强调连续的沟通和处理变化的能力
    • 计划驱动模型是关卡式控制质量,敏捷开发是高迭代式开发确保质量。
    • 计划驱动模型仅在产品最终完成后进检查,敏捷开发每完成一小块工作就进行检查。
    • 计划驱动模型以预估什么将被交付为起点,敏捷开发以完成一个需求为目标做为起点
    适应变化能力(Y轴)                            时间(X轴)



    可见性(Y轴)                               时间(X轴)








    在敏捷开发中:
    客户满意度是以迅速,持续的交付可用软件为导向。
    强调人和互动要高于强调流程和工具。
    客户,开发者,还有测试人员一直保持互动。
    可用软件频繁的被交付使用(按周交付高于按月交付)
    面对面交流是最好的沟通形式。
    业务人员和开发者保持近距离的,日常的协作。
    持续关注出色的技术和设计。
    适应易变情况。
    需求中较晚的改动也受欢迎。

    善于使用计划驱动模型的管理团队同样也能够善于使用敏捷开发方法。

    缺乏能力使用计划驱动模型的管理团队也没有能力使用敏捷开发方法。


    敏捷开发Agile


    敏捷软件开发的原理和价值用于帮助团队打破流程循环膨胀,着重于用简单的技术去实现目标。目标?什么是目标?

    每一个软件开发者,开发团队的主要目标是为老板和客户制造尽可能高的价值。

    敏捷开发的核心是把传统的软件开发方法(瀑布式开发)的五个步骤压缩成一个一周的开发周期。用敏捷开发方法去开发一个系统时,项目中会不断贯穿着重复的周期开发和较小模块的开发,并在开发过程中允许开发者测试和检查。高速度,低成本,灵活性是敏捷开发的主要优势。


    敏捷开发发展极为迅速,从2001年的只有1%的开发者使用敏捷开发到现在的60-80%的开发者在使用敏捷开发。更大的吸引力是因为敏捷开发提供:
    • 改善的质量
    • 在项目过程中有更多的机会做出修改更正
    • 提高客户或商业满意度
    • 使业务和IT更好的组合在一起
    • 更优化的面向市场的时间


    敏捷开发使用者从来不会害怕变化。他们把需求变化看作是好事,因为这些变化意味着团队又收获了更多关于怎样满足客户的经验。敏捷开发团队成员一起协作项目的方方面面。每一个成员都允许为项目整体提出意见或做贡献。没有一个团队成员是单一的负责架构或者需求或者测试。团队分享这些责任,同时每个成员都会对它们产生影响。

    我们有很多的敏捷开发流程:Scrum,crystal,BDD(Behavior-Driven Development行为驱动开发),TDD(Test-Driven Development测试驱动开发),FDD(Feature-Driven Development功能驱动开发),ADP(Adaptive Software Development自适应软件开发),XP(Extreme Programming极限编程),等等等等。然而,大量成功的敏捷开发团队从所有这些方法中吸取经验与知识,进而调整生成他们自己特有的敏捷开发方式。这些改编后的方法通常与SCRUM还有XP组合在一起,SCRUM实践用来管理使用极限编程XP的团队。


    极限编程XP


    As developers we need to remember that XP is not the only game in town.- Pete McBreen
    作为开发者,我们需要记住极限编程并不是城里唯一的游戏。

    极限编程强调团队合作(经理,客户,开发者)。它从五个关键点改善软件项目:沟通,简明,反馈,尊重,还有勇气


    维基百科对极限编程的定义:极限编程XP是一种软件开发方法,它的意图是提搞软件质量及对用户需求变化的响应能力。作为一种敏捷软件开发方法,它提倡在短开发周期中频繁地发布,从而提高软件生产力并提出新客户需求能够被采纳的检查点。


    极限编程是一系列嵌入到敏捷开发中的简易并坚实的实践。极限编程是一个非常好的通用软件开发方法。许多项目团队都采用它,同时更多的团队通过添加或修改实践来把它变得更适用。
    • 它是大多数敏捷开发方法的始祖
    • 在90年代末期和21世纪初期,Kent Beck提出了热门的话题
    • 协调流程与实践
     Kent Beck 的基本观念:
    • 采取已关注过的有效团队实践
    • 迫使它们走向极端

    “迫使它们走向极端”是什么意思呢?是不是如下图一样?

    或者下图


    不,这不是极限编程。让我们看看它的真正意思:


    出色的实践       迫使它走向极端
    代码复查 结对编程
    测试 TDD测试驱动开发和常数回归
    软件设计 不停地重构
    简单 最简单的事会有意想不到的效果
    集成测试 不断的集成/整合
    短迭代 把制定计划当作游戏

    极限编程是一系列遵循敏捷开发原则和价值的实践。极限编程是离散的方法,而敏捷开发是一类方法。有很多的敏捷开发方法,极限编程只是其中一种。
    极限编程在敏捷开发方法中是范围宽阔,出类拔萃的。Scrum有些类似极限编程,拥有极限编程的大多数特征。但是在细节是它们有很多的不同,公平的说Scrum是是极限编程的子集。甚至,许多Scrum团队争论着要把极限编程实践加入Scrum流程中,如满意度测试,结对编程,持续集成,以及测试驱动开发。
     

    在所有敏捷开发方法当中,极限编程是唯一的一种方法为开发者的日常工作提供深度的,意义深远的开发准则。在这些准则中,测试驱动开发是最革命性的。下图中都是一些出色的极限编程实践。


    Scrum


    Scrum是和种迭代式及递增式的敏捷软件开发框架,它用于管理软件项目,产品,或程序的开发。它的着重点是一个灵活的,全面的产品开发策略,它把一个开发团队通常作为一个单位进而实现一个常规目的。相反,它不着重于传递的序列化式的方法。Scrum会问传统瀑布式开发“为什么我们要花费这么长时间,这么多努力去做一件事?为什么我们不能衡量出做一件事所需时间和人力?” Scrum拥抱变化和创造力,因为这是人们的工作方式。Scrum有一个流程学习结构,能够让团队评估他们做了什么以及他们怎样做的。
    • 1986年,Scrum第一次被定义成一个灵活的全面的产品开发策略。--Hirotaka Takeuchi,Ikujiro Nonaka
    • 1995年,Sutherland和Schwaber共同地发表了一篇关于Scrum方法学的论文。



    Scrum角色


    三个核心角色:
    1. 产品持有人 Product Owner
    2. 开发团队 Development Team
    3. Scrum领导人 ScrumMaster

    产品持有人 Product Owner


    • 产品持有人代表着公司或股东的权益并传递客户的声音。
    • 专门负责确保商业价值
    • 制定以客户为中心的一些工作条目,排序后放到产品待处理列表(Product backlog)中。
    • Scrum团队应该有一个产品持有人,他/她也可以是开发团队中的一员。
    • 产品持有人不是Scrum领导者(ScrumMaster)。

    开发团队 Development Team



    • 在每一个Sprint周期结束后,负责交付将来需要发布的产品的模块。
    • 由3到9人组成并拥有各种所需技能(分析,设计,开发,测试,技术沟通,文档,等等)。
    • 自我组织,有可能需要与更高级的项目管理部门交流。


    Scrum领导人 ScrumMaster



    • 专门负责扫清团队在交付Sprint目标或产品中遇到的障碍。
    • 不是团队领导人,但是扮演着团队与可能分散团队注意力的影响之间的缓冲区。
    • 确保Scrum流程的使用在计划中。
    • 规则强制执行人。团队保护者,以保持团队专注于他们手中的工作。
    • 也会被看作一个人民公仆去加强这些双重观点。
    • 不同于一个项目经理,没有与ScrumMaster不相关的人员管理职责
    • 没有任何额外的员工责任。

    Backlog未完成项列表


    产品的待完成项列表是一个需求的排列列表,我们维护这个列表是为了更好的开发产品。它的组成有功能,BUG修复,非功能需求等任何为了成功发布可用软件系统的所必须的内容。在Scrum中,开始一个项目不必先开发一个冗长文档去记录所有的需求。这个敏捷产品backlog对于第一个Sprint足够了。当有更多产品需求时和客户需求时,Scrum产品backlog允许变更和增加。

    Sprint backlog是开发团队下个Sprint需要处理的工作列表。这个列表是产品backlog最上面的需求项衍生出来的,直到开发团队在这个Sprint中有足够的工作去做。开发团队通过问一些问题来完成backlog的选择,如“我们是不是也能做这个?”。



    从概念上讲,团队从优先级最高的Scrum backlog开始画一条线划分出优先级较低的项,同时线上面的backlog也是团队认为他们可以完成的项。在实践中,团队通常不会去选择优先级最高的五项再选择优先级较低的两项组合在一起即使它们是互相关联的。


    敏捷开发调查

    这项调查发起于2012年8月9日至2012年11月1日之间,由VersionOne赞助的。调查从软件开发社团的不同渠道中选择了4048人。数据由Analysis.Net Research分析并总结成报告。

    谁知道敏捷开发?


    一般情况下,相比业务人员,越接近开发团队角色的人了解敏捷开发的越多

    敏捷开发失败原因


    进一步使用敏捷开发的障碍物


    使用敏捷开发最大的担心




    总结


    一个好的敏捷团队会选择最适合他们的管理与技术实践。当试着去使用敏捷开发时,会有一万个借口为什么这行不通。只有那些真正理解敏捷开发优势并真心实意地想要使用敏捷开发的人们才会有可能成功。那些正在搜索为什么Agile会失败的人们,他们可能最终会找到答案也可能放弃之前所做的一切努力不再使用敏捷开发。Elisabeth Hendrickson称这种行为“假敏捷开发”。



    为了支持一下我的结论,让我们引用一些名言(从Robert C. Martin收集):
    "In preparing for battle I have always found that plans are useless, but planning is indispensable." - General Dwight David Eisenhower 
    在战斗准备中,我总是发现那些计划是鸡肋,但是制定计划是不可缺少的。

    局限于别人的方法世界里不是可取的,因为公司需求,公司情况,项目都有可能一直在变化着。如果你想你的项目成功,你一定要灵活地应用这些现成的方法去管理项目。任何单一的方法都不是一把尚方宝剑,因此关键是看哪种方法适合你并能协调你的方法去满足你的个人需求。

    记住,Scrum和Agile不是一个死产品 ,它是在持续改进的基础上不断进行中的一门哲学。


    翻译:http://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t
    展开全文
  • 什么敏捷开发

    万次阅读 多人点赞 2019-05-31 10:49:56
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,...

    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。

    在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

    简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

    是谁这么厉害,提出了敏捷开发思想?是一位名叫 Martin Fowler 的美国大叔。

    大叔不但是敏捷开发的创始人之一,还在面向对象开发、设计模式、UML 建模领域做出了重要贡献。目前担任 ThoughtWorks 公司的首席科学家。

    敏捷开发模式的分类
    敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

    同样是敏捷开发,XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程等,关键要看具体的应用场景。

    SCRUM 则是一种开发流程框架,也可以说是一种套路。SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。在这里我们重点讨论的是 SCRUM。

    SCRUM 的工作流程

    学习 Scrum 之前,我们先要了解几个基本术语:

    Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
    User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
    Task:由 User Story 拆分成的具体开发任务。
    Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
    Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
    Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
    Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
    Release:开发周期完成,项目发布新的可用版本。
    在这里插入图片描述
    如上图所示,在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份 Product Backlog,为项目做出整体排期。

    随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的 Sprint Backlog,再细化成一个个 Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行 Daily meeting,根据情况更新自己的 Task 状态,整个团队更新 Sprint burn down chart。

    当这一周期的 Sprint backlog 全部完成,团队会进行 Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的 Release,并且进行 Sprint 回顾会议(Sprint Retrospective Meeting)。

    那么,现实中的 Scrum 是什么样的情景呢?看看下面的照片就知道了:
    在这里插入图片描述
    敏捷开发与 DevOps
    DevOps 是 Development 和 Operations 的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢?需要我们的项目做到持续集成、持续交付、持续部署。

    时下流行的 Jenkins、Bamboo,就是两款优秀的持续集成工具。而 Docker 容器则为 DevOps 提供了强大而有效的统一环境。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 敏捷开发 模型讲解

    千次阅读 2017-03-01 16:56:54
    CSDN:在你的工作生涯,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...

    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法?

    黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我个人比较倾向于 Scrum。我理解的敏捷其实是一种思想,Scrum 是对让这个思想落地的一个参考。也就是说,我们大可不必完全拘泥于 Scrum 定义的规范,只需要参考它并结合自身的条件做适当调整即可。比如说,每日站会这个环节就非常重要,不管是放在每天上午,还是放在每天下午,总之最好要有固定的周期。此外,每次 Sprint(迭代)结束后除了有评审会以外,Scrum Master 不要忘记对本次 Sprint 做一个回顾与总结,哪些是本次迭代中做的好的地方,哪些是做的不好的,再对比上次迭代的的结论,哪些是有改进的,哪些是新的问题。

    Scrum 提供了三类角色,分别是:Product Owner(一般由产品经理担任)、Scrum Master(一般由开发经理担任)、Scrum Team(包括开发与测试人员),其中,Scrum Master 的角色至关重要,对项目的成败起决定性作用。

    阿里巴巴也在广泛使用 Scrum 敏捷开发模式,而且整个项目几十人都可以用 Scrum,只是首先需要将整个团队拆分成若干小团队,保证每个小团队按照 Scrum 进行操作,此外,再将每个小团队的 Scrum Master 召集在一起,再做一轮 Scrum,这就是所谓的 Scrum of Scrum。过程稍微复杂一点,但可以将敏捷用于更大的团队规模,并能保证敏捷的效果。

    CSDN:你认为Scrum Master 的角色至关重要,对项目的成败起决定性作用。那敏捷开发中由产品经理担任Scrum Master会有什么问题?

    黄勇:我个人不太建议由产品经理来担当Scrum Master,原因如下:

    1. Scrum Master 关注的是项目开发视角,而产品经理关注的是产品功能视角,两者关注的视角是不一样的。
    2. Scrum Master 需要有一定的技术开发功底,需要对开发工作量进行评估,也需要对技术实现进行评审,可能还会有一定的编码工作,而具有技术功底的产品经理毕竟太少了,即便有的话,可能对技术方面也不会太深入。
    3. 需要有一个人,他来对整个产品负责,这个人就是Product Owner,该角色最好由产品经理来担任。

    CSDN:敏捷开发过程中测试团队的职责和产出是什么?

    黄勇:在敏捷开发过程中,我认为测试团队的职责有以下几点:

    1. 根据产品需求,定义测试用例。
    2. 针对测试用例进行功能测试,并将测试的结果反馈给开发人员。
    3. 负责搭建系统运行所需的环境,包括软件安装、数据初始化等。

    CSDN:除了Scrum,还有XP、CM、FDD、ASD、DSDM等敏捷开发方法,如何去选择一个合适的敏捷开发工具或者方法呢?

    黄勇:敏捷开发方法有很多,不仅仅只有Scrum 一种,其实不妨相互借鉴,再结合自身的特点,定义一套适合自己的敏捷开发方法。例如XP 中所提倡的结对编程、持续集成、测试驱动等,这些都是很好的方法,值得借鉴。包括看板也是一个很不错的工具,可以结合Scrum 来工作。

    CSDN:从博客上,你也研究过「使用看板进行敏捷开发」,能不能分享你的研究成果?

    黄勇:敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

    我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

    • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。
    • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。
    • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

    可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!

    那么 Kanban 到底是什么呢?我们先来看看这张表格吧:


    下面我们来理解一下这个表格吧!

    • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)
    • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)
    • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

    在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

    实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

    需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

    也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

    对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

    好!继续我们的 Kanban,有意思的事情即将发生!


    产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

    开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

    开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了 然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


    现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


    有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


    部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


    此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


    完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


    所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


    部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


    整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


    看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


    几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

    我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!


    CSDN:一个成功的项目,离不开每个人的努力,能够分享下你曾经的项目管理经验?

    黄勇:给大家提出以下 10 点建议及其目标:

    1. Sprint 第一天,需要将目标定义清楚,并让团队所有人都知道「确保建立一致的目标并使之明确」;
    2. 若出现需求变更,则优先排到下次迭代,特殊情况需特殊处理「确保本次迭代可以按时完工」;
    3. Scrum Master 将迭代中的需求分解为任务,每个任务只能有一个任务负责人,且不超过一个人天「确保每日任务可评估」;
    4. 让 Product Owner 直接与相关开发人员确定需求,Scrum Master 需一同参与「确保需求与实现不会发生偏差」;
    5. 每日定时站会,时长不超过 15 分钟,规模不要太大「确保任务完成情况与计划保持一致」;
    6. 每日进行一次代码评审,由 Scrum Master 负责,并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」;
    7. 各个团队的 Scrum Master 保持每日沟通一次,时间不要超过 15 分钟「确保项目管理不会出现风险」;
    8. 每次迭代结束,让大家稍微放松一下,可提供一些团队活动,比如聚餐「确保团队能够更加凝聚」;
    9. Scrum Master 需要给团队一些承诺,比如项目奖金或特殊福利等「确保团队更加有激情」;
    10. 对于情绪异常的员工,Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」;

    此外,作为项目管理者,需要不断在团队中加强以下 6 点文化:

    1. 方向一致
    2. 当面沟通
    3. 全情投入
    4. 充分信任
    5. 说到做到
    文章节选自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315,如需阅读完整访谈内容,请移步大神博客。
    展开全文
  • 敏捷开发之旅的第三站,我想要和大家一起分享FDD特征驱动开发方法。 特征驱动开发——Feature Driven Development 还是老规矩,讨论之前,我们先了解一下什么是Feature?什么FDD? Feature ...
  • 敏捷开发FDD过程

    千次阅读 2012-08-31 10:48:30
    FDD过程 阶段一:开发一个总体模型  本阶段一个最基本的项目范围内的活动,就是在一个有经验的对象建模人员即主架构师的指导下,业务人员和开发小组成员一起工作。  业务专家们完成一个贯穿整个系统及其内外...
  • 敏捷开发--特性驱动开发(FDD)

    千次阅读 2012-08-31 12:54:36
    什么是Feature: The unit of development and thus an increment in an FDD project - a feature - is tiny; … Features (tiny, granular pieces of client-valued function) are being completed every week ...
  • 敏捷开发思想

    千次阅读 2019-04-12 22:55:16
    敏捷开发思想SCRUM 是什么?敏捷开发什么?...Scrum是敏捷开发中的名词。 敏捷开发什么敏捷开发(Agile Development) 是一种以人为核心、迭代、循序渐进的开发方法。 简单的说的话: 它只是...
  • 那么,敏捷开发什么好处呢?    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐...
  • 敏捷项目管理框架及流程:在敏捷项目管理框架下可应用FDD(特征驱动开发)+ XP(极限编程)等方式
  • 那么什么敏捷开发呢?下面一起来了解一下相关的知识吧!  常用的 4 种开发模式:  1.瀑布式开发  瀑布式开发是由 WW.Royce 在 1970 年提出的软件开发模型,是一种比较老的计算机软件开发模式, 也是典型的预见...
  • <br /> 今天浏览51testing,有个讨论是“敏捷开发中,测试人员的工作成绩如何体现”,想想我们公司的项目不就是敏捷开发吗?需求不确定,经常改,做的差不多了,产品就交付,用户再提意见,再修改。看到有个人...
  • 敏捷开发什么好处?

    万次阅读 2013-08-19 18:17:04
    原文地址:敏捷开发什么好处?作者:苗得雨 软件开发方法一直处在不断发展过程。在诸多方法,敏捷开发以其能持续满足不断变化的用户需求正在受到越来越多人的重视,从中小项目开始进入大型开发项目,近几年来上升...
  • 时间到了2020年,敏捷开发早就已经是软件行业内一个几乎既成事实的标准,几乎每个软件研发团队都说采取了敏捷开发流程。 老司机以自己长期以来的软件实践,以及混迹于敏捷圈子近10年的体会,可以负责地说,敏捷原本...
  • 本文综述了嵌入式系统敏捷开发(Agile Development),敏捷宣言,敏捷的原则,很多的敏捷开发的实践习惯,敏捷开发与瀑布开发流程的区别,敏捷的任务stories划分,并行开发、敏捷的时间安排,敏捷的通信交流方式等等。...
  • 敏捷开发实践总结

    2018-11-25 23:46:06
    敏捷开发实践的认识什么敏捷开发敏捷开发的原则多种敏捷开发的方法一个敏捷团队敏捷开发中常用的术语迭代的典型流程致谢 什么敏捷开发 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发...
  • 敏捷开发中的文档怎么写

    千次阅读 2018-06-05 13:19:13
    我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-&...国外的软件先行者们针对瀑布开发暴露出来的问题进行了一系列的探索、思考和总结,提出了Agile Dev的概念,中文翻译为敏捷开发。一.什么...
  • 敏捷开发 —— TDD(测试驱动开发)

    千次阅读 2018-06-06 22:45:43
    测试驱动开发 TDD(Test-Driven Development)是敏捷开发的一项核心实践,同时也是一种设计技术和方法。1. 基本思想在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷...
  • 敏捷开发原则及方法

    2020-03-10 11:46:37
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程软件一直处于...
  • 敏捷开发 简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目...
1 2 3 4 5 ... 20
收藏数 1,129
精华内容 451
关键字:

敏捷开发中fdd什么意思