Please enable JavaScript.
Coggle requires JavaScript to display documents.
Desarrollo de Software Ágil - Coggle Diagram
Desarrollo de Software Ágil
Una filosofía con un conjunto de lineamientos de desarrollo.
Pone en énfasis las
satisfacciones del cliente
y en la
entrega rápida de software incremental
, los
equipos pequeños
y muy motivados para concretar el proyecto, los
métodos informales
, los
productos de trabajo con mínima ingeniería de software
y la
sencillez
general del desarrollo
Los lineamientos de desarrollo
enfatizan la entrega
sobre el análisis y el diseño y la
comunicación activa-continua
entre los desarrolladores y clientes.
Actividades estructurales fundamentales (
comunicación, planeación, modelado, construcción, despliegue
). Son el
conjunto mínimo de tareas
que lleva la equipo del proyecto hacia la construcción y entrega.
El único
producto
del trabajo que importa es un
"incremento del software" operativo
que se entregue al cliente en la fecha acordada.
Constratar
maniobridad y la adaptabilidad
y constituyen un rango de métodos basados en el
desarrollo iterativo e incremental
en donde se diseña e implementa el software.
Implican directamente a los
usuarios
, el
participa activamente
durate el desarrollo del sistema.
SCRUM
Metodología ágil de gestión de proyectos, su objetivo es elevar al maximo la productividad del equipo.
Características
Solo abarca
prácticas de gestión
Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione.
Produce
resultados en periodos muy breves de tiempo
mediante iteraciones
Delega la responsabilidad de decidir la mejor manera de trabajar en el equipo para incrementar la productividad
Da gran protagonismo a las
ceremonias
(Dailys)
Sus raíces teóricas estan en las teorías de la
autoorganización
Ideal para proyectos con un rápido
cambio de requerimientos
SPRINT
base del desarrollo del scrum, periodo de corta duración que va desde 2 a 4 semanas, que debe finalizar con un prototipo operativo/potencialmente entregable. Al inicio se definen la US y tareas a realizar durante ese periodo de tiempo.
Para poder entender bien las actividades y el producto, antes se debe describir que es una Historia de Usuario.
HISTORIA DE USUARIO
representación de un requisito escrito en una frase utilizando el lenguaje común del usuario. Agregando valor particular al cliente
utlidad
proviene de ser utilizadas en las metodologías de desarrollo ágiles para la identificación de requisitos, acompañadas de las discusiones con los usuarios y las pruebas de validación o criterio de aceptacion.
¿qué son?
explicaciones generales e informales de una función de software escrita desde una perspectiva del usuario final o cliente. Encargadas de determinar el qué del sistema.
forma
suelen identificarse ya que deben responder a tres preguntas:
¿Quién se beneficia? -
Como
[Rol del usuario]
¿Qué se quiere? -
Quiero
[Objetivo-funcionalidad]
¿Cuál es el beneficio (Motivo)? -
Para
[Beneficio]
ROLES
(se trata de quién)
Product Owner (PO)
Dueño del producto. Se encarga de definir y ajustar funcionalidades del producto, además de ser el responsable de su rentabilidad en base a su priorización de funcionalidades de acuerdo con el valor del mercado. Dicho esto es capaz de aceptar o rechazar los resultados del trabajo del equipo.
Scrum Master
Responsable de la gestión del proyecto. Se asegura que el equipo sea funcional y productivo, promoviendo los valores y prácticas del scrum, remueve impedimentos y es un escudo del equipo ante interferencias externas. Es el único que puede cancelar un sprint.
Team
Es el equipo de sistemas. Este es multi-funcional, y sus miembros deberán ser de tiempo completo. Además son autoorganizativos y autogestionados. Se encargan de todas las actividades relacionadas con el producto, responsables de transformar el backlog de la iteración (sprint backlog) en un incremento de la funcionalidad del software. Solo puede haber cambio de miembros entre los Sprints, no durante el trayecto de uno.
ACTIVIDADES
(cómo se va a llevar a cabo)
Planificación del release
Es la planificación donde se establece la suración de cada sprint, el producto backlog y la priorización de este y los releases.
Releases
: conjunto de funcionalidades (software) que se entrega al cliente.
Planificación del sprint
Realizada al comienzo de cada sprint. Define una lista de historias de usuario (sprint backlog) que serán analizadas, desarrolladas y testeadas. Las cuales deberán ser finalizadas y entregadas durante el sprint por el grupo, donde se seleccionan del
Product backlog re-priorizado
. Cada US tiene un valor que las prioriza, aquí se establece el valor de cada una.
Reuniones diarias (Dailys)
Reuniones diarias cortas, de 15 a 20 mnutos, donde cada integrante plantea: que se hizo, que se va a hacer y que problemas se presentaron.
Revisión del sprint
Ya finalizado el sprint, se realiza esta actividad, donde se deberá entregar algo de funcionalidad del sistema demostrándole al PO los avances logrados y se muestra el sistema en funcionamiento con sus US cumplidas.
Restrospectiva del sprint
Realizado al final del proyecto, donde se revian eventos y aprender mejor de la experiencia. Sirviendo así para que los integrantes den su opinión sobre el sprint y así mejorar la gestión como grupo sprint a sprint.
Se analiza
: que se hizo bien, mal y que se puede mejorar
ARTEFACTOS
(es la salida, el
qué
del producto)
Product Backlog (Pila de producto)
Al inicio es una definición de los requisitos que servirá para la planificación del proceso, si bien no es una lista completa y definitiva, es un listado vivo y dinámico que puede actualizarse durante el avance del desarrollo del sistema, incorporando las constantes necesidades del sistema y manteniendosé durante todo su ciclo de vida.
Es priorizado por el PO.
Se vuelve a priorizar al comienzo de cada sprint.
Expresados de forma que tomen valor para cada usuario del producto.
Considera las US
Sprint Backlog (Pila de sprint)
Se seleccionaun conjunto de US del Product Backlog, donde luego se describirán las US elegidas para ese sprint definiendo el detalle de tareas que se van a desarrollar según los requisitos señalados.
Tanto las US como las tareas comprenden una estimación y duración.
Finalizado cada sprint se busca un incremento en la funcionalidad.
Producto software instalable (incrementos)
Desarrollo de un sistema o producto puesto en producción con la documentación necesaria para instalarlo y usarlo en la organización, negocio o contexto del sistema.