敏捷的本质

最新推荐文章于 2023-06-19 16:18:14 发布
置顶 最新推荐文章于 2023-06-19 16:18:14 发布
阅读量728 收藏 2
点赞数 2
分类专栏： 软件开发 文章标签： 敏捷 Agile 本质 敏捷宣言 敏捷原则
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/SystemEngineeringLab/article/details/85617877
版权

更多请关注微信公众号 SystemEngineeringLab
SystemEngineeringLab

我们一直在谈论敏捷、学习并实践敏捷，在敏捷大爆发的今天，许多组织或团队都声称是“敏捷的”，那么到底什么是 “敏捷” 呢 ？要回答这个问题，我们必须要要回归到敏捷诞生的标志–敏捷宣言。

1. 敏捷的诞生

在2001年，17位具有反叛精神的软件开发方法的代表性人物相聚在犹他州的雪鸟城，并进行为期三天的小型会议。这些人都是来自当时“轻量级”软件开发方法的代表性人物，相比于计划驱动的开发方式，特别是已被业界普遍接受的瀑布模型，这些轻量级的软件开发方法还不太为大众所熟知。他们共同探讨了关于软件的构想、开发、交付甚至涉及了关于世界运作的方式，并最终签署了敏捷的标志性文件-敏捷宣言。

2. 敏捷宣言

2.1 敏捷的价值观

敏捷宣言的开篇即描述了敏捷宣言的初衷，其所探求的是更好的软件开发方式。实践出真知，正在通过在不断的实践中进行总结、抽象、剥离，最终汇总出来这四颗 “银弹”（当然没有万能的银弹），为诸多寻求更好的的软件开发方式的人提供思想指引。
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.
最后一句总结同样重要，敏捷宣言对左右两侧的价值都认可，并不是否认右侧存在的价值。只是，敏捷认为左侧更为重要。
中文如下：

  1. 个体和交互 胜过 流程和工具
  2. 可工作的软件 胜过 面面俱到的文档
  3. 客户合作 胜过 合同谈判
  4. 响应变化 胜过 遵循计划

2.2 敏捷宣言背后的原则

也许敏捷所遵循的原则通过英文的方式表述更加“原汁原味”，不同的中文翻译多有偏颇，下面是摘自官方英文版的原文。
We follow these principles:

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

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

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

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

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

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

Working software is the primary measure of progress.

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

Continuous attention to technical excellence and good design enhances agility.

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

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

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

这12个原则所表述的不是什么“新”东西，也不是敏捷的独创性原则，大家在软件开发的过程中已经亲身实践着里面的一个或多个原则。这些原则是17位敏捷宣言签署者从已有的软件开发方法中汇总、提炼所得，有几分最佳实践的意思。
大家结合自身的工程经历，对每条原则可能会有不同的体会。我个人印象最深刻是：

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

简单！简单! 简单！
简单是敏捷的精髓，这是使 “不需要做的工作最大化” 的一门艺术。如何保持简单确实是一门艺术。根据“二八原则”，80%的价值通过20%的工作实现。当我们完成了百分之八十的价值之后，剩余的百分之二十的价值要耗费我们百分之八十的工作量，那我们还需要继续做下去吗？当然。剩余的80%的工作依然适用二八原则。但最终我们关注的是给客户带来的价值，通过最少的工作使客户最大的价值得以满足，可谓是“事半功倍”了。

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

我们最高优先级的目标是通过尽早的、持续的交付有价值的软件使客户满意。的确如此，我们软件开发的原始动力是要为商业目标服务。我们开发出来的软件产品能够满足客户的需求，并最终获得客户的认可，这是实现商业目标的必要条件。及早的和持续的交付有架子的软件是实现这一条件的有效方式。及早的交付能够实现客户所关注的价值的软件能够有效提升客户满意度，持续的交付（相对的概念，可能“频繁的交付”更为合适）有助于我们尽快获得客户的反馈，及早捕获客户可能得变更，降低后续变更带来的风险。

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

