| Agile: opportunity and threat |
AbstractOn February 2001, a group of representatives of different development methodologies gathered in Utah. Their mission: to come to an agreement about the necessity of alternate methods for the traditional development process. The concerns about the cost, inefficiency and lack of good results, known to waterfall development, took them to agree with various principles, later stated in their “Manifesto for Agile Software Development”. From the snow-covered mountains of Utah, the agile way of thinking has taken the world by surprise and it is a need for every developer to know its implications. This article is an introduction to the Agile thinking, its interesting proposals and the threats of adopting its principles too lightly, especially if they have not been completely understood. Key words:life cycle, Agile Manifesto, Systems Engineering, Architecture ContextThe life cycle of software can be seen as the phases that the development has to go through from the application’s conception, to the launching of the software. To go through these phases implies the use of a methodology. At the moment, one of the most famous stigmas of software development is the well-known delivery delay, together with over-costs and over-work that end up being a discontent for the client and a sub-optimum product. Every study about this problem shows the used methodology as the main cause of it, along with the developer slack of required abilities. In this context, the word “developer” is a synonym of member of the development group, and not necessarily an encoder or a system engineer. Because of this, a group of innovators and thinkers, (also called anarchists by some people because of their ideas against the traditional stream), have developed new methodologies that seek decreasing or eliminating the problems, that they think, the traditional methodologies have. At the beginning of 2001, seventeen of these scholars got together to sky in the Wasatch Mountains, Utah. Their concern was the proliferation of methodologies lacking principles that will guide them to a common goal: to improve development. As a result of that meeting they got the Manifesto for Agile Software Development. Up to now, the “Agility” in development has become not only the “must have” for all development groups, but also a requirement from every client. “Agility” and PrinciplesTraditional development has been criticized for its lack of flexibility. The waterfall life cycle has become “the unspeakable term” by the supporters of the “Agility” because of its preliminary exhaustive design principle: it can’t go on to the next phase unless everything has been covered and planned; therefore, documented. This principle indicates that every requirement has to be discovered and described before the development starts. The problem is that a lot of time is consumed doing these two things, and that generates a lot of documentation that will end up being useless at the moment requirements change. Furthermore, the defect correction phases turn out to be mini waterfalls that incorporate new functionality. Why do all the requirements have to be defined before moving on to the next phase? This is the question raised by the ones that defend the “agility”. They believe the problem is that the methodology does not have the ability to manage requirements’ changes at advanced phases, nor the problems generated by bad planning that are detected only when coding is done; which is in turn considered a phase that starts too late in the process. The term “agile” refers to the capacity of dealing with problems and changes, and skipping the plan if that is beneficial to the clients. Another problem found in the so-called waterfall, is that the methodology is based on predefined and strict contracts. Clients cannot change their minds or adjust things in order to improve their vision because it will be more expensive for them. This plan’s centralization and the contract’s rigidity, away from being the application’s particular goal, are one of the sources of the client’s dissatisfaction. The “agility” movement is not based on creating a new methodology but in following principles that will help changing the problem of the rigid methodology. These principles are based on the balance of the proposed values of the manifesto. At this moment, all the agile methodologies, obviously follow the principles mentioned before and none of them follow the waterfall. In summary, the principles are:
It is important to note that the problems for which the followers of the “agility” reject the waterfall life cycle lay in the lack of flexibility of the methodology more than in the division of their phases. The importance of this difference will be discussed later on this article. Another important distinction that usually creates confusion, even between “agility” followers, is that the problem in question is not the planning, but the predictive approach. The waterfall methodology tries to “predict” all future requirements while agility adapts to changes. Therefore, the agile methods do not have a problem with planning or discipline. Known Agile methodologiesVarious alternate development methodologies created even before this manifesto, follow the agility principles. This is a list of the current ones; a description of each one is not covered in this article.
Adoption and OpportunityAs it has been mentioned, “agility” is not a methodology, but a guide to be followed. To adopt “agility” demands a change in the way of doing things, a change of priorities and a revision of the methodology followed until now. It does not mean that the present technology should be forgotten and changed with a famous one, but that the principles should be incorporated in the daily, personal and team work. Adopting these will affect the team at all levels. Accepting the Agile philosophy should be seen as an improvement opportunity in the daily routine. Such acceptance also brings an opportunity to review the methodology currently used. And, of course, not following the world’s trend can become a differentiation risk. Adaptation and threatNevertheless, this adoption has to be done carefully and guided by professionals that know and fully understand the agile philosophy. As stated before, the agile world can present confusing concepts that might seem trivial, but they are really deep. This has caused many people rejecting phased methodologies just because of their similarity to the waterfall. There are other that think being agile means to be insubordinate and to avoid planning. This becomes a threat because the idea of building better software can be easily lost, by focusing on bad practices like no order or no planning. One of the devices not well accepted by the agile community, is the one known as BDUP (Big Design Up Front). This refers to the tendency of creating a design that covers all the edges before the development is started. There are the ones who even avoid any kind of diagram, up to the extreme of creating the whole application directly by encoding. One of the biggest proclamations is the decease of the system’s architecture. In association with the BDUP’s generation and diagrams, the architecture is vetoed from the agile teams. Architecture, usually done in the waterfall’s analysis and design phases, where code is not generated, is a synonym of losing time in documentation. However, the authors have already started to indicate that this separation is dangerous. The methodologies that build structure from the code tend to lose the global vision and might require a lot of change and “adaptation” work. For large projects, the application of the agile principles must include analysis and architectural building, planning and designs to guide the development. This all means adopting Agile is not just throwing away all order and discipline, but to make that order more flexible. If precautions are not taken, adoption may be done in the wrong way, causing even more problems. As a conclusionThis brief article tries to explain, in a simple way, the agility concept and how it is revolutionizing the way how software is made. Although the ideas and principles are common sense, their implications can be very subtle and not as easy to adopt. This cannot be ignored. It is important to study a way to incorporate agility carefully, not at once, to avoid any kind of confusions that might turn it into a threat.
|
William Martinez Pomares