Вы находитесь на странице: 1из 24

Agile

Introduction to Agile methodologies

The Agile manifesto


The Agile Manifesto 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/

Priciples
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicitythe art of maximizing the amount of work not doneis essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Overview

Product Backlog
The most important element of the process It's all the product's functionalities Does not contain all requests to the smallest detail It grows along with the product It contains: features, user stories and TODOs

Organizing the Product Backlog


1)ID unique ID. 2)Name a short name for the story. Syntax: As a <user role>, I want to <goal> so that <benefit>. 3)Importance, from the Product Owner's point of view (an integer value). 4)Initial estimate team's estimation on the total effort involved (story points). 5)How to demo description of how the demonstration should be done. 6)Notes other useful data.

Velocity

Estimation
It is a team activity; each member is involved in this activity A user story usually involves more expertise from different team members Throughout joint estimation, each team member gets to understand the complexity of a story, leading to cross-functional teams. A story should be between 2-8 man days; if longer, it needs to be split in more stories. Characteristics of a story: Independent, Negotiable, Valuable, Estimable, Sized appropriately, Testable

Story points
It expresses the dimension of a story It is influenced by the work load and complexity involved It is only significant as a relative value It has no measuring unit (story points) Recommended values to use: 1, 2, 3, 5, 8, 13, ....

Sprint planning
Goal: Obtain commitment on the content of the sprint. Tools: Creating a list of tasks, estimated in hours Clarifications on user stories Identifying the availability of each member Input: Product backlog Product Owner familiar with all the stories Importance from backlog Output: Sprint goal Sprint backlog Sprint demo date Daily Scrum location

Sprint planning

User stories

Story vs. Task

A story is a deliverable in which the Product Owner is interested A task is a nondeliverable, important for the team A story must be decomposed into tasks

Daily Scrum
Everyday in the same location, at the same hour Problem solving is done after the meeting, in private Each member responds to 3 questions: 1.What have you done yesterday? 2.What will you do today? 3.Are there any obstacles to eliminate?

Sprint start

Sprint after 1 day

st

Sprint after a few days

Burndown chart

Problem Burndown

Problem Burndown

Sprint demo

Sprint demo = acknowledgment of team's work The existence of the Demo forces the team to finish it's tasks Maintain a business vocabulary during the demo, not a technical one Concentration on main features, not on the small things All participants should test the product themselves, too

Sprint retrospective

Without this, the team continues to make the same mistakes again Every team member states things that he liked and disliked during the sprint If the difference between Estimated velocity and Actual velocity is high, it should be analyzed The Scrum master summarizes the Sprint backlog, focusing on important events and decisions

Sprint retrospective

The suggestions are summarized on 3 columns:


1.Things we want to repeat 2.Things we want to do different 3.Ideas for improving the next sprint

After dot voting, the most important 5 suggestions will be implemented in the next sprint.

Вам также может понравиться