Utilisateur
Alistair Cockburn
• Teams can optimize workflow - Team members can and should work together to develop the optimal
workflow process for each project.
• All projects are unique - Every project is different from others and requires some specific methods and
strategies. Since all projects are unique and constantly changing, the tools and processes needed vary
project by project. It should therefore be up to a project’s team to determine which methodologies to use
make a strategy to win the game.
1. People involved
2. Interaction between the teams
3. Community
4. Skills of people involved
5. Their Talents
6. Communication between all the teams
1. Frequent delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to an Expert User
7. Good Technical environment & frequent integration
1. Criticality
2. Team size
3. Priority
which are malfunctions that can cause physical harm to a person, or possibly loss of life
which are malfunctions that may cause loss of money essential for the organization’s
survival
which are malfunctions that may cause loss of money but are not essential for the
organization’s survival
which are malfunctions that do not cause measurable monetary loss and yet still decrease comfort and pleasure to the users.
Gauged by the losses that a malfunction would cause and the level of potential damage the system can cause if it
does not perform as designed. How imperative are the results of the project? Is it life or death?
• Determined by the number of team members working in the project
• that project size is not measured in lines-of-code or function points but by the number of developers
Measured by the time pressure on the project.
Where does the project rank? Is it a higher priority than other work?
n iterative and
incremental processes
self-organize and work towards a common goal
It is inspired by a scrum in the sport of rugby.
In rugby, the team comes together in what they call a scrum to work together to move the ball forward
Product Owner
Scrum master
Scrum Team
The product owner represents the customer’s best interest. The Product Owner focuses on ensuring the
development team delivers the most value to the business. They understand and prioritize the changing needs of
end users and customers.
This person is a facilitator, responsible for arranging the daily meetings, improving team interactions, and
maximizing productivity. The Scrum Master oversees keeping Scrum up to date, providing coaching,
mentoring and training to the teams in case it needs it.
They are a group of professionals with the necessary technical knowledge who develop the project.
maximize transparency of key information so that everybody has the same understanding of the artifact.
1. Product Backlog
2. Sprint Backlog
3. Burn-Down Chart
4. Increment
An ordered list of all the remaining requirements or user stories for a product. The product owner prioritizes and orders the
requirements. Everybody can see what still needs to be done overal
It is the list of tasks that need to be done for the current sprint. Tasks here are broken down, so developers know exactly what
to do. Rather than tasks being assigned, developers choose their next task based on the sprint backlog and their skills.
A frequently updated publicly displayed chart showing the remaining log in the current sprint backlog. This is the project
status chart that is used in the daily scrum meeting. The burn down chart starts with all the work that is yet to be accomplished
and highlights how much work is remaining
The sum of all requirements implemented in this sprint and all previous sprints.
in a project, every scrum event has a predefined
maximum duration. These events enable transparency on the project progress to all who are involved in the
project.
❑ Sprint Planning
❑ Daily Scrum Meetings
❑ The Sprint Review
❑ The Sprint Retrospective
A sprint (also called an iteration) is the basic unit of development in Scrum. The sprint is a time-
boxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is
normally between one week and one month, with two weeks being the most common. A new Sprint starts
immediately after the conclusion of the previous Sprint
The work to be performed in the Sprint is planned in the Sprint Planning Meeting. During sprint planning, the
product owner and the team decide on what will be implemented during that sprint.
The development team meets for 15 minutes (or less) every day of the sprint to inspect progress toward the
sprint goal. They describe for each other how their own work is going, ask for help when needed, and consider
whether they are still on track to meet the sprint goal. This is a short meeting in which team members synchronize,
make sure they are on-track, and ask for help if needed. 25
The Sprint Review takes place after a Sprint ends. The Sprint Team meets with stakeholders to show what they
have accomplished and get feedback. During Review, the Product Owner explains what planned work either was
or was not completed during the Sprint. The team then presents completed work and talks through what went
well and how problems were solved
The final event in the Sprint is the Sprint Retrospective. This is when the Scrum Team reviews what could be
improved for future Sprints and how they should do it The Sprint Retrospective is held after the sprint review at the
end of each sprint. It offers the team an opportunity to inspect itself and create a plan for improvements to
be enacted during the next Sprint.
26
visual system
with “Kan” meaning signal and “ban” card in Japanese.
1. Visualize the Workflow
2. Limit Work in Progress (WIP)
3. Manage Flow
4. Make Process Policies Explicit
5. Implement feedback loops
6. Improve Collaboratively (Using Models & the Scientific Method)
use, modify and share the open-source software. During the open-source software
development, the programmer can add or fix a part of the software in order to make the software work properly.
1.Small releases
2.Informal, written
communication using Internet
tools
3.Customer availability
4.Continuous integration
5.Shared vision
Open Source
Larger teams
Communication is often Asynchronous
Large scale Projects
VS
Agile
Smaller teams
Communication is Synchronous
Small scale Projects
practice that allows a single team to manage the entire
application development life cycle: development, testing, deployment, and monitoring.
✓ Cultural: open mindedness and integration of information with mutual trust among all stake holder groups, including the
users.
✓ Automation: implementing and using high level of tools and automation, especially for CI/CD and testing.
✓ Lean: much like Kanban, minimize the WIP and applying lean principles to improve efficiency and speed across all aspects
of the product life cycle.
✓ Measurement: monitoring the overall system with key metrics for development, test, delivery, support, quality, user opinion,
value, etc.
✓ Sharing: free flow of information and knowledge along with sharing of responsibilities across all groups of development,
delivery, and operations.
✓ Frequent Delivery
✓ Face-to-Face Communication with clients.
✓ Efficient design and fulfils the business requirement.
✓ Anytime changes are acceptable.
✓ Fast results and usable systems
✓ Low cost and low complexity
o Not scalable:
Agile processes have been used by relatively small teams. Many projects are too big or too critical to be developed with Agile
methods.
o Heavy reliance on teamwork:
Not all people are able to work well in teams. Often, one bad member can destroy the cohesiveness of the entire team.
o Reliance on frequent access to customer:
Agile methods need frequent feedback from the customer. Not all customers are willing or able to provide this level of
cooperation and feedback. Without customer feedback, Agile methods are not able to validate requirements or adapt to change.
o Cultural clash:
Many XP practices clash with accepted software engineering wisdom, or with common management techniques. Performance
evaluations, for example, are harder to perform in XP because the work is done in pairs, and the code is owned by the whole
team.
