28 mayo, 2014

Como escribir historias de usuario

Qué son las historias de usuario

Las historias de usuario son una representación simple y breve de las funcionalidades o características deseadas en nuestro sistema o producto. Representan los requisitos del sistema como los vería un usuario del sistema y normalmente se escriben en tarjetas de papel tipo kardex como si los hubiera escrito el mismo usuario (aunque no es obligación escribirlas en papel y para algunos equipos de trabajo será mas conveniente usar alguna aplicación que las gestione)
Algunos ejemplos de historias de usuario pueden ser:

"Como Administrador puedo asignar roles a los usuarios para controlar el acceso a las aplicaciones"

"Como Supervisor quiero seleccionar un archivo desde el escritorio para adjuntar a una solicitud"

"Como vendedor puedo iniciar un pedido de ventas"


Cómo escribir historias

Con el fin de obtener historias bien redactadas y que sean eficaces, las historias de usuario deben ser expresadas de forma muy breve, que no superen las tres lineas de texto, y ademas deben seguir una estructura definida:

"Como <rol o usuario> puedo/quiero <hacer algo> para/por qué <algo>"

Como se observa arriba, esta estructura se forma de tres partes:
  1. Como <rol o usuario>: Identifica al usuario, tipo de usuario o rol que hace uso de la funcionalidad o característica.
  2. Puedo/Quiero <hacer algo>: Describe breve mente la funcionalidad o característica como lo ve el usuario.
  3. Para/Por qué <algo>: Es opcional para algunas historias y describe el motivo de hacer uso de la funcionalidad o característica.

Obtener historias desde casos de uso

Idealmente las historias de usuario se pueden obtener desde los casos de uso, donde cada ovalo que representa un caso se profundizará en una historia de usuario.
Por ejemplo en un diagrama donde existen los casos "asignar roles a los usuarios", "seleccionar un archivo desde el escritorio", "iniciar un pedido de ventas" y se relacionan con actores Administrador, Supervisor o Vendedor, podemos extraer rápidamente las historias.


26 mayo, 2014

Introducción a Scrum

Que es Scrum?

Scrum es un marco de referencia o marco de trabajo para manejar procesos, y se puede aplicar en muchas actividades que van mas allá del desarrollo de software
En nuestro caso, enfocados en el desarrollo de software, podemos definir Scrum como una forma ágil de manejar proyectos de software.

Desarrollo Scrum: En que consiste?

  • Progreso del proyecto mediante una serie de Sprints
  • Reuniones de planeacion (Planning meetings)
  • Scrum diario (Daily Scrum)
  • Reuniones diarias (Daily Stand Up Meetings)
  • Revision del Sprint (Sprint Reviews)
Scrum consiste en hacer progresar el proyecto mediante una serie de Iteraciones de desarrollo llamadas Sprints, los cuales pueden tener una duración de entre 2 a 4 semanas, dando preferencia a los periodos mas cortos de tiempo.

Al comienzo de cada Sprint, se realizan reuniones de planeación llamadas Planning Meetings, en las cuales se seleccionan los objetivos de mayor prioridad al momento de comenzar el nuevo Sprint y se dividen en tareas mas pequeñas que ayudan a completar cada objetivo. Al final de cada Sprint se debe tener un producto o sistema en un estado potencialmente entregable.

Cada día en el Sprint es el Scrum Diario, una pequeña iteración de desarrollo llamada Daily Scrum y al comienzo de cada una de estas iteraciones diarias se realiza una reunión breve, llamada Daily Stand Up Meeting, la cual se debe realizar de preferencia todos los días a la misma hora, estando los asistentes de pie y con una duración máxima de 15 minutos (para favorecer la brevedad y comunicación temprana).

En la reunión diaria pueden participar Desarrolladores, Scrum Master, Product Owner y algún invitado especial importante para el progreso del proyecto, pero solo los participantes comprometidos con el desarrollo pueden hablar. En esta reunión los comprometidos deben responder 3 preguntas:
  1. ¿Que has hecho desde ayer?
  2. ¿Tienes algún problema que te impida continuar adelante?
  3. ¿Que piensas hacer hoy?
Al finalizar el Sprint de 2 o 4 semanas, el equipo de trabajo se reúne para hacer una revisión retrospectiva donde se evalúan los avances y se piensa en que se puede mejorar para la siguiente iteración.

Proceso Scrum: Artefactos principales

El proceso Scrum involucra un conjunto de artefactos principales:
  1. El producto mismo
  2. Product Backlog
  3. Sprint Backlog
  4. Sprint Burn Down Chart
  5. Release Burn Down Chart
El producto mismo obviamente es la razón de ser del proceso, es un artefacto y es por supuesto el más importante. El resultado de cada iteración es un incremento de este producto.

El segundo artefacto es el Product Backlog, que es una lista de funcionalidades o características deseables del producto. En palabras simples es la lista de todas las historias de usuarios que forman el todo del producto deseado.

El Sprint Backlog es una lista de todas las tareas que se deben realizar para completar las funcionalidades o historias de usuario seleccionadas para cada Sprint o iteración.

Para medir el progreso del Proceso Scrum existen dos artefactos, el Sprint Burn Down Chart y el Release Burn Down Chart, estos artefactos son básicamente unos gráficos que se van actualizando cada dia del proceso con la estimación de horas restantes de desarrollo, cada miembro del equipo puede estimar y re-estimar el tiempo para la tarea que realiza actualmente, así a medida que se progresa en el desarrollo de una tarea, esta estimación es cada vez menor, lo que va produciendo un gráfico con valores descendientes en el tiempo.

Proyecto Ágil Scrum: Roles principales

En Scrum existen tres roles principales
  1. Scrum Master
  2. Product Owner
  3. Scrum Team
El Scrum Master es el coach del Scrum Team, es el arbitro que vela por que se cumplan las reglas de Scrum y es quien ayuda los practicantes de Scrum a obtener su máximo nivel de rendimiento. 
A diferencia de otros métodos de gestión de proyecto, en Scrum no existe el Project Manager o Jefe de Proyecto y el Scrum Master no provee dirección diaria al equipo ni asigna tareas de forma individual. El Scrum Master protege al equipo de las distracciones externas y le ayuda a mantenerse enfocado en su objetivo y ser mejor cada vez.

El Product Owner trabaja para dirigir al Scrum Team hacia la meta correcta, creando una visión convincente del producto y transmitiendola al equipo mediante el Product Backlog. El Product Owner es el responsable de priorizar el backlog durante el desarrollo Scrum, a medida que se aprende del sistema que se está construyendo.

El ultimo rol es el Scrum Team, es el equipo de desarrollo, el automóvil que está listo para partir en la dirección que sea puesto, el Product Owner es el conductor del automóvil que se asegura de siempre ir en la dirección correcta, y el Scrum Master es el mecánico que mantiene el auto en buen estado para su mejor rendimiento.

En Scrum, a diferencia de otros métodos de gestión de proyectos, el Team es visto como un todo, un grupo sin jerarquías como Jefe de proyecto, Desarrollador Senior o Junior, etc., mas bien pone énfasis sobre las personas y sus habilidades, talentos y aptitudes, siendo todos los actores comprometidos con el resultado.

10 mayo, 2014

Principios del Manifiesto Agil

Estos son los principios del manifiesto agil:

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.

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.

Extraido de la funete original: