You are on page 1of 1

Azka Sumbel,IBIT,Punjab University Characteristics of Agile Methodologies

People Oriented- Agile methodologies think about people consumers, developers, stakeholders, and end users like the most significant element of software methodologies. Adaptive The contributors in an agile procedure are not reluctant of variation. Agilists encouraged modifications at just about all phases of the project [1]. Conformance to Actual Agile methodologies advantage is conformance to the actual results as in contrast to conformance to the comprehensive plan. Highsmith states, Agile projects are not managed by conformance to plan but by conformance to the business value [3]. Balancing Flexibility and Planning Plans are worthwhile, though the problem is that software projects cannot be efficiently forecasted far away right into the future, because there are lots of parameters to consider into account. A significantly better planning strategy is to make detailed plans for the next few weeks, very rough plans for the next few months, and extremely crude plans beyond that [4]. Empirical Process Agile approaches develop software as an empirical (or nonlinear) procedure. In engineering, processes are either characterized or empirical.. Laurie Williams states, It is highly unlikely that any set of predefined steps will lead to a desirable, predictable outcome because requirements change technology changes, people are added and taken off the team, and so on [5]. Decentralized Approach Establishing a decentralized operations design can greatly influence a software project simply because it could save a whole lot of time than an autocratic management process.. Simplicity Agile teams always take the simplest path that is consistent with their goals. Fowler states, They (agile teams) dont anticipate tomorrows problems and try to defend against them today [1]. Collaboration Agile methodology focused on customer responses on a regular and frequent basis. As well, constant collaboration between agile team members is essential. Small Self-organizing teams An agile team is an own organizing team. Obligations are disseminated to the team all together, and the team pinpoints the best approach to satisfy them.

The 12 principles of the Agile Software development made by the Agile Manifesto [2]: 1. Our greatest concern is actually to fulfill the customers by means of ahead of time and steady delivery of worthwhile software. 2. Encourage altering specifications, even overdue in development. Agile processes control change for the customer's competitive advantage [2]. 3. Provide working software frequently, with a inclination to the smaller timescale [2]. 4. Enterprise people and developers must work mutually everyday all through the project[2]. 5. Develop projects close to determined and inspired individuals. Provide them the environment (workspace) and support they require, and have confidence in them to get the job achieved [2]. 6. The highly effective and efficient approach of transferring information to and within just a development team is live interaction [2]. 7. Working software is the leading matice of progress [2]. 8. Agile processes encourage sustainable development. The vendors, developers, and users should be able to preserve a persistent pace indefinitely [2]. 9. Constant attention to technical brilliance and ameliorates agility [2]. 10. Simplicity--the art of capitalizing on the amount of work not done--is absolutely essential [2]. 11. The finest architectures, requirements, and designs come through from self-organizing teams [2]. 12. At standard intervals, the team echos on how to grow to be more efficient, then tunes and changes its actions accordingly[2]. References: 1: M. Fowler, The New Methodology, 2: W. Cunningham, Agile Manifesto. http://www.agilemanifesto.org/, 3: J. Highsmith, Agile Software Development Ecosystem, Addison Wesley, 2002 4: J. A. Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Addison Wesley 2000. 5: L. Williams and A. Cockburn, Agile Software Development: Its about Feedback and Change, IEEE Computer, June 2003, pp. 39-43

You might also like