KARABUK UNIVERSITY
Computer Engineering Department
CPE 310 Software Engineering
Lab#5
Agile Frameworks - XP and Kanban
Hasan Kivrak
Agenda Major Agile Methodologies
a family of iterative, incremental methods
● We will learn about two Agile Software
practises:
○ XP – Extreme Programming (1996)
○ Kanban (2010) DSDM
Scrum XP FDD
Crystal
Kanban
Extreme Programming
● Extreme Programming (XP) takes an ‘extreme’ approach to iterative
development.
○ Uses an object-oriented approach
○ Includes a set of rules and practises:
■ planning
■ design
■ coding
■ testing
XP Phases/Process
Planning (Planning Game) Design
● Begins with the listening and ● Follows the KIS (keep it
creation of “user stories” simple) principle
● Agile team assesses each story ● Encourage the use of CRC
and assigns a cost (measured in (class-responsibility-collab
development weeks.) orator) cards for OOP.
● Stories are grouped to for a next ● For difficult design problems,
release (next software increment) suggests the creation of
“spike solutions”—a design
● A commitment(agreement) is prototype implement and
evaluate
made on delivery date
● Encourages “refactoring”—an
● After the first increment(project
iterative refinement of the
release), “project velocity” is internal program design
computed.
○ #user stories Coding
implemented
● Recommends the
○ used to help define following construction of a unit test
delivery dates for other Testing
for a store before coding
increments(releases) ● All unit tests are executed daily (fixing small errors take less ○ Knowing the exam question
time fixing huge errors) before you begin to study
● Encourages “pair
● “Acceptance tests” are defined by the customer and
programming”(two heads are
executed to assess customer visible functionality better than one)
Refactoring
● Refactoring is the process of changing the design of your code without changing its
behavior—what it does stays the same, but how it does it changes.
● You can think of it like improving a function-method-class without changing its interface.
● However, some changes requires architecture refactoring and this is much more expensive.
● Examples of refactoring:
○ Re-organization of a class hierarchy to remove duplicate code.
○ Tidying up and renaming attributes and methods to make them easier to understand.
○ The replacement of inline code with calls to methods that have been included in a
program library.
Pair Programming Environment
Advantages of Pair Programming
● It supports the idea of collective ownership and responsibility for the system.
○ Individuals are not held responsible for problems with the code. Instead,
the team has collective responsibility for resolving these problems.
● It acts as an informal review process because each line of code is looked at by
at least two people.
● It helps support refactoring, which is a process of software improvement.
○ Where pair programming and collective ownership are used, others
benefit immediately from the refactoring so they are likely to support the
process.
Test Driven Development
● Test-driven development (TDD) is a software development technique that uses
really short development cycles to incrementally design your software.
○ Red: Before you write any new code for the system, you first write a failing
unit test, showing the intent of what you would like the new code to do.
Here you are thinking critically about the design.
○ Green: Then you do whatever it takes to make the test pass. If you see the
full implementation, add the new code. If you don’t, do just enough to get
the test to pass.
○ Refactor: Then you go back and clean up any code while trying to get the
test to pass.
Collective Ownership
● Collective code ownership spreads responsibility for maintaining the code to
all the programmers. Collective code ownership is exactly what it sounds like:
everyone shares responsibility for the quality of the code.
● No single person claims ownership over any part of the system, and anyone
can make any necessary changes anywhere.
● Collective code ownership requires letting go of a little bit of ego. Rather than
taking pride in your code, take pride in your team’s code.
Always leave the code a little better than you found it.
Collective Ownership
● How can you take ownership of code that you don’t understand?
○ take advantage of pair programming
○ Rely on the unit tests for further documentation and as your safety net
○ As you work, look for opportunities to refactor the code.
● Collective code ownership shares knowledge and improves skills, but it won’t make everyone
an expert at everything. Take advantage of all skills and specialties.
● Rather than turning your junior programmers loose on the code, make sure they pair with
experienced members of the team.
● Collective ownership increases the possibility of merge conflicts, and so it also requires
continuous integration. Continuous integration decreases the chances of merge conflicts.
Continous Integration
● The ultimate goal of continuous integration is to be able to deploy all but the last few
hours of work at any time.
● Most software development efforts have a hidden delay between when the team says
“we’re done” and when the software is actually ready to ship.
● The point is to be technologically ready to release even if you’re not functionally ready to
release.
○ Integrate your code every few hours.
○ Keep your build, tests, and other release infrastructure up-to-date.
● To guarantee an always-working build
○ make sure what works on your computer will work on anybody’s computer.
○ nobody gets code that hasn’t been proven to build successfully.
XP Principles
● Incremental development is supported through small, frequent
system releases.
● Customer involvement means full-time customer engagement with
the team.
● People not process through pair programming, collective ownership
and a process that avoids long working hours.
● Change supported through regular system releases.
● Maintaining simplicity through constant refactoring of code.
XP loops
Xp Values Xp Practices
1. The Planning Game
2. Small Releases
1. Simplicity 3. Metaphor
2. Feedback 4. Simple Design
5. Testing
3. Courage 6. Refactoring
4. Pespect 7. Pair Programming
8. Collective Ownership
9. Continuous Integration
10. 40-hour week
11. On-site Customer
12. Coding Standard
Kanban
Kanban
Backlog Goal: Build a Job Website
Analyze
Develop
Post a new job
Update Test
resume Login
Update Release
Signup
job
Property#1: Visualize your workflow
Submit a Make
resume payment
Create
Upload
profile
pic
Backlog Analyze Develop Test Release
Doing Done Doing Done
Post a new job
Update Login
resume
Update Signup
job
Property#1: Visualize your workflow
Submit a Make
resume payment
Create
Upload
profile
pic
Backlog Analyze Develop Test Release
Doing Done Doing Done
Post a new job
Update Login
resume
Update Signup
job
Property#1: Visualize your workflow
Submit a Make
resume payment
Create
Upload
profile
pic
After few days..
2 3 2
Backlog Analyze Develop Test Release
Doing Done Doing Done
Upload Update Update Submit a Create Post a new job
pic resume job resume profile
Signup
Make
payment
Login
Property#1: Visualize your workflow
Property#2: Limit WIP (Work in progress)
2 3 2
Backlog Analyze Develop Test Release
Doing Done Doing Done
Upload Update Submit a Make Create Post a new job
pic resume resume payment profile
Update
Login Signup
job
Property#1: Visualize your workflow
Property#2: Limit WIP (Work in progress)
2 3 2
Backlog Analyze Develop Test Release
Doing Done Doing Done
Upload Update Submit a Make Create Post a new job
pic resume resume payment profile
Update
Login Signup
job
Property#1: Visualize your workflow
Property#2: Limit WIP (Work in progress)
2 3 2
Backlog Analyze Develop Test Release
Doing Done Doing Done
Upload Update Submit a Make Create Post a new job
pic resume resume payment profile
Update
Login Signup
job
Property#1: Visualize your workflow
Property#2: Limit WIP (Work in progress)
2 3 2
Backlog Analyze Develop Test Release
Doing Done Doing Done
Upload Update Submit a Make Create Post a new job
pic resume resume payment profile
Update
Login Signup
job
Property#1: Visualize your workflow
Property#2: Limit WIP (Work in progress)
2 3 2
Backlog Analyze Develop Test Release
Doing Done Doing Done
Upload Update Submit a Make Create Post a new job
pic resume resume payment profile
Update
Login Signup
job
FLOW
Property#1: Visualize your workflow
Property#2: Limit WIP (Work in progress)
Property#3: Manage the flow
Property#4: Make Process Policies Explicit
Kanban Principles Kanban Properties
1. Start with what you do know 1. Visualize the workflow
2. Agree to pursue incremental, 2. Limit WIP (work in progress)
evolutionary change
3. Manage flow
3. Respect the current process,
4. Make process policies explicit
roles, responsibilities & titles
5. Improve Collaboratively
Kanban in a Nutshell
● Visualize the workflow
● Limit Work In Progress (WIP) – assign explicit limits to how many items
may be in progress at each workflow state.
● Measure the lead time (average time to complete one item, sometimes
called “cycle time”), optimize the process to make lead time as small and
predictable as possible.
Scrum vs Kanban
● Scrum is more prescriptive
● Kanban doesn’t prescribe any roles at all.
● In Kanban timeboxed iterations are not prescribed. You can go using
○ Single Scrum iterations
○ Multiple periodic cadances
○ Multiple Event-driven cadances. E.g. We trigger a release whenever there is a set of
Minimum Marketable Features (MMFs) ready for release
Scrum vs Kanban
● Kanban limits WIP per workflow state, Scrum limits WIP per
iteration.
● Scrum board is reset between each sprint
● Scrum prescribes cross-functional teams, Kanban boards are cross-team
● Scrum backlog items must fit in a sprint
One day in Kanban
Book on Scrum and XP
Scrum XP
● Scrum and XP from the Trenches - 2nd Edition
● By Henrik Kniberg
