Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
5 Cards in this Set
- Front
- Back
|
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 |