周期性的检视、调整以追求卓越。敏捷没有终点，倡导持续性的检视和改进。这是一个持续性的过程，不以项目的开始而开始，项目的结束而结束。在单个团队、多个团队和组织内持续的改进。我们要有审视自身问题的勇气和改进的决心，不以追责和批判为目的，以发现问题和改进为导向，在更加积极、热情的分为下，形成检视-改进的良性循环。

3. 关于敏捷的一些探讨

探讨一：敏捷的本质是什么 ？

“敏捷”是一种抽象的软件开发思想，敏捷宣言用四颗“银弹”勾勒出一种思维方式，这种思维方法有助于我们更好进行软件开发，甚至有助于我们更好的认识世界。
我个人认为敏捷是纯粹的，敏捷白喉的原则不应当属于敏捷定义的范畴。敏捷是通过其价值观所体现出的一种思想方式，是纯粹的价值观。
“敏捷”不是方法论，敏捷也不是“框架”，“方法即为具体，框架即结构”，敏捷没有告我们进行软件开发的具体步骤，也没有为我们描绘软件开发的框架，我们在实际开发中如何实践敏捷多有差异。如果您在工程实践中遵循了敏捷的价值观，就可以认为具有“敏捷性”。

探讨二：敏捷过时了吗 ？

自2001年到现在，作为一份签署的历史性文件敏捷宣言已经有近17年了。如此长的一段时间内，已经涌现出非常多的、优秀的软件开发方法实践。但软件开发的根本思想变化并不是很大，过去的一些价值和原则时至今日依然适用。当然，我们不能完全的认为敏捷宣言是百分之百正确的且无懈可击的，世界上本没有“银弹”，依然有很多人对敏捷持有不同见解和意见。不可否认，敏捷宣言所倡导的价值观和原则确实能够使得我们在软件开发中受益，只是作为一份历史性的材料，敏捷宣言已经不可能再发生改变。
也许，敏捷宣言的签署者们也没有料想到敏捷宣言会带来如此大的变化，拥有如此众多的敏捷追随者。但令人不安的是，当前敏捷似乎已经“泛滥”了，大家都在谈敏捷、实践敏捷并声称自己是敏捷的，同时，也涌现出了很多的其他的敏捷领域，紧跟“敏捷”之后，“敏捷软件”、“敏捷教练”、“敏捷培训”和“敏捷会议”都成为了“敏捷开发”的理念。这些理念不能说是错的，也不能说是“纯粹”敏捷，或多或少地都是遵循了敏捷的价值和原则。个人并不排斥这种“百家争鸣”式的 “发展”，但另许多人不安的是，这些敏捷似乎已经脱离了 “技术性” 的轨道，也许这种场景下，“纯粹敏捷” 拥护者已经不再认为那是敏捷了。

探讨三：敏捷等于“快”？

许多企业或组织准备引入敏捷的最初动力就是 “敏捷能使我们更快”，因为我们引入了敏捷，所以我们一定能：1. 更快的开发出产品 2. 让团队能拥有更高的开发效率 3. …
非常不幸的是，敏捷并不等于“快”，相反，敏捷引入的初期可能会导致生产力的下降。比如，为了能够实现所谓的“更快”的目标，管理层频繁的向团队施压，要求团队在更短的时间内交付更多的价值。团队面对管理层的压力也就不得不靠“加班”来实现预期结果了（退队自组织的成熟度有限，在实际落地时，或多或少都会感受到来自“管理层”的压力。）。虽然在短期内可能能够“立竿见影”，但这种方式已经“不敏捷”了，因为它不具备“持续性”。
可以肯定的是，有效的实施敏捷确实能使我们更好的交付商业价值、客户更加满意、缩短产品上市时间。但这并不是基于 “敏捷等于快” 的这个论调。以敏捷的价值观为指引，遵循敏捷的相关原则，我们会更加关注业务价值的交付，并且会尽可能早的交付客户，尽快获得客户的反馈，自组织的团队也更关注研发能力提升、使不需要做的工作最大化了等等…所有这些改变和提升都有利于我们变得更 “快”。

