por Mary Loftus 12 anos atrás
543
Mais informações
I think some of the arguments put forward by people of the Agile method are misleading. Take a hypothetical comparison between agile methods and more formal methods.
Both approaches are applied to the same project. Both make their initial studies and conclude their are four main tasks to this project. Let us say A, B, C and D, which are inter-dependent. As I understand it the agile approach will tackle the module A first. It will design, code, document, test and deliver this module to the user for user acceptance testing. During this UAT, the team commence work on module . Minor bugs are discovered in Module A by the users, so the Agile team revisits A, makes the necessary fixes, delivers the revised module to the user and returns to work on B. The user is happy with module A and module B is soon ready for UAT. the Agile Team commence work on to C and so on to until the project is just about complete?
At the same time the Formal team are designing the modules A, B, C and D, keeping their documentation testing etc, up to spec. Soon they are ready to commence coding. And similarly they program, fairly much in the order of the modules as the Agile team. But when they get to D, they discover a flaw in the design (maybe something the client forgot to tell them) which has consequences for the whole project, all the modules. From what I understand of the argument, the Formal team will now have to go back over their designs, testing and coding. The Agile team discover the flaw in the same area.
Given the inter-dependence of the modules, will the Agile team not have to do the same thing? Go back over all their modules? Add to this that the Agile team have also wasted the clients time doing UATs on modules that will now have to be re-tested. The Formal team have not transferred any such work as yet to the client. So where is the benefit??
It seems to me that Agile protagonists tend to compare there approach with the older 'waterfall' lifecycle - sequential approach. But this approach has been refined over the last twenty year or so, and now has several versions, with iterative phases [McConnell, S (1996), pp136-139, pp143-147], [Rob, P., Coronel, C. & Crockett, K. (2008), pp487-493]. If this approach were applied to our example above the Formal team (using iterative actions) would quite possibly discover the flaw earlier in their development cycle, than the Agile team. Kent Beck, in a interview with Michael Krigsman, said "I think software projects are still going to fail because there still [will be] the promising ideas that don’t work out in practice. One thing that agile development can give you is to make sure those projects fail faster, sooner, cheaper, so you can get on with the next thing." [Krigsman, M. (2007 Nov 25)] A early failed project is not necessarily very comforting to a client, nor will it necessarily be discovered faster than a formal approach, and consequentially may not be cheaper. (Not for the client, who has invested time and effort in 'pre-mature' UAT)
I accept the fact the aspects of a Agile or Rapid development are possibly more suited to certain smaller projects and likewise more formal methods, more suited to larger projects. The agile approach (informal/less formal), by whatever name has been around for far longer than the various labels and names given to it. Like others in this discussion I think once the hype is gone, the term Agile will not last, but the general approach will continue to be around, as it always has been.
References
Krigsman, M. (2007 Nov 25) Agile development, early warning, Darwin, and failure ; (ZDNet, IT Project Failures)
Retrieved from http://blogs.zdnet.com/projectfailures/?p=494
McConnell, S. (1996) Rapid Development; Taming Wild Software Schedules. Redmond, Washington, USA: Microsoft Press.
Pressman, R. S. (2010) Software Engineering: A Practitioner’s Approach (7th ed). New York, USA: McGraw-Hill.
Rob, P., Coronel, C. & Crockett, K. (2008) DATABASE SYSTEMS : Design, implementation & Management. London, England; Cengage Learning EMEA
Trish's Rebuttal
RE: RE: DQ 1 - Agile Methods - will they last? Consider a hypothetical comparison
O'Connell, Trish
3/25/2010
0
Hiya Eric,
thought that made soo much sense to me that I rang Dave and he talked me back down.....
Seemingly in Agile development you wouldn't just work on A. The developers would do as much on A,B C & D as could be done in a Sprint and these small functional pieces are demo'd to the Customer. At that point the feedback is immediate. So itwould never happen that requirements would change completely. At most you only lose the work done in the previous Sprint.. or something like that... there was a mention of developers locked in a room for months and prying bug ridden disks out of cold dead hands but I'll skip that part;-))
Rgds,
Trish
RE: DQ 1 - Agile Methods - will they last?
O'Keeffe, Padraic
3/25/2010
0
Most of the web pages and books that I have seen with respect to Agile have the word ‘chaos’ referenced somewhere. While it does get referred to as ‘controlled chaos’ I have to admit I was concerned to see it mentioned so much. It is also characterized as an ‘antidote to bureaucracy’ or a ‘license to hack’ (Marick, 2005). However having further researched it, these characterizations seems to stem from people that are not totally up to speed on the concepts of Agile.
Working in the medical device environment we are extremely restricted by paper work. This makes it next to impossible to deliver software quickly no matter how small the software requirement. While the waterfall model as stated by Proinnsias has proven itself for large projects and large companies over time, I feel it is starting to do me out of a job.
Customers now know that even the smallest software change drives a large amount of documentation updates. As a result of this customers would rather live with the software bugs than face the daunting task of updating the documents. (On average for every 1 day coding there are 5 days for documentation and validations). It is on this basis that we are currently looking for a different approach that will allow us to produce the same good quality software but with far less documentation.
We need to introduce the concept of Lean more into our entire software development life cycle and to do this I think we need to embrace the concepts of Agile software development. Based on my research, Agile attempts to address these issues of flexibility, failure to meet customer expectations, missed delivery dates etc that the ‘waterfall’ approach has introduced. It does this by introducing some of the following methods.
* Crystal Clear
* Scrum
* Feature Driven development
* Adaptive Software Development
* DSDM [Dynamic Systems Development Model]
* Rational Unified Process.
Ambler (2008) performed an internet survey that identified a 69% adoption rate on a yearly basis from 2005 of the Agile process within organizations. Based on this data I think it’s fair to say that Agile is here to stay.
References
Marick, B. (2005, December 13). The New Methodology. Martin Fowler. Retrieved March 25, 2010, from http://martinfowler.com/articles/newMethodology.html
Ambler, S. W. (2008, May 7). Dr Dobbs - Has Agile Peaked?. C++, Development Tools, Java, Open Source, Web... the world of software development from Dr Dobb's. Retrieved March 25, 2010, from http://www.drdobbs.com/architecture-and-design/207600615;jsessionid=HOMGHMZGW5SZPQE1GHPCKH4ATMY32JVN
RE: DQ 1 - Agile Methods - will they last?
O'Keeffe, Padraic
3/25/2010
0
Most of the web pages and books that I have seen with respect to Agile have the word ‘chaos’ referenced somewhere. While it does get referred to as ‘controlled chaos’ I have to admit I was concerned to see it mentioned so much. It is also characterized as an ‘antidote to bureaucracy’ or a ‘license to hack’ (Marick, 2005). However having further researched it, these characterizations seems to stem from people that are not totally up to speed on the concepts of Agile.
Working in the medical device environment we are extremely restricted by paper work. This makes it next to impossible to deliver software quickly no matter how small the software requirement. While the waterfall model as stated by Proinnsias has proven itself for large projects and large companies over time, I feel it is starting to do me out of a job.
Customers now know that even the smallest software change drives a large amount of documentation updates. As a result of this customers would rather live with the software bugs than face the daunting task of updating the documents. (On average for every 1 day coding there are 5 days for documentation and validations). It is on this basis that we are currently looking for a different approach that will allow us to produce the same good quality software but with far less documentation.
We need to introduce the concept of Lean more into our entire software development life cycle and to do this I think we need to embrace the concepts of Agile software development. Based on my research, Agile attempts to address these issues of flexibility, failure to meet customer expectations, missed delivery dates etc that the ‘waterfall’ approach has introduced. It does this by introducing some of the following methods.
* Crystal Clear
* Scrum
* Feature Driven development
* Adaptive Software Development
* DSDM [Dynamic Systems Development Model]
* Rational Unified Process.
Ambler (2008) performed an internet survey that identified a 69% adoption rate on a yearly basis from 2005 of the Agile process within organizations. Based on this data I think it’s fair to say that Agile is here to stay.
References
Marick, B. (2005, December 13). The New Methodology. Martin Fowler. Retrieved March 25, 2010, from http://martinfowler.com/articles/newMethodology.html
Ambler, S. W. (2008, May 7). Dr Dobbs - Has Agile Peaked?. C++, Development Tools, Java, Open Source, Web... the world of software development from Dr Dobb's. Retrieved March 25, 2010, from http://www.drdobbs.com/architecture-and-design/207600615;jsessionid=HOMGHMZGW5SZPQE1GHPCKH4ATMY32JVN
Ken:
I like your reference to unnecessary documentation, and can certainly relate to it. I think that the frustration that developers have with documentation is the lack of shelf life that it carries. I’m sure that many of you have experienced the issue of finalising draft requirements with the nagging feeling in the back of your mind that the sands are shifting from under your feet, and that the document is out of date before it is actually completed. The (strict) process of change management then kicks in, with suitable time scales. All the while, the developers can see technological changes over the horizon that they want to get their hands on and play with, but the documentation driven process has put the brakes on them.
Rory
Importance of good doc organisation/archiving
Morville et al
Morville, P., Rosenfeld, L. (1998) Information Architecture for the World Wide Web. O'Reilly Inc. Catalog available at http://oreilly.com/catalog/9781565922822
Feynman
Feynman, R.P (1974) Cargo Cult Science. (essay) Adapted from Caltech commencement address, 1974. Available online at http://www.lhup.edu/~DSIMANEK/cargocul.htm
Hi Trish,
As somebody who has done Lean Six Sigma training one of the key philosophies is hearing the Voice of the Customer (VOC), which should delight the customer? Anything that's not required by the customer is considered waste or non value added might be a more appropriate term. As well as hearing the Voice of the Customer the other important thing is correctly identifying who your customer is - it's unlikely to be the person that actually buys your company's product - he's the sales people or retailer's customer. Addmittedly I am only familiar with Lean from a manufacturing perspective but as a process engineer the manufacturing department are my customers. The seven wastes that we typically strive to eliminate in a manufacturing environment are:
Transportation
Inventory
Motion
Waiting
Overprocessing (I guess this ties in closest with providing the customer with what he wants, the philosophy being why "waste" time, resources etc with the bells and whistles that the customer doesn't want or is not willing to pay for)
Overproduction
Defects
Kevin
Agile methods provided a necessary creative input into traditional software engineering practices when it was needed but they will not last.
Our first question this week considers the agile movement in Software Engineering? We touched on this briefly last week.
What is it?
The agile movement is a software engineering best practice that utilizes a structured project management process that has a tolerance to change emphasizes teamwork whilst also holding each team member responsible for the progress of the specific tasks.
What does the research tell us?
In order to consistently deliver large development projects successfully, software engineering practices need to be employed. My readings have shown that employing such practices result in the timely delivery of effective software solutions in terms of productivity of systems development and the quality of the developed systems.
However such practices are not widely used due to complexity and cost. My own experience with large development projects is littered with failed attempts to implement software engineering best practices. At the introduction phase there is a hugh drive to start using these tools but then after a short period gaps start appearing with the specific tools ability to accommodate a particular development activity. This failing in the tools ability puts a damper on initial enthusiasm consequently results in the team reverting back to old practices.
My research and experiences agree with Trish’s observation in that agile may be just a quality fad and will be replaced by a new fad in the near future with technology advancements. However that said TODAY I too have learned about ‘Scrum’ for the first time and share Paul’s enthusiasm especially with its approach to meetings, where clutter or hot air as Paul put it is taken out of the meetings and there is more focus on holding each team member accountable for the advancement of the project through there respective tasks.
Trish,
Thanks for the response – it’s good for me to get a perspective that doesn’t match mine, and doesn’t see the role naming process as sensible as I thought. When questioned, it does seem a bit silly, but it still makes sense to me.
I may be wrong but I see it as a way of differentiating between those who have an opinion and those who actually do the work. Meetings go on and on and on… because some people love to talk, rather than go back to their desks and work.
Often, the guys who actually do the work, like to keep their heads down, do what they’re told, and don’t like talking at meetings. I think this way forces those guys that really know how the project is going to inform everyone else in a public way. It saves a lot time, hot air, second hand information and unnecessary opinions.
If you know you’re going to be asked “what you’ve done since yesterday?”, “what are you going to do today?”, and “are there any problems?” – the answers are generally short and sweet.
You show up with your homework done if you know it’s going to be checked in a public manner. I’d be motivated to work harder by knowing that everyone in interested in my work, and how I’m getting on.
Is it a Fad? I don’t know, but I doubt it. I’ve watched several Agile & Scrum lectures through You Tube and Google Talks. The speakers are smart, enthusiastic, and I think I’d use it if I were looking for a project management methodology.
Is it perfect – No. (Moe, Dingsøyr, & Dybå, 2010) found that self managing teams didn’t manage so well without guidance and ”Scrum and agile methods offer no advice on how shared leadership should be implemented”
Reference:
Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480-491. doi:doi: DOI: 10.1016/j.infsof.2009.11.004
The following for anyone who hasn’t read the Chicken and the Pig definition of roles for Scrum as described in Wikipedia. If you haven’t, Trish is right – it seems a stupid naming convention. If you’ve read it already, please ignore, it’s a direct copy from :
http://en.wikipedia.org/wiki/Scrum_%28development%29
Roles
A number of roles are defined in Scrum. All roles fall into two distinct groups—pigs and chickens—based on the nature of their involvement in the development process. These groups get their names from a joke [5] about a pig and a chicken opening a restaurant:[6]
A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”
So the “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken”—interested in the project but really indifferent because if it fails they’re not the pigs—that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project.
Prionnsias
Trish I’m afraid I have to disagree with you on this one. I must say I’ve bought into the agile methodology and core principles. But i do see where you are coming from with your scepticism.
If you read the manifesto I can see how there is enough there to frighten off most people.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Getting corporate buy in to these principles can be tough. But at the core of the manifesto is the principle “Continuous attention to technical excellence and good design enhances agility” (Agile Manifesto)
On your question of whether it survive in the future or is it a fad?
While I think we all agree that the waterfall methodology will always be there, it’s proven and has worked with large projects for large companies, I take your point that the future of agile is not set in stone.
But I see the future particularly in Ireland of small, smart, lean SME’s where cost of software delivery is key and agile greatly helps here. It is in these environments that I see it thriving.
Larger companies, government agencies with larger budgets may go for the tried and trusted methodologies. But I see this as an organisational mindset as opposed to a slight on Agile.
These are 2 useful links to a quick references on agile.
http://www.agilemanifesto.org/
http://www.agilemanifesto.org/principles.html (link to the 12 principles of agile development)
Some that stand out for me are
· Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
· Working software is the primary measure of progress.
I may be a bit bias, as a do know someone, that runs agile training and delivers agile project management and software development from their company. They are big proponents of agile.
But they already have some marquee names on their and I think others will follow suit when they see the success and quality of the products delivered.
Trish-
I agree that this is one of the biggest roadblocks standing in the way of agile methodologies: the silly jargon. You have Pigs and Chickens in Scrum, "goal donors" and "gold owners" in Extreme Programming, and those are the ones I know about! I've seen two explanations for this:
1. It is an attempt to inject a bit of humour and frivolity into what is often a humourless process
2. It is a deliberate attempt to scare off the "suits", who won't "get it" anyway
Frankly, I think it's backfired. This is a pity because I think there is a lot of useful ideas in Agile.
One idea I'm particularly interested in is Pair Programming. Granted, my friends who have worked on projects where it's been tried have been pretty negative about it. However, I think it's the only way of really doing code reviews. I've lost count of the number of projects I've worked on where a code review was promised (threatened?) and where a) the review was dropped entirely because of schedule slip or b) no-one had time to study the code they were supposed to be reviewing and the thing descended into a nitpicking session over indent style and other inconsequential matters. Reading any non-trivial piece of code after it has been written is difficult because you are seeing the finished solution and you are missing the "scaffolding" of false starts and little experiments that the original programmer used to find the shape of the problem. The only way you can see this is by looking over the programmer's shoulder as they write the code -- hence, Pair Programming. I think much of the resistance to Pair Programming arises because it is a pretty "alien" way of working and most development environments have no support for it. Hopefully, this will improve... assuming the agile guys can get their act together and stop burdening their ideas with silly names guaranteed to get peoples' backs up!
- K
SCRUM is the version of Agile that has caught my attention. There are others doing this course who can speak about Agile & Scrum – from experience – I wish I could, but it didn’t exist the last time I was studying Project Management, and it wasn’t being used anywhere I’ve worked since – mores the pity. Short iterative project goals and steps must be easier to manage and know how you're getting on.
I’d never heard of it before we started this course, so I’m glad to have learned of it’s existence and use. I’ve looked through a lot of documentation and videos on Scrum, and the one I like the most is wikipedia :
http://en.wikipedia.org/wiki/Scrum_%28development%29
It’s a simple straightforward introduction, explaining the scrum master, chicken and pig roles (involved vs. committed). I like the idea of short, regular meetings that start and finish on time, where you know the questions that are going to be asked, so you come prepared to answer them : what did you do since yesterday, what are you going to do today, and are you having any problems. I like the fact that only the pigs are allowed to speak.
I watched a “Scrum in under 10 minutes video” at http://www.youtube.com/watch?v=Q5k7a9YEoUI&fmt=22
That did a simple demonstration of the Product Backlog, the Sprint Backlog and the Burn Down Chart that are listed as Artifacts for the scrum system.
There are other more academic explanations, but I prefer simple.
Will it last? I think so, because as you watch prople talking about successful projects they've implemented using Agile, they are trying to share the faith. One example is the following 3 part lecture where they explain their schedule if they had used waterfall and the No1 reasons they chose Agile was because of "Improved Time to Market".
http://www.youtube.com/watch?v=NjZzH7cYjus
Ken
I like you points about the documentation issue. I think there is nothing more valuable than well written documentation. It can saves days of frustrating investigation of undocumented systems. Well documented code does not serve the same purpose.
Regarding Agile and the term 'Unnecessary' documentation, I think it is the slippery slope. I think your example of individuals who rejoice in should loose statements indicates this.
Sorry - "in should loose" should of course read "in such loose"! (amd 24/3/10 EL)
Hi Paul,
I am soooo caught up with this - no other part of the course to date has 'hooked' me like Agile. Am only regretful that I will never get a chance to use it... will have to live vicariously thru Dave (my husband). I got him to bring home all of his Agile training materials so I could dig deeper and I even got up earlier this morning so I could start the essay/paper forthis week.
That said I have a couple of queries for the lean agilistas out there.. are there any.. heads above the parapet time!!!
The literature talks about eliminating waste as "adding no extraneous features or functions"..
How does this tie in with 'delighting the customer' or 'exceeding expectations'?? I always thought that (within reason) the idea was to strive to meet and exceed what the customer wanted thereby creating a happy customer who will return. This new way seems more a case of you got what you asked for so do one!!!
And on this subject "no formal written requirements"?? - I'm apoplectic...I think Ken referred to the lack of documentation in an earlier post and I would certainly concur with him - I'm not a big fan of documentation more of a necessary evil.. but no written requirements only use cases... surely this is limiting the customer again? An organisation would want to have one smart chicken in the meetings ( aka customer - see am really getting into the spirit of this!!)
Need to move along here or i won't get the paper started..
All the best
Trish
Hi Paul,
I haven't really done much research on Agile yet and consequently I only know what I've gleaned from the discusion forums that have mentioned it. From what you describe I can see straight away how/why it works altho it does sound a bit fad-like: chickens?/ talking pigs and scrum master. I guess the beauty of this is the really quick feedback , the pressure to perform and not let ones team mates down, the incremental testing which makes SO much sense to a non-software bod like me.. rather than take a year to create a behemoth and then discover it doesn't work test the development in stages and get each bit working as required. Its so simple its bloody brilliant!!
But will it last or is it a passing fad??
The cynic in me who has seen quality programs come and go : Zero defects, Right First Time,CQI,TQM and now 6 Sigma ( ok so the latter has hung around for a bit..) would lead me to think that Agile will most likely be replaced by a new fad in a few years time - perhaps this could be my thesis!!!??
Seriously I reckon it may well end up being relabelled and reborn within the next five years..
thats not to say it isn't good but this is the way human nature seems to work
Am off to do some real research now & will post again tomorrow
Cheers,
Trish
In their paper in 2009 on Agile Software Development, Dyba and Dingsoyr (2009) reviewed the literature on Agile Methods and conducted a systematic study about the benefits and limitations to these methods. They point out that in 2005, a survey of US and European companies found that 14% of companies were using agile methods, with almost half of those surveyed (49%) reporting an awareness of agile methods and expressing an interest in adopting them. They contend that their literature review, which they began in 2008, was the first (and at that time, the only) “review to systematically evaluate, synthesize, and present the available empirical findings”. Their paper is published in the IEEE Software Journal, which according to IEEE (2010) contains “peer reviewed articles”, so it should be a good representation of the (reasonably current) literature.
Among the findings, Dyba and Dingsoyr found that agile methods appeared to contribute to improved job satisfaction and productivity among developers, as well as increased customer satisfaction. Evidence for these improvements was strongest among mature agile teams, which seemed to indicate the importance of developer confidence in their own abilities along with good interpersonal skills. They also found that extreme programming (XP) was not particularly suited to large, complex organisations and that agile methods were difficult to introduce into large, complex projects.
I do not have any personal experience with Agile Methods, but I can see the attraction. I cannot help but draw an analogy from the maritime shipping industry. The large cargo freighters which travel across the oceans between continents are particularly well suited to that task. They are generally large ships, with many thousands of containers. However, they require deep water berths in order to dock, and in the open sea (and at cruising speed) can take 3-5 km to stop or alter course. They would not be particularly well suited to ferrying goods to some of the smaller islands off the coast of Ireland on a daily basis. That task would be better suited to smaller, more maneuverable vessels that can get into small ports. At the same time, these ferries would not do a trip to North America without some serious modifications. The point being that the tools to be used must be reasonable for the required project.
References
Dyba, T., & Dingsoyr, T. (2009). What Do We Know about Agile Software Development? Software, IEEE, 26(5), 6-9.
IEEE. (2010). Which Journal Would Be Right for My Research? Retrieved March 24, 2010, from http://www.ieee.org/web/publications/journmag/newperiodicals.html#ps
Trish-
I agree that this is one of the biggest roadblocks standing in the way of agile methodologies: the silly jargon. You have Pigs and Chickens in Scrum, "goal donors" and "gold owners" in Extreme Programming, and those are the ones I know about! I've seen two explanations for this:
1. It is an attempt to inject a bit of humour and frivolity into what is often a humourless process
2. It is a deliberate attempt to scare off the "suits", who won't "get it" anyway
Frankly, I think it's backfired. This is a pity because I think there is a lot of useful ideas in Agile.
One idea I'm particularly interested in is Pair Programming. Granted, my friends who have worked on projects where it's been tried have been pretty negative about it. However, I think it's the only way of really doing code reviews. I've lost count of the number of projects I've worked on where a code review was promised (threatened?) and where a) the review was dropped entirely because of schedule slip or b) no-one had time to study the code they were supposed to be reviewing and the thing descended into a nitpicking session over indent style and other inconsequential matters. Reading any non-trivial piece of code after it has been written is difficult because you are seeing the finished solution and you are missing the "scaffolding" of false starts and little experiments that the original programmer used to find the shape of the problem. The only way you can see this is by looking over the programmer's shoulder as they write the code -- hence, Pair Programming. I think much of the resistance to Pair Programming arises because it is a pretty "alien" way of working and most development environments have no support for it. Hopefully, this will improve... assuming the agile guys can get their act together and stop burdening their ideas with silly names guaranteed to get peoples' backs up!
- K
Agile methods provided a necessary creative input into traditional software engineering practices when it was needed but they will not last.
Our first question this week considers the agile movement in Software Engineering? We touched on this briefly last week.
What is it?
Does anyone have experience with agile approaches?
Are they effective?
What does the research tell us?
The software applications are developed through different methodologies, like waterfall mode, integration model, prototype development, agile development, extreme programming, etc. In general, developers would give the code to QA to find the bugs. QA’s first task would be to find the place where it would break. They had submit a whole bunch of bugs, which developers would fix. This cycle would repeat until they couldn’t find any more. Quality Engineers perform independent verification and validation activities inorder to assess the quality of the system. Often these teams also review design artifacts. Sometimes they are also having a hand in defining and/or enforcing the process by which the software is made. In order to avoid such problems, the agile movement came into the picture. The agile movement in software development came into the picture with the publishing of the agile software development manifesto by a group of practitioners and consultants in 2001.
Agile Manifesto Principles
v Its highest priority is to satisfy the customer through early and continuous delivery of valuable software
v Welcome changing requirements, even late in development
v Deliver working software frequently, from couple of weeks to a couple of months, with a preference to the shorter timescale.
v Business people and developers must work together daily throughout the project.
v Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
v Have face to face conversation within team
v Working software is the primary measure of progress
v Agile processes promote sustainable development
v The sponsors, developers and users should be able to maintain a constant pace indefinitely
v Continuous attention to technical excellence and good design enhances agility.
v Simplicity – the art of maximizing the amount of work not done – is essential.
v At regular intervals, the team reflects on how to become more effective and then tunes and adjusts its behavior accordingly
Different Agile Development Methodologies
Different types of Agile Development Methodologies are as follows
* Extreme programming (XP)
* Crystal
* Adaptive Software Development (ASD)
* Scrum
* Feature Driven Development (FDD)
* Dynamic Systems Development Method (DSDM)
At any rate, the most common and widely used methodologies in these days are agile/extreme programming. The application development is normally globally distributed development (GDD) and is usually executed at both on-site (customer location) and offshore (ASP’s location)
Agile software Development (ASD) is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development focuses on keeping the code simple, testing often, and delivering functional bits of the application as soon as they are ready. The goal of ASD is to build upon small client-approved parts as the project progresses, as opposed to delivering one large application as the end of the project. This is very critical in application development as the solution is tested frequently, certified and is very much customer focused.
