5 Prácticas Esenciales De Agile

Documentación:

Sólo hacer la documentación mínima para poder continuar con el trabajo

Documentación sobre lo que ya se tiene

Escribir bien software - capaz de ser leído sin capacidad de comentarios

Los contratos son medidas defensivas

Forma de contratos que acepten el cambio

Aceptar cambios es una ventaja competitiva

Importante:

Satisfacer las necesidades del cliente en tiempo

______________________

SCRUM

Administración de Proyectos Confiable

OBJETIVO Entregar el valor de negocio lo antes posible

En todas las iteraciones se entrega código que funcione

Al entregar al cliente se provocan cambios

ROLES

Scrum Master - Es quien guía los sprints

Product Owner

Development Team

Duración:

Sprints, son iteraciones recomendadas de 2 semanas en México

En cada sprint hay algo entregable al usuario

JUNTA INICIAL (se deja pendiente para después)

¿Qué tenía que hacer ayer?

¿Qué tengo que hacer hoy?

¿Qué problemas tuve?

PRODUCT BACKLOG

Lista priorizada de los elementos de los requisitos hasta unidades individuales y construibles en poco tiempo

HISTORIAS DE USUARIO (USER STORIES)

Se hace la estimación del product backlog al inicio

Es decir, se calcula el tiempo por cada uno de los elementos

Esto se hace con el usuario presente para que conozca los tiempos y los alcances de cada sprint

INICIO DE IMPLEMENTACIÓN

Uso de sprints

Al finalizar el sprint sentar frente a la máquina: ¿está bien, te gustó, quieres algún cambio?

Razón simple: El usuario siempre va a querer cambios

Lo que se hace con el usuario es: se aceptan cambios. Aquí decides si lo pones al principio o lo pones al final. Haré la iteración.

La mayoría de la gente en un proyecto Ágil consigue la aceptación del proyecto antes del número de iteraciones.

__________

USER STORIES

QUÉ ES

Requerimientos, Comunicación y Retroalimentación - Sustitutos de casos de uso

"Es algo que el cliente quiera que el sistema haga. Las historias deben de ser estimables de uno a cinco semanas ideales de programación. Las historias deben ser verificables."

"Las historias necesitan ser de un tamaño que puedas construir algunas de ellas en una interacción".

"Las historias no tienen necesariamente que representar valor de negocio al cliente, pero si tienen que representar progreso. Sólo el cliente sabe que se considera un avance, así que ellos eligen qué se construye".

QUÉ SON

Cubetas de tamaño arbitrario. Tanto tiempo, 3 días, 1 semana, 2 semanas, 3 semanas, 4 semanas.

Las historias de usuario son precios unitarios. Es convertir el desarrollo de software en algo que tenga el equivalente a precios unitarios. Los ladrillos son todos del mismo tamaño, los blocks son todos del mismo tamaño, independientemente a quién se las compres.

Mecanismo para que lo que vas a hacer sea del mismo tamaño.

QUÉ SON

Son un truco para crear una iteración

TÉCNICA SENCILLA Y EFECTIVA

Para dividir los problemas en cosas más pequeñas

Se escriben en fichas

Describen la interacción con el sistema desde el punto de vista del usuario

"El usuario oprime el botón de Nuevo Widget, selecciona el instrumento y escribe los detalles al sistema. Al completar, oprime aceptar".

Se debe de asociar un título con un rol por cada historia, como si estuvieran en post-it.

DEFINICIÓN COLABORATIVA - 1:19:30

Al momento de definir la historia de usuario,

En el proceso de partirla se aprende más el requerimiento

Parte de adelante especificación

Parte de atrás, cómo el usuario comprueba el funcionamiento

USER STORIES

La prueba es el requerimiento

Se necesitan especificar pruebas de aceptación para que el alcance no se aumentó en el desarrollo

Con un formato simple:

Cuando hago esto, espero tal resultado

Se debe de aspirar a automatizar estas pruebas de aceptación

Puede que se necesiten especificar más pruebas en el transcurso de la interacción

Se recomienda trabajar con el equipo de QA para verificar y dar seguimiento a las pruebas (unión Test Driven Development)

______________________________

TEST DRIVEN DEVELOPMENT

CALIDAD INCLUIDA DESDE EL INICIO

Popularizado por Kent Beck en XP (eXtreme Programming)

Técnica o práctica de programación que involucra escribir repetidamente casos de prueba y luego escribir solamente el código necesario para aprobar dichos casos

Es un enfoque de desarrollo que combina TFD (Test-First Development) y Refactoring

TDD = TFD + Refactoring

TFD significa diseñar primero una prueba antes de escribir una línea de código que satisfaga dicha prueba

Refactoring significa mejorar el código existente, no significa agregar funcionalidad

ROLES PARTICIPATIVOS

Los desarrolladores preparan pruebas unitarias antes de la construcción del software

Test-Driven Development (TDD)

Las pruebas se automatizan

Comúnmente se usa xUnit Framework

Deben correr al 100% antes de proceder

El cliente define las pruebas de aceptación

Escritas por el cliente

Actúan como "contratos"

...