敏捷宣言_敏捷宣言和企业scrum作者mike beedle去世 - CSDN
精华内容
参与话题
  • 敏捷宣言

    2018-05-08 22:25:48
    敏捷宣言个体和互动高于流程和工具盲目地遵循流程与使用好的工具有的时候也会

    敏捷宣言

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

        盲目地遵循流程与使用好的工具有的时候也会帮你更快地犯错。往往这些流程和工具都是一些“领导”或一些“有经验”的“老员工”交给你的,而且他们会经常说这是对你有好处的,但是如果使用者并不认可他要使用的流程或工具,他就无法将这些东西坚持使用到最后。更糟糕的是,人们只是表面遵循这些流程规定的动作,即使这些做法会得到毫不相干的结果。

        近些年发现,在每日站立会议时每个员工都仅仅是快速地“讲”完了自己前一天干了些什么事情,然后就完事大吉了,别人发言的时候他们往往不太关心,因为别人往往与他们并不是一个领域,也有事不关己高高挂起的态度,但是这样不利于团队的成长,也不利于团队要交付的内容,他们需要理解一起工作的方式,明白每个人的工作会对其他人造成怎样的影响。


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

        一个团队有很多详尽的文档很容易,但是这些文档到最后往往没有人去阅读,而对于客户来说,一个可工作的软件对他们更有吸引力,那么什么是可工作的软件。可工作的软件是可以给公司组织带来价值的软件。这可以是公司出售的软件,也可以是帮助公司员工更高效工作的软件。这里同样要说明客户的概念,我在华为的时候学到的优秀理念就是,客户并不是狭义上的客户,只要是你工作的交付对象都是你的客户,比如你写测试报告,那么所有读测试报告的人都是你的客户,所以你的测试报告要能够给客户带来实际的价值。

        那么有些人又会拿来说事,来给自己完全不写文档寻找了一个“合理”的理由,但是根据国内外优秀的敏捷经验来看,文档还是要写的。一个号的文档能帮助团队理解问题,与用户沟通,以及避免将错误的需求开发进软件。有经验的团队往往可以采用一些将文档嵌入软件本身的创新方法。“测试驱动开发”就是这样的一种敏捷实践。在测试驱动开发中,程序员首先开发自动化测试单元测试,然后再开发上述单元测试的软件。自动化测试也可以当做文档使用,因为测试可以帮助程序员记录代码应该完成的功能,以及软件中单个组件预期的行为。


    客户协作高于合同谈判

        上述讲了在华为中学到的客户概念,这里的合同同样也是一个广义的概念。在很多公司中,不同开发团队之间、测试和开发之间以及开发团队和用户之间都会把服务级别协议(Service Level Agreement, SLA)(服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约)放在台面上讨论。这样做也许降低风险,减少与老板之间的矛盾,因为你可以指责其他团队影响了软件的交付。但是如果大家要达到的目标是给公司外的用户交付可工作的软件,这种做法只会适得其反。

        之前看到一篇文章中说,成功地项目需要定期且频繁地客户反馈,不是依赖于合同或者关于工作的陈述,而是让软件的客户和开发团队密切的工作在一起。不能糊弄客户,不能与客户成为敌对关系,客户也会想办法对付你。软件开发的最终目的是要给用户交付能够带来商业价值的软件,实现客户的商业目标以及公司的业务目标。


    响应变化高于遵循计划

        我原来是做测试组长的,包括我在内,所有的人最头疼的就是客户又有想法,又有变化的需求,这就意味着又一个通宵的到来。在业内,制定计划的人抗拒变化是很常见的事情,因为改变计划需要消耗精力。例如要把工作分割成多份,并估算每一份的工作量,这本身就需要消耗不少精力。一个变化就可能导致项目经理把这些事情全部做一遍。尽管遵循计划有利于项目顺利执行,但是如果真的有变化出现,在代码完成度更高的时候处理变化更为困难。

        造成这种现象还有一方面是计划做的不科学,一个良好的做计划的策略是:为下一周做一份详细的计划,可以把每件事都按照3W1H模式做好,为下3个月做一份粗略的计划,就不用制定的那么精确了,再为一整年或者后一年做一个极为简略的计划,有个初步概念即可了。

        即使有将计划做的很小,也会有很多团队在进行中很快就变成小瀑布模式了。任务的拆分也就是为了完成这件事,执行一个时间表,而团队为了在开始迭代前梳理清楚需求,要PRD(需求文档,产品项目由“概念化”到“图纸化”的最重要的文档,其作用就是对市场需求文档的内容进行指标化和技术化。),并在迭代中规定不要轻易改变迭代内容等。这与敏捷里地快速迭代初衷相违背了,为什么要求快速迭代,因为需求变化往往太快,快到你刚刚评审完用户故事,它下一刻就有了变化,这种变化是市场决定的。

        就像吃鸡模式的兴起,有一款游戏本来是看好模拟求生模式,做的游戏是让玩家在艰苦条件下挑战生存,但是一直不温不火,开发团队本来是计划增加一些有意思的生存点来吸引玩家,但是看到吃鸡模式的成功,索性在游戏中加入了该模式,直接救活了该游戏。国内外跟风在自家游戏中添加吃鸡模式的比比皆是,无论是剑网三还是LOL,都在考虑或者已经加入了该模式。这些开发人员肯定不擅长做这部分内容,但是市场决定了方向,极快的变化使得原先的计划必须作废,虽然打乱了计划,但是为客户、公司带来的实际的利益,这才是敏捷能够带来的优势。



    展开全文
  • 敏捷宣言》及敏捷开发十二原则

    千次阅读 2018-03-24 15:02:16
    敏捷开发宣言《敏捷宣言》我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应...
    

    敏捷开发宣言

    《敏捷宣言》

    我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观:

    个体与交互 重于 过程和工具
    可用的软件 重于 完备的文档
    客户协作 重于 合同谈判
    响应变化 重于 遵循计划

    在每对比对中,后者并非全无价值,但我们更看重前者

    敏捷宣言是对敏捷的高度总结和升华,即使现在不理解也没有问题,在实践的过程中我们会逐渐对它有一个深刻的认识。

    敏捷开发十二原则

    在敏捷开发中,我们遵循以下准则:

    1. 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
    2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
    3. 要不断交付可用的软件,周期从几周到几个月不等,且越短越好
    4. 项目过程中,业务人员与开发人员必须在一起工作。
    5. 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
    6. 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
    7. 可用的软件是衡量进度的主要指标。
    8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
    9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
    10. 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
    11. 最佳的架构、需求和设计出自于自组织的团队。
    12. 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
    展开全文
  • 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观: 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 ...响应变化 高于 遵循计划 ...

    我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

    个体和互动 高于 流程和工具
    工作的软件 高于 详尽的文档
    客户合作 高于 合同谈判
    响应变化 高于 遵循计划

    也就是说,尽管右项有其价值,我们更重视左项的价值。

    我们遵循以下原则:

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

    欣然面对需求变化,即使在开发后期也一样。善于掌控变化,帮助客户获得竞争优势。

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

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

    激发个体的斗志,以他们为核心搭建项目。提供他们所需的环境和支持,相信他们能够达成目标。

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

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

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

    对技术精益求精,对设计不断完善,将提高敏捷能力。

    以简洁为本,极力减少不必要工作量。

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

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

     

    展开全文
  • 敏捷方法论的前世今生 敏捷方法的历史: - 敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。 - 迭代和增量开发方法最早可以追溯到1957年 - 在二十...

    敏捷方法论的前世今生

    敏捷方法的历史:

    • 敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。
      • 迭代和增量开发方法最早可以追溯到二十世纪三十年代非软件项目。
      • 二十世纪六十年代美国航天局水星计划使用了一些极限编程和测试先行的防范。
      • 在二十世纪九十年代,各种各种轻量级软件开发方法纷纷被提出,其中包括:
        • 1991: RAD (rapid application development)
        • 1994: UP (unified process) 和 DSDM(dynamic systems development method).
        • 1995: Scrum
        • 1996: Crystal Clear & XP(extreme programming)
        • 1997: FDD (feature-driven development)
      • 2001年,17位软件开发者齐聚在美国的犹他州的雪鸟(snowbird),讨论上述轻量级的软件开发方法,并写下了敏捷软件开发宣言。

    敏捷宣言(Manifesto for Agile Software Development):

    - 个体和互动高于流程和工具 (Individuals and interactions over processes and tools)
    - 工作的软件高于详尽的文档 (Working software over comprehensive documentation)
    - 客户合作高于合同谈判 (Customer collaboration over contract negotiation)
    - 响应变化高于遵循计划 (Responding to change over following a plan)
    

    敏捷12条原则中文版:

    1. 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 
    2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。 
    4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。 
    5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
    7. 可工作的软件是进度的首要度量标准。
    8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    10. 以简洁为本,它是极力减少不必要工作量的艺术。
    11. 最好的架构、需求和设计出自自组织团队。
    12. 团队定期地反思如何能提高成效,并依此调整自身的举止表现。
    

    敏捷12条原则英文版 (Twelve Principles of Agile Software):

    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 ableto 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.
    

    评价一个敏捷团队是否合格的衡量标准(个人观点仅供参考)

    - 迭代开发:整个开发过程被分为好几个迭代周期,每个迭代周期可以是定长或者不定长。
    - 增量交付:产品在每个迭代周期内被增量交付使用,而不是在整个开发周期结束的时候一次性交付。
    - 团队成员与用户积极反馈以推动产品的开发:用户全程参与到产品的开发过程中。
    - 持续集成: 新的功能或者变化持续整合到产品中。
    - 自我管理: 积极的,自我管理的,具备自由交流风格的团队。
    
    展开全文
  • 敏捷观点:更看重个人及团队工作协作,沟通。 可以工作的软件胜过面面俱到的文档 传统观点:好的软件来自好的设计,好的设计来自好的分析模型。 敏捷观点:更看重可工作的软件,鼓励差不多建模来帮助理解问题和...
  • 敏捷开发宣言

    千次阅读 2017-03-03 16:53:22
    敏捷开发宣言:  1. 个体和交互胜过过程和工具  2. 可工作的软件胜过面面俱到的文档  3. 客户协作胜过合同谈判  4. 响应变化胜过遵循计划  从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行...
  • 前几天写培训PPT,突然发现不知道把敏捷宣言放在那里好。因为看上去,敏捷宣言中既有体现价值观的内容,也有直接的操作层面上的内容。大家请看(前后删除了一些): 个体与互动 胜于 过程与工具可工作软件 胜于 ...
  • 敏捷开发需要编写文档吗?

    千次阅读 2016-03-21 16:41:26
    在产品研发过程中经常需要编写很多文档,而敏捷宣言的第二条“可工作的软件胜于详尽的文档",那么需要编写文档吗?有没有简单的判断方法呢?
  • 敏捷开发实践(一)--谈谈我对敏捷开发的理解

    万次阅读 热门讨论 2015-05-31 09:58:51
    随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • 系列课程的目标是帮助学习者系统掌握数据结构课程的相关知识,具备利用这些知识分析问题、解决问题的能力。课程提供视频、课件、例程、自测、实践要求、参考解答等整套的解决方案,帮助学习者达到目标。...
  • 本系列文章将会分几篇文章为你分享什么是敏捷敏捷的“官方”定义,敏捷流程框架及最佳实践,敏捷在中国面临的挑战,实践敏捷所需要的土壤,最后给出我对敏捷的理解。本文是第一篇,我们将从“打针”说起!有没有搞...
  • 敏捷开发的价值观与十二条原则

    万次阅读 2017-02-26 18:10:34
    敏捷不是某一种方法论、过程或框架,更不是字面意义上的敏捷,而是一组价值观与原则。
  • 敏捷其实很简单(1)重读敏捷宣言

    千次阅读 2016-10-25 20:44:27
    本人在软件开发行业中混迹多年,接触敏捷开发也有3年多的时间了,期间SM, Agile Coach 都曾经从事过,在工作过程中也有过一些对软件开发流程,敏捷开发的一些思考和总结。这里想记录下来,和大家分享一下,也作为...
  • 这是敏捷开发一千零一问系列的第二篇。(在这里提问,之一,之二,之三,问题总目录)也是般若敏捷系列第十一篇。(之一,之二,之三,之四,之五,之六,之七,之八,之九,之十,之十一,之十二) 无住在般若敏捷...
  • 敏捷开发中的软件测试

    千次阅读 2007-09-05 20:15:00
    敏捷开发中的软件测试...》和《Agile Testing Challenges》 敏捷宣言:个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。- www.a
  • 读华为敏捷转型有感

    千次阅读 2017-03-04 20:09:09
    感谢万能的互联网,有机会拜读了华为的敏捷转型资料,做一些摘录与自己的理解,初步规划一下当下团队的敏捷推进计划。
  • 究竟什么是敏捷测试

    万次阅读 2013-04-17 10:26:03
    因为两年前(2010年底)时任谷歌中国测试经理的段念先生就写了一篇文章《什么是敏捷软件测试》(刊登在InfoQ网站上[1]), 就已经谈到这个话题,“敏捷软件测试更多的是一种理念,而非过程”。在2011年,我自己也写...
  • 在上篇文章中,我们重新理解了敏捷宣言,其中包括往往被人们忽视的前两句话。那么接下来这篇文章我们会看一下敏捷宣言的12原则。理解一下这12原则对敏捷开发在实践中的指导意义。 12原则作为敏捷开发对于软件开发...
  • 文:姚冬(华为云DevCloud首席技术布道师,资深DevOps与精益/敏捷专家,金融解决方案技术Leader,中国DevOpsDays社区核心组织者) 前言 敏捷是什么?DevOps是什么?两者有什么区别? 持续集成不是XP里面的么,...
  • 敏捷宣言 vs. 瀑布宣言

    千次阅读 2014-03-16 21:59:00
    2001年2月11日,在美国犹他州雪鸟(Utah Snowbird)滑雪圣地的一间小屋中,由著名专家Kent Beck等领头的17位... Manifesto),简称为“敏捷宣言”。 该宣言定义了敏捷开发的四项价值观,全文如下: 从亲自和
1 2 3 4 5 ... 20
收藏数 6,777
精华内容 2,710
关键字:

敏捷宣言