phần mềm phương pháp agile phát triển rà soát, phân tích

2.2. Overview and definitions The “Agile Movement” in software industry saw the light of day with the Agile Software Development Manifesto4 published by a group of software practitioners and consultants in 2001 (Beck et al. 2001; Cockburn 2002a). The focal values honored by the agilists are presented in the following: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan These central values that the agile community adheres to are: First, the agile movement emphasizes the relationship and communality of software developers and the human role reflected in the contracts, as opposed to institutionalized processes and development tools. In the existing agile practices, this manifests itself in close team relationships, close working environment arrangements, and other procedures boosting team spirit. Second, the vital objective of the software team is to continuously turn out tested working software. New releases are produced at frequent intervals, in some approaches even hourly or daily, but more usually bi-monthly or monthly. The developers are urged to keep the code simple, straightforward, and technically as advanced as possible, thus lessening the documentation burden to an appropriate level. Third, the relationship and cooperation between the developers and the clients is given the preference over strict contracts, although the importance of well drafted contracts does grow at the same pace as the size of the software project. The negotiation process itself should be seen as a means of achieving and 4 agilemanifesto.org and www.agilealliance.org, (1.5.2002) 11 maintaining a viable relationship. From a business point of view, agile development is focused on delivering business value immediately as the project starts, thus reducing the risks of non-fulfillment regarding the contract. Fourth, the development group, comprising both software developers and customer representatives, should be well-informed, competent and authorized to consider possible adjustment needs emerging during the development process life-cycle. This means that the participants are prepared to make changes and that also the existing contracts are formed with tools that support and allow these enhancements to be made. According to Highsmith and Cockburn (2001, p. 122), “what is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and maneuverability. This yields a new combination of values and principles that define an agile world view.” Boehm (2002) illustrates the spectrum of different planning methods with Figure 1, in which hackers are placed at one end and the so called inch-pebble ironbound contractual approach at the opposite end: InchMilestone Milestone pebble risk-driven planironbound driven development models models contract ... ... Adaptive SW Hackers XP Agile methods Software CMM CMM Figure 1. The planning spectrum (Boehm 2002, p. 65). Hawrysh and Ruprecht (2000) state that a single methodology can not work for the whole spectrum of different projects, but instead the project management should identify the specific nature of the project at hand and then select the best applicable development methodology. To stress the point further, according to McCauley (2001) there is a need for both agile and process-oriented methods, as 12 there is no one-size-fits-all software development model that suits all imaginable purposes. This opinion is shared by several experts in the field (Glass 2001). Cockburn (2002a, p. xxii) defines the core of agile software development methods as the use of light-but-sufficient rules of project behavior and the use of human- and communication-oriented rules. The agile process is both light and sufficient. Lightness is a means of remaining maneuverable. Sufficiency is a matter of staying in the game (Cockburn 2002a). He proposes the following “sweet spots” the presence of which in software development work enhances the prospects for a successful project outcome: - Two to eight people in one room o Communication and community - Onsite usage experts o Short and continuous feedback cycles - Short increments o One to three months, allows quick testing and repairing - Fully automated regression tests o Unit and functional tests stabilize code and allow continuous improvement - Experienced developers o Experience speeds up the development time from 2 to 10 times compared to slower team members. 13 2.3. Characterization Miller (2001) gives the following characteristics to agile software processes from the fast delivery point of view, which allow shortening the life-cycle of projects: 1. Modularity on development process level 2. Iterative with short cycles enabling fast verifications and corrections 3. Time-bound with iteration cycles from one to six weeks 4. Parsimony in development process removes all unnecessary activities 5. Adaptive with possible emergent new risks 6. Incremental process approach that allows functioning application building in small steps 7. Convergent (and incremental) approach minimizes the risks 8. People-oriented, i.e. agile processes favor people over processes and technology 9. Collaborative and communicative working style Favaro (2002) discusses the emergence of strategies for confronting a vague process showing changing requirements. He proposes the iterative development paradigm as the common denominator of agile processes. Requirements may be introduced, modified or removed in successive iterations. Once more, this approach featuring changing requirements and delayed implementation calls for new contractual conventions. These are, e.g., transition from point-view contracts (nailing down the requirements up front) towards process-view contracts, and also the consideration of the anticipation of legal aspects in relationship evolvement (Pöyhönen 2000). These theoretical legal aspects, however, are still in their beginning, not to mention the concrete capitalization of these new contractual phenomena. Also the framework contracts efficiently used 14 together with relevant project or work order agreements reflect the ongoing development in software business, which inherently supports this kind of agile software development (Warsta 2001). Highsmith and Cockburn (2001) report that the changing environment in software business also affects the software development processes. According to the authors, to satisfy the customers at the time of delivery has taken precedence over satisfying the customer at the moment of the project initiation. This calls for procedures not so much dealing with how to stop change early in a project, but how to better handle inevitable changes throughout its life cycle. It is further claimed that agile methods are designed to: - produce the first delivery in weeks, to achieve an early win and rapid feedback - invent simple solutions, so there is less to change and making those changes is easier - improve design quality continually, making the next iteration less costly to implement, and - test constantly, for earlier, less expensive, defect detection. The basic principles of agile methods comprise an unforgiving honesty of working code, effectiveness of people working together with goodwill, and focus on teamwork. A set of commonsense approaches emerging from agile software development processes have been suggested by Ambler (2002b) as follows: - people matter - less documentation is possible - communication is a critical issue - modeling tools are not as useful as usually thought - big up-front design is not required. Home-ground Agile methods area Developers Geographically distributed, collaborative, knowledgeable an d agile teams Customers Dedicated, Dedicated , knowledgeable, knowledgeable, collocated, collaborative, and collaborative, empowered representative, a nd empowered Requirements Largely emergen Largely emergent; rapid change, t; commonly owned rapid change , continually evolvi ng – Architecture Designed for Open, designed fo current r requirements current requireme nts Refactoring Inexpensive Inexpensive Size Agile, knowledgeable, collocated, and collaborative 15 Open source software Plan-driven methods Plan-oriented; adequate skills; access to exte rnal knowledge Access to knowledgeable, collaborative, representative, and empowered custom ers Knowable early; lar gely stable Designed for current and foreseeable require ments Expensive Smaller teams a Larger dispersed Larger teams and teams and smaller products nd products products Primary objecti Rapid value ve Challenging probl High assurance em Boehm (2002) analyses the agile and process-oriented methodologies or plandriven as he calls them. Table 2 shows how the Open Source Software (OSS) paradigm places itself between the agile and plan-driven methods. The OSS is still fairly new in business environment and a number of interesting research questions remain to be analyzed and answered. Thus the OSS approach can be seen as one variant of the multifaceted agile methods. Table 2. Home ground for agile and plan-driven methods (Boehm 2002), augmented with open source software column. 16 2.4. Summary The focal aspects of light and agile methods are simplicity and speed. In