Agile Software Development: Understanding Software Process Movements and Scrum Methodology, Study notes of Software Engineering

An overview of software process movements, focusing on predictive, iterative, and adaptive approaches. It also delves into Agile methodologies, including Scrum, and discusses the Agile Manifesto and its principles. various aspects of Scrum, such as the definition of done, artifacts, events, and sprint planning.

Typology: Study notes

2021/2022

Uploaded on 09/27/2022

lana23
lana23 🇺🇸

4.8

(4)

216 documents

1 / 19

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
2/13/18
1
CS314 Software Engineering
Project Management
Dave Matthews
Software process movements
Predictive – 1970
Waterfall
Iterative – 1980s, 1990s
Spiral, RAD, RUP
Adaptive (Agile) – late 1990s
XP, Scrum, Crystal, FDD, Lean, DSDM, Kanban,
Enterprise Adaptive (Lean & Agile) – late 2000s
SAFe, Nexus,
Agile Software Requirements, Dean Leffingwell
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13

Partial preview of the text

Download Agile Software Development: Understanding Software Process Movements and Scrum Methodology and more Study notes Software Engineering in PDF only on Docsity!

CS314 Software Engineering

Project Management

Dave Matthews

Software process movements

  • Predictive – 1970
    • Waterfall
  • Iterative – 1980s, 1990s
    • Spiral, RAD, RUP
  • Adaptive (Agile) – late 1990s
    • XP, Scrum, Crystal, FDD, Lean, DSDM, Kanban, …
  • Enterprise Adaptive (Lean & Agile) – late 2000s
    • SAFe, Nexus, … Agile Software Requirements, Dean Leffingwell

Plan Driven versus Value Driven

Plan Driven Value Driven Time (^) Features Resources Resources Features (^) Fixed Time Flexible Agile Software Requirements, Dean Leffingwell

Manifesto for Agile Software Development

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 That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/

Definition of Done

A shared

understanding of

what it means for

work to be

complete.

Team

  • Product Owner
  • Development Team
  • Scrum Master

Artifacts

  • Product Backlog
  • Sprint Backlog
  • Product Increment

Events

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Sprint Planning

What we can do?

Sprint Goal

  • An objective set during the Sprint Planning meeting.
  • Selected Backlog Items (Epics) deliver one coherent function.
  • Provides guidance to development team on why it is building the increment.
  • Gives flexibility regarding the functionality implemented for the sprint.
  • Causes Development Team to work together rather than on separate initiatives.

Sprint Planning

  • Product Owner can help to clarify Product Backlog items (epics) and make trade-offs.
  • Development Team may renegotiate selected Product Backlog items (epics) if it has too much or too little work.
  • By the end of Sprint Planning, Development Team should be able to explain how it intends to work as a self- organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Planning

  • Time-boxed event
    • maximum 8 hours for 4 week sprint (160 work hours)
    • maximum 1.5 hours for our 3 week sprint (24 work hours)
  • Plan answers two questions:
    • What can be delivered in the increment this sprint? Epics
    • How will the work to deliver the increment be achieved? Tasks

Task Estimation

  • Estimates are guesses
    • The larger the project, the less accurate the estimate
    • The farther from completion, the less accurate the estimate
  • When paired with historical data they become more useful
    • burndown charts - are you on track to achieve your goal
    • velocity charts - how fast are you progressing
  • Story points versus time estimates
    • story points are unit-less, sized in relation to other tasks
    • independent of person doing the work

Planning Poker

  • Discuss a backlog item (epic / task)
  • Estimate the size using Fibonacci cards
    • relative to each other / hours to do
  • If large range, discuss further to understand why
  • Done when estimates are similar (not identical)
  • Breakdown tasks with estimates > 3

Story Board

New Issues Icebox Backlog In Progress Done/Closed

  • add new epics / tasks - epics / tasks that will not be completed in this sprint - add estimate - add milestone - add labels - add assignee - add release
  • Create milestones with start and end dates
  • Create labels for tasks

Burndown Charts

  • Monitor your team's progress during the sprint.
  • Based on your initial sprint planning and refinement during the sprint.

Daily Scrum

What are we doing now?

Daily Scrum

  • A 15-minute time-boxed event for the development team.
  • Held at the same time and place every day of the sprint.
  • Plans work for the next 24 hours.
  • Inspects work since last Daily Scrum.
  • Forecast upcoming Sprint work.
  • Optimized the probability to meet the Sprint Goal.

Some Key Questions

  • What did I do yesterday that helped meet the Sprint Goal?
  • What will I do today to help meet the Sprint Goal?
  • Do I see any impediments that prevent us from meeting the Sprint Goal.

cs314 - record Daily Scrums in sprint.md

Date Done In Progress Impediments 1/30 #12,#14,#15 #8,# (tasks from Zenhub) (tasks from Zenhub)

Sprint Review

  • Held at end of Sprint to
    • Inspect the Increment
    • Adapt the Product Backlog
  • Informal meeting to elicit feedback and foster collaboration
    • 4 hour meeting for 4 week sprint (less in our case)
  • Scrum team and stakeholders collaborate on
    • what was done for the Sprint
    • changes to the Product Backlog during the Sprint
    • next things that could be done to optimize value.

Sprint Review

  • Explains what Product Backlog items have been done and what has not been done.
  • Discusses what went well during the Sprint, what problems were encountered, and how they were resolved.
  • Demonstrates and answers questions about the Increment.
  • Discusses the Product Backlog as it stands.
  • Collaborates on what to do next as input to Sprint Planning

cs314 - Update sprint.md before Demo

  • Review
    • Done
    • Not Done
    • What went well
    • Problems encountered and their resolution
  • Metrics
    • Add ending values for the Sprint

cs314 - Demo in class

  • Attendance required
  • Demonstrate the increment and answer questions
  • Discuss and revise the Product Backlog to start Sprint Planning

Sprint Restrospective

  • Inspect how the last sprint went with regards to people, relationships, processes, and tools.
  • Identify and order the major items that went well and potential improvements.
  • Create a plan for implementing improvements to the way the team does work.

cs314 - Update sprint.md before Demo

Topic Teamwork Process Tools What we changed for this Sprint* What we did well What we need to work on What we will change next time