Agile Project Management - Aalto · PDF fileAgile Project Management ... RAD Crystal family...

Click here to load reader

  • date post

    22-Jul-2018
  • Category

    Documents

  • view

    215
  • download

    0

Embed Size (px)

Transcript of Agile Project Management - Aalto · PDF fileAgile Project Management ... RAD Crystal family...

  • 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

  • 38.4.2003 Jari Vanhanen

    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

    Cant be used in all projects!

    Some starting points for the interested:

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

  • 48.4.2003 Jari Vanhanen

    Some Published Agile Processes

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

  • 58.4.2003 Jari Vanhanen

    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

    Dont agree at the fourth leveldetailed project tactics

  • 68.4.2003 Jari Vanhanen

    Principles of the Agile Alliance

    Satisfy the customer through early and continuous delivery of valuable softwareAgile processes harness change for the customers 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

  • 78.4.2003 Jari Vanhanen

    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

  • 88.4.2003 Jari Vanhanen

    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

  • 98.4.2003 Jari Vanhanen

    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

  • 108.4.2003 Jari Vanhanen

    SCRUM

  • eXtreme Programming

  • 128.4.2003 Jari Vanhanen

    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.

  • 138.4.2003 Jari Vanhanen

    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

  • 148.4.2003 Jari Vanhanen

    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

  • 158.4.2003 Jari Vanhanen

    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 peoples instincts, not against themaccepted responsibilitylocal adaptation travel lighthonest measurement

  • 168.4.2003 Jari Vanhanen

    XP Practices

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

    Simple, well-known practicespractices support each others weaknesses

  • 178.4.2003 Jari Vanhanen

    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 possibleplan 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

  • 188.4.2003 Jari Vanhanen

  • 198.4.2003 Jari Vanhanen

    XP Planning Game Release Planning

    Customer decidesscopepriorityrelease dates

    Developers are responsible ofeffort estimatestechnical consequencesdevelopment processdetailed scheduling within iterations

  • 208.4.2003 Jari Vanhanen

    Planning Game Release Planning Steps (1/3)

    Customer writes user storieschunk of functionality that is of value to the customercustomer 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#:

  • 218.4.2003 Jari Vanhanen

    Planning Game Release Planning Steps (2/3)

    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

  • 228.4.2003 Jari Vanhanen

    Planning Game Release Planning Steps (3/3)

    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

  • 238.4.2003 Jari Vanhanen

    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

  • 248.4.2003 Jari Vanhanen

    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 youre done?

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

    Stand-up meetings