- most practitioners agree with this philosophy in theory
- pragmatic issues surface in the real world that may cause items on the
right to be as important as items on the left
- can deliver successful systems quickly
- stresses continuous communication and collaboration among developers and customers
- embraces a philosophy that encourages
- customer satisfaction
- incremental software delivery
- small project teams (composed of software engineers and stakeholders)
- informal methods
- minimal software engineering work products
- guidelines stress on-time delivery of an operational software increment
over analysis and design
- effective (rapid and adaptive) response to change
- project plans must be flexible
- effective communication among all stakeholders
- encourages team structures and attitudes that improve communication
- drawing the customer onto the team
- eliminates separation between customers and developers
- organizing a team so that it is in control of the work performed
- emphasizes the importance of rapid delivery of operational software
- de-emphasizes importance of intermediate work products
- yielding …rapid, incremental
delivery of software
- the project team is allowed to streamline tasks and
- conduct planning in way that eliminates non-essential work products
- based on three key assumptions
- difficult to predict in advance which requirements or customer priorities will change and which will not
- many types of software design and construction activities are interleaved (construction is used to prove the design)
- analysis, design, and testing are not as predictable from a planning perspective as one might like them to be
- driven by customer descriptions of what is required (scenarios)
- recognize that plans are short-lived
- develop software iteratively with a heavy emphasis on construction activities
- delivers multiple ‘software increments’
- adapts as changes occur
- adapt incrementally to manage unpredictability
- incremental adaptation requires customer feedback
- based on evaluation of delivered software increments (executable prototypes)
- over short time periods
- highest priority - satisfy customer through early and continuous delivery of valuable software
- welcome changing requirements even late in development, accommodating change is viewed as increasing the customer's competitive advantage
- delivering working software frequently with a preference for shorter delivery schedules (e.g., every 2 or 3 weeks)
- business people and developers must work together daily during the project
- build projects around motivated individuals, given them the environment and support they need, trust them to get the job done
- face-to-face communication is the most effective method of conveying information within the development team
- working software is the primary measure of progress
- agile processes support sustainable development, developers and customers should be able to continue development indefinitely
- continuous attention to technical excellence and good design enhances agility
- simplicity (defined as maximizing the work not done) is essential
- the best architectures, requirements, and design emerge from self-organizing teams
- at regular intervals teams reflect on how to become more effective
and adjust behavior accordingly
- Competence
- Common focus
- Collaboration
- Decision-making ability
- Fuzzy-problem solving ability
- Mutual trust and respect
- Self-organization
- Extreme Programming (XP)
- Adaptive Software Development (ASD)
- Dynamic Systems Development Method (DSDM)
- Scrum
- Crystal
- Feature Driven Development (FDD)
- Agile Modeling (AM)
- Extreme Programming - XP
- most widely used agile process - originally proposed by Kent Beck
- relies on an object-oriented approach
- key activities
- planning
- creation of user stories
- stories ordered by customer value
- agile team assesses each story and assigns a cost
- stories are grouped to form a deliverable increment
- commitment is made on first increment delivery date
- after the first delivery project velocity is used to help define subsequent delivery dates
- design
- simple designs preferred - the KIS principle
- CRC cards and design prototypes are only work
products
- creation of spike solutions - a design prototype - for difficult design problems
- encourages use of refactoring - an iterative refinement of the internal program design
- coding
- focuses on unit tests to exercise stories
- emphasizes use of pair programming to create story code
- continuous integration and smoke testing is utilized
- testing
- unit tests created before coding
- implemented using an automated testing framework
- encourage use of regression testing
- integration and validation testing done on daily basis
- acceptance tests focus on system features and functions viewable by the customer
- planning
- Adaptive Software Development - ASD
- philosophy - cooperate to create a solution to a problem that is beyond the capability of any individual agent
- emphasizes
- self-organizing teams
- interpersonal collaboration
- individual and team learning
- phases
- speculation
- project initiated
- adaptive cycle planning takes place
- collaboration
- requires teamwork from a jelled team
- joint application development is preferred
- requirements gathering approach
- minispecs created
- learning
- components implemented and tested
- focus groups provide feedback
- formal technical reviews
- postmortems
- speculation
- Dynamic Systems Development Method - DSDM (www.dsdm.org)
- similar in most respects to XP and/or ASD
- nine guiding principles
- active user involvement is imperative
- DSDM teams must be empowered to make decisions
- focus is on frequent delivery of products.
- fitness for business purpose is the essential criterion for acceptance of deliverables
- iterative and incremental development is necessary to converge on an accurate business solution
- all changes during development are reversible
- requirements are baselined at a high level
- testing is integrated throughout the life-cycle
- Scrum
- Development work is partitioned into “packets”
- Testing and documentation are on-going as the product is constructed
- Work occurs in “sprints” and is derived from a “backlog” of existing requirements
- Meetings are very short and sometimes conducted without chairs
- “demos” are delivered to the customer with the time-box
allocated
- Crystal
- a family of process models that allow “maneuverability” based on problem characteristics
- face-to-face communication is emphasized
- use of “reflection workshops” to review the work habits
of the team
- Feature Driven Development - FDD
- emphasis is on defining “features”
- a feature “is a client-valued function that can be implemented in two weeks or less.”
- uses a feature template
example - add the product to a shopping cart - a features list is created and “plan by feature” is conducted
- design and construction merge in FDD
- practice-based methodology for effective modeling and documentation of software systems in a light-weight manner
- agile modeling principles
- model with a purpose
- use multiple models
- travel light (only keep models with long-term value)
- content is more important than representation
- know the models and tools you use to create them
- adapt locally