程序代写代做代考 game C flex Excel algorithm Agile Software Development Practices (SOFT2412)

Agile Software Development Practices (SOFT2412)
Agile Methods – Scrum
Dr. Basem Suleiman School of Information Technologies
The University of Sydney
Page 1

Agenda
– AgileManifesto
– Valuesandprinciples
– Agile Methods – Scrum,XP
– Scrum
– Definition and Values
– Teams and Roles
– Events
– Artifacts
– Measuringprogress
The University of Sydney
Page 2

Agile Process
– Agile advocates believe:
– Current software development processes are too heavy-weight or
cumbersome
– Current software development is too rigid – More active customer involvement needed
The University of Sydney
Page 3

Agile Process
– Agile methods are considered – Light-weight
– People-based
– Several agile methods
– Extreme Programming (XP), Scrum
– Agile Manifesto closest to a definition – Set of principles
– Developed by Agile Alliance
The University of Sydney
Page 4

Agile Manifesto – Revisit
– “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value”
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
Agile Manifesto: http://agilemanifesto.org/
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
The University of Sydney
Page 6

Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Businesspeople and developers must work together daily throughout the project
Agile Alliance: http://www.agilealliance.org
The University of Sydney Page 7

Agile Principles
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.
Agile Alliance: http://www.agilealliance.org
The University of Sydney Page 8

Agile Principles
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done is essential. 11. The best architectures, requirements, and designs emerge from self-
organizing teams
12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly
Agile Alliance: http://www.agilealliance.org The University of Sydney
Page 9

Agile Methods
• Shared goal; delivering valuable software iteratively
• Might have some different practices to achieve this goal
• Examples of Agile methods: • Scrum
• Extreme Programming (XP)
• Lean software development
• Kanban (lean development)
The University of Sydney
Page 11

eXtreme Programming (XP)
– Development and delivery of very small increments of functionality
– Relies on constant code improvement, user involvement in the
development team and pair wise programming.
– Emphasizes Test Driven Development (TDD) as part of the small development iterations.
The University of Sydney
Page 12

Agile Methods
The common aspects among different Agile methods
The University of Sydney Page 13

Scrum
– Method for “product development” lifecycle from H. Takeuchi and I. Nonaka (1986)
– Speedandflexibility
– Used for software development by K. Schwaber, J. Sutherland and others
– Extensively used in various organizations (e.g., manufacturing, product development, software, hardware)
https://en.wikipedia.org/wiki/Scrum_%28software_development%29
The University of Sydney
Page 14

Scrum (Software Development)
– Managing software development to deliver products with highest value
– Continuous improvement of the product, the team and the working environment
– Scrum is lightweight, simple to understand but difficult to master
https://en.wikipedia.org/wiki/Scrum_%28software_development%29
The University of Sydney
Page 15

Scrum Theory
– Based on ‘empirical process control’ theory
– Knowledge from experience and decisions based on knowns
– Optimize predictability and control risks
– Pillars of empirical process control
– Transparency: the process visible to those responsible for the outcome
– Inspection: frequently inspect Scrum artefacts and progress to detect variances
– Adaptation: adjust the process to the acceptable limits The University of Sydney
Page 16

Scrum Values
– Commitment: personally commit to achieving the goals of the Team
– Courage: members can do the right thing and work on tough problems
– Focus: everyone focuses on the work of the iteration and the team’s goals
– Openness: the team and the stakeholders agree to be open about the work and the challenges with performing the work
– Respect: team members respect each other to be capable, independent
The University of Sydney Page 17

Scrum Practices
– Teams and their roles
– Product Owner, Scrum Master, Dev Team
– Events
– Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Retrospective
– Artifacts
– Product Backlog, Sprint Backlog, Increment
– Project estimation and Sprint estimation
– Rules govern the relationships between roles, events and artifacts
The University of Sydney
Page 18

The Scrum Team
The University of Sydney Page 20

Scrum Team
– Scrum Team
– Small enough to be agile
– Cross-functional
– Self-organizing
– Deliver products iteratively and incrementally, maximizing opportunities for feedback
– Team roles
– Development Team
– Product Owner (one person!)
– Scrum Master (one person!)
The University of Sydney
Page 21

Scrum Team – The Product Owner
– Product Owner: maximize value of the product and the work
– Understand requirements and its priorities
– Manage the Product Backlog (only person)
• Can assign it to the development team, but still accountable
– Managing the product backlog:
– Record product backlog items and order it
– Optimize the value of the work the development team performs
– Ensure transparency and clarity of the product backlog
– Ensure the development team understands product backlog
The University of Sydney
Page 22

