term1 Definition1term2 Definition2term3 Definition3
Please sign in to your Google account to access your documents:
What are the characteristics of agile processes?
1:short releases and iterations
-divide work into small pieces
-release software to customer as soon as possible
2: incremental design
-dont do a complete design up front (it will change anyways and we dont have enough info)
-delay design decisions for as long as possible
3: user involvement
-dont produce formal, immutable documents at the start
-instead, ask users for constant feedback
4:minimal documentation
-source code is considered documentation
informal communications
5: informal communications
-maintain constant comm, but informally (emails, texts)
6: change
-assume everything will change
Why is agile development necessary?
came about due to the limitations and assumptions in traditional, heavyweight models
Problems with traditional processes
many traditional models were created decades ago at a time when big companies and projects were the norm (e.g, aerospace)
development times were 75 years.
times have changed and smaller companies and projects prevail
also, today technology changes quite rapidly
traditional models cannot cope with changing requirements
traditional models have the hidden assumption that the requirements are well understood
traditional models rely on extra development effort to make up for lost time - the mythical man month
traditional models have a lot of waste or duplication of effort (E.G lots of doc is produced, but is never look at and is quickly out of date)
What is extreme programming?
-a model for small teams in the face of changing requirements
-takeaways : places a lot of emphasis on business values, relies on frequent customer communication
balances cost/demand with programming effort.
Key characteristics of XP
-short releases
-simple design: dont spend a lot of time up front on a complicated design because things are going to change
-test driven development: write the unit test before you write the code so that you can tests small units at a time and that you wont be biased when you test
-design improvement: places an emphasis on refactoring or improving design and code as you go along
-pairwise programming : to catch mistakes
-collective ownership: anyone can change anything at any time
-continuous integration: always have a working copy
-on-site customer: customer is a team member
-coding standards: consistent naming conventions
-documentless: no traditional document is producted instead the code and the test suites are considered document
Need help typing ? See our FAQ (opens in new window)
Please sign in to create this set. We'll bring you back here when you are done.
Discard Changes Sign in
Please sign in to add to folders.
Sign in
Don't have an account? Sign Up »
You have created 2 folders. Please upgrade to Cram Premium to create hundreds of folders!