Transcription
AGILE SOFTWAREDEVELOPMENTKeith Pine Kumeel Alsmail Parker Li Björn Davis
INTRODUCTION TO AGILE Whatis Agile? Originsof Agile Does Agile Work? Methodologies
WHAT IS AGILE? Aset of software methodologies that are based on iterativedevelopment Requirementsare expected to change, and response tochange is rapid Time-boxedreleases
PLAN-DRIVEN VS ITERATIVE Plan-driven methods need requirements in advance Waterfall Requirements are relatively staticIterative methods expect change Spiral-model Evolutionary processes and Agile
CT CONSTRAINTS
TRADITIONAL t
AGILE DEVELOPMENTReview & AdjustReview & AdjustReview & ssteTDefineDefinei3i2i1FinalProduct
PREDECESSORS OF AGILEFDDXPScrumCrystalASDDSDM
ORIGINS February2001 at Snowbird Ski Resort 17representatives of emerging ‘lightweight’ methods met tofind a common ground KentBeck, Alistair Cockburn, Ward Cunningham, MartinFowler, Jim Highsmith, Bob Martin, etc. Looking Thefor freedom from “Dilbertesque corporations”term “Agile” was coined
MANIFESTO FOR AGILESOFTWARE DEVELOPMENT Individuals Workingand interactions over processes and toolssoftware over comprehensive documentation Customercollaboration over contract negotiation Respondingto change over following a plan
12 PRINCIPLES1. Customer satisfaction through early and continuous delivery of valuable software2. Changing requirements are welcome, even late in development.3. Deliver working software as quickly as possible4. Daily cooperation between business people and developers5. Build projects around motivated individuals, and provide the support they need6. Face-to-face conversation is the most efficient and effective method of communication7. Progress is primarily measured through working software8. Sustainable development is promoted9. Continuous attention to technical excellence and good design10.Simplicity – the art of maximizing the amount of work not done – is essential11.Self organizing teams produce the best architectures, requirements and designs12.Regular reflection by the team is key to becoming more effective
PRINCIPLES NOT RULES Values and Principles Not a pre-defined process Context sensitive to each team and project Common recommendations iterations no longer than a month long each iteration should result in something that everyone agrees is “done” withfeedback from the stakeholders figure out what you’re doing at the start of the iteration reflect on accomplishments/failures at the end of the iteration non-stop communication
BENEFITS OF AGILE Ableto quickly respond to changing requirements andpriorities Lowercost and risk Continuousintegration and delivery - more visibility intoproject progress Businessvalue is prioritized Deliversbusiness value early and often
DOES AGILE WORK? Scott Ambler (Practice Leader for Agile Development with IBM) - Agile Adoption Rates Survey How have agile approaches affected your productivity? 60% report increased productivity 34% report no change Only 6% claimed lowered productivityHow have agile approaches affected the quality of systems deployed? 66% responded that quality is higher About 30% said no change in qualityHow have agile approaches affected business stakeholder satisfaction? 58% reported improved satisfaction 3% report reduced satisfaction.
DOES AGILE WORK? VersionOne - “The State of Agile Development” 2011 (6,042 responses)Benefits Obtained From Implementing Agile75%Increased Productivity71%Faster time-to-market15%68%Enhanced software quality49%Reduce cost0%25%Got BetterGot Worse50%No BenefitDon’t Know5%17%28%75%100%
DOES AGILE WORK?Salesforce.com568% morevaluedelivered inthe first yearof being agile.Source: Salesforce.com, Green & Fry & Mountain Goat Software
DOES AGILE WORK?Faster time to marketAgileprojects are16% moreproductive ata statisticallysignificantlevel ofconfidence.Source: Mah 2008 & Mountain Goat Software
DOWNSIDES OF AGILE Releasesmay be to often for customers to handle (enterprisesoftware) Technicaldebt Documentation Hardcan be lackingto scale properly, may require colocation
SHOULD YOU USE AGILE?HighColtsUncertaintySimple, young projects.Need agility.Tight Teams.SheepdogsLaissez faireBullsAgility to handle uncertainty.Process definition to copewith complexity.CowsComplex, mature market.Need defined interfaces.LowLowProject ComplexityHigh
SHOULD YOU USE AGILE? Betterthan chaos Easierto transition to a lightweight method than heavyweight Easierto follow with less bureaucracy Co-operative Strongteambusiness leadership Requiresalignment with company philosophy and culture
WHEN NOT TO USE AGILE Heavyweightmethodologies can be successful when: Requirements Thetechnology is mature New It’s Howrarely changeand unknown is minimalbeen done beforemany projects fit that description?
AGILE METHODOLOGIES CrystalMethods (Crystal Clear, Yellow, Orange and Red) FeatureDriven Development (FDD) ExtremeProgramming (XP) DynamicSystems Development Method (DSDM) Scrum AdaptiveProject Framework (APF)
ADAPTIVE SOFTWAREDEVELOPMENT
AGILE
ADAPTIVE PROJECTFRAMEWORK (APF) General approach Fundamental concept scope is variable within time and cost constraints Maximizes business value Client focused and Client driven Change is embraced and not avoided Just in time planning Principle that you learn by doing
APF CORE VALUES Client-focused Client-driven Incremental results early and often Continuous questioning and introspection Change is progress to a better solution Don’t speculate on the future Emphasizes “learning” Iterative Time-boxed Risk driven and change-tolerant
APF LIFE CYCLE
APF – VERSION SCOPE
VERSION SCOPE COSis input to decision on what PMLC model to be usedand then write POS. Fivecomponents of scope triangle are prioritized for decisionmaking and problem solving in cycle build phase
APF – SCOPE TRIANGLE
PRIORITIZATION APPROACHESFOR SCOPE TRIANGLE Forced PairedRankingComparison MoSCoW
PRIORITIZATION APPROACHES– FORCED RANKINGMANAGERABCDRANK SUMFORCED 6FUNCTION
PRIORITIZATION APPROACHES– PAIRED COMPARISON123456SUM 00000X06
PRIORITIZATIONAPPROACHES - MOSCOWM:Must HaveS:Should HaveC:Could HaveW:Would be Nice to Have
APF – SCOPE TRIANGLERANKINGPriorityCritical(1)(2)(3) Scope QualityTime CostResourceAvailability(4)Flexible(5)
APF – CYCLE PLAN
APF CYCLE PLANNING EFFORT Extractfrom the WBS the functions to be built Complete Buildthe extracted WBS down to the task levelthe dependency network diagram Partitionthe tasks into independent meaningful groups andassign teams to each group Eachteam will develop a plan and schedule
APF – RESOURCE LOADEDSCHEDULE
CYCLE BUILD Conduct detailed planning for producing thefunctionality assigned to this cycle Begin cycle work Monitor and adjust cycle build Create a Scope Bank Create Issues Build Cycle Functionality Monitoring and ControlMeasuring Team Strength:TS # of We’s / # of I’s # We’s
CYCLE BUILD Monitor and Control: Team status meeting Major issues are posted in Issue LogClose Cycle: Time Box expired All swim lanes competed early A major problem occurs
CLIENT CHECKPOINT Clientand project teamperform a quality review ofthe functionality produced Thesequence Cycle Plan /Cycle Build / ClientCheckpoint is repeated Operatemanageras Co-projectIf the client accepts everything, theteam will move to the next cycle.
SCOPE BANK Identify and prioritize Probative Swim Lane Identify and prioritize Integrative Swim Lane
POST-VERSION REVIEW Determineif the expected business outcome was realized Determinewhat was learned that can be used to improve thesolution Determinewhat was learned that can be used to improve theeffectiveness of APF
ADAPTING APFProof of ConceptCycleRevising the VersionPlanEmbedding APF
IMPLEMENTING APFThere are too manyfailed projectsSMPMTeamMemberBottom-upClientTeam MemberSponsor
EXTREME PROGRAMMING
WHAT IS EXTREMEPROGRAMMING (XP)?software development methodology which is intended toimprove software quality and responsiveness to changingcustomer requirements. A Asa type of agile software development, it advocates frequent"releases" in short development cycles. Helpimprove productivity and introduce checkpoints wherenew customer requirements can be adopted.
HISTORY Extreme programming was createdby Kent Beck during his work onthe Chrysler ComprehensiveCompensation System (C3)payroll project. Beck became the C3 projectleader in March 1996 and beganto refine the development methodused in the project and wrote abook on the method (in October1999, Extreme ProgrammingExplained was published)
GOAL OF XPXP attempts to reduce thecost of changes inrequirements by havingmultiple short developmentcycles, rather than a long one.
XP - PROCESS Planning Designing Coding Testing
XP - PLANNING User Stories Functionalities of the system aredescribed using stories, shortdescriptions of customer-visiblefunctionalitiesSmall & Short Releases Every release should be as small aspossible, containing the mostvaluable business requirements It is far better to plan a month ortwo at a time than six months or ayear at a time
XP - DESIGNING SimpleDesign (KISS) CRCCards: Class, Responsibility, Collaborator SpikeSolutions Refactoring
SIMPLE DESIGN Misconception Truth: XPabout XP: XP advises to avoid designadvises: Avoidtoo much Up Front Design / extra design at earlyphase, as requirement is not clear. Simple Avoidand elegant designover design
CRC CARDS Used to identify Classes, Responsibilities,& Collaborations between objects Created from index cards with with thisinformation: Class name Responsibilities of the class Names of other classes with whichthe class will collaborate to fulfill itsresponsibilities. Author
SPIKE SOLUTION1. A design problem occurs2. Create a PROTOTYPE of that portionof the design3. Implement and evaluate the prototypeIntent:To lower the risk when true implementation starts.
REFACTORINGChanging a software system in such a way that:1. The internal structure is improved2. The external behavior is not altered (not changed)Also means:Design occurs CONTINUOUSLY as the system is constructed
XP - CODING
COMMON PRACTICES Code Pairthe Unit test firstProgramming Continuous LeaveIntegration (CI)Optimization until last
PAIR PROGRAMMING Two people work together at onecomputer to create code for a story This provides a mechanism for realtime problem solving and real-timequality assurance Keeps the developers focused onthe problem at hand As pair programmers complete theirwork, the code they develop isintegrated with the work of others
CONTINUOUS INTEGRATION Avoidance of “big bang” integrations Integration for each pair occurs several times each day All tests run prior to commitment to code base Makes the cause of failures more obvious Minimizes merge pain Facilitates the code base evolving steadily Forces bug fixing to occur immediately Often supplemented by daily builds Contributes to the avoidance of quality & integration debt
CODING STANDARDS Consensus of coding style andpractices Facilitates moving about the code base Contributes to definition of clean codeand “doneness” Removes distraction of endlessarguments Goal is that code looks anonymous Standards evolve over time
XP - TESTING
TESTING PRACTICES Allcode should have Unit Tests Allcode must pass all unit tests before itcan be released Whena bug is found tests are created Unit Testspublishedand Acceptance tests are run often and the score is
UNIT TESTStests are written beforethe code Unit Testsare run to ensure thatthe software failsgood test case is one thatensures that the software fails A Testis rerun until it passes
ACCEPTANCE TEST Alsoknown as customer tests Theyare specified by thecustomer Theyfocus on the overall systemfeatures and functionality that arevisible and reviewable by thecustomer Theyare derived from userstories
Hint:Fixing small problems every few hours takes lesstime than fixing huge problems just before thedeadline.
WHEN TO USE XP? Dynamicallychanging requirements Riskyprojects Smalldevelopment groups (up to 100) Non-fixedprice contract
DYNAMIC SYSTEMSDEVELOPMENT METHOD
INTRODUCTION TO DSDM An iterative and incremental approach that emphasis continuoususer involvement DSDM became the number one framework for RapidApplication Development (RAD) Most mature agile development method DSDM is about people, not tools It seems ideally suited for software development that place a highimportance on the user interface or usability aspects of products.
HISTORY OF DSDM Developedin the United Kingdomin the 1990’s and was first releasedin 1995 Developedby several vendors andexperts in the field of InformationSystems (IS), combining their bestpractice experiences
9 PRINCIPLES OF DSDM1. Active user involvement is imperative2. Team must be empowered to make decisions3. Focus is on frequent delivery4. Fitness for business is criterion for acceptance of deliverables5. Iterative and incremental development is mandatory6. All changes during development must be reversible7. Requirements are base-lined at high-level8. Testing is integrated throughout the cycle9. Collaborative and Co-operative approach
PHASES OF DSDMPre-projectIncludes project suggestion and selection of a proposedproject candidate.Feasibility studyDefinition of the problem to be addressed, assessments ofthe likely cost and technical feasibility of delivering of acomputer system to solve the business problem.
PHASES OF DSDMBusiness StudyThis stage examines the influenced business processes, usergroups involved and their respective needs and wishes.Functional Model Iteration (FMI)The focus is on refining and studying the business-basedaspects of the computer system.
PHASES OF DSDMDesign and Build IterationThe product is designedand developed in iterations.In each iteration a designmodel is made of the areabeing developed, and thenthat area is coded andreviewed.
PHASES OF DSDMImplementationProduct is wrapped up.Documentation is written.Review is drawn up.Compare the requirements with their fulfillments in the product.The users are trained in how to use the system, and the usersgive approval to the system
PHASES OF DSDMPost-projectPost-project tasks include measurements on how thedeployed system is performing and if any furtherenhancements are required.
PROJECT LIFE CYCLE OVERVIEW
ADVANTAGES OF DSDM Activeuser participation throughout the life of the projectand iterative nature of development improves quality ofthe product Ensuresrapid, effective and maintainable deliveries whichmatch the needs of the business better Bothof the above factors result in reduced project costs
LIMITATIONS OF DSDM Requires Switchingsignificant user involvementto DSDM is neither cheap nor fast, and requires asignificant cultural shift in any organization
COMPANIES USING DSDM
SCRUM
HISTORY Started out as “rugby approach” Applied to commercial productdevelopment Team tries to “go the distance as aunit, passing the ball back and forth” Emphasized speed & flexibilityBecame “Scrum,” referring to a restartin rugby, or the huddle
WHAT IS SCRUM? Not just a standup meeting every day “An agile framework for completing complex projects.” – Scrum Alliance Iterative and incremental process Repeatable way to divide larger projects into manageable pieces Projects are divided into pieces called Sprints Teams are self-organizing and cross-functional No reliance on other groups to deliver Team members under different disciplines are physically close to each other3 main lists (artifacts), meetings, and roles
OVERVIEW OF THE PROCESS
SPRINTS Typically last 1 to 4 weeks Preceded by a Sprint planning meeting Team works on completing the items in theSprint backlog No changes allowed to the Sprint backlog oncethe Sprint has started At the end of every Sprint, the team presents ausable product Sprint review meeting After the current Sprint is finished, begin thenext one
ARTIFACTS: PRODUCTBACKLOG Prioritized list of everything needed in theproduct Single source of requirements for any changes tobe made to the product Constantly evolving and changing Attributes - description, order, estimate May contain features, bug fixes, requirements,etc. As product is used and feedback acquired,product backlog will grow
ARTIFACTS: SPRINT BACKLOG The set of Product Backlog itemsselected for the current Sprint A forecast of what functionality will bein the next increment of work Modified throughout the Sprint Belongs to the Development Team only Real-time picture of the team’s status Only the team can add/remove items
ARTIFACTS: BURNDOWNCHART
ROLES: PRODUCT OWNER Typically a single person Represents the voice of the customer – communicates the vision of theproduct to the Development Team Maximizes value of the product and work of the Development Team Responsible for delivering the best possible product within time and budget Solely responsible for managing the Product Backlog Content Organization Organization must respect the Product Owner’s decisions (visible in theProduct Backlog’s content/organization) Similar to a sports coach – sets up the plan, focuses the team on the goaland then lets them execute it
ROLES: DEVELOPMENT TEAM Responsible for delivering a potentially shippable product at the end ofevery Sprint Cross-functional skills ensure independence from other groups Self-organizing (still may meet with project management) – only oneswho decide how to turn backlog into releasable increments No titles (other than Developer) No sub-teams Optimum size is 3-9 members Smaller: skill constraints, smaller increments Larger: excessive coordination and complexity
ROLES: SCRUM MASTER Servant-leader for the team Makes certain the Scrum process is understood Ensures the team adheres to Scrum theory and practices Enforces the rules - part of the Scrum Master’s job is as the referee Remove obstructions in the team’s way Buffer between the team and distracting influences Acts like a liaison between Product Owner and Development Team
MEETINGS: SPRINT PLANNING Designates what work will be done in the current Sprint Takes items from the top of the Product Backlog and places them in theSprint Backlog Product Owner presents the Product Backlog items to the DevelopmentTeam Development Team solely decides the number of items to be placed into theSprint Backlog Product Owner can clarify selected Product Backlog items and help maketrade-offs Development Team can renegotiate work with Product Owner if there is toomuch/little
MEETINGS: DAILY SCRUM Usually a stand-up meeting that lasts no longer than 15 minutes Assesses daily progress made by the Development Team Only Development Team members speak (others may attend) Each member of Development Team: What has been accomplished since last meeting? What will be done before next meeting? What obstacles are in the way?Scrum Master’s role is to facilitate the resolution of theseobstacles/impediments and keep the meeting under 15 minutes
MEETINGS: SPRINT REVIEW Performed after Sprint is finished Review work completed/incomplete Present/demonstrate completed product tostakeholders Incomplete work is not demonstrated Discuss what went well, which problems arose, and how they were solved Product Owner discusses Product Backlog as it stands Entire group collaborates on what to do next and prepare for the next SprintPlanning meeting End result: revised Product Backlog
OTHER MEETINGS SprintRetrospective Scrumof Scrums Backloggrooming
SPRINT RETROSPECTIVE Teammembers reflect on the past sprint Lessonslearned Processimprovements – plan to improve the next Sprint
SCRUM OF SCRUMS Used in scaling Scrum to large project teams A representative from each Daily Scrum Meetingconducts their own Scrum Meeting What has your team done since we last met? What will your team do before we meet again? Is anything slowing your team down or getting intheir way? Are you about to put something in another team’sway?
BACKLOG GROOMING Teamspends time during the Sprint to do backloggrooming Estimating Refiningbacklog effortacceptance criteria for backlog items
PROS Breaks down projects into smaller, digestible chunks in a methodical way Each team member carries responsibility and ownership Increased communication Daily Scrum Meetings Physical location of team members Provides quantified progress Constant and current status updates (can be a con) Customer can update/change requirements Constant feedback from customer through regular demonstrations of iterations Low up front documentation Developers can choose what they take on
CONS Even with Scrum of Scrums Meetings, large scale projects may presentcomplications. For example, system testing may become difficult. Meetings and planning can be excessive – takes time away fromdevelopment Have to update status constantly Shorter iterations have higher overhead Possibility of scope creep (items keep getting added to ProjectBacklog)
WRAP UP Adoptionof Agile in the Industry
Source: VersionOne - “The State of Agile Development” 2011How Many Organizations haveadopted agile development?How Many TeamsAdopted Agile?How long have respondents beenpracticing agile development?Number ofCompany ProjectsUsing AgileWHO’S USING AGILE?
GovernmentFinancialServicesHealthcareMedia S USING AGILE?
Q&AKeith Pine Kumeel Alsmail Parker Li Björn Davis
REFERENCES Ambysoft- http://www.ambysoft.com Stateof Agile Development Survey Results - http://www.versionone.com/state of agile development survey/11/ Manifestofor Agile Software Development - http://agilemanifesto.org/ MartingFowler, The New Methodology - ml
REFERENCES Williams, Laurie, ASurvey of Agile Development Methodologies- .pdf RallySoftware - http://www.rallydev.com MountainGoat Software - Reported Benefits of AgileDevelopment Wysocki, Robert Slideshare.netK., 2009. Effective Project Management.
AGILE DEVELOPMENT Ideas Define t Code i1 Define Define Define i2 i3 Final Product Review & Adjust Review & Adjust Review & Adjust. PRE
