Agile Methodologies and Principles
10 Questions
0 Views

Agile Methodologies and Principles

Created by
@GuiltlessDecagon

Podcast Beta

Play an AI-generated podcast conversation about this lesson

Questions and Answers

The Agile Manifesto prioritizes comprehensive documentation over working software.

False

Extreme Programming (XP) emphasizes the need for systems to be both testable and always ready for deployment.

True

The principle of simplicity in XP encourages engineers to choose the most complex solution to validate their work with customers.

False

In Agile, an architectural spike is a process for evaluating high- and medium-level architectures during product development.

<p>True</p> Signup and view all the answers

Agile processes prioritize customer collaboration over contract negotiation.

<p>True</p> Signup and view all the answers

TDD is primarily used to ensure manual testing is a key part of development.

<p>False</p> Signup and view all the answers

In SCRUM, a product owner is responsible for defining features based on market value.

<p>True</p> Signup and view all the answers

SCRUM teams can accept new requirements at any time during a sprint.

<p>False</p> Signup and view all the answers

A burndown chart tracks the total remaining team task hours across multiple sprints.

<p>False</p> Signup and view all the answers

The team in SCRUM is typically composed of 5 to 10 people.

<p>False</p> Signup and view all the answers

Study Notes

Agile Manifesto

  • Emphasizes collaboration, working software, responsiveness to change, and individuals over processes.
  • Aims to decrease development time wasted on building the wrong thing and allow teams to experiment with design alternatives.

Agile Process

  • Utilizes Test Driven Development (TDD), Emergent Design, and code refactoring.
  • Emergent Design starts with a Minimum Viable Product (MVP) and introduces abstractions to address code duplication.
  • Refactoring code should be preceded by an architectural spike.

Agile Benefits

  • Increased customer interaction.
  • Focus on experimentation.
  • System remains in a buildable state.
  • Greater flexibility.

Extreme Programming (XP)

  • Emphasizes continuous integration, testability, and adaptation.
  • Encourages devs to start small, adapt, and refactor systems.

XP Principles

  • Communication: Essential for project success and schedule decisions.
  • Simplicity: Focus on the simplest solutions for initial validation.
  • Feedback: Gather insights from tests, customers, and teams for informed decisions.
  • Courage: Discard failed experiments to learn and improve.
  • Respect: Maintain a stable build and focus on long-term understandability.

Spikes

  • Short, intensive activities preceding development iterations to provide insights for decision-making.
  • Architectural spikes determine high- and medium-level architecture (e.g., tech stack, collaborators, subcomponents).
  • User Interface spikes define the look and feel, UI framework, and plan for UI expansion.

Test Driven Development (TDD)

  • Prioritizes automated testing as a core part of development.
  • Crucial due to agile's focus on quick code refactoring.
  • Often challenging for developers to write tests before code.

Scrum

  • An incremental, iteration-based methodology with fixed-length sprints (1-3 weeks).
  • Aims for shippable code at the end of each sprint.
  • Teams work in a series of sprints with no new requirements during a sprint.
  • Dev team commits to completing user stories within a sprint.
  • Utilizes a scrum board to track progress, with unsolved items moving back to the product backlog.

Scrum Roles

  • Product Owner: Defines product features, prioritizes them based on market value, and adjusts them in every iteration.
  • Scrum Lead: Facilitates the scrum process, resolves issues, and shields the team from external interferences (not a manager).
  • Team: Self-organizing, cross-functional team consisting of devs, designers, managers, and clients (7+/- people).

Scrum Artifacts

  • Product Backlog: Prioritized list of backlog items (PBIs) specifying customer-centric features.
  • Sprint Backlog: List of user stories negotiated by the team and product owner from the product backlog.
  • Burndown Chart: Tracks total remaining team task hours within a sprint.

Scrum Ceremonies

  • Sprint Planning: Determines user stories for the sprint, estimates task duration, and decides which tasks to include.
  • Daily Standup Meeting (15 minutes): Provides a daily update on completed tasks, work in progress, and any blocking issues.
  • Sprint Review (less than 2 hours): Demonstrates completed features to the product owner at the end of a sprint.
  • Retrospective (end of sprint): Reflects on team activities to identify areas for improvement and refinement.

