Download - Agile Project Management - Aalto University · Agile Project Management ... RAD Crystal family ... The Rational Unified Process: An Introduction, Second Edition, Addison-Wesley, 2000.

Agile Project Management

Jari VanhanenHelsinki University of Technology

SoberITSEMS Project

http://www.soberit.hut.fi/sems/

http://www.soberit.hut.fi/sems/

28.4.2003 Jari Vanhanen

Presentation Outline

Agile processes overvieweXtreme Programming (XP)Exercise - XP Planning Game


Agile Processes

Iterative and incremental in naturePackage existing software engineering practices

Nothing new, except the underlying philosophy and perhaps the combination of practices

Embrace change rather than control it

Suitable for extremely turbulent environments

Focus on delivering business value

Customer/User involvement paramount

Can’t be used in all projects!

Some starting points for the interested:

http://www.agilealliance.org/http://www.martinfowler.com/articles/newMethodology.html


Some Published Agile Processes

eXtreme Programming (XP)ScrumDSDMFeature Driven Development (FDD)Lean DevelopmentAdaptive Software Development (ASD)RADCrystal family(MS Synch-and-Stabilize)


Agile Software Development Manifesto

Signed by authors of ASD, XP, Scrum, Crystal, FDD, DSDM, and ”pragmatic programming” + some othersAgree at the first level

need to respond to change

Agree at the second levelindividuals and interactions over processes and toolsworking software over comprehensive documentationcustomer collaboration over contract negotiationresponding to change over following a plan

Agree at the third level12 more detailed statements

Don’t agree at the fourth leveldetailed project tactics


Principles of the Agile Alliance

Satisfy the customer through early and continuous delivery of valuable softwareAgile processes harness change for the customer’s competitive advantageDeliver working software frequentlyWorking software is the primary measure of progressAgile processes promote sustainable development at a constant paceBusiness people and developers must work together dailyBuild projects around motivated individuals, give them support and trust them to get the job done

The most efficient and effective way of conveying information is face-to-face conversationAttention to technical excellence and good design enhances agilitySimplicity--the art of maximizing the amount of work NOT done--is essentialThe best architectures, requirements, and designs emerge from self-organizing teamsAt regular intervals the team tunes and adjusts its behavior to become more effective


Individuals

Programmers and communication

a stereotype of a programmer is noncommunicativeprogramming has been work of individualsagile methodologies emphasize communication

programmers like communi-cating about technical thingshigh acceptance of pair programming

Diversity presents communication difficulty and personal friction but also allows for efficiency

mixed teams often outperform homogeneous teams

People factors predict project trajectories quite well, overriding choice of process or technology

a well-functioning team of adequate people succeeds almost regardless of the used process or technologycollaboration and communication between people

Hard to design a system composed of humans

humans are contradictory, depending on work, time, other people, etc.people differ in their ways to solve problems


Light but Sufficient Methodology

Primary goal is to deliver softwareSecondary goal is to set up for the next

TeamProduct version…

Questions:How to allocate resources to each goal?How much of the knowledge to document?

Recommendations for documentation

Just enough required to communicate with the readersReplace typing with faster communications media

visits in personvideo clips

Remember, there will be new persons requiring more documentationRun documentation as a parallel, resource competing thread of the project


Sweet Spots of Software Development

2-8 people in one roominformation moves fastest

Onsite usage expertminimized feedback time of the solution

One-month (max) incrementsfeedback of the product and the process

Fully automated regression testsconfidence to changing and improving the system


SCRUM

eXtreme Programming


From Waterfall to XP

Time

Analysis

Design

Implementation

Test

Waterfall Iterative XP

Reference: Beck Kent, “Embracing Change with Extreme Programming”, IEEE Computer, Vol. 32, No. 10, 1999, pp. 70-77.


XP Values (1/2)

Communicationlack of it is the reason for most problemspunishment from bad news kills itXP employs practices that keep programmers, customers and managers communicating

SimplicityWhat is the simplest thing that could possibly work?general vs. simple design

anticipatory design assumes more work today saves laterYAGNI low rate of changes

• anticipatory designhigh rate of changes

• refactoring and continuous design

a simple solution is easier to understand


XP Values (2/2)

Feedbackconcrete feedback about the state of the systemscale of minutes or days

unit tests, quality of stories (requirements), progress of tasks

scale of weeks or monthsacceptance tests, schedule, system in production

Couragechanging the systemthrowing code awaypair programming


XP Principles

Fundamental principlesrapid feedback

critical for learningassume simplicity

treat every problem as if it can be solved with simplicity

incremental changeseries of smallest changes that make a difference

embracing changebest strategy preserves most options while actually solving your most pressing problem

quality workexcellent qualitynobody likes doing a bad job

Secondary principlesteach learningsmall initial investmentplay to winconcrete experimentsopen, honest communicationwork with people’s instincts, not against themaccepted responsibilitylocal adaptation travel lighthonest measurement


XP Practices