Scrum Team – The Development Team
– Professionals who do the work of delivering a potentially releasable product at the end of each iteration
– Creates the increment (only by dev team)
– What’s the optimal team size? Discuss
– Small enough and large enough!
– Less than 3 members?
– More than 9 members
The University of Sydney
Page 23

Scrum Team – The Development Team
– Professionals who do the work of delivering a potentially releasable product at the end of each iteration
– Creates the increment (only by dev team)
– What’s the optimal team size? Discuss
– Small enough and large enough!
– Two-Pizza team (4-9 members)
The University of Sydney
Page 24

Scrum Team – The Development Team
– Self-organizing:turnsproductbacklogintoincrementsofpotentially releasable functionality
– Cross-functional: skills mix necessary to create a product
– No sub-teams: regardless of domains that need to be addressed
– Whole team is accountable
– No titles for Dev team members
The University of Sydney
Page 25

Scrum Team – The Scrum Master
– Keeps the team focused on using Scrum properly (“servant-leader”)
– EveryoneunderstandsScrumrulesandvalues(coaching)
– Remove impediments
– Helps those outside the Scrum team which of their interactions with the Scrum team are/aren’t helpful
– Maximize the value created by the Scrum team through changing team interactions
The University of Sydney Page 26

Scrum Team – The Scrum Master
– Serves the product owner to ensure;
– Mutualunderstandingofgoals,scopeandproductdomain
– Effective ways for managing the product backlog
– The Scrum team understands the need for clear and concise product backlog items;
– Arranging the Product Backlog to maximize value;
– Understandingandpracticingagility
– Facilitating Scrum events as requested or needed
The University of Sydney
Page 27

Scrum Team – The Scrum Master
– Serves the Dev team to ensure:
– Beself-organizingandcross-functional;
– Createhigh-valueproducts;
– Remove impediments to the Dev team’s progress;
– Facilitating Scrum events as requested or needed; and,
– Coaching the Dev team
The University of Sydney
Page 28

Scrum Team – Interactions
Which of the following best describe(s) Scrum team in terms of roles and interactions?
The University of Sydney
Page 30
Team A
Team B

The Scrum Events
The University of Sydney Page 31

Scrum Events
– To create regularity and minimize the need for meetings
– Time-boxed (max. duration)
– Cannot be changed once an iteration (sprint) has started
– Enable transparency and a formal approach to inspect and adapt work
The University of Sydney
Page 32

Scrum Events – The Sprint
– A development iteration (one cycle)
– Useable and potentially releasable product increment is created
– Time-boxed (typically 2-4 weeks)
– Too long sprints may lead to changes in the definition
– Sprints have consistent durations during the product development
– Consists of the Sprint Planning, Daily Scrum, the Development Work, the
Sprint Review and the Sprint Retrospective The University of Sydney
Page 33

Scrum Events – Sprint Planning
– Identify the Sprint Goal (items from the “Product Backlog”)
– Identify work to be done to deliver this
– Two-parts meeting (Scrum Master (SM), Product Owner (PO) and Dev team)
– Before meeting: PO prepares prioritized list of most valuable items
– Part 1 (max. 4 hours): PO & Dev team select items to be delivered at the end of the Sprint based value and team’s estimate of how much work needed
– Part 2 (max. 4 hours): Dev team (with the PO’s help) identify the individual tasks they’ll use to implement those items
– Output: Sprint Backlog (the items selected by the team for development)
The University of Sydney Page 34

Scrum – Sprint Planning
Which team organization better describes the Scrum Sprint/iteration planning?
The University of Sydney
Page 35
Team C
Team D

Scrum Iteration Process
– Sprint (development iteration)
– Timeboxed (typically 2–4 weeks – no more than one month)
– Create a “Done” usable, potentially releasable product
– A Sprint (Scrum iteration) contains a list of tasks and work product outputs that will be done in defined duration
▪ At the beginning of the Sprint duration, each team member has a pretty good idea of what they will be working on
▪ Management should not add new work product outputs to the Sprint – should be add to the Product Backlog instead
The University of Sydney Page 36

Scrum Iteration Process
The University of Sydney Page 37

Scrum Events – During Sprint
– Daily Scrum meeting
– To ensure problems and obstacles are visible to the team
– Timeboxed 15 minutes (same time and place each day)
– All team members including Scrum Master and Product Owner must attend
– Interested stakeholders may attend as observers
– Each briefly answers three questions:
• What did I do yesterday that helped the development team meet the Sprint Goal?
• What I will do today to help the development team meet the Sprint Goal?
• do I see any obstacles that presents me or the Dev team to meeting the Sprint Goal?
– No problem-solving during the meeting
• Follow-up meetings if further discussion is required
The University of Sydney Page 38