Scrum Strengths

  • Delivers small quantities of software regularly, aiming for delivery after every sprint.

Kanban

  • A pull-based software process emphasizing continuous delivery and flexibility.
  • Unlike Scrum, it's a continuous process without a sprint backlog.
  • Employs agile boards to visualize and track work in real-time.
  • Utilizes a pull system with work-in-progress (WIP) limits to manage workload and prevent overworking.

Kanban Columns

  • Backlog: All available work.
  • Doing: Current work in progress.
  • Review: Work ready for team sharing and review.
  • Done: Reviewed and completed work.

Kanban vs. Scrum

  • No specific release dates in Kanban, team decides.
  • No sprint planning or reviews, but daily standups are still included.
  • Kanban used for faster releases than Scrum.
  • Less rigid ceremonies in Kanban.
  • Focus on continuous feature development, allowing for immediate shipping when a feature moves to "Done."

User Stories

  • Lightweight descriptions of features used to specify software development tasks.
  • Used for discussing features, validation methods, and costs.
  • Help improve communication between product owners and engineers.
  • Follow the format: ROLE-GOAL-BENEFIT: "As a [role], I want to [goal], so that [benefit]."

Definition of Done (DoD)

  • Specific descriptions of how a user story can be validated by both developers and product owners.
  • Ensures the completion of a story correctly.
  • Should be user-level, describing client-oriented solutions, not code.
  • Derives test suites and encourages discussion of verification methods before development begins.

User Story Example

  • RGB: As a shopper, I want to be able to buy something and then see it in my purchased list so that I can spend money on the site.
  • DoD: User clicks the buy button, the item appears in their purchased list, it's shipped, and the money is deducted from their account.

Bad User Story and DoD Example

  • RGB: As a buyer, when I’m told that I’m not approved for purchase by the system, I want to beable to click request approval (solution domain!) and then receive confirmation that the approval request has been sent. (No benefit!)
  • DoD: User sees "not approved," clicks "request approval," which triggers a React function that adds the user's ID to the approval request list and sends an email confirming processing.

Engineering Tasks

  • Useful for developers to track how features interact with the system or subsystem.
  • Not from a user's perspective (e.g., "finish parser," "set up database," "mock for testing").
  • Devs use them to estimate the time required for a story.

Story Points

  • Represent an hour of development work.
  • Traditionally estimated by devs based on experience.
  • Moving toward an ontology-based approach, using classifications for more accurate estimation.
  • Used to track team progress and ensure workloads are manageable.

Task Hierarchy

  • Task: Specific piece of technical work for a user story.
  • User Story: Discrete product function producing value for the customer.
  • Epic: Group of related user stories delivered over multiple sprints, sharing a common goal.
  • Theme: Groups epics, describing a high-level objective.

Technical Debt

  • Design choices made for speed or budget instead of technical justifications.
  • Accumulates over time and requires significant restructuring to reduce.
  • Should be allocated separately and disclosed to the customer for negotiation.

User Story Estimation

  • Stories should be written clearly for developers to estimate time required (using Fibonacci).
  • Precise user stories enable tractable task scheduling and project management.

User Story Size

  • Aim for stories taking between half a day and half an iteration.
  • Split up longer stories to ensure completion within a sprint.
  • Over-granulating can lead to undesirable dependencies between stories.

User Story Testability

  • Ensuring a story is testable with a DoD verifies completion according to customer requirements.
  • Not all aspects are testable (e.g., making the user happy).
  • Testability facilitates validation and improves process effectiveness.

Requirements

  • Functional Requirements: Specify what the system should do, not how it should be done.
  • Quality Attributes: Desirable properties of the product, often described with adjectives.
  • Quality attributes can conflict with each other (e.g., complexity vs. performance, usability vs. scalability).
  • Examples of quality attributes: security (privacy, confidentiality), reliability (durability, recoverability), performance (scalability, capacity), legal.

Studying That Suits You

Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

Quiz Team

Related Documents

CPSC 310 Q1.pdf

Description

This quiz covers the Agile Manifesto, Agile processes including Test Driven Development, and Extreme Programming (XP) principles. Participants will explore key concepts such as collaboration, customer interaction, and the benefits of Agile methodologies. Test your knowledge on how Agile enhances software development efficiency.

More Like This

Use Quizgecko on...
Browser
Browser