Practicesplanning gamesmall releasestestingcontinuous integration metaphorsimple designrefactoringpair programmingcollective ownershipcoding standard on-site customer40-hour week

Simple, well-known practicespractices support each other’s weaknesses


Development Phasing in XP

Release 1 …Release 2 Release NIteration 1 Iteration 2 Iteration N… Iteration 1 Iteration 2 Iteration N… Iteration 1 Iteration 2 Iteration N…

Time, resources and quality are fixed in the beginning of a release/iterationControlling by tuning the scope

Releasesdelivers something valuable to the customerlength 2-6 months, ”as short as possible”plan 1-2 releases at a time

Iterationslength 1-4 weeksstart with the architecture skeleton, then the functionality having the highest business value

manages risksproduce functionality that passes acceptance tests


XP Planning Game – Release Planning

Customer decidesscopepriorityrelease dates

Developers are responsible ofeffort estimatestechnical consequencesdevelopment processdetailed scheduling within iterations


Planning Game – Release Planning Steps (1/3)

Customer writes user stories”chunk of functionality that is of value to the customer”customer explains and developers ask questionsdocumented by one sentence

details discussed with the on-site customer during developmentamount: enought for the first releasesize

you must be able to a few of them in each iterationstories should be independent, concrete and testableparts having different priorities to separate stories

Story#:Description:

Estimate: (ideal days)Release#:Iteration#:



Developers estimate story efforts in ideal working dayscompare to previous similar stories, use spikesrelative efforts between stories more important than accuracyyou can mostly ignore dependencies between storiesask customer to split too large stories



Customer selects stories for the release and prioritizes themteam velocity in the previous release defines the available effortnon story related work is assumed constantstories for the first 1-2 iterations are assigned

Infrastructure work is done in parallel as required by the stories


XP Planning Game – Iteration Planning

Development team splits stories into tasktask size: a few days of ideal effort the customer is available to clarify the details of the stories

Each programmer accepts and estimates a set of tasksbased on personal speed

Balancing the scopeif these more accurate estimates are far from the story estimates, scope is tuned


XP Planning Game – Iteration Tracking

Tracker tracks the progressasks each developer regularly

how many ideal days have your worked on this task?how many ideal days do you need before you’re done?

is responsible for noticing problems with the progressprovides feecback on the accuracy of the estimates to the team

Stand-up meetingsshort daily meetings

What did you do yesterday?What are you going to do today?Are there any problems or announcments that are important for the team to know?

purpose is to communicate problems, not to solve them


XP Planning Game Exercise

Scenario6 developers, co-located teamrelease length 4 monthsiteration length 1 monthteam velocity

42 (6*7) ideal days/iteration168 (4*42) ideal days/release

development environment, technologies & high level architecture decided already

Resultshigh level requirements and corresponding effort estimatesprioritization of requirementsreturn to the course

summary document of the post-it notes

Release planning steps1. customer writes user stories (one

sentence/story) and explains them to the developers

• start from the most business critical ones

2. developers estimate the effort of the stories (in ideal days)

3. Repeat 1&2 until you have 10-15 stories estimated

4. customer chooses the stories to the firstrelease 1

5. customer chooses stories for the first iteration and prioritizes them

Iteration planning steps (optional)1. developers split stories into tasks2. developers accept a set of tasks for their

responsibilty and estimate them3. developers check that the total effort is

realistic

Story#:Description:

Estimate: (ideal days)Release#:Iteration#:


References and Additional Material

Agile Manifesto, “http://www.agilealliance.org/”Beck, K., “Embracing Change with Extreme Programming”, IEEE Computer, Vol. 32, No. 10, 1999, pp. 70-77.Beck, K., Extreme Programming Explained, Boston, Addison-Wesley, 2000.Cockburn, A., Agile Software Development. Addison Wesley, 2001.Crystal, “http://crystalmethodologies.org/”Cusumano, M. and R. Selby, Microsoft Secrets, The Free Press, 1995.Cusumano, M. and D. Yoffie, “Software Development on Internet Time”, IEEE Computer, Vol. 32, No. 10, 1999, pp. 60-69.DSDM, “http://www.dsdm.org/about/lifecycle.asp”Highsmith III, J., Adaptive Software Development, Dorset House Publishing, 2000.Highsmith III, J., Agile Software Development Ecosystems, Addison-Wesley, 2002.Kruchten, Philippe, The Rational Unified Process: An Introduction, Second Edition, Addison-Wesley, 2000.McCormick, M., “Programming Extremism”, Communications of the ACM, Vol. 44, No. 6, 2001, pp. 109-111.Palmer, S. and J. Felsing, A Practical Guide to Feauture-Driven Development, Prentice Hall, 2002.RAD, “http://csweb.cs.bgsu.edu/maner/domains/RAD.gif”RUP, “http://www.rational.com/products/rup/”Schwaber, K. and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2002.SCRUM, “http://www.controlchaos.com/”Stapleton, J., Dynamic Systems Development Method, Addison-Wesley, 1997.XP, “http:// www.extremeprogramming.org/”