敏捷开发的应用_敏捷开发 应用场景 - CSDN
  • 关于敏捷开发部分思想在项目中的应用心得

    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.  开发软件的四项基本工作

    编码、测试、倾听、设计

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

    开发模式以及流程

    参考禅道敏捷开发论坛1整理除了一份(可能)适合自己公司的开发模式,具体如下图:
    这里写图片描述

    小团队对于项目开发上也走了很多弯路,目前还处在一个探索阶段,出于多种考虑很多看起来比较完善的方案无法去实施。


    展开全文
  • 大厂的敏捷开发应用

    2019-05-09 16:35:08
    一个应用敏捷开发的小组日常 这个小组是做网站开发,基于微服务负责网站的某一个小模块,标准配置7人、4个程序员(要起码有一个资深程序员有架构能力)、1个产品经理(Scrum里叫Product Owner),1个测试、1个项目...

       我们继续讨论大厂的敏捷方法应用。

        我们上节提过,如果每周一个Sprint,怎么保证每周都有交付,同时还能保证产品质量?

        一个应用敏捷开发的小组日常

    这个小组是做网站开发,基于微服务负责网站的某一个小模块,标准配置7人、4个程序员(要起码有一个资深程序员有架构能力)、1个产品经理(Scrum里叫Product Owner),1个测试、1个项目经理(Scrum里叫Scrum Master),主要负责网站某模块的维护和协调工作。

        分工上:

    1. 产品经理:写需求设计文档,将需求整理成Ticket,随时和项目成员沟通确认需求;
    2. 开发人员:每天从看板上按照优先级高低提取Ticket,完成日常开发任务;
    3. 测试人员:测试已经部署到测试环境的程序,如果发现Bug,提交Ticket;
    4. 项目经理:保障日常工作流程正常执行,协调团队成员的沟通工作,提供必要帮助和解决问题

    如何完成需求和修复Bug

    这个小组的日常工作,也是围绕Ticket来开展的,所有的需求、Bug、任务都作为Ticket提交到项目Backlog,每个Sprint的任务都以看板的形式展现出来。

        每个人忙完自己的“To Do”后把对应的Ticket移动到“Done”,再按优先级选取新的Ticket,然后移动到“In Process”栏。

    1. 每周一部署生产环境

        一般部署放在周一,如果是周五的话,万一部署发现问题,周末就需要加班无法好好休息了,所以除非紧急,部署都是放在上半周,这样遇到的问题后续有足够的时间去应对。

        部署很简单,按照流程执行几个命令就可以完成生产环境部署,然后需要对线上监控图标进行观察,有问题及时甄别,必要的话对部署进行回滚操作,但要记得不要轻易打补丁重新上线,仓促之间的修复会导致更大的问题。

        敏捷开发一周一个Sprint的好处在于即使这周的部署回滚了,下周再一起部署不会有太大影响。

    1. 每周二开迭代回顾会议,总结上周Sprint

        每周二,小组会预留一个小时的时间,作为迭代回顾会议(Sprint Retrospective)会议,目的是总结迭代中,团队做的好的地方和不好的地方。

        对于后续需要改进的,需要创建Ticket,加入到Backlog中,后续迭代中改进完善。

        例如测试人员反馈说,上一个Sprint,开发人员上线前几个小时还往预部署的分支里更新代码,导致测试需要重新弄做回归测试,但因为时间不够了,来不及测试完整,导致上线后不稳定,对于这样的问题,可以反映出流程出了问题,需要商定不是紧急的修复,不能在预部署分支上更新,确实需要加,要和测试确认。

        会议中涉及项目的决策,最好通过集体表决的方式决策,尽可能避免独裁式决策,因为敏捷的原则之一就是要善于激励项目人员,给他们需要的环境和支持,并给予充分的信任。

    1. 每周四迭代规划会,计划下周工作

    每周四也需要一个小时的组织会议来迭代规划(Sprint Planning Meeting),大家一起讨论下一个Sprint的内容。

        开会前,产品经理和项目经理商量好Ticket优先级,大家按照优先级从Backlog中选出下个Sprint的内容。团队每个成员对下个Sprint Backlog中的Ticket进行同时打分,决定Ticket的工作量。

    1. 评估每条Ticket工作量的大概流程如下:
    1. 会议组织者阅读一条Ticket,可能是用户故事,可能是Bug,可能是优化任务,询问大家是否有疑问
    2. 大家一起讨论这个Ticket,确保充分理解Ticket
    3. 大家对Ticket进行工作量估算
    4. 估分存在分歧,出分最高和最低说明理由,最有达成一致

    这种估算方法叫估算扑克,也就是poker,此方法的评估好处:

    1. 大家积极参与,详细了解需求,
    2. 工作量是由实际参与开发的成员做出评估,往往更准确易接受
    3. 促进成员的交流和经验分享

    所以,经过N个Sprint的磨合后,一般一个团队的每个Sprint产出是比较稳定的,比如上面那个团队组成,一个Sprint预计完成20-30分的Ticket。

    1. 每周五分支切割

    周五标志着一周的工作结束,所以下班之前,做branch out,把Master主干分支代码克隆到分支上,因为一周的开发,master已经合并了不少新的PR,如果我们直接把master部署到生产环境,是有风险的,毕竟自动化测试无法完全代替专业测试人员,所以需要再人工测试出来的Bug进行修复,直到稳定下来。此预部署的分支测试验收通过后,预部署分支的代码会部署到生产环境中。

    https://static001.geekbang.org/resource/image/a1/67/a1ff4dc93ffa7d68ab5d757317623167.png

    1. 每周轮值

    日常开发还有很多琐碎的事情,比如每周部署生产环境,每天部署测试环境,每周的branch out,回答其他小组的问题,主持每日会议,这些琐碎的事情在敏捷开发中,通过轮值让每个人去体验一下,大家会更有集体荣誉感和责任感。

    问题就出来了,

    1. 基于这种敏捷开发的方式加班多吗?

    加不加班跟是不是敏捷开发关系不大,要看项目组情况,基于敏捷开发一个Sprint,一个Sprint迭代,节奏稳固,这个Sprint做不完可以顺延到下个Sprint,不影响发布,而瀑布模型会前松后紧,后期加班可能性很大。

    1. 一周一个迭代怎么保证质量
    1. 足够比例的自动化测试代码,可以很好的保证质量,用户的主要功能通过自动化测试覆盖时,基本可以保证主要功能流程不会出问题
    2. 一个Sprint开发完毕后,并不立马部署到生产环境,而是先部署到测试环境,会有一周时间测试。
    3. 有专业的测试人员进行测试,并非完全依赖自动化测试,甚至有时打的功能更新,会组织全组成员一起测试。

    https://static001.geekbang.org/resource/image/30/c5/30f2a81130d5adc74921c88a0f7464c5.png

    1. 基于敏捷开发如何做计划

    大厂通常会在上一年底确定第二年的大的开发计划,并确定上线的时间范围,每个季度再根据实际情况进行调整,大的计划会变成具体的开发任务,大的开发任务会分拆到各个部门,各部门再将任务分拆到各个项目组,基于敏捷开发的话,要看开发任务放到哪几个Sprint去做,并且确保在规定的时间范围内完成。攻击估算上,会对每个Ticket进行打分,根据分数评估工作量。

    1. 如何沟通协作?

    组和组之间的沟通协作,主要通过邮件、会议、内部沟通工具,最终任务会以Ticket的形式体现,团队内部的话,每天站立会议都是很好的沟通方式。敏捷开发中的一种实践结对编程,两个程序员一台电脑工作,这个争议一直比较大,不过我觉得如果两个人一起排查Bug,或者资深程序员带新手程序员,我觉得到时非常好的协作方式。

    1. 上面介绍的实践案例和标准Scrum有什么不同?

    角色称呼不一样,Scrum里是Product Owner、Scrum Master和Team,而本案例是产品经理、项目经理和开发测试人员,而且传统项目经理是偏控制型,而Scrum Master是服务型,主要职责就是保障敏捷流程的执行,以及提供必要的帮助,集体决策是很好的团队决策法。

    Scrum有四种会议,每日站会(Daily Scrum)、Sprint计划会(Sprint Planning)、Sprint回顾会议(Sprint Retrospective)和Sprint评审会(Sprint Review)。

    敏捷开发核心其实并不是应用了哪个方法,而是应用的时候,是否遵循了敏捷开发的价值观和原则。

    总结起来,大厂的敏捷实践,关键是分而治之,很注重流程和工具使用,通过Ticket方式来管理和跟踪开发任务,通过自动化方式来部署生产环境测试。一般基于Scrum、极限编程和看板。

    展开全文
  • 敏捷开发在实际项目中的使用介绍第一周工作内容第二周工作内容 介绍 根据公司项目实际情况,设计实施了两周一个版本的快速迭代计划,精确每个角色到每一天的工作安排,供大家参考。 第一周工作内容 第二周工作内容 ...

    敏捷开发在实际项目中的使用

    介绍

    根据公司项目实际情况,设计实施了两周一个版本的快速迭代计划,精确每个角色到每一天的工作安排,供大家参考。

    第一周工作内容

    在这里插入图片描述

    第二周工作内容

    在这里插入图片描述

    展开全文
  • 很早以前,就有这么一个想法:开发一套高效的、用于软件开发行业进行项目管理的管理型软件。之所以有这个想法,与我本人的经历有关。早年,在做**系统的时候,部门的总监就让我去做那么一套东西,基于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等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 关于敏捷开发框架的实际应用,现在无外乎有以下几种常见的情形: 很多团队想使用敏捷开发框架,但不知道该怎么上手; 有的团队已经应用敏捷开发框架的实践,然而效果不理想,不知道是敏捷开发框架的问题,还是...
  • 敏捷开发对软件架构设计产生了一定的影响,让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验,和大家一起讨论一下敏捷中的架构设计这个话题。 首先,笔者认为敏捷开发是一种软件过程方法和工具,敏捷开发...
  • 敏捷开发思想

    2019-04-12 22:55:16
    敏捷开发思想SCRUM 是什么?敏捷开发是什么?以人为核心是什么意思?迭代 是什么意思?SCRUM 与 敏捷开发思想有什么关系?敏捷开发的模式分类(摘抄至互联网):SCRUM 的工作流程(摘抄至互联网)流程: SCRUM 是什么? ...
  • 你不需要任何的编程技术,自己就可以通过力软敏捷开发框架上面的APP应用,拼图式自己快速搭建出一个手机互联网APP。 在整体框架都已经搭建好了,开发者只用实现业务功能。并且敏捷开发框架内已经集成了大量业务...
1 2 3 4 5 ... 20
收藏数 81,724
精华内容 32,689
关键字:

敏捷开发的应用