开放探讨

到底怎样做我的团队或组织才算是敏捷了呢 ？敏捷背后有这么多建议的原则我都要遵循才是敏捷吗 ？

欢迎大家留言讨论 ！

SystemEngineeringLab
关注
  • 2
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
打造敏捷团队
04-15
敏捷门派很多，什么才是敏捷呢？敏捷过于理想，无法在中国落地？如何才能让敏捷真正发挥实效呢？开发人员过于“闷骚”，敏捷不起来，咋办呢？本课程将会为你逐一拆解！
敏捷开发纵横谈（4）——敏捷的本质是什么？
张传波（网名：Fireball，大大大火球）
10-01 3380
敏捷开发简单说就是用简单有效的办法去做有用的事情，过程的目的是让项目做得更好，不是为了过程而过程，不是用过程来“框死”项目，过程是为项目服务的。各家各派的敏捷方法论，其实基本道理都是这样的，只是各自从不同的角度来阐述如何做软件开发。我们没有必要盲目崇拜某某方法论，各种方法论也没有必要PK，我们应该集百家所长，为我所用！
敏捷开发_敏捷开发的本质到底是什么
weixin_42552637的博客
12-25 540
我们一直在谈论、学习并实践敏捷，在敏捷大爆发的今天，许多组织或团队都声称自己是“敏捷的”，那么到底什么是 “敏捷” 呢 ？要回答这个问题，我们有必要回归到标志着敏捷诞生的敏捷宣言。敏捷的诞生在2001年，17位具有反叛精神的软件开发方法的代表性人物相聚在犹他州的雪鸟城，并进行为期三天的小型会议。这些人都是来自当时“轻量级”软件开发方法的代表性人物，相比于计划驱动的开发方式，特别是已被业界普遍接受的...
敏捷到底是个什么鬼？
敏于思 捷于行
08-16 1273
“如何用一两句话说清楚敏捷的本质是什么呢？”温馨提示，如果眼睛太累或者在忙其他事，按照这个攻略可以听本文：看文章很累，不如听吧！手把手教你如何听公众号文章大家都知道，敏捷虽然是由一群软...
基于模型的系统工程（MBSE）
qq_41854911的博客
08-24 6869
要说MBSE，首先看看它的全称：Model-Based Systems Engineering字面即有三层含义：“”。首先，得聊聊系统（System）：用大白话就是从宏观到微观，多个相互作用的部分组合在一起成为一个整体，从而达到既定的目的。落到工程技术来看，其实就是“软件+硬件+流程+人员+信息+技术+……=产品/平台”。其次，一起看看**“系统工程”。**系统工程（SE，Systems Engineering）：如果说系统是部分组成的整体，那么系统工程就是让系统达成目的的方法和手段。
大敏捷的本质.pdf
08-10
### 大敏捷的本质 #### 赵卫 (David ZHAO) ##### 敏捷教练及顾问 ##### IBM大中华区敏捷及DevOps卓越中心主管 --- ### 大敏捷概述 在探讨“大敏捷”的本质之前，我们需要理解何为“大敏捷”。通常来说，“大...
敏捷开发纵横谈
01-30
“敏捷”一词实质没有统一定义，各家有自家的说法，本教程将让你了解“敏捷”的来龙去脉，抓住“敏捷”本质，并能在工作中实践“敏捷”。小甲想到某开发公司应聘开发工程师，向该公司的某开发人员打听他们的开发方式...
敏捷估算扑克
03-04
其实应该叫“估算扑克”更准确一些，本质上是扑克牌，基于Delphi估算原理，可以快速估算出需要的数字。估算扑克牌上的数字，有的牌是自然数排列，有些是斐波纳契数，有些则是不连续自然数。具体选用哪种扑克，要根据...
ASPICE 如何和敏捷开发相融合
最新发布
lautoplus的博客
06-19 411
在敏捷开发中使用自动化测试和持续集成：自动化测试和持续集成可以帮助团队更好地控制软件开发过程的质量和效率。整合ASPICE评估和敏捷过程：在敏捷开发中，软件开发过程是迭代的，需要不断地进行反馈和改进。将ASPICE评估融入敏捷开发中的过程：在敏捷开发中，可以将ASPICE评估融入到迭代的开发过程中，以便更好地控制软件开发过程的质量。总之，ASPICE和敏捷开发可以相融合，以实现高效的软件开发。团队可以选择适合自己的方法来整合ASPICE和敏捷开发，以便更好地实施ASPICE评估和持续改进。
现代软件工程之敏捷开发
10-29 260
敏捷软件工程是哲学理念和一系列开发指南的综合。这种哲学理念推崇：让客户满意且尽早的增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。开发的指导方针强调超越分析和设计的发布，以及开发人员和客户之间主动和持续的沟通。 推荐： 敏捷开发之扫盲Scrum SCRUM 视频 什么是敏捷开发？ 敏捷已经成为了当今描述现代软件过程的时髦用词。敏捷开发(Agi...
A SPICE (Automotive SPICE® Process Assessment Model)
07-26
Title: Automotive SPICE® Process Assessment Model Author(s): Automotive SIG Date: 2010-05-10 Status: RELEASED Confidentiality: Automotive SIG File Ref: automotiveSIG_PRM_v45.pdf automotiveSIG_PAM_v25.pdf
Agile.Project.Management.with.Scrum
04-18
Foreword: Why Scrum Works<br/>Suppose I’m traveling from Chicago to Boston by airplane. Before and during the flight, the pilot gets instructions from air traffic control. We take off on command and follow the prescribed route. Once we are in the air, computers predict almost to the minute when we will land in Boston. If things change—say the air is bumpy—the pilot must get permission to move to a different altitude. As we approach the airport, the pilot is told what runway to land on and what gate to go to.<br/><br/>If, however, I set out for Boston in a car, I can take whatever route I want, whenever I want. I don’t know exactly when I’ll get there, and I probably haven’t planned what route I’ll take or where I’ll stop for the night. En route, I follow traffic laws and conventions: I stop at red lights, merge into traffic according to the prevailing customs, and keep my speed consistent with the flow. In an automobile, I am an independent agent, making decisions in my own best interests framed by the rules of the game of driving.<br/><br/>It’s amazing to me that thousands upon thousands of people travel by car every day, accomplishing their goals in a framework of simple traffic rules, with no central control or dispatching service. It also amazes me that when I want to ship a package, I can enter a pickup request on the shipper’s Web site and a driver will arrive at my door before the time that I specify. The driver isn’t dispatched to each house; he or she receives a continually updated list of addresses and deadlines. It’s the driver’s job to plot a route to get all the packages picked up on time.<br/><br/>As complexity increases, central control and dispatching systems break down. Some might try valiantly to make the control system work by applying more rigor, and indeed that works for a while. But the people who prevail are those who figure out how to change to a system of independent agents operating under an appropriate set of rules. It might work to provide same-day delivery with a dispatch system that plans a driver’s route at the beginning of the day. However, it is far more difficult to preplan a pickup route when customers can enter pickup requests at any time. Taxi companies sort things out at a central control center. Some shipping companies send the request to the driver responsible for the area and let the driver determine the best route based on current conditions and other demands.<br/><br/>The more complex the system, the more likely it is that central control systems will break down. This is the reason companies decentralize and governments deregulate—relinquishing control to independent agents is a time- honored approach to dealing with complexity. Scrum travels this well-trodden path by moving control from a central scheduling and dispatching authority to the individual teams doing the work. The more complex the project, the more necessary it becomes to delegate decision making to independent agents who are close to the work.<br/><br/>Another reason that Scrum works is that it dramatically shortens the feedback loop between customer and developer, between wish list and implementation, and between investment and return on investment. Again, complexity plays a role here. When a system is simple, it’s not so hard to know in advance what to do. But when we are dealing with a market economy that changes all the time and with technology that won’t stand still, learning through short cycles of discovery is the tried-and-true problem-solving approach.<br/><br/>We already know this. We try out various marketing campaigns and discover which approach works. We simulate vehicle behavior during car design to discover the best slope of the hood and best distribution of weight. Virtually all process-improvement programs use some version of the Deming cycle to study a problem, experiment with a solution, measure the results, and adopt proven improvements. We call this fact-based decision making, and we know that it works a lot better than front-end-loaded predictive approaches.<br/><br/>Scrum is built on 30-day learning cycles that prove complete business concepts. If we already know everything and have nothing to discover, perhaps we don’t need to use Scrum. If we need to learn, however, Scrum’s insistence on delivering complete increments of business value helps us learn rapidly and completely. One of the reasons complete increments are important is that partial answers often fool us into thinking that an approach will work, when in reality, the approach doesn’t work upon closer examination. We know that until software is tested, integrated, and released to production, we can’t really be sure that it will deliver the intended business value. Scrum forces us to test and integrate our experiments and encourages us to release them to production, so that we have a complete learning cycle every 30 days.<br/><br/>Scrum doesn’t focus on delivering just any increment of business value; it focuses on delivering the highest priority business value as defined by the customer (Product Owner). The Product Owner and the Team confer about what that definition is, and then the Team decides what it can do in 30 days to deliver high-priority business value. Thus the short feedback loop becomes a business feedback loop—Scrum tests early and often whether the system being developed will deliver value and exactly what that value will look like. This allows the system to be molded over time to deliver value as it is currently understood, even as it helps to develop a better understanding of that value.<br/><br/>Another reason Scrum works is that it unleashes the brainpower of many minds on a problem. We know that when things go wrong, there are people around who knew there was a problem, but somehow their ideas were overlooked. For example, when the space shuttle disintegrated on reentry, a widely reported interpretation of the causes of the disaster suggests that there were engineers who were well aware that there could be a problem, but they were unable to get their concerns taken seriously. What management system can we use to leverage the experience, ideas, and concerns of the people closest to the work to be done?<br/><br/>According to Gary Convis, president of Toyota Motor Manufacturing Kentucky, the role of managers in a healthy, thriving, work environment is “to shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals.[1] <br/><br/>Scrum turns small teams into managers of their own fate. We know that when we are responsible for choosing our own driving route to Boston, we will find a way to get there. We will detour around construction and avoid rush hour traffic jams, making decisions on the fly, adapting to the independent decisions of all of the other drivers out there. Similarly, Scrum Teams accept a challenge and then figure out how to meet that challenge, detouring around roadblocks in creative ways that could not be planned by a central control and dispatching center.<br/><br/>If teams are of a size that encourages every member to participate, and team members feel like they are in control of their own destiny, the experience, ideas, and concerns of individual members will be leveraged, not squelched. When team members share a common purpose that everyone believes in, they will figure out how to achieve it. When teams understand and commit to delivering business value for their customers, when they are free to figure out how to perform tasks, and when they are given the resources they need, they will succeed.<br/><br/>Gary Convis notes that Toyota’s sustainable success comes from an “interlocking set of three underlying elements: the philosophical underpinnings, the managerial culture and the technical tools. The philosophical underpinnings include a joint [worker], customer-first focus, an emphasis on people first, a commitment to continuous improvement…. The managerial culture…is rooted in several factors, including developing and sustaining a sense of trust, a commitment to involving those affected by first, teamwork, equal and fair treatment for all, and finally, fact-based decision making and long-term thinking.[2] <br/><br/>Scrum works for all the same reasons. Its philosophical underpinnings focus on empowering the development team and satisfying customers. Its managerial culture is rooted in helping others achieve their goals. Its technical tools are focused on making fact-based decisions through a learning process. When all of these factors are in place, it’s hard for Scrum not to succeed.<br/><br/>—Mary Poppendieck<br/>Poppendieck.LLC<br/><br/>
MBSE对汽车EEA研发的作用何在？
03-03
传统的EEA中最核心的系统设计基本都是以文字描述为基础的，辅助以各种图表。现在的大多数国产车都是这么造出来的。看起来好像也没毛病，毕竟我们的几十个自主品牌靠这种方式造了几十年的车，广大的人民群众也渐渐接受了国产车，国产车的份额也能占到国内份额的30%左右，好像按照这种方式也能够继续生存下去。可是我们中国人民是有理想的，我们一直在想着弯道超车或者换道超车。既然想超车就要换个好的动力系统或者靠超强的能力。我们先说说超强的能力怎么获得，说句心里话，这个真的很难，我们的优势在于成本控制，IT技术应用比较成熟，敢于创新，还有我们的员工很敬业，这是我们能够在过去的几十年里能够取得那么大的进步的基础。可是，
项目管理之敏捷开发之道
纸上得来终觉浅，绝知此事要躬行
05-21 1万+
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷迷雾背后的本质
me.think(everything.about("software")).serialize(this);//古路刀客
04-12 177
&nbsp;&nbsp;&nbsp; 我想表达的意思是，&ldquo;敏捷&rdquo;这个字眼包含的意义太多了。每个人理解都不一样，它到底意味着什么。我可以形容一只狗很敏捷。敏捷，已经退化为一种符号，只是人们谈论时的一种外衣，已经不具备任何意义。 &nbsp; &nbsp;&nbsp;&nbsp; 在软件开发范畴中中，敏捷不是终点，而是达成目的的一种手段。XP好？Scurm好？Lean好？F...
敏捷本质 - 价值驱动，拥抱变化
weixin_30329623的博客
07-07 373
　　敏捷开发可以说是一次变革行动，行动之前团队对敏捷的本质有个初步的共识是敏捷实施成功的关键。这个话题来自我的一个2天的敏捷开发相关的企业培训，主要讲解敏捷背后的那些核心概念，有利于形成敏捷开发中的核心理念。 转载于:https://www.cnblogs.com/zhoujg/p/3475730.html...
敏捷的本质在于短和小（Size Matters）
敏于思 捷于行
04-29 337
预计阅读时间：3分钟“敏捷开发有什么特别的？早几十年前就有迭代开发的概念了。”“用户故事和需求文档里的功能点有什么区别？瀑布模式也是一个个功能点做的呀。”“持续交付有什...
敏捷开发流程总结
热门推荐
alvanchen的专栏
07-20 12万+
<br />Agile——敏捷开发，作为CMM神话崩溃后被引入的一套新的软件开发模式，这几年来被广泛引起关注，并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知，但以下总结了我所在公司的敏捷开发试验，希望可以达到管中窥豹的目的。<br /><br />敏捷开发宣言——<br />个体和交互 胜过 过程和工具<br />可以工作的软件 胜过 面面俱到的文档<br />客户合作 胜过 合同谈判<br />响应变化 胜过 遵循计划<br />虽然右项也有价值，但是我们认为左项具有更大的价值。<br /><
敏捷无它，唯持续改进
博文视点（北京）官方博客
08-29 2302
这个案例发生在我曾经所在的C公司，我是两进两出这个公司，这个案例主要是讲述我第二次进这个公司后一年之中所发生的一些事情，以及我的一些思考。 那一年，距离公司引入Scrum已经将近3年，喧嚣过后，Scrum和敏捷何去何从？公司经过3年变得敏捷了吗？敏捷的本质又是什么？
敏捷开发：超越单一过程，探索敏捷方法的本质
"本文主要探讨了敏捷开发的误区，指出敏捷并非单一的过程，而是一类遵循敏捷价值观和原则的过程的集合。敏捷开发起源于上世纪90年代，通过一系列方法学的发展，如极限编程（XP）、Scrum、水晶方法（Crystal）、特性...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值