Only article is used to express some of the criticism of the industry phenomenon.
Agile is now very popular software R & D model, and the industry is becoming mainstream. The figure comes from the software testing industry in the 2018 report, respondents can be seen in the tester, the working class in the proportion of agility or agile projects already up to 89%.
The test mode into the agile, be adjusted according to the model of agile projects, to achieve "quick test" is the Capability Maturity test team must have.
Before talking about agility test, we must first find out what is agility.
Agility, Chinese Glossary refers to the reaction (multi-finger gesture or words and deeds) rapid and efficient, the key is quick word. It is due to this feature is ideal for today's small run-paced project, but also makes agile been popular. To do the project, will talk about agility, not agile project managers are embarrassed to go say hello to people.
However, many (alarmist to say that even most) project for the understanding and application of agile are produced deviations. For some project organizers, the agile like a straw, so that they can justifiably discarded red tape they think, self-righteous energy into the team they think the most valuable areas as well. This agile, process contempt, contempt for management, contempt for all the preparation and planning, in the end the project can only be a mess .
Agility is a well-established principles and practices, but must be properly look at and use.
When we talk about agility, what we in the end talking about
There are some theoretical system, will be agile and some common software model side by side and talk about life, I think agile and waterfall model, iterative model as a "model." However, I believe, its agility is considered a model as it is a subversive idea. The contrast of the concept of agility, not the software life model, but more fundamental, approach to software development organization: the "software engineering."
Development of software industry, through many stages, from the early development = programming software, to the 1970s, gradually born engineering system. Up to now, software engineering is already a standard concept in the industry.
We might look back and ask why software development to a "project" type of organization?
We do not tangle its Glossary, what scene the following projects in the common usage of the word it? One area he was most probably used: Infrastructure "project" , such as building a house, the decoration - a typical project management.
We can compare same-sex class software development and infrastructure projects: through the accumulation of code line by line, with a brick of a building will be built up, it is not very similar? !
So it is as shown below, our software development process and infrastructure projects made an analogy:
This analogy is very ok, and indeed we can in the form of infrastructure projects of the organization, will be the same software development project management. Until now, the "software engineering" is already standard definitions and modalities within our profession.
In the project-oriented thinking, a lot of "lean production" system theory in the field of integration is also being constantly in the software development industry, such as PMP project management, such as CMMi maturity models, and so on.
-------------------------- ---------------------- divided about --------------------
However, with the accelerated pace of society, people in the industry gradually found the drawbacks of project management. For example, red tape into project organization, planning, design phase takes, and even much higher than the actual production.
This time we'll go back and look at our comparison on software engineering and infrastructure projects, they really are a dime same?
Cover a house, we need rigorous project planning, design, procurement requires strict accordance with the plan of building materials, structural design requires strict accordance with the requirements of the construction. Planning and design of a little unreasonable that occur, are likely to shake the foundation of the follow-up work; the construction process a little bit loose, are likely to bring into a shabby.
Then the software development is not also true? Is not a product features, using the method completes A and B will have a fundamental way to do problems? Is not less write a few lines of code, will certainly lead to the collapse of the product? Is not no design drawings, engineers completely unable to carry out construction (coding) work?
You will find answers to these questions are all negative, software development and infrastructure projects by no means entirely similar, measure the success of software development or not, or even only one criteria: customer satisfaction .
From a different angle, the software engineering research and development in the traditional sense, the software is regarded as a product for sale , he did not like the other two commodity production process. So the concept of lean manufacturing, streamlined management workshop also introduced the software development process. Really software and factory production lines of the product the same? Absolutely not the same, the demand for software is highly customizable features, different people different companies different groups require different software, not for daily use product is so stereotyped. With the concept of updates and upgrades, and now the industry more thought, not so much software is a product, software is a service . Do software development with the idea of doing service and one quick point of departure.
So from this point of view, what software is developed through the process of how to come out, not as important as the software is developed to meet user needs. Behind closed doors, behave, workshop-style software development, many projects can not meet today's needs.
We can look at what agile four Declaration are talking about:
- Personnel exchanges over processes of the tool ( the Individuals and Interactions over Processes and Tools)
- Heavy software product in lengthy ( Working Software over Comprehensive Documentation)
- Customer collaboration is more important than contract negotiation ( the Customer Collaboration over Contract negotiation)
- Adaptable to behave weight ( Responding to Change over following Plan A)
For these agile to promote the idea, if you do not understand the agility of the above background, it will have applied bias.
For example, the second point: the software product is more important than long-winded, stressed that the document is not the core of complex software developed, the product itself is our ultimate goal. Refers to the fact that we should not be excessive pursuit of complex documents, referring to the document in the form of change, rather than documents do not ! Agile projects with their own forms of organization applicable documents, such as agility needs more inclined to use the form of user stories, rather than the PRD in the traditional sense.
Another example of the fourth point: resourcefulness is more important than behave, emphasized that mean that one should follow the rigid plan, but should embrace change. He was talking about core issues that deal with and respond to change, rather than a haphazard, disorganized !
Such as software development in the traditional sense, a software may take a year or two finally come out, and in the last couple of years time, the software in the end whether the market position and customer needs, this judgment is ambiguous, because the process end users do not always see the finished software. The Agile emphasizes the strong response to user needs by introducing sprint cycle in the form of the large software development process to be split on the stage of 2-4 weeks, quick output of basic products. The base product quickly to the market and users, allows users to judge the degree of applicable products, if the market satisfaction is low, one word: change.
Embrace change, this is the agility.
To sum up:
Agile core is sensitive and quick, that fast. The ultimate goal is not to fast quick and fast, not to cut corners and fast, not because you are poor management, a lot of things you organize well, so you do not altogether abandon the ability to do these things to achieve rapid purpose. Not because it can not demand agility, agility because the do not do so, not in order to achieve the purpose of agile as an excuse to be lazy, which ignorant and shameless performance!
Agile is now very popular software R & D model, and the industry is becoming mainstream. The figure comes from the software testing industry in the 2018 report, respondents can be seen in the tester, the working class in the proportion of agility or agile projects already up to 89%.
The test mode into the agile, be adjusted according to the model of agile projects, to achieve "quick test" is the Capability Maturity test team must have.
Before talking about agility test, we must first find out what is agility.
Agility, Chinese Glossary refers to the reaction (multi-finger gesture or words and deeds) rapid and efficient, the key is quick word. It is due to this feature is ideal for today's small run-paced project, but also makes agile been popular. To do the project, will talk about agility, not agile project managers are embarrassed to go say hello to people.
However, many (alarmist to say that even most) project for the understanding and application of agile are produced deviations. For some project organizers, the agile like a straw, so that they can justifiably discarded red tape they think, self-righteous energy into the team they think the most valuable areas as well. This agile, process contempt, contempt for management, contempt for all the preparation and planning, in the end the project can only be a mess .
Agility is a well-established principles and practices, but must be properly look at and use.
When we talk about agility, what we in the end talking about
There are some theoretical system, will be agile and some common software model side by side and talk about life, I think agile and waterfall model, iterative model as a "model." However, I believe, its agility is considered a model as it is a subversive idea. The contrast of the concept of agility, not the software life model, but more fundamental, approach to software development organization: the "software engineering."
Development of software industry, through many stages, from the early development = programming software, to the 1970s, gradually born engineering system. Up to now, software engineering is already a standard concept in the industry.
We might look back and ask why software development to a "project" type of organization?
We do not tangle its Glossary, what scene the following projects in the common usage of the word it? One area he was most probably used: Infrastructure "project" , such as building a house, the decoration - a typical project management.
We can compare same-sex class software development and infrastructure projects: through the accumulation of code line by line, with a brick of a building will be built up, it is not very similar? !
So it is as shown below, our software development process and infrastructure projects made an analogy:
This analogy is very ok, and indeed we can in the form of infrastructure projects of the organization, will be the same software development project management. Until now, the "software engineering" is already standard definitions and modalities within our profession.
在工程思维导向下，许多“精益生产”领域的理论体系也在被不断的融入软件研发行业内，比如PMP项目管理，比如CMMi成熟度模型，等等。
——————————————————————————分割一下——————————————————————————————————————————
但是，随着社会节奏的加快，业内的人士逐渐发现了工程式管理的弊端。比如，繁文缛节的项目组织、计划、设计阶段所花费的投入，甚至远高于实际的产品生产。
这个时候我们再回过头去审视我们关于软件工程和基建工程的对比，他们真的是一毛一样的吗？
盖一栋房子，我们需要严密的工程规划，设计，需要严格按照计划进行建筑材料的采购，需要严格按照结构设计的要求进行施工。规划和设计中出现的一点不合理，都可能会动摇后续的工作的根基；施工过程中的一点点不严谨，都可能造就成一项豆腐渣工程。
那么软件研发是不是也同样如此？是不是一个产品功能特性，采用A方法完成和B方法完成会产生根本性问题？是不是少写几行代码，就一定会导致产品的崩溃？是不是没有设计图纸，工程师就完全无法开展施工（编码）工作？
你会发现这些问题的答案全部都是否定的，软件研发与基础建设工程绝非完全类同，衡量软件研发的成功与否，甚至只有一条标准：用户的满意。
换一个角度来说，传统工程意义上的软件研发，将软件视作一种待售产品，他与其他的商品生产过程并无二样。那么精益生产的理念，流水线式的生产车间管理也被引入软件研发过程。软件真的与工厂里流水线上生产的产品一样吗？绝对不一样，软件的需求具有高度定制的特性，不同的企业不同的人不同的群体，需要不同的软件，绝非日用产品那般千篇一律。随着理念的更新和升级，现在的业界更多认为，与其说软件是一种产品，软件更是一种服务。用做服务的思想去做软件研发，也是敏捷的出发点之一。
所以从这个角度而言，软件究竟通过怎么样的过程被研发出来，并不重要，重要的是研发出来的软件要符合用户需求。闭门造车，循规蹈矩，工厂车间式的软件研发，已经不能适应当今的许多项目需求。
我们可以看看，敏捷四宣言都在谈论什么：
- 人员交流重于过程与工具（Individuals and interactions over processes and tools）
- 软件产品重于长篇大论（Working software over comprehensive documentation）
- 客户协作重于合同谈判（Customer collaboration over contract negotiation）
- 随机应变重于循规蹈矩（Responding to change over following a plan）
对于这些敏捷宣扬的理念，如果不理解敏捷的上述背景，就会产生应用的偏差。
比如说第二点：软件产品重于长篇大论，强调说复杂的文档不是软件研发的核心，产品本身才是我们的最终目标。指的其实是我们不应该过分追求复杂的文档，指的是文档形式的转变，而不是不要文档！敏捷项目有着自己适用的文档组织形式，比如敏捷需求更倾向于使用用户故事形式，而非传统意义上的PRD。
再比如说第四点：随机应变重于循规蹈矩，强调说不应该死板的遵循计划，而是应该拥抱变化。他谈论的问题核心在于变化的处理和应对，而不是毫无计划，杂乱无章！
比如传统意义上的软件研发，可能耗费一两年一个软件才最终问世，而在这一两年的时间内，这个软件到底是否符合市场定位和用户需求，这一判断是含糊的，因为这个过程中最终用户始终也没有看到软件的成品。而敏捷则强调对于用户需求的强响应，通过引入冲刺周期的形式，将庞大的软件开发过程拆分成为期2-4周的阶段，快速的产出基础产品。快速的将基础产品推向市场和用户，让用户来评判产品的适用度，如果市场满意度低，一个字：改。
拥抱变化，这才是敏捷。
最后总结一下：
敏捷的核心在于灵敏迅捷，在于快速。快速的终极目标不是为了快速而快速，不是为了偷工减料而快速，不是因为你管理能力低下，很多事情你组织不好，所以干脆抛弃这些你没能力做好的事情来达到快速目的。不是因为敏捷所以可以不要需求，因为敏捷所以该做的事情不做，不要以敏捷为借口来达到偷懒的目的，这是无知和无耻的表现！