精华内容
参与话题
问答
  • 敏捷开发思想

    千次阅读 2019-04-12 22:52:55
    敏捷开发思想SCRUM 是什么?敏捷开发是什么?以人为核心是什么意思?迭代 是什么意思?SCRUM 与 敏捷开发思想有什么关系?敏捷开发的模式分类(摘抄至互联网):SCRUM 的工作流程(摘抄至互联网)流程: SCRUM 是什么? ...

    SCRUM 是什么?

    Scrum是敏捷开发中的名词。

    敏捷开发是什么?

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

    简单的说的话:

    1. 它只是一种开发思想,而不是开发技术;
    2. 其次,需要明白,通过敏捷开发的项目,包含的诸多子项目,都会带有,已经测试结束,具备了集合和可运行的特征;
    3. 敏捷开发,初始,并不追求完美的设计以及编码,而是,尽可能快的先开发出产品的核心功能,以及发布可用版本。之后,才会在多余的生产周期内,根据需求,不断的完善升级与迭代产品。

    eg:对于Java全栈式开发工程师来讲,拿到需求,了解之后,第一件事,并不是先去完善后台代码,而是迅速的先将需求页面(网站),先实现。而后,才开始根据需求一步步实现功能。

    以人为核心是什么意思?

    一句话概括来讲的话,便是:

    不似瀑布开发的思想,往往开发完后,写了一堆的开发文档进行开发、
    而是,尽量的少写开发文档,只写一些必要性的文档,因为敏捷开发注重的是人与人面对面之间的交流。所以说它是以人为核心。

    迭代 是什么意思?

    类似与 单体开发 与 微服务、分布式开发的区别。
    一个是,将所有的功能实现后,方可测试与后续操作。
    另一个是,将所有的功能分为一个个服务或小功能,完成一个便可开发,测试,上线一个小功能。慢慢的完成总体。

    循序渐进自然,也可由上明白。

    SCRUM 与 敏捷开发思想有什么关系?

    Scrum是敏捷开发之后的方法的一种。

    敏捷开发的模式分类(摘抄至互联网):

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

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

    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. 由产品的负责人,按照需求的优先级,优先取出一部分Backlog(需求清单)。
    2. 在每个Sprint(冲刺周期),开发团队根据计划,确定好每个周期的需求清单(Backlog)。既,在每段时间内需要完成的工作任务是什么。
    3. 对团队成员进行任务的分配开发。每天,团队都会开启Daily meeting(每天的站会)【既,明白自己之前完成了什么】。
      而后团队成员调整自己的Task状态【既,每个小任务的完成时间又该控制在什么时间内】,整个团队便更新自己的Sprint burn down(冲刺燃尽图)。
    4. 当这份Backlog(需求清单)完成之后,便会开启团队的Sprint Review meeting:(冲刺评审会议)。没问题的话,便会发布出发此阶段产品的发型版本(Release),且进行Sprint review meeting(回顾会议)

    写在最后,PS:此文内容,部分摘抄至互联网,如若,原文博主介意,可私聊。谢谢。
    自然,此文并不完善,欢迎各位点评。

    展开全文
  • 敏捷开发思想与实践,及Jira与Confluence工具的使用
  • 敏捷开发的定义:其实敏捷开发就是以用户需求为导向,需求进化为核心,采用迭代、逐步完善的方式进行软件开发,其中的核心思想就是用户需求的进化与迭代并逐步完善,前者保证我们所做的项目开发对于用户是有意义的...

    团队最近在进行传统开发向敏捷开发的过渡,谈谈我对敏捷开发的认识。

    1、敏捷开发定义

    敏捷开发的定义:其实敏捷开发就是以用户需求为导向,需求进化为核心,采用迭代、逐步完善的方式进行软件开发,其中的核心思想就是用户需求的进化与迭代并逐步完善,前者保证我们所做的项目开发对于用户是有意义的(包括终端用户、产品、领导者、开发人员、运维人员等提出的合理需求),后者保证了开发的有序性,并在一定的周期内产出成果,并不断优化。

    另外,敏捷开发只是一种开发思想,其具体的实现方法有很多,在实际的开发过程中经常用到的就是Scrum迭代。下面说一下什么是Scrum迭代。

    2、Scrum迭代定义

    Scrum迭代的定义:Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中整个开发周期包括若干个小的迭代周期,每个小的迭代周期成为一个Spring,每个Spring建议长度为2到4周。

    在Scrum中,使用Product Backlog来管理产品或项目的需求,Product Backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为User Story.

    3、Scrum迭代在敏捷开发方法中的应用

    Scrum的开发团队总是先开发对客户价值较高的需求,在需求分析会议上通过分析、讨论和估算得到需要开发的需求列表,在每个迭代结束时,Scrum团队将交付潜在可交付的产品增量。

    另外Scrum迭代式软件开发方法,包含SM(项目经理)、PO(产品经理)、TEAM(开发人员)。职责分工如下:SM-维护团队的稳定性确保其不受外界干扰,PO-需求的整理、优先级排序、内部验收等,TEAM-整个团队的开发人员,主要负责研发与测试。

    Scrum的开发方法主张一切从简,少文档、少会议、多沟通;但Scrum有几个必要的会议是不能省略的:1、项目启动会(需求评审、用时评估、故事分配、任务拆分、承诺完成时间)2、每日站会(昨天完成任务,今日计划完成任务,任务进度与困难)3、评审会(团队迭代周期成功的展示及验收)4、经验总结会(对迭代过程中优缺点,改进方法等)

    4、更多精彩内容欢迎关注微信公众号

    展开全文
  • 响应变化重于遵循计划),我认为,敏捷开发大致应该体现如下的思想:拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。 1、拥抱变化 Kent Beck和Martin Fowler在介绍极限编程(eXtreme Programming)...

    秉承敏捷宣言的精神(个体与交付重于过程和工具;可用的软件重于完备的文档;客户协作重于合同谈判;响应变化重于遵循计划),我认为,敏捷开发大致应该体现如下的思想:拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。

    1、拥抱变化

     

     Kent Beck和Martin Fowler在介绍极限编程(eXtreme Programming)时,最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度,那就是不拒绝,而且还要主动求变。有一句经典的论断说得好:“在软件开发领域中,唯一的不变就是变化。”其实,不仅仅是软件开发领域,世间万事万物都处在永恒的变化之中,这是宇宙的基本规律。奥巴马在竞选美国总统的时候,提出的口号就是“变化”。变化才是真正的常态。

    传统的软件开发过程由于过分强调文档的完整,重视与客户的谈判与签订合同。所以,开发团队最希望的一件事情是冻结需求规格说明书。只要双方签字,需求就确定下来,不可更改。若要更改,必须经过需求变更委员会,走非常严格的需求变更流程。如果软件开发真能如此,倒也算是我们开发人员的幸事。但现实总是残酷的,需求总是会变化。变化的原因有以下几种: 
    1)业务发生了变化; 
    2)客户对业务的理解发生了变化; 
    3)需求分析人员对需求的理解出现了偏差,需要修正。

    对于第一点,或许我们还能够根据合同与客户讨价还价,而对于后两点,尤其是第三点,我们显然是不可拒绝的。而敏捷方法则要求团队随时响应客户的需求,针对变化给出相应的解决方案。

    如何拥抱变化呢?我想可以通过如下方式来实现: 
    1)现场客户

    很多开发团队并不喜欢客户对他们指手画脚,甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无论团队中聚集了多么权威的领域专家,但真正了解客户需求的还是客户自己。也许他们很难用语言来表述自己的想法,但有了和现场客户的及时沟通,我们才能够在发生变化的初始就能够获得第一手的资讯。如果事情总要发生,早解决绝对比晚解决要好,而且要好得多。

    如果在开发中,没有办法让客户成为团队的一员,那么我们也应该指定一位客户代表,退而求其次,也应该在团队中指定一位业务专家负责业务事宜,也就是Scrum中Product Owner的角色。总之,我们需要在项目开发中,能够让开发人员在对需求理解发生困惑时,能够明确地知道由谁来负责。而一旦需求发生变化,也必须有专门的角色负责向整个团队或者相关人士传达。至于业务功能的优先级和重要程度排定,也必须由这个角色指定。

    2)定期迭代和小版本交付

    不仅要定期迭代,而且要尽可能地让迭代周期短,并及时交付可以工作的小版本发布。XP的迭代周期通常为一周,而发布一个小版本大约是一个月。而Scrum则将迭代称之为Sprint,持续时间推荐为一个月。Sprint结束就需要向客户展示当前迭代完成的版本。

    敏捷方法绝对不可闭门造车,因为需求总是可能存在二义性,且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本,一方面可以给与开发团队和客户以信心,另一方面也有助于我们及时获得客户的反馈。而衍生带来的还有一个好处是我们可以免费找到最优秀的测试人员了,那就是我们的客户。如果没有现场客户,则小版本的交付则显得尤为重要,因为它给了我们及早修订错误的机会。

    3)持续改进

    开发过程总是会出现错误,无论是开发方法、技能,还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程,才能够及时而有效地解决错误,避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队,同时必然会是一个拥抱变化的团队。

    在Scrum中,每个Sprint完成并结束了评审会议之后,都会召开一个回顾会议,即使总结优秀经验,检讨错误与教训,团队方能够从错误中成长起来。此外,回顾会议还能够帮助团队正确地认识自己,帮助团队成员进行交流与沟通。作为“鸡”角色的客户若能参加回顾会议,可以让客户更直观地了解团队,比提出自己的看法,有助于在后面的开发过程改善合作的质量。

    敬请期待第二篇《敏捷开发思想之自我组织》







    本文转自wayfarer51CTO博客,原文链接:http://blog.51cto.com/wayfarer/280167,如需转载请自行联系原作者

    展开全文
  • 导语:现在每当直接或间接带一支研发团队我都会给大家做一次敏捷思想和实践的培训(注:软件方向,复杂的硬件开发流程建议使用IPD思想)。作为一个有近10年的开发编码工作经验的资深程序员,作为一个管理者,作为一...

    导语:现在每当直接或间接带一支研发团队我都会给大家做一次敏捷思想和实践的培训(注:软件方向,复杂的硬件开发流程建议使用IPD思想)。作为一个有近10年的开发编码工作经验的资深程序员,作为一个管理者,作为一个还算转型成功的创业者,我一直有种初心

    • 希望所有研发人员能够敢于并且会表达自己,让更多的人了解自己;

    • 希望所有的研发人员不仅仅是机械的写代码,也能洞悉市场、了解用户,让自己的产出能够适配用户和市场的需求,这何尝不是一种成就感;

    • 希望所有的研发人员不再受困于狭窄的职场方向,而是有更多可能转型产品、市场、管理

    我认为敏捷开发的实践带给了我这些:工作的收益、内心的释放、转型的机遇以及最重要的自信,所以也想分享给大家这些。


    敏捷开发思想


    350833a2ed7b19fc70c24b02e1994daa.jpg

    • 所有人都可以从字面上理解敏捷代表着“快”;

    • 呆伯特老板的理解:没有什么计划或者文档,直接开始写代码......

    • 很多业内人士的理解:迭代开发。

    以上理解不能算是错,但都是盲人摸象式的理解。我们先看看几种常见的开发模式:

    • 计划驱动的瀑布式开发;

    • 逐步完善的迭代开发;

    • 风险驱动的螺旋式开发;

    • 价值驱动的敏捷开发;

    除却外包项目常采用的瀑布式开发外,在很多人印象里仿佛剩下的三种开发方式都该是敏捷开发,其实这里有个文字游戏,就是“***的”这个定语,敏捷开发是由用户价值(用户的需求)驱动,这才是区分标准,这种对核心的强调,是在提醒我们需要最重视的是什么。至于用户价值的意义,不言而喻——如果我们做出的东西并不是用户需要的,那又有什么意义?在敏捷开发的过程中其实既有螺旋式开发的思维,也有迭代式开发的流程,甚至有计划式开发的阶段。

    敏捷宣言—价值观

    5dcd3cdf3058f8ca5d4613ce5cd845ed.jpg

    很多“保守力量”反对敏捷开发的原因就是说敏捷不注重计划或者是文档等等。这里的文字游戏就是“胜过”二字,并不是没有,而是取舍侧重的分别。总结如下:

    “自组织团队与客户紧密协作,通过高度迭代式、增量式的软件开发过程响应变化,并在每次迭代结束时交付经过编码与测试的有价值的软件。”

                                                                       胜过

    “与客户确定合同后在初期制定并遵循基于活动的完整计划,在重型过程和工具指导下,通过完成大量文档进行知识传递,最后交付需求。”

    敏捷开发之 12 条敏捷原则

    1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

    注:客户的期望值管理

    2、即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

    注:欢迎变更需求但不是意味着可以随时变更,在一个计划节点内要保证需求不变更

    3、经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好

    注:比如scrum,节点周期往往设置为2到4周

    4、在整个项目开发期间,业务人员和开发人员必须天天都在一起工作

    注:研发人员对业务的理解可以使产品更具备可用性甚至有卓越的用户体验,业务人员对技术的理解也会让其更专业,还可以加深不同团队的交融理解

    5、围绕被激励起来的个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。

    注:比如针对需求和实现性大家的头脑风暴,鼓励每个人发言,比如任务采取主动领取,而不是被动分配,倡导民主和开放

    6、在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈

    注:面对面交谈不但效率高,而且有利于清晰透彻的了解对方的意图,直面解决冲突

    7、工作的软件是首要进度度量标准。

    注:每一个节点都要保证软件是可用的,而不是99%的完成但不可用

    8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

    注:scrum节点就如同心跳一般让我们的计划有规律

    9、不断地关注优秀的技能和好的设计会增强敏捷能力。

    注:倡导每个人要有自主学习能力,建立学习型组织

    10、简单----使未完成的工作最大化的艺术----是根本的。

    注:书籍 大道至简 (豆瓣), UNIX编程艺术 (豆瓣) 的核心思想

    11、最好的构架、需求和设计出自于自组织的团队

    注:《失控》中的去中心化,生物般的进化

    12、每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整

    注:“实践——反省——修正——成长......”的正循环

    基于以上这些原则和关键词,抽出几个敏捷开发的核心:“价值”、“客户”、“人”、“团队”。


    敏捷实践之Scrum

    大家要明白一个区别,敏捷开发是一种思想,下面来讲述一下承载这种思想的其中一种开发过程Scrum。

    808c8c9cee185a311ca1426b8b6dca0f.jpg


    从这张开发过程使用的统计图中可以看出Scrum的流行程度。Scrum本身并不是方法论,它只是一个框架,它只定义了高层次的管理流程,如下图示

    329c8f42edf95bdf20668a992c0271ff.jpg

    它并不涉及具体开发方法或者人员的有效沟通技巧等。这些没有涉及的领域需要同其他理论和技能互为补充,以确保项目的成功。

    086881c5c6c2e0707694fef4b1d98ece.jpg

    9fd1b8d391eb985b4885647642342290.jpg

    可以看到Scrum的实施过程是建立在敏捷开发思想12原则基础上的。反过来,对流程的实施也可以加深大家对敏捷原则的理解。

    Scrum兼有的价值观

    • 核心价值观:承诺、专注、公开、敬重和勇气

    • 提倡的原则:自我管理、涌现机制、可视性和评估/适应循环

    Scrum的要点提炼

    • Backlog——明晰商业价值,场景化用户故事

    • 任务估算——精细,可控,准确

    • 会议——专注,高效,开放

    • 目标——清晰,可达成


    敏捷开发的书籍推荐

    硝烟中的Scrum和XP 

    高效程序员的45个习惯 

    敏捷开发的工具推荐

    Jira && confluence 项目管理、wiki知识库

    Redmine 需求、原型、协作

    jenkins 持续集成

    本文转自永远的朋友博客51CTO博客,原文链接http://blog.51cto.com/yaocoder/1977245如需转载请自行联系原作者


    yaocoder

    展开全文
  • 敏捷开发思想与实践

    2017-02-07 11:22:05
    前言软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的工作;“学而优则仕”的...
  • DevOps敏捷开发思想和架构

    千次阅读 2019-02-27 14:15:13
    从概念上说,DevOps 是一种方法论,是一组过程、方法与系统的统称,用于促进应用开发、应用运维和质量保障(QA)部门之间的沟通、协作与整合。概念有了,怎么落地?很多公司在实施容器云时实现CI(Continuous ...
  • 极限编程中有一条著名的懒汉原则,称之为KISS原则,KISS是Keep it simple and stupid的缩写。简略地说,就是设计尽量保证简单。这里我们将谈到敏捷开发思想中的简单最好原则。
  • 如今,随着信息技术的不断发展,互联网进入了一个相对繁荣的时期,而企业要想跟得上潮流,信息化建设必不可少,但是面对眼花缭乱的软件开发公司,选择成了难题。 传统软件开发 传统的软件业务更多的是走定制...
  • 极限编程中有一条著名的懒汉原则,称之为KISS原则,KISS是Keep it simple and stupid的缩写。简略地说,就是设计尽量保证简单。极限编程坚持只为今天的需求设计以及编码,而不用考虑明天。这颇有一些“做一天和尚撞...
  • 最佳的架构、需求和设计出自于自组织的团队。蜂巢中的工蜂们看似忙碌,但其工作却是有序而有效,归根结底就是它们的组织架构其实是自我组织的。在自我组织的团队中,团队是一个整体,没有角色之分、职位之分、也没有...
  • 本次分享的主题是:敏捷。 分享之前,先把最近讨论过的发版方案回顾了一下。回顾方法我用了最近刚学习的ORID回顾法。详细了解这一方法可以看看这篇文章《敏捷个人必备方法:1、ORID》 然后进入了今天的主题,...

空空如也

1 2 3 4 5 ... 20
收藏数 1,779
精华内容 711
关键字:

敏捷开发思想