1
Hans-‐Pe(er Halvorsen, M.Sc.
Agile So6ware Development
S. Adams. Dilbert. Available: h(p://dilbert.com
I’ll go up and find out what they need and the rest of you start coding!
Agile?
4
Typical Job Ad
The Development Process
5Design
ImplementaKon
TesKng
Requirements
Deployment
In this case the overall Requirements are given by the Teacher in the
Assignment.
The details are wri(en by you!
The Development Process involves different phases, e.g.: The Requirements may be
given by the Customer
When you are finished, you deploy and test the soluKon on the Customer Site
Make sure everything work as expected
The Design phase is important, but make sure you have Kme le6 for all the other tasks as well)
Are the Design wrong? Go back and correct it!
Errors? Improve your code and fix the bugs
Agile methods
•
Scrum
•
XP (eXtreme Programming)
•
Lean So6ware Development
•
Feature Driven Development (FDD)
•
Test Driven Development (TDD)
•
etc.
So6ware Development Methods
7
TradiKonal Plan-‐driven Methods Agile Methods
Waterfall Method V-‐Model Scrum eXtreme Programming (XP) Lean So6ware Development Feature Driven Development (FDD)
Even if we use different so6ware development methods, we deal with the same phases like Requirements, Design, Coding, TesKng and Deployment – but they may have different
priority and may be done in different manners and order, etc.
Teams and Roles
•
Customer/Stakeholders
•
Project Manager
•
So6ware Architect
•
UX Designer
•
Developer
•
Tester
•
etc.
8UX Designer Programmer
So6ware Tester
Project Manager So6ware Architect
Collabora:on!
Plan-‐driven vs. Agile
9 Requirements specification Requirements engineering Design and implementation Requirements change requests Plan-based development Agile development Requirementsengineering implementationDesign and
Agile vs. TradiKonal Development
10
Agile vs. TradiKonal
11
12
Agile So6ware Development
O. W idde r. (2013). ge ek &pok e. A vai lab le : h( p: // ge ek -‐an d-‐ po ke .c om
Manifesto for Agile So6ware Development
We are uncovering be(er ways of developing so6ware by doing it and helping others do it. Through this work we have come to value: • Individuals and interacKons over processes
and tools
• Working so6ware over comprehensive
documentaKon
• Customer collaboraKon over contract
negoKaKon
• Responding to change over following a plan That is, while there is value in the items on
the right, we value the items on the le6 more.
13
Agile Alliance. (2013). Agile Manifesto. Available:
h(p://agilemanifesto.org O. W idde r. (2013). ge ek &pok e. A vai lab le : h( p: // ge ek -‐an d-‐ po ke .c om
14
15
O. Widder. (2013). geek&poke. Available: h(p://geek-‐and-‐poke.com
Agile Development
Agile
16
•
A group of so6ware development methods
•
IteraKve approach
•
Incremental: So6ware available to Customers
every 2-‐4 weeks
•
Self-‐organizing and cross-‐funcKonal Teams
•
Refactoring
Examples:
•
Scrum
17 O. W idde r. (2013). ge ek &pok e. A vai lab le : h( p: // ge ek -‐an d-‐ po ke .c om
Burn Down Chart
• A burn down chart is a graphical representaKon of work le6 to do versus Kme. • The outstanding work (or backlog) is o6en on the verKcal axis, with Kme along the
horizontal. That is, it is a run chart of outstanding work.
• It is useful for predicKng when all of the work will be completed.
• It is o6en used in agile so6ware development methodologies such as Scrum. • However, burn down charts can be applied to any project containing measurable
progress over Kme.
Code Review &
Refactoring
19
20
Hans-‐Pe(er Halvorsen, M.Sc.
eXtreme
Programming
O. Widder. (2013). geek&poke. Available: h(p://geek-‐and-‐poke.com
eXreme Programming (XP)
eXtreme Programming (XP)
eXreme Programming (XP)
•
An Agile method
•
Pair Programming
•
Code Reviews
•
Refactoring
•
Unit TesKng
•
Standup MeeKngs
23Exercise – Pair Programming
•
Work together 2 and 2
and test out Pair
Programming
•
Pros and Cons? – Make a
list
25
Pair Programming
Is Pair Programming Good or Bad?
• Various Studies of the ProducKvity of Pair Programming
• Study 1: Comparable with that of 2 developers work independtly
• Study 2: A significant loss in producKvity compared with 2 developers wprking alone
Should the 2 developers have the same skills or not? Newerless, there are benefits:
• CollecKve Ownership
• ConKnuous informal Review process because each codeline is looked at by at least 2 people
• It supports Refactoring, which is a proces of so6ware improvement
• Less Kme is spent on repairing bugs. • Improved Code Quality
• It reduced the overall risks
I. Sommerville, So*ware Engineering: Pearson, 2010.
O. W idde r. (2013). ge ek &pok e. A vai lab le : h( p: // ge ek -‐an d-‐ po ke .c om
Refactoring
29
Hans-‐Pe(er Halvorsen, M.Sc.
Stakeholders Product Owner Scrum Master Product Backlog Development Team 3-‐9 persons Sprint Backlog Sprint
Daily Scrum MeeKngs Sprint
Review
Scrum
31
Daily Scrum MeeKngs
Scrum
•
A Framework for So6ware Development
•
Agile So6ware Development method
•
Simple to understand
•
Flexible
•
Exremely difficult to master!
•
Self-‐organizing Teams (3-‐9 persons)
•
Scrum Team:
–
Product Owner
–
Scrum Master
–
Development Team
33
Hans-‐Pe(er Halvorsen, M.Sc.
Lean
So6ware
Lean So6ware Development
•
Based on the Toyota ProducKon System and
Lean manufacuring
Summary
35
•
You should “always” Refactor
your Code – even if you don’t do
Agile!
•
Pair Programming could be
useful in some situaKons
•
Scrum is probably the most
popular Agile method
•
Agile means less documentaKon
•
Agile is more flexible than
tradiKonal methods (like the
waterfall)
References
• I. Sommerville, So*ware Engineering: Pearson, 2010.
• E. J. Braude and M. E.Bernstein, So*ware Engineering. Modern Approaches, 2 ed.: Wiley, 2011.
• Wikipedia. (2013). Scrum Development. Available:
h(p://en.wikipedia.org/wiki/Scrum_(development)
• Wikipedia. (2013). Agile So*ware Development. Available:
h(p://en.wikipedia.org/wiki/Agile_so6ware_development
• CoreTrek. (2013). Scrum i et nø@eskall. Available:
h(p://www.coretrek.no/scrum-‐i-‐et-‐noe(eskall/category642.html
• S. Adams. Dilbert. Available: h(p://dilbert.com
• O. Widder. (2013). geek&poke. Available: h(p://geek-‐and-‐poke.com
• Agile Alliance. (2013). Agile Manifesto. Available: h(p://agilemanifesto.org
• EssenKals of So6ware Engineering, Frank Tsui; Orlando Karam; Barbara Bernal, 3 ed., Jones & Bartle( Learning.
Hans-‐PeMer Halvorsen, M.Sc.
Telemark University College
Faculty of Technology
Department of Electrical Engineering, Informa:on Technology and Cyberne:cs
