SWE TEST 2 Chapter 5 A
LIMITATIONS OF TRADITIONAL PROCESS METHODOLOGIES
1.Lengthy development times
2.Inability to cope with changing requirements
3.Complex methodology
4.Waste/duplication of effort
5.Too much reliance on heroic developer effort
AGILE SOFTWARE DEVELOPMENT
The Agile software development methodology is one of the simplest and effective processes to turn a vision for a
business need into software solutions
▪ involves working in iterations.
▪ works off the basis that a project can be continuously improved upon throughout its life cycle, with changes
being made quickly and responsively.
▪ is the most popular approaches to project management due to its flexibility, adaptability to change, and high
level of customer input.
▪ involves constant collaboration with stakeholders and continuous improvement at every stage.
▪ incorporates continuous testing and responsiveness to change
Characteristics and methods that depict Agile methods
✓ Short releases:
Divide the work into small pieces. Release the software to the customer as often as possible.
✓ Incremental design:
Don’t try to complete the design up front because not enough is known early about the system anyway. Delay
design decisions as much as possible and improve the existing design when more knowledge is acquired.
✓ User involvement:
Rather than trying to produce formal, complete, immutable standards at the beginning, ask the users involved with
the project to provide constant feedback. This usually leads to a better-suited system.
Characteristics and methods that depict Agile methods
✓ Minimal documentation:
Do only the necessary amount of documentation, which is just a means to an end. The source code is a big
part of the actual documentation.
✓ Informal communication:
Maintain constant communication but not necessarily through formal documents. People communicate better
informally. This approach works as long as understanding is achieved.
✓ Change:
Assume that the requirements and environment will change and try to find good ways to deal with this fact.
Benefits of Agile project management
Satisfied customers
Improved quality
Adaptability
Predictability
Reduced risk
Better communication
Agile methodologies frameworks
1. Extreme Programming (XP),
2. The Crystal family
3. Unified Process as Agile
4. Open-Source software Development
5. Scrum
6. Kanban
Extreme Programming (XP)
is a software development methodology that’s part of Agile methodologies.
The main focus of extreme programming is
customer satisfaction, and their development teams achieve it by
organizing itself.
XP is built upon
1. Core Values
2. Fundamental principles
3. Key practices
Values of XP:
1. Frequent Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect:
XP Principles
1. Rapid feedback
2. Assume simplicity
3. Incremental change
4. Embracing change
5. Quality work
Extreme Programming (XP) PRACTICES
1.The Planning game (user stories)
2.Short releases
3.Metaphor
4.Simple design
5.Test-driven development
6.Design Improvement (Refactoring)
7.Pair programming
8.Collective ownership
9.Continuous Integration
10.Sustainable pace
11.On-site customer
12.Coding standards
AGILE METHODOLOGIES FRAMEWORKS
Extreme Programming (XP)
Core Practices
1. Planning
2. Short releases (Frequent releases)
3. Metaphor (Easy to understand)
4. Simple design (Avoid Complexities)
5. Test-driven development (Test as much as possible)
6. Design improvement (refactoring - cleaning up your code)
7. Pair programming (two developers sit together and work on the same code)
8. Collective ownership
9. Continuous integration:(Immediately test code changes when they are added into the larger
codebase)
10. Sustainable pace (40-hour week)
11. On-site customer (A customer sits with the team full-time)
12. Coding standards (the whole team should understand the code)
Extreme Programming (XP)
The Planning Game
The players include
development personnel and customers, and the artifacts are story cards and task cards.
Businesspeople and customers decide on the following:
Scope, Priorities, Release scope and Release dates
The technical staff must make decisions on the following:
Estimates:, Consequences and Process.
Two major artifacts in XP are
User Story Cards and Task Cards
User Story Cards
t is a document that describes the user’s requirement.
• Customer designs or writes a user card.
• It describes the system from the customer’s point of view.
• A user card is simple and not much technical language.
• A user card should be detailed enough so that the developer can estimate how long it will take for a
particular story to get designed, tested, and implemented.
• One feature description requires one user card in the system. In other words, one user card for each
requirement.
• The estimates for the feature delivery are done using the user story cards.
Task Cards
A Task Card is created by the Development team to implement the task in an organized manner. It will have the
following task details against a particular user story-
• The list of tasks required for the implementation of a User Story is called a Task Card.
• Moreover, only one task card gets designed and issued against one user story.
• In addition to that, the Task cards work as the base for task assignments and providing an estimate to complete
a task.
How to play the planning game?
Step 1: Creation or selection of the story
Step 2: Story estimation
Step 3: Prioritization of stories
Step 4: The process is repeated
he XP game in agile is divided into two parts:
elease planning and iteration planning
Release Planning (What should be released?)
1. In Exploration phase,
• The customer collects user stories and writes them on the user story cards.
• The developer estimates the required man-hours for each user story and writes the estimated value on the story card.
• If a user story cannot be estimated, it will be re-decomposed by the customer and then estimated by the developer.
2. In Commitment phase,
• Customers prioritize user stories based on business value, and the developers prioritize user stories based on risk, and
confirm the development velocity.
• Finally, the customer chooses the user story to be completed for the next release.
3. In Guidance/Steering phase,
• Developers and customers can adjust and modify the plan. For example, the priority of user stories can be changed,
and the deviations of estimates exist. This is an opportunity to adjust the plan accordingly.
Iteration Planning (Start working on requirements)
The iteration planning is further planning of the release planning, which is done right at the beginning of each
iteration.
1. In Exploration phase,
• The team discusses each user story and breaks it down into tasks, and then estimates the working hours
for the tasks.
2. In Commitment phase,
• Each developer voluntarily claim tasks and makes a final estimate of the tasks he is responsible for, and the
team should evaluate whether they are overloaded. One or more developer is responsible for one task.
3. In Guidance/Steering phase,
• In each subsequent iteration, developers implement each task, record the status and readjusting to the
plan.