Scrum Events – During The Sprint
– Development Work; the Dev team
– Builds the items in the Sprint Backlog into working software
– Should inform the Product Owner if they are overcommitted or can add extra items if time allows
– Must update the Sprint backlog and keep it visible to everyone
The University of Sydney Page 39

Scrum Events – During The Sprint
The Sprint Review
– End of Sprint meeting (max. 4-hours)
– Dev team demonstrates working software to customers/stakeholders
• Completed, tested & accepted features (by PO)
• Functional working software
– Stakeholders share their feedback/thoughts about the demo
– The PO updates the Product Backlog with any changes for next Sprint planning
– The SM ensures participants understand its purpose, and maintain within the time-box
– Output: revised Product Backlog and probable items for next iteration
The University of Sydney Page 40

Scrum Events – Retrospectives
– Opportunity for the team to inspect itself and create plan for improvements
– Inspect how the last Sprint went; people, relationships, process, & tools;
– Identify and order the major items that went well and potential improvements;
– Create a plan for implementing improvements to the way the Scrum Team does its work
The University of Sydney Page 41

Scrum Events – Retrospectives
Retrospective meetings (max. 1-3 hours)
– The SM and the Dev. team (PO)
– Each to answer 2 questions:
– What went well during the Sprint?
– What can be improved in the future?
– The SM notes improvements that should be added to the Product Backlog
– E.g., set-up a better build server, better design principles, changing office layout
– Output: identified improvements to be implemented in the next Sprint (adaptation)
The University of Sydney Page 42

Scrum Events – Retrospectives
The Retrospectives Prime Directive:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
(From Norm Kerth’s book on Project Retrospectives See also http://www.retrospectives.com )

Why this rule?
The University of Sydney
Page 43

Scrum Artifacts
The University of Sydney Page 44

Scrum Artifacts – Product Backlog
– Set of all features and sub-features to build the product (the “Plan” for multiple iterations)
– Functions, requirements, enhancements and fixes identified from previous Sprints – Maintained by the PO in collaboration with customers and team
– The source of the product requirements
– The items ordered by priority – value to the customer
The University of Sydney Page 45

Scrum Artifacts – Product Backlog
– What does a Product Backlog look like? – Simple spreadsheet
– Someitemsare“customerfeatures”
• E.g., user screen, interaction scenario or use case, a new report/algorithm
– Some items are internal tasks that contribute to the value of the product • Can a design document be an item?
– Effort estimates The University of Sydney
Page 46

Scrum Artifacts – Sprint Backlog
– Set of items selected for the Sprint, a plan for delivering the product increment and realize the Sprint Goal
– Identified by the Dev. team
– Includes at least one high-priority improvement from previous Sprint – The Dev. team adds new work to the Sprint Backlog
– The estimated remaining work is updated once an item is completed – Visible to anyone and to be modified by the Dev. team
The University of Sydney
Page 47

Sprint Backlog – Example
– Typically divided into 3 sections; To Do, In Progress, Done
– Tools to support Sprint planning and monitoring; e.g., Trello
The University of Sydney
Page 48

Sprint Backlog – Example
–JIRA Agile – Scrum Board
The University of Sydney Page 49

Scrum Estimation
The University of Sydney Page 50

Scrum Artifacts – Progress Monitoring
– Total work remaining to reach the goal – the product owner tracks this at least every Sprint Review
– Compare with previous Sprints to assess progress toward projected work (transparent to all stakeholders)
– Forecasting progress through burn-downs, burn-ups or cumulative flows • It’s an estimate – there’re some risks of unknowns
The University of Sydney Page 51

Scrum Artifacts – Burn-down Chart (Example)
https://commons.wikimedia.org/wiki/File:SampleBurndownChart.png
The University of Sydney Page 53

Summary of Scrum
The University of Sydney Page 55

References
– Andrew Stellman, Margaret C. L. Greene 2014. Learning Agile: Understanding Scrum, XP, Lean and Kanban (1st Edition). O’Reilly, CA, USA.
– Ken Schwaber and Jeff Sutherland, The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum- Guide-US.pdf#zoom=100
– Agile Alliance. [agilealliance.info]
– Scrum Software Development.
[https://en.wikipedia.org/wiki/Scrum_%28software_development%29] The University of Sydney
Page 57