敏捷开发思想 - CSDN
  • 敏捷开发的核心思想

    2015-10-12 10:39:08
    敏捷开发的核心思想主要是迭代式开发,将整个项目分解为数个短期的迭代周期,快速相应需求进行增量开发。 结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤: 需求制定——》需求分析——》设计...
    敏捷开发的核心思想主要是迭代式开发,将整个项目分解为数个短期的迭代周期,快速相应需求进行增量开发。
    结合我们公司的开发经验来看,我个人觉得敏捷开发主要包括几个步骤:
    需求制定——》需求分析——》设计编码——》测试、功能验证——》发布版本——》下一个周期

    1、需求制定:需求方根据上一个版本,提出的新开发需求或调整等。
    2、需求分析:开发及测试人员,与需求方讨论并分析新需求,并验证需求的可行性。
    3、涉及编码:根据确认后的需求,设计实现方式并进行编码。
    4、测试、功能验证:对软件稳定性进行各种测试,并由配合需求方进行功能验证。
    5、发布版本:将这个版本发布给需求方。
    6、下一个周期:重复1到5步骤。

    实际开发中不可能情况非常顺利,一般都会有新的需求或修改在开发过程中被发现或提出,
    这时候并非不能调整原有的开发计划,可以视具体情况而定决定是否加入开发计划中,
    如果涉及到大规模的改动则一般需要作为下一个版本的开发任务。

    由于敏捷开发是使用增量式的开发,开发周期短响应快,一般不会出现致命的缺陷,整个开发过程较为流畅。


    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。
    
    敏捷开发宣言——
    个体和交互 胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作 胜过 合同谈判
    响应变化 胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
    Iteration
    迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
    IterationPlanningMeeting
    迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
    在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
    站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
    结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
    持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
    总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
    演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
    重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
    测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    

    敏捷方法反思:
    自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
    1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
    2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
    3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
    4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
    5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
    6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
    7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • 敏捷开发思想

    2019-04-12 22:55:16
    敏捷开发思想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:此文内容,部分摘抄至互联网,如若,原文博主介意,可私聊。谢谢。
    自然,此文并不完善,欢迎各位点评。

    展开全文
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可...是谁这么厉害,提出了敏捷开发思想?是一位名叫 Ma...

    敏捷开发(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 提供了强大而有效的统一环境。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 敏捷开发核心思想

    2011-04-20 09:08:00
    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可...

    一、4句敏捷宣言

    个体与交互               胜过     过程与工具


    可以工作的软件        胜过     面面俱到的文档


    客户协作                 胜过     合同谈判


    响应变化                 胜过     遵循计划

     

     

    二、12条敏捷原则


         4句敏捷宣言中讲了敏捷开发的价值观, 从这些价值观中可以引出下面的12条原则, 它们是敏捷实践区别于重型过程的特征所在。在Agile Software Development - Principles,Patterns,and Practices(中文书名: 敏捷软件开发-原则、模式与实践)中对这12条原则分别进行了阐述,这里我就不重复解释书本的内容了,将从我个人的理解去讲解这些原则,希望大家多多补充 独到见解。

     

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


       规划迭代故事时必须按照优先级安排,为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作,及时反馈提高产品质量。敏捷小组关注完成和交 付具有用户价值的功能,而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求,敏捷使用用户故事来罗列需求。用户故事是一种表示需求的 轻量级技术,它没有

    固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板:“作为【用户的类型】,我希 望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时,仍可能需要原型和编写文档,只是工作重点更多的转移到了口头交流。

     

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


      敏捷过程参与者不怕变化,他们认为改变需求是好事情,因为这些改变意味着我们更了解市场需求。
     
    3。经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。


       迭代是受实践框限制的,意味着即使放弃一些功能也必须按时结束迭代。只要我们可以保证交付的软件可以很好的工作,那么交付时间越短,我们和客户协作就越 紧密,对产品质量就更有益。虽然我们多次迭代,但并不是每次迭代的结果都需要交付给用户,敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中 都会增加一些功能,增加的每个功能都是经过编码、测试,达到了可发布的质量标准的。
      另外敏捷开发项目中对开发阶段没有什么重要的分割,没有先期的需求阶段,然后是分析阶段,架构设计阶段,编码测试阶段等,在项目真正开始后,每次迭代中都会同时进

    行所有的上述阶段工作。
     
    4。在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。


      软件项目不会依照之前设定的计划原路执行,中间对业务的理解、软件的解决方案肯定会存在偏差,所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁 

    的交互,这样就可以在早期及时的发现并解决问题。
     
    5。围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。


      业务和技术是引起不确定的二个主要方面,人是第三个方面。而业务和技术又必须由人来执行,所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团

    队的目标一致,我们就需要鼓舞起每个人的积极性,以个人为中心构建项目,提供所需的环境、支持与信任。

     

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


      在十几或者二十几个人组成的大团队中,文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人(大团队实施敏捷时也会分成多个小的敏捷团队),所以

    大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。
     
    7、可工作的软件是首要进度度量标准。


       一般的工作都比较容易衡量任务进展,比如让你去搬运1吨的石头,我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说,在软件没有编 码、测试完

    成之前,我们都不能因为代码编写了多少行,测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工 作了,对用户来说已经可

    以应用了。

     

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


       很多人都认为软件开发中加班是很正常的,不加班反而不正常,我对此有点不理解,这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发,开发速度不会 随着迭代的任务不同而不同,不欣赏所谓的拼一拼也能完成的态度,开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了,因为完成一个项目 后会接踵而来下一个项目,而只要还是拼拼的态度,下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说,那我们就一直加班,也是“持续的开发速 度”啊,这时可要注意了,持续加班智

    慧导致人疲劳、厌倦,保持长期恒定的速度也只是一种理想而已。
     
    9。不断地关注优秀的技能和好的设计会增强敏捷能力。


      敏捷过程有很多好的技术实践可以加强产品敏捷能力,很多原则、模式和实践也可以增强敏捷开发能力。 《敏捷软件开发-原则、模式与实践》一书中介绍了很多设计,感兴趣的可以去仔细看看。
     
    10。简单----使未完成的工作最大化的艺术----是根本的。


       我们不可能预期后面需求会如何变化,所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件,而把注意力放在如何通 过最简单的方法完成现在需要解决的问题。这时有人会说,我已经预计到了肯定存在哪些需求扩展点,我们在一开始是否需要考虑呢?这时团队需要根据自己的理解 去决定是否考虑,如果深信在明天发生了这个问题也可以轻易处理的话,那么就最好先不考虑。
     
    11。最好的构架、需求和设计出自与自组织的团队。


            敏捷中有很多种实践,大家都知道,迭代式开发是主要的实践方法,而自组织团队也是主要的实践之一。在自组织团队中,管理者不再发号施令,而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。CSDN采访Mishkin Berteig中说到 自组织团队的第一个要素就是必须有一个团队,而不仅仅是一群人。一群人是一帮在一起工作的人,他们彼此之间并没有太多的沟通,他们也并不视彼此为一体。项目一开始,我们就会组建“团队”,但很多时候由构架师、需求人员、开发人员和测试人员组成的是一群人而已。他还认为,团队的形成必须经历几个时期。在 经历了初期的磨合后,成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩,而且这些规矩是不言而喻的。比如,每个人 都知道上午九点来上班,都会主动询问别人是否需要帮助,也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契,那么这个团队将成为一个真正高 效的工作团队。在这样团队中,成员之间相互理解,工作效率非常高。在自组织团队中,团队成员不需要遵从别人的详细指令。他们需要更高层次的指导,这种指 导更像是一个目标,一个致力于开发出更好的软件的目标。总之,自组织团队是一个自动自发、有着共同目标和工作文化的团队,这样的团队总是在向它的组织做出 承诺。但是,实现这些承诺对于自组织团队来说非常重要。否则,一旦出现问题,团队成员之间就会出现信任危机。


      虽然敏捷开发小组是以小组为整体 来工作的,但是还是有必要指明一些承担一定任务的角色。第一个角色是产品所有者(Product Owner)。产品所有者的主要职责包括:确认小组所有成员都在追求一个共同的项目前景,确定功能的优先级以便总是在处理最具有价值的功能,以及作出决定 使得对项目的投入可以产生良好的回报。可以对应为以前开发中的“产品经理”。另一角色是开发团队(developer),这里的开发人员包括了架构师、设计师、程序员、需求人员、测试人员、文档编写者等,有时产品所有者也可以被看作是

    开发人员。还有一个重要角色就是项目经理(project manager)。敏捷开发的项目经理会更多的关注领导而不是管理。在某些项目中,项目经理可能同时也是开发人员,少数时候也会担任产品所有者。
      
    12。每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。


      由于很多不确定性因素会导致计划失效,比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。 敏捷不是基于预定义的工作方式,而是基于经验性的方式,对以上这些变化,小组通过不断的反省调整来保持团队的敏捷性。

    展开全文
  • 从概念上说,DevOps 是一种方法论,是一组过程、方法与系统的统称,用于促进应用开发、应用运维和质量保障(QA)部门之间的沟通、协作与整合。概念有了,怎么落地?很多公司在实施容器云时实现CI(Continuous ...
  • 首先是关于敏捷开发的核心思想。我理解的敏捷开发的核心思想,简而言之,就是八个字:“化整为零,逼近极限”。敏捷开发的世界观敏捷开发者眼中的世界,用西方哲学来说叫“绝对运动与相对静止的对立统一”的世界;用...
  • 敏捷开发的定义:其实敏捷开发就是以用户需求为导向,需求进化为核心,采用迭代、逐步完善的方式进行软件开发,其中的核心思想就是用户需求的进化与迭代并逐步完善,前者保证我们所做的项目开发对于用户是有意义的...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 如今,随着信息技术的不断发展,互联网进入了一个相对繁荣的时期,而企业要想跟得上潮流,信息化建设必不可少,但是面对眼花缭乱的软件开发公司,选择成了难题。 传统软件开发 传统的软件业务更多的是走定制...
  • 敏捷开发学习心得

    2014-02-15 22:03:03
    过年放假这几天读了一些敏捷开发方面的书籍,基于自己对敏捷开发的理解总结出以下几点。本文内容还会进一步整理,暂时先贴出来,权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发,如果能留言进行进一步...
  • 他们消极的对待敏捷开发思想以及敏捷相关实践方法的原因是什么?有没有这种可能,他们认为导致方法失败的东西其实完全不是敏捷实践,而误会了敏捷的价值呢? 有这种可能性,但是团队成员认为他们只是敏捷教练的棋子...
  • 敏捷开发思想谈  敏捷的原则   敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先,请大家有这么个概念:    敏捷开发绝对不是...
  • 笔者所在的公司根据自身开发实力和承接项目规模选择了敏捷开发思想来开发这个项目。在开发过程中,我们感受到了敏捷思想给我们带来的成果,也看到了敏捷思想在我们所处的实际情况下的需要本地化的地方。我们对这些...
  • 敏捷开发基本思想

    2011-01-29 11:26:30
    本文主要总结一下敏捷开发模式的基本思想   1、测试驱动开发(TDD):敏捷开发中,测试是在功能实现之前。就是要实现一个功能,首先根据业务需求,写出相应的测试,然后再写功能代码使得每个测试都可以通过。可以...
  • 本文将分享自己对敏捷开发的认识,和实现敏捷开发思想的核心方法。 敏捷开发: 一、什么是敏捷开发?   AgileDevelopment是一种以人为核心、迭代、循序渐进的开发方法。 1、以人为核心 vs  以文档为驱动   ...
  •  敏捷开发思想 1) 个体与交互胜过过程与工具 2) 可以工作的软件胜过面面俱到的文档 3) 客户协作胜过合同谈判 4) 响应变化胜过遵循计划 二. 敏捷开发介绍 敏捷开发是一个统称,早在20世纪60年代初的美国...
  • 本文将结合敏捷开发周期短,变化快等特点,介绍如何通过在开发过程中采取一系列步骤来保证和提高整个开发团队的代码质量,并阐述了每一步可以利用的工具和最佳实践,从而使开发过程更加规范化,成就高质量的代码,...
1 2 3 4 5 ... 20
收藏数 35,281
精华内容 14,112
热门标签
关键字:

敏捷开发思想