精华内容
下载资源
问答
  • 响应变化高于遵循计划”—敏捷宣言。 在当今变化莫测的时代,昨天5G刚刚兴起,今日6G已悄然开始布局。如何抓住时代的红利是每个产品或者项目管理者都要思考的事情。越早响应变化,就越早能够享受变革带来的红利,...

    前言

    响应变化高于遵循计划
    响应变化高于遵循计划”—敏捷宣言。

    在当今变化莫测的时代,昨天5G刚刚兴起,今日6G已悄然开始布局。如何抓住时代的红利是每个产品或者项目管理者都要思考的事情。越早响应变化,就越早能够享受变革带来的红利,反之,一味的遵循计划只会被时代抛弃。

    接下来老程与大家一起分享敏捷项目管理中的响应变化的知识,旨在让大家了解,敏捷并非是洪水猛兽那么可怕,相反,顺应时代的潮流,引领大家体验敏捷的奥妙!

    请各位抓紧时间上车,坐好扶稳,老司机开始飙车了
    let’s go


    适应学

    世界上最后能生存的生物,不是最强的;也不是智慧最高的,而是适应能力最强的
    “世界上最后能生存的生物,不是最强的;也不是智慧最高的,而是适应能力最强的”—英国生物学家达尔文

    传统的项目管理者注重按计划行事,尽量做到和计划没有出入;
    而敏捷项目领导者关注如何成功的去适应不可避免出现的变化
    《敏捷项目管理第二版》
    
    

    传统的瀑布式项目管理,往往前期做了大量的计划,制定各项约束,详尽的文档。而敏捷项目管理者则更注重价值。

    曾经有段时间,老程接收集团一个LMS(实验室系统)时,先收集需求(各部门及客户)勾画更重流程图,反复的讨论;在调研完毕后,关起门来,奋力书写几天,终于在抽了几包烟以及双眼熬成“国宝”项目需求说明书,项目计划书等等文稿出世了。

    接下来信息慢慢,觉得这下子,改兄弟们大展拳脚了。一开始项目进展挺好,中期有一次和市场部门人员闲聊时,对方提了一个随意的问题;听闻他讲完,老程心中不禁大吃一惊。糟糕,这里没有想到,确实是客户需要的功能,但项目已经进行到中期,如果改动,意味着要打破计划,于是,心一横,对市场人员说,你的想法很好,第二个版本我会考虑加上。

    就这么团队人员吭叽吭叽码了几个月代码,项目宣告完成,交于市场人员推向市场,获得反馈真是多,比各位粉丝的评论还要热烈,于是团队成员不得不再次修改项目,期间团队的气氛压抑到极点,好在最后经过无数次的抢救,项目被抢救过来了,市场反应相对小一些。

    结果这一次项目,反思了一点,为何要制定详尽的计划?详尽的计划一定是对的吗?能不能,划分模块,相互独立的模块,由市场人员来确定优先级,做完一个阶段的功能后,让市场人员进行评审,并收集反馈,进行更高。

    于是在第二个项目《XX旅游网》启动时,采用轻计划及规范。由客户参与,罗列出项目的愿景及价值。在一次周日,老程坐上游轮到香港的中环,在总部和客户进行一次交流,虽然那几个美女热情的讲解,但没听懂多少(对方讲英文,连蒙带猜,懂了50%左右);咳咳,一不小心跑题了。
    书归正传
    在第二个项目中,我们团队吸取上个项目的教训,决定采用迭代式交付。虽然也属于传统型项目管理,但比瀑布式要好的多。

    通过小版本的迭代—评审–修复缺陷–发布,期间用到看板,这种项目管理流程,HK的客户MM们挺满意,期间特意从HK来公司进行深入交流,气氛异常融洽。

    直到接触到敏捷后,才知道,原来是有一种项目管理方法是基于变化、实现客户价值为核心的方法,那就是敏捷。

    适应性原则声明

    《声明》:预测不确定性,并设法通过迭代、预防、适应来应对不确定性;
    
    《声明》:通过使用根据具体情况而定的策略、流程和实践来提高效率和可靠性;
    
    《宣言》:响应变化胜过遵循计划;
    
    《宣言》:即使在产品研发后期,也乐于接受变化的需求,敏捷流程充分利用变化以增加客户竞争优势;
    
    《宣言》:团队定期反省如何做到更有效,然后响应的调整团队的行为。
    

    总结:
    以客户价值和质量为目标,计划就是实现这些目标的方式而非目标的本身。计划中的约束依然重要,只是不是重点,重点变成了计划约束是指导项目完成的一种方法,在随着项目的深入,要对计划进行剪裁和更新,使一潭水由死变为活水。


    敏捷项目管理之探索
    敏捷是为了在动荡的商业环境中创造利润而制造并响应变化的能力–《敏捷项目管理》

    有响应变化的能力固然很好,但是如果能给竞争对手创造变化则更佳。创造变化就是向对手展开竞争攻势。想赢对手的变化,是防守。

    变革是困难的,比如,老程一直想戒烟,无奈抽上容易,戒掉很难。要警惕那些固有的习惯,习惯有时会成为惰性,阻止我们作出变化。

    尽管敏捷价值观告诉我们,响应变化比执行计划更重要;但往往研发团队习惯固有的计划,而不愿作出大胆的探索,因为探索带来的可能是颠覆性的重构。

    探索式困难的,容易引发焦虑、恐惧。这是就需要敏捷项目管理者及时鼓励团队成员,鼓励试错、借鉴成功经验和错误经验,创造安全的环境,让大伙大胆地说出自己的想法。外部的鼓励和内部的鼓励可以帮助团队建立内部激励;

    研发产品是需要被引导而不是被管理,我们容许团队成员有好的点子,有变革的激情。每个项目都有一只和未知的条件、有确定因素和不确定的因素,因此,如何在计划和变化中找到平衡点变得尤为重要。这就需要我们用各种方法去探索例如用户故事作坊、用户特性、用户角色、用户画像、用户故事、每日展会、评审会等等方法来帮助我们。


    研发人员

    在研发团队中,最重要的就是人员。如何点燃人员的激情,很重要。需要各种激励和惩罚手段来调动和约束人员。

    人员的意愿也很重要,如果人员对敏捷项目管理或者对公司文化认同,不用打鸡血,人员会释放自己的激情,关于如何做,请参照老程的另一篇《敏捷项目管理-在敏捷环境中交付》一文。


    障碍还是机会

    障碍?机会?

    老程经常有听到:“敏捷做法太耗时间、敏捷做法太昂贵了、敏捷流于形式”等等对敏捷的抱怨。这种做法往往是针对短期迭代、频繁更新、持续整合、测试等一系列其他的敏捷做法。

    大多时候,人们感觉适应变化成本太高,是因为做事相率低下–没有抓住机会简化流程提高组织的适应能力。敏捷研发需要短期迭代,持续集成。很多公司在运用敏捷时,对WIP没有限制,一股脑的把probacklog中的所有事项集中到doit中,高速公路因为在制品的增多,不堵车才怪。可以参照我的另一篇文章《敏捷项目管理-精益产品开发》。

    如何看待障碍和机会?我们在遇到困难或作出变革时,要经常问一句“这样做对我们有什么益处?”


    结束

    开发优质的产品需要探索,而不是遵循计划。探索和适应是创新的两个行为特质–拥有探索未知世界的勇气,拥有承认错误并适应形式的谦逊。
    在敏捷中,我们运用一些列的方法“KANBAN、精益软件研发、Scrum、xp、sprint、站会、评审、回顾”等等方法,丰富软件研发的方法,为我们提供有依据的探索工具和方法,让我们在研发的探索之路上不迷路!
    —2020-03-10 0:28 中山

    展开全文
  • 而敏捷项目领导者关注如何成功地区适应不可避免出现的变化。   01.以客户价值和质量为目标,计划就是实现这些目标的方式。   02.适应性原则声明  《声明》:预测不确性,并设法通过迭代、预防、适应来应对不确定...

    00.传统的项目管理者这种按计划行事,尽量做到和计划没有出入;而敏捷项目领导者关注如何成功地区适应不可避免出现的变化。

     

    01.以客户价值和质量为目标,计划就是实现这些目标的方式。

     

    02.适应性原则声明

      《声明》:预测不确性,并设法通过迭代、预防、适应来应对不确定性

      《声明》:通过使用根据具体情况而定的策略、流程和实践来提高效率和可靠性

      《宣言》:响应变化胜过遵循计划

      《宣言》:即使在产品开发后期,也乐于接受变化的需求。敏捷流程充分利用变化以增加客户竞争优势

      《宣言》:团队定期繁盛如何做到更有效,然后响应调整团队行为

     

    03.适应可以看作是对变化做出的深思熟虑的回应。

     

    04.对于敏捷项目而言,这个集合包括核心团队成员、客户、供应商、高级主管和以及各种方式相互影响的其他参与者。

     

    05.创造变化,就是向对手展开竞争攻势。响应竞争对手的变化,就是在防守。

     

    06.伟大的探索者清楚表述出可以激发人们灵感的目标——让人们激动、自我激励的目标。

     

    07.团队需要有共同的目的和目标,也同样需要有人鼓励他们试验、探索、犯错误、重新编组和向前迈进。

     

    08.预测变化(不确定性)、然后做响应调整,而不是遵循过期计划。

     

    09.实施可重复流程已经是许多公司的目标,但是在产品开发领域,重复被证明是错误的目标,事实上,它还是及其反作用的目标。重复意味着按照同样的方式做同样的事情,并取得同样的结果;而可靠意味着无论在前进道路中遇到什么障碍,都能达到目标,也意味着为达到一个目标而不断改变。

     

    10.即使声称使用重复流程也能成功的组织,通常也不是因为那些流程而成功,而是因为使用那些流程的人的适应能力强罢了。

     

    11.有效的团队在回顾时涉及4个领域:

      产品——从客户的角度和技术质量的角度;

      流程——团队正在使用的优秀流程和做法;

      团队——作为高绩效团队,这个小组的工作情况如何;

      项目——项目按计划进行的如何;

     

    12.根据需要调整流程和做法。

     

    13.开发优质的产品需要探索,而不是遵循计划。探索和适应是创新的两个行为特质——拥有探索未知世界的勇气、拥有承认错误并适应形势的谦逊。

     

    展开全文
  • 敏捷开发

    2017-04-07 23:00:00
    瀑布开发  瀑布模型(Waterfall Model)是Royce在1970年提出的,他把大型软件开发分为... 响应变化胜过遵循计划  从上面的宣言可以看出, 敏捷开发的核心是人 、协作、时刻可运行的软件、变化 。  

    瀑布开发

           瀑布模型(Waterfall Model)是Royce在1970年提出的,他把大型软件开发分为:分析与编程,象工厂流水线一样把软件开发过程分成各种工序,并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路,所以成为软件开发企业使用最多的开发模型。


           瀑布模型的特点:
           1、强调文档,前一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。所以很多开发人员好  象是在开发文档,而不是开发软件,因为要到开发的后期,才可以看到软件的“模样”。
           2、没有迭代与反馈。瀑布模型对反馈没有涉及,所以对变化的客户需求非常不容易适应,瀑布就意味着没有回头路。 
           3、管理人员喜欢瀑布模型的原因是把文档理解为开发的速度,可以方便地界定不同阶段的里程碑。
           瀑布模型的用户很多,也有一些反对的意见:
           第一 瀑布模型不适合客户需求不断变化的软件开发,尤其是客户的业务管理的软件,业务随着市场变化,而软件初期的设计可能已经大大变化,而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里,一方面市场带动需求变化,另一方面初期客户对需求描述不清楚,都为瀑布模型的使用团队带来困难。
            第二 瀑布模型是一种软件文档的开发,把开发者变成流水线上的机器,大量重复性的工作让编程人员提不起兴趣,工作很枯燥,没有激情,编程成了一种没有创意的机械劳动,这让一向以高科技为标志的高级程序人员大为恼火。
            在这种背景下,敏捷开发带来了新鲜的空气!


    敏捷开发

           那什么叫敏捷开发呢?简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

           敏捷开发宣言:
          1. 个体和交互胜过过程和工具
          2. 可工作的软件胜过面面俱到的文档
          3. 客户协作胜过合同谈判
          4. 响应变化胜过遵循计划
          从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行的软件、变化

     

    展开全文
  • "响应变化胜过遵循计划"对于存在很高变更比率的软件项目尤为重要。同样,我们通过相应变化来代替抑制变化以及大量的时间和精力来遵循一个大型计划。敏捷项目具有很高的工作队列的可视性,通过代办事项和任务看板来...

    再次理解敏捷宣言

    看到这张图片时,是不是倍感亲切。每一个接触敏捷的人,几乎都是从这张图片里的内容开始的。

    右项虽然也有价值,但是我们认为 左项 具有更大价值

    下面我们来理解下敏捷宣言中的四句话:

    1、个体和互动高于流程和工具

    流程和工具是我们项目中需要的,将团队的目的聚焦于个体参与和互动。项目是通过人来完成的,而不是通过工具。困难也是通过人来解决的,而不是通过流程。同样,项目是由人来完成的,范围由人来确定,项目成功也是由人来定义的。个体的参与和交互有利于项目的成功。但是,并不是说流程和工具对项目的成功和没有帮助,这些反而是重要的组织过程资产。我们拥有工科背景的人,会自然地倾向于流程和工具带来的逻辑性和遇见性。然而,项目最终还是关系到人,所以要想成功,我们需要花费大量的时间去完善一些不可预知的领域。第一条价值观"个体和交互胜过流程和工具"有助于聚焦个体的时间、能量和激情。

    2、可以工作的软件高于详尽的文档

    软件项目可以创造价值、高质量的软件为首要目标。然而很多人经常会过多的关注一些临时的可交付成果,比如泛泛的文档,却不太关注支持项目最终目标的可工作的软件。没有文档描述的软件在技术支持和维护上一定会出现问题及障碍,但是只有详尽的文档而没有完成软件对于任何一个组织而言都是没有价值的。所以,文档是需要的,但是需要把握其中的度。

    在庞大的团队、复杂的软件系统中,会经常出现无文本遗留等问题。所以,在这样的环境下,文档是必需的。很多软件开发人员都会注重细节和流程,虽然这些可以带来高的收益,但是会使开发人员的关注点远离软件开发的项目的初衷————完成可工作的软件。所以敏捷宣言"可工作的软件胜过详尽的文档"提醒项目成员更多的聚焦与项目的目标————价值。如果过度的关注了文档而牺牲了可工作的软件,那么文档也是无用的、没有价值的。

    3、客户合作高于合同谈判

    本条价值观提醒我们需要做到灵活与包容,而不能死板,类似于"正确的做事"和"做正确的事"。我们可以完全按照最初规定来完成产品,一旦客户改变想法或优先级,最好的做法就是通过灵活的方法完成新目标,而不是用最初的规定来对抗。

    知识型项目是动态的,特别是软件系统;软件是无形的和难以参考的,每一个软件都是独特的。外界的需求变化很快,技术的革新非常迅速,我们应该识别出将要发生变更的事件,与客户共同的定义"完成"。这将取决于互信关系和更灵活的合同模式,同时也需要将我们工作的重点从没有附加值的活动(例如对范围的争论)转移至更富有价值的工作上。

    4、响应变化高于遵循变化

    遵循计划是指按计划行事,中间可能需要采取纠正措施,目的是为了使预期的未来绩效与项目计划一致而做的一切事情。响应变化则是适应的过程,通过卓越构想和不断的反馈来采取适应性措施,适应性的目的是对实践而非预定计划的回应,是响应而非纠正。

    最初的计划有时候是不完全完善的。如果我们努力将项目按照最初的计划执行,那么会使我们投入更多的精力去响应必然的更变,从而导致投入的精力会浪费掉。但是敏捷宣言并没有建议我们为了应对变化而完全放弃计划。我们需要对项目做计划,同时我们也要明白,最初的项目计划是我们开始的时候制定的,随着工作的进程,我们需要持续更新计划。

    "响应变化胜过遵循计划"对于存在很高变更比率的软件项目尤为重要。同样,我们通过相应变化来代替抑制变化以及大量的时间和精力来遵循一个大型计划。敏捷项目具有很高的工作队列的可视性,通过代办事项和任务看板来形成计划。敏捷价值观的主旨就是提倡适应性计划,要求全员积极参与。

     

    敏捷的七个领域

    • 敏捷准则和理念
    • 价值驱动的交付
    • 干系人参与
    • 团队绩效
    • 适应性计划
    • 问题发现与解决
    • 持续改进(产品、过程、人员)

     《敏捷宣言》十二大原则

    1. 我们最重要的目标,是通过及早和持续不断地交付有价值的软件使客户满意。

    2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

    3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

    4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。

    5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

    6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

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

    8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

    9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

    10. 以简洁为本,它是极力减少不必要工作量的艺术。

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

    12. 团队定期地反思如何能提高成效,并依此调整自身的行为表现。

    敏捷宣言的17位作者

    • Alistair Cockburn
    • Andrew Hunt
    • Arie van Bennekum
    • Brian Marick
    • Dave Thomas
    • James Grenning
    • Jeff Sutherland
    • Jim Highsmith
    • Jon Kern
    • Kent Beck
    • Ken Schwaber
    • Martin Fowler
    • Mike Beedle
    • Robert C. Martin
    • Ron Jeffries
    • Steve Mellor
    • Ward Cunningham

    ---------------------------------------------------------------------------------------------------------------------------------------

    Link to:http://agilemanifesto.org/

    Principles behind the Agile Manifesto

    We follow these principles:

    1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

    3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    4. Business people and developers must work together daily throughout the project.

    5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    7. Working software is the primary measure of progress.

    8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    9. Continuous attention to technical excellence and good design enhances agility.

    10. Simplicity--the art of maximizing the amount of work not done--is essential.

    11. The best architectures, requirements, and designs emerge from self-organizing teams.

    12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

     

    Subway Map to Agile Practices

    https://www.agilealliance.org/agile101/subway-map-to-agile-practices/

    Agile Glossary

    https://www.agilealliance.org/agile101/agile-glossary/

     

    展开全文
  • 过程与工具、面面俱到的文档、合同谈判、遵循计划个体与交互胜过过程与工具可以工作的软件胜过面面俱到的文档客户协作胜过合同谈判响应变化胜过遵循计划2001年2月由17位世界轻量级方法学家提出了一份敏捷联盟宣言,...
  • 响应变化胜过遵循计划 1.1 个体和交互胜过过程和工具 一次次项目的惨败,激发我们创建一个过程来约束我们的活动、要求有某些人为制品(如文档)的输出。 如果团队中没有优秀的成员,那么就是使用好的过程也不能从...
  • 敏捷软件开发

    2007-11-23 15:17:57
    个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划
  • 因此我们需要明白“响应变化高于遵循计划”的原则。那么如何维持这两者之间的平衡,高效的完成一件事,这个问题也正是这篇文章所要和大家分享的,如何在敏捷开发中做计划,即敏捷规划。 一个人不能没有生活,而生活...
  • 软件项目管理,第二讲,习题记录

    千次阅读 2020-03-12 11:12:59
    A:个体和交互 胜过 流程和工具 B:客户谈判 胜过 客户合作 C:可以工作的软件 胜过 面面俱到的文档 D:响应变化 胜过 遵循计划 选B ( )是七大浪费中最大的浪费,它除造成直观的浪费外,还会把“等待是浪费”隐藏...
  • 响应变化胜过遵循计划”,所以敏捷开发中的估算过程主要指在每个迭代计划会中,由开发人员自主估算本次迭代的工作内容。可是,随着一个个迭代结束,开发人员可能才逐渐感觉到整个项目需要一年,而实际上,高层领导...
  • A:软件开发应该遵循严格受控的过程和详细的项目规划 B:客户应该和开发团队在一起密切地工作 C:通过高度迭代和增量式的软件开发过程响应变化 D:通过频繁地提供可以工作的软件来搜集人们对产品的反馈 选A 敏捷...
  • Scrum题目 我最棒谢谢

    千次阅读 2019-10-09 15:23:19
    B:随着项目的进展,需要计划和重新计划是正常的 C:计划只有在所有利益相关方完全同意的情况下才能改变 D:由于敏捷是增量式的,因此不需要计划 选B ( )是七大浪费中最大的浪费,它除造成...
  • Scrum题库

    万次阅读 2018-12-18 09:39:39
    B:随着项目的进展,需要计划和重新计划是正常的 C:计划只有在所有利益相关方完全同意的情况下才能改变 D:由于敏捷是增量式的,因此不需要计划  选B ( )是七大浪费中最大的浪费,它除造成直观的浪费外,还会把...
  •     本文阐述敏捷开发的相关要点,做到理解切忌照搬硬套,特别是如果针对面试...》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗的理...
  • 项目管理之敏捷开发之道

    万次阅读 2017-05-21 10:55:46
    如果你决定保留7个模型,不论何时,一旦有变化发生(新需求的提出,原需求的更新,团队接受了一种新方法,采纳了一项新技术...),你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3...
  • 敏捷基础概念介绍 彭珂 Date: July 2012 敏捷的概念 敏捷...并发布了宣言和原则 敏捷宣言 个体和交互 胜过过程和工具 可以工作的软件胜过面面俱到的文档 客户合作 胜过合同谈判 响应变化 胜过遵循计划 虽然右边的也有价
  • 响应变化 胜过 遵循计划 敏捷开发12个原则: 1、最先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 2、即使到了开发的后期,也欢迎改变需求。敏捷过程利用适应变化来为客户创造竞争优势。(适应需求...
  • 敏捷宣言 * 个体和交互胜过流程和工具 * 可以工作的软件胜过面面俱到的文档 * 客户合作胜过合同谈判 * 响应变化胜过遵循计划 * 虽然右项也具有价值,但我们认为左项更具有价值 7.相互依赖声明 * 通过持续为客户创造...
  • 敏捷软件开发scrum介绍

    千次阅读 2018-08-31 20:30:54
    4.响应变化胜过遵循计划 拥抱变化,面对变更应及时调整策略 敏捷方法是一系列过程的统称,都包括哪些过程呢? XP(极限编程)、RUP(统一软件过程)、Scrum等。 其中scrum在近些年越来越流行。因此我们专门...
  • 敏捷的价值观有5条,分别是:个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划、虽然右项有价值,但我们更重视左项。值得注意的是,敏捷的价值观并未否定...
  • 实战中的Agile开发

    千次阅读 2015-07-23 12:07:25
    Agile(敏捷)开发介绍 开始本篇之前先来大致看看敏捷开发的内容: ... 响应变化 胜过 遵循计划 再来看一下,敏捷开发需要遵循的一些原则: 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
  • 响应变化胜过遵循计划。 除了上述价值观,他们还提出12条原则: 1.我们的当务之急,是尽快把有价值的软件交给客户,并持续进行交付。 2.我们欢迎客户修改需求,即便在开发阶段行将结束时也依然如此。敏捷流程会...
  • 敏捷开发 之Scrum

    2017-03-30 22:05:35
    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   ...为了不落后他人,于是我也...响应变化 胜过 遵循计划   作者: Taven.李锡远 出处: http://taven.cnblogs.com/  
  • 敏捷哲学崇尚“客户合作胜过合同谈判”和“响应变化胜过遵循计划”。跟1亿多个客户合作是艰难的。合同谈判在跨团队依赖性管理方面是至关重要的。(参见第8章的“要么听我的,要么走人”栏目。)遵循计划对于商业承诺...
  • 打造敏捷的自组织团队

    千次阅读 2014-07-30 10:35:09
    响应变化胜过遵循计划”这条宣言告诉我们,软件项目的评估是为了适应变化而非为了遵循计划。更深一层的含义是,项目计划应当保持一定的弹性(指计划时间可以经常适时地调整,项目管理也得敏捷!),即如期完成项目...
  • 本文总结于《软件工程——原理、方法与应用》第三版 第九章 ...可以运行的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划 极限过程:轻量级、敏捷的开发方法 四个价值观:交流、简单、反馈和勇气
  • 敏捷测试Agile Testing 敏捷宣言 个体和交互胜过流程和工具 可用的软件胜过完备的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 敏捷方法 Scrum Crystal 极限编程XP 动态系统开发方法DSDM 特征驱动开发FDD 测试...
  • 然而,这种模式有很多问题,包括不能很好的响应变化,容易开发出庞杂而难以理解的系统,导致维护和二次开发变得很困难等。此外,这种模式还会降低团队的开发效率,使得团队经常创建错误的产品。其原因在于这样的过程...

空空如也

空空如也

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

响应变化胜过遵循计划