Chapter 5: Agile Development

Agile vs. Opensource

-- Agile is small -- Open source is huge, distributed teams, and larger scale projects -- Both are collaborative, shared vision, continued integration

Common characteristics of Agile processes (7)

1 ) Short releases and iterations -- Divide the work into small pieces -- Release software to customer as often as possible 2 ) Incremental Design -- Don't do a complete design up front (it's going to change anyway and you don't have enough info) -- Delay design decisions as long as possible 3 ) User Involvement -- Don't produce formal, immutable docs at the start -- Instead, ask the users for constant feedback 4 ) Minimal Documentation -- Source code is considered documentation 5 ) Informal communications -- Maintain constant communication, but do it informally 6 ) Change -- Assume everything will change

Problems with traditional processes

-- Many traditional models were created decades ago at a time when big projects and companies were the norm (e.g., aerospace) -- Times have changed, and smaller companies and projects prevail -- Today, technology changes quite rapidly, and 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 -- Traditional models have a lot of waste or duplication of effort (e.g., lots of doc is produced, but never looked at and is quickly out of date)

Key Characteristics of XP (Know for FINAL)

-- Short releases → every 2-4 weeks -- Simple design → don't spend a lot of time up front on a complicated design because things are going to change in unanticipated ways -- Test-Driven Development → write unit tests before writing the code (unbiased test cases) -- Design Improvement → Places an emphasis on refactoring (restructuring) or improving design and code as you go along -- Pairwise Programming → Two programs on one keyboard. Why? 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, etc. -- Documentless → No traditional documentation is produced. Instead, the code ant the test suites are considered documentation

Extreme Programming (XP)

-- example agile process -- DEF: A model for small teams facing the pressure of changing requirements -- Places a lot of emphasis on business value -- To achieve this, it relies on frequent customer communication -- Balances cost demand with program effort

Analysis of XP

-- Pairwise programming → are we wasting personnel or gaining quality? -- Customer Communication → are we wasting everyone's time or gaining quality? -- Documentless → saving time or lost without a road map?

Agile processes

A family of software development methodologies

Why is agile development necessary?

Agile development lame about due to the limitations and assumptions in traditional, heavyweight models (this was from notes? need new definition)