Agile

Que es Agile?

  • No Proceso Formal
  • Método
  • Mini-Waterfall
  • Manifiesto
  • SCRUM

Agile Manifest

(Manifiesto por el Desarrollo Agil de Software)

Individuos e interacciones sobre procesos y herramientas

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda

Software funcionando sobre documentación extensiva

Respuesta ante el cambio sobre seguir un plan

Colaboración con el cliente sobre negociación contractual

Agile en práctica

Los Doce Principios

Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.

Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al
cliente.

Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.

Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.

Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.

Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.

El software funcionando es la medida principal de
progreso.

Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.

La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.

Cruz de Hierro

Bueno

Barato

Rápido

Terminado

Métricas de Agile

Cuanto Trabajo Hay

(Story Points)

Cuanto Podemos Terminar

(Velocity)

User Stories

Independent

Negotiable

Valuable

Estimable

Small (Specific)

Testable

INVEST

Story Points

  • Nos ayuda saber cuanto trabajo existe
  • Es un cálculo de cantidad, no de tiempo!
  • Solo representa el tamaño del User Story en relación con otros User Stories

Story Points

8

5

3

2

1

?

No sabemos, crear un Spike

∞

Demasiado Grande, hay que dividir

Velocity

  • Cálculo de cuantos Story Points el equipo puede terminar un una iteración
  • Al principio es muy volátil
  • Si fluctúa mucho, indica que no estamos calculando bien los Story Points

Tiempo = Points / Velocidad

Tasks

  • Trabajo específico
  • Pequeño (Más o menos un dia)
  • Calculado con horas
  • Se actualiza todos los dias con las horas que quedan

Horas que quedan

Iteration Progress

Burn Down Chart of Remaining Work

Example

User Story: Login

  • User's can login with an email address and password
  • If a user forgets their password, they need to be able to reset it
  • We should prevent brute force logins with some kind of "Not a Robot" check
  • It would be nice if we allowed two-factor authentication as well

Example - Split

User Story 1: Login with Email and Password

User Story 2: Reset Password/Forgot Password

User Story 3: Prevent Brute Force Login Attempts

User Story 4: Two-Factor Authentication

User Story 5: SPIKE: Research Two-Factor Authentication

- Spike puede ser investigacion, prototipos, pruebas, etc.

- Meta es poder calcular Story 4

Example - Estimate

(3) User Story 1: Login with Email and Password

(3) User Story 2: Reset Password/Forgot Password

(2) User Story 3: Prevent Brute Force Login Attempts

User Story 4: Two-Factor Authentication

(1) User Story 5: SPIKE: Research Two-Factor Authentication

- Spike puede ser investigacion, prototipos, pruebas, etc.

- Meta es poder calcular Story 4

Example - Tasks

(3) User Story 1: Login with Email and Password

  • Public API interface
  • Update database schema
  • Create Models, Entities and configure Mappings
  • Create Authentication Service
  • Login Layout
  • Login Fields

2h

2h

2h

4h

8h

8h

Example - Acceptance Criteria

  • Acceptance Criteria son las condiciones, o los scenarios que hay que cumplir el User Story
  • Se usa Gherkin

Given (Dada) Alguna Condición

  And (Y) Otra Condicion

When (Cuando) La Acción

Then (Entonces) El Resultado

Example - Acceptance Criteria

Given the user has provided the correct username and password

When they click Login

Then they should be redirected to the dashboard

Given the user has provided incorrect credentials

When they click Login

Then they should see an error message

Given the user has provided incorrect credentials

  And they have attempted 5 times

When they click Login

Then they should see an error message

  And the account should be locked

Example - Acceptance Criteria

Proceso

  • Backlog Refinement
  • Iteration Review / Demo
  • Iteration Evaluation
  • Iteration Planning

Resumen

  • Agile acepta los cambios como parte del proceso
  • Agile produce data
  • Agile nos ayuda a cumplir con nuestra responsabilidad principal
  • User Stories (INVEST)
  • Tasks
    • Especificos
    • Horas
    • Se actualiza diaro

The End

Made with Slides.com