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

Agile
By Jared Stark
Agile
- 293