敏捷开发应用_敏捷开发 应用场景 - CSDN
  • 如今,随着信息技术的不断发展,互联网进入了一个相对繁荣的时期,而企业要想跟得上潮流,信息化建设必不可少,但是面对眼花缭乱的软件开发公司,选择成了难题。 传统软件开发 传统的软件.....

    如今,随着信息技术的不断发展,互联网进入了一个相对繁荣的时期,而企业要想跟得上潮流,信息化建设必不可少,但是面对眼花缭乱的软件开发公司,选择成了难题。

    传统软件开发


    5cb07b1f0001617206450427.jpg

    传统的软件业务更多的是走定制开发的路子,当然,也有一些行业公司会选择通用软件,这些通用软件多由一些大厂提供,价格上可以说不具备任何优势。比如,我们经常会提到的sap,动辄几十万的产品价格令许多公司望而却步,而实际上这里面有很多功能可能是企业并不需要的,实际操作起来也会更加复杂,这样一方面造成了浪费,另一方面还影响了企业资金的正确投入。因为一个发展中的企业,过多的资金投入在信息化建设上本身是不明智的,而软件并非越贵越好,适合企业的发展才是硬道理。

    快速开发平台


    5cb07b200001d85312400592.jpg

    鉴于企业软件实际需求的断层,快速开发平台进入了人们的视野。

    快速开发平台,顾名思义就是利用平台进行软件的快速开发,一般使用敏捷思想作为指导,力求功能完善、使用便捷、价格适中,以期解决企业信息化建设中的实际问题。

    目前,很多快速开发平台都标榜自己可以零代码开发,实际上这一点有待商榷,很简单,如果一个快速开发平台做到了零代码开发,那么功能势必要非常完善,因为每个企业的管理或业务特点都不尽相同,这就要求软件开发过程中所有细节都必须考虑到,这在实际开发的过程中是不现实的。如果说确实不用写一行代码,就可以完成一些常用功能,这个可以实现,但是这和通用软件的套路就差不多了,无非就是功能配齐全,需要再调用,灵活性受到限制。如果加上自己的人工成本,实际花费是否会比通用软件低,很难说。

    而且有一点需要明确的是,即使使用通用开发平台,后期需要的开发或者说配置总需要有人做,你是找一个懂开发的,还是找一个不懂开发的去做呢?而不懂开发的员工又愿不愿意做呢?懂开发的员工会不会感受不到自己的价值呢?后期如果出问题了谁维护呢?找开发公司?等得起吗?所以,基于通用软件思想做出来的软件开发平台,必然有它的局限性,妄想随便找一个人就把一个系统弄好是很不现实的,所以,基于敏捷思想做出来的快速开发平台才是一个合适的选择。


    5cb07b200001aea412400593.jpg

    快速开发平台的功能实现是需要开发人员的配合,当然,技术水平可以不用那么高,也就是说不用这个开发人员多厉害,基础的都都了解就行,这样企业一些比较个性化的需求,在框架的上进行开发配置,实现也比较轻松,后期的维护也省去了许多麻烦,控制权也会在自己的手里。

    相信,随着敏捷思想的不断深入,快速开发平台会得到越来越多人的认同,毕竟,价值才是第一驱动力。


    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69912114/viewspace-2641225/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/69912114/viewspace-2641225/

    展开全文
  • 关于敏捷开发部分思想在项目中的应用心得

    1.  极限编程在项目中的应用

    最早接触极限编程的概念是在2010年看的一本书《解析极限编程--拥抱变化》,当时并没有一下子看完,之后断断续续的读着。但在是实际项目中并没有真正的应用。

    在2011年3月份进入一个3500多万的项目中,在调研和开发的过程中,遇到了很多问题,在这个过程中,开始逐步的把极限编程的部分思想来应用于项目。

    1.1.  沟通很重要

      无论是在工作还是在日常生活中,沟通对我们来说,都是非常重要的交流与获取反馈的有效途径,在项目管理中,尤为重要。若沟通不良,对项目造成的影响是具大的,比如没有向客户询问该问的问题,而导致程序在关键性设计中出现失误。管理人员不向开发人员问该问的问题,而导致项目进度误报。

      在项目管理中,沟通是获取客户需求的关键,是程序设计的依据,是制定项目计划的参考。所以我们要促进良性沟通,避免不良沟通。

    1.2.  简单设计

    有三条准备可以避免软件项目中常见的戏剧性效果和机能障碍。

    1.在项目初期不可能收集到所有需求。

    2.不管你收集到什么需求,最终它们肯定会发生变化。

    3.总会有任务超时、超支。

    所以在设计的时候要尽量的简单,避免过度设计

    1.3.  每周交付一些有价值的东西

    大部分情况下,客户不能确切的告诉你他们需要什么,一旦客户见到第一个版本,他们就知道了在第二个版本中他们需要的东西……或者说他们在第一个版本中实际想要什么。所以我们有必要每周都交付一些可用的东西。

    这样做的好处是:

    1.及时反馈:可以及时获取用户反馈,通过频繁的与用户沟通、反馈,形成良性沟通,明确用户真实需求。

    2.保障项目进度:短周期的交付,便于项目的调整,减少用户意途与开发之间的理解误差。便于项目进度的掌控。

    3.给用户和开发人员信心:由于每周都能看到可用或可演示的东西,让用户对项目有信心,也可以了解项目进度,这要比一个月交付的一次更有说服力。同时对于开发人员,每周的功能都能得到用户的确认,若需要调整,也是小幅度调整,若不需要调整,则是对工作内容的肯定与激励,可以提高工作激情。

    1.4.  控制范围

    极限编程中的四个变量是:成本、时间、质量和范围,其中范围的控制最有价值。

    一般在项目合同中,均会对时间、范围进行约束,质量就不用说了,如果质量不合格,用户是不会验收的。对于成本和时间基本是不可能有大的改变的,对于范围,合同中不可能对边界定义的十分明确,这就需要我们在整个项目进展中进行有效控制。

    客户在开发的过程中,会将范围无限的扩大,如果项目经理不对范围进行控制,这个项目会不断的扩展,造成成本增加,开发周期变长,无法在合同规定内完成项目的验收。

    所以说范围的控制最为有价值,他是我们项目管理人员唯一有主动权的要素。

    关于质量和时间,牺牲质量以换取时间的做法是不可取的,这种短暂的收益在项目后期将导致致命的伤害。所以要平衡这两者的关系,使得开发人员可以在有限的时间内开发出高效的产品。

    1.5.  结对编程

    对于极限编程中的结对编程思想,在现实中似乎是不可能应用的,不过在2015年2月份,很有幸的体验了一下。

    在一个需求开发即将结束的时候,正好另外有一个需求过来,而且其中有一部分有重叠,于是我和另一个负责人商量了一下,决定把重叠部分进行重构优化,合并抽象为一个模块。由于对于这部分我们两人都了解,所以开发过程中,我们尝试了一下结对编程,他写代码的时候,我在旁边看着,并提示注意事项(当然还可以喝喝茶、吃点东西),然后我再接着写,他在旁边看着,并提示我注意或忽略的地方。3个小时,模块功能完成,测试通过,OK。

    这次尝试感觉还是很成功的,两个人的效率还是很高的,而且目标明确,思虑清晰,轻松高效。

    但是这种编程方式是不适合推广的:

       a.要求高:要两个人有一定的默契,不然反而事倍功半。

       b.国情:目前没有适合的土壤。

    2.   关于极限编程部分关键词

    参选书目:《敏捷武士:看敏捷高手交付卓绝软件》析级限编程》

    2.1.  概述

    极限编程是一个轻量级的、灵巧的软件开发方法;同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气;即,任何一个软件项目都可以从四个方面入手进行改善:加强交流;从简单做起;寻求反馈;勇于实事求是。XP是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期;通过积极的交流、反馈以及其它一系列的方法,开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。

     

    2.2.  核心价值

    极限编程中有四个核心价值是我们在开发中必须注意的:沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇 气(Courage)、此外还扩展了第五个价值观:谦逊(Modesty)。  XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱;无论是术语命名、专著叙述内容和方式、过程要求,都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践,在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

    2.3.  四个变量

    成本、时间、质量和范围,其中范围的控制最有价值。

    2.4.  四个准则

    沟通、简单、反馈、勇气

    2.5.  基本原则

    快速反馈、假设简单、递增更改、提倡更改、优质工作。

    2.6.  开发软件的四项基本工作

    编码、测试、倾听、设计

    展开全文
  • 敏捷开发-实例1

    2016-03-21 15:02:49
    本系列的第一篇【用户故事驱动的敏捷开发 – 1. 规划篇】跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog。产品backlog是敏捷开发中...

    用户故事驱动的敏捷开发 – 2. 创建backlog


    本系列的第一篇【用户故事驱动的敏捷开发 – 1. 规划篇】跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog。产品backlog是敏捷开发中用来管理需求列表,排定优先级,形成迭代计划,组织开发/测试和交付过程的工具。可以说,产品backlog是一个敏捷团队管理开发过程的核心,所有的活动和交付物都围绕backlog来进行。一旦需求明确,我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程,确保我们的想法可以按照我们希望的时间和质量交付,及时了解偏差并做出调整。

    从这个时间点开始,我们需要引入电子化工具来管理我们的开发过程。其实,每个开发团队都会或多或少的使用某种电子化工具,用最多的估计是Word/Excel/Project这种办公软件,还有就是如Jira, Redmine, Bugzilla 等工具。对于软件研发来说,我们需要管理内容包括:1)需求/任务/测试用例/Bug/问题等工作事项;2)源代码;3)各种计划,包括迭代计划,发布计划,测试计划等;4)各种工件(包括:依赖包/在制品/交付物),如:JAR包,WAR包,NuGet包,NPM包,安装包,交付包等;5)人员/团队。所以,对于软件研发管理系统来说,我们至少需要这些功能:1)工作项跟踪;2)计划制定和跟踪;3)人员(包括权限)管理;4)源代码管理;5)自动化引擎。

    很多敏捷教练其实对电子化工具持保留态度,觉得电子化的backlog或者kanban等工具会影响团队的参与感和灵活性。对这一点,我也同意,特别是在进行创造的过程中,我也不赞成使用电子化工具。主要原因是创造的过程需要集思广益,需要每个团队成员都有参与感,需要每个人可以随时对于用户故事做出改变,这样的过程如果使用电子化工具会很受限制。

    但是,电子化工具仍然有其不可替代的用武之地,特别是我们需要进行持续的跟踪和数据分析的时候,电子化工具就显示出它的优势;同时,如果你的团队分布在不同的物理地点,那么使用电子化工具就成为一种必然。因为这些场景都是物理板无法发挥作用的时候。另外,考虑到软件开发过程的复杂性和各个部分只见关联性很强,如果没有电子化工具的辅助,是很难支撑一个团队的开发工作的。

    在我带领团队使用用户故事地图的过程中,随着用户故事数量的增加,我发现团队开始迷失功能点与故事之间关联性,分解出来的功能点被淹没在不同的模块之中了,用户故事已经开始慢慢消失了。这是个非常不好兆头,所以我在这个时候开始要求团队引入电子化工具。

    样例程序和用户故事列表


    为了能够更好的说明这个过程,在这个系列中我使用【凤凰项目:一个IT运维的传奇故事】这本书为背景的ASP.NET 5样例应用,创建了一些用户故事

    关于【凤凰项目:一个IT运维的传奇故事】:本书讲述了一位IT经理临危受命,在未来董事的帮助和自己“三步工作法”理念的支撑下,最终挽救了一家具有悠久历史的汽车配件制造商的故事。 小说揭示了管理现代IT组织与管理传统工厂的共通之处,让读者不仅能对如何管理IT组织心领神会,更重要的是将以完全不同于以往的视角看待自己的工作环境。

    可以通过以下链接购买这本书的中文版:http://item.jd.com/10034038960.html 

    udad-2-create-backlog-01

    这个样例应用可以通过以下地址访问:

    http://pucd.chinacloudsites.cn/

    udad-2-create-backlog-02

    这是一个简单的电子商务网站原型,具备产品列表,购物车,后台管理,促销和订单处理等电子商务网站的基本功能。你可以浏览一下这个网站,对其中的功能简单了解一下。

    用户故事列表


    以下是我使用影响地图用户故事地图整理出来的故事列表,每张图片的左侧是影响地图,列出一个故事;右侧是这个故事所分解出来的功能点摆放在用户故事地图上的的效果。

    udad-2-create-backlog-us-01

    udad-2-create-backlog-us-02

    udad-2-create-backlog-us-03

    udad-2-create-backlog-us-04

    udad-2-create-backlog-us-05

    上面5个用户故事所分解出来的功能点我分别使用不同颜色在故事地图上进行了标注,你可以看到当故事不停增加的时候,这个地图会慢慢变得非常庞大而繁杂,分辨出用户故事变得越来越难。

    使用Team Foundation Server来管理用户故事


    Team Foundation Server (TFS) 是微软公司的研发管理平台,其中提供了从需求管理,项目管理,配置(源代码)管理,测试管理,代码编译持续集成,自动化测试,自动化发布及部署环境管理在内的研发运维一体化(DevOps)的完整工具链。微软自己的大多数产品都在使用这个平台进行研发管理,其中也对敏捷开发提供了很好的支持。

    在整理用户故事的过程中,我们可以先使用Excel来记录这些用户故事和功能点,同时记录每个功能点所属的功能区域,形成类似以下的文档。

    udad-2-create-backlog-03

    以上表格中,我们用二维表的方式保存了用户故事地图上的所有关键信息,在导入到TFS的时候需要注意:

    • 故事地图实际上是一个二维表格,顶部的功能区域/模块部分是功能点的分类,这部分内容可以使用TFS所自带的区域路径 来进行表达
    • 每个故事(左侧的WHY-WHO-HOW/WHAT),与右侧的功能点之间是一种父子的一对多关系,可以用TFS backlog中的不同级别的工作项所代表,TFS可以维护不同级别工作项之间的父子关系,正好可以跟踪这部分信息
    • 右侧的每个卡片对应到这个二维表顶部的特定的功能区域/模块,我们在导入的时候只要设置每个工作项的 区域路径 字段的值,完成这种对应信息的跟踪

    首先,在TFS中按照功能区域和模块创建区域路径,对应到用户故事地图顶部的分类信息

    udad-2-create-backlog-04

    现在我们就可以将我们的用户故事导入到TFS中,

    udad-2-create-backlog-05

    关于如何使用Excel批量导入和更新工作项,请参考:https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel

    形成的backlog如下,你可以看到TFS很好的维护了我们的用户故事到功能点之间的联系,同时也保留了每个功能点所对应的功能区域,这样就把用户故事地图上的关键数据进行了很好的维护,便于我们从不同的角度来查看和跟踪。

    udad-2-create-backlog-06

    导入的工作项用不同的字段保留了用户故事地图上的关键信息:

    udad-2-create-backlog-07

    当然,你仍然需要对每个用户故事工作项和功能点工作项进行进一步完善,将团队在讨论过程中所产出的信息进行记录,比如:每个用户故事需要包括用户背景,操作流程图,交互设计原型;每个功能点需要包括数据字典,输入输出,数据验证,界面原型等。这些内容可以直接填写在工作项的 说明 字段,或者使用附件的形式上传到工作项上统一保存。

    在规划篇中,我强调过用户故事所注重的是它所驱动的过程,而不是那份文档。但是,我们仍然需要将团队讨论中所产生的关键信息进行详细的记录,这样便于团队在后续的开发中回忆起讨论的细节。这些信息在看板或者白板这种物理工具上是无法表达和保存的,所以这个时候引入电子化工具恰到好处。

    我们所导入的故事和功能点将构成后续开发所使用的backlog,便于团队对这些内容进行优先级排序,迭代规划,任务分解,测试计划的制定,测试用例的分解等等。也就是说,后续的软件研发过程均会按照我们导入的backlog作为主线进行。这样,团队既可以按照用户的角度来抽取出相应的功能点,也可以从产品模块的角度查看功能列表和影响这些模块的用户需求,保证团队在满足用户需求与架构优化演进之间做出取舍,为团队建立起完整的需求跟踪视图(有很多团队会称之为需求跟踪矩阵)。

    见下图,我们之前所做的其实就是建立的图中的 架构模型 和 条目化需求 部分的内容,同时在这两部分内容之间建立的联系,这些是建立一个软件研发管理系统的源头。

    udad-2-create-backlog-08

    至此,我们就完成了用户故事到产品backlog的转化,下一篇中将介绍如何完成开发和测试计划的制定,并开始引入Kanban来跟踪开发过程。


    注:以上场景是【DevOps敏捷开发动手实验】的一部分,请点击以下链接访问这个动手实验的指导文档:
    http://vsalm-hols.readthedocs.org/


    展开全文
  • 敏捷开发,瀑布式开发,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
    展开全文
  • 开发模式以及流程参考禅道敏捷开发论坛1整理除了一份(可能)适合自己公司的开发模式,具体如下图: 小团队对于项目开发上也走了很多弯路,目前还处在一个探索阶段,出于多种考虑很多看起来比较完善的方案无法去...
  • 敏捷开发应用

    2011-02-18 14:49:00
    的各个阶段都要随之变化,包括分析建模、概要设计、详细设计、代码设计、软件测试等等,因而对软件开发的成本、工作量、开发进度、软件质量都形成了严峻的 考验。  在研发过程中,由于需求的变更而引起的...
  • 大厂的敏捷开发应用

    2019-05-09 16:35:08
    一个应用敏捷开发的小组日常 这个小组是做网站开发,基于微服务负责网站的某一个小模块,标准配置7人、4个程序员(要起码有一个资深程序员有架构能力)、1个产品经理(Scrum里叫Product Owner),1个测试、1个项目...
  • 很早以前,就有这么一个想法:开发一套高效的、用于软件开发行业进行项目管理的管理型软件。之所以有这个想法,与我本人的经历有关。早年,在做**系统的时候,部门的总监就让我去做那么一套东西,基于Visual Basic和...
  • 前言:  本文主要探讨在产品外包的模式下, 精益敏捷开发如何能... 精益敏捷开发应用在产品外包的工作模式时, 便是藉由下列的方法, 使外包人员的能力, 可迅速的获得提升: 1. 以可视化的 “路径树”, “表格” 为主
  • 大型软件的团队有效协作对项目成功起到越来越关键的作用,“敏捷之旅广州站——精进之旅”的活动,请来了业界敏捷项目管理的专家做了几场公益性的讲座,涉及敏捷开发应用和互联网项目管理的一些实用的方法,本文结合...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。  敏捷开发宣言—— 个体和交互 胜过 过程和工具 可以工作的软件 胜过 ...
  • 接下来,将由浅入深地来分析分析敏捷开发的基本概念,然后说明一下敏捷开发的代表–XP(极限编程)与Srcum过程。敏捷开发概念与价值观敏捷开发运动历史相对于整个软件开发而言算是较为悠久的,其真正开始的标志是01年2...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 力软敏捷开发框架是基于.net平台研发出的一套采用面向构件技术实现企业级应用开发、配置、运行集成一体的综合技术平台。平台可以开发企业整个应用软件体系,并为其提供一个组件化、低代码、可视化的软件开发模式。 ...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  • 敏捷开发实战经验

    2018-05-30 18:22:35
    敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 关于敏捷开发框架的实际应用,现在无外乎有以下几种常见的情形: 很多团队想使用敏捷开发框架,但不知道该怎么上手; 有的团队已经应用敏捷开发框架的实践,然而效果不理想,不知道是敏捷开发框架的问题,还是...
  • 敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。 首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发...
1 2 3 4 5 ... 20
收藏数 81,900
精华内容 32,760
关键字:

敏捷开发应用