SISTEMAS DE INFORMACION RESUMEN PARCIAL 1

TEMAS:

DER
SCRUM
KANBAN
KANBAN vs SCRUM
Principios Agiles(Manifiesto)
Ciclo De Vida Clsico Vs SCRUM

DER (DIAGRAMA ENTIDAD-RELACIN)

QU ES?

El Diagrama Entidad Relacin(o tambin conocido como DER) es una herramienta que permite
modelar las entidades relevantes de un sistema as como sus interrelaciones y propiedades.

ELEMENTOS

En un DER, cada entidad se representa mediante un rectngulo, cada relacin mediante un rombo
y cada dominio mediante un crculo. Los dominios son un conjunto de atributos que se asignan a
una entidad. Cada entidad tiene un atributo clave que las diferencia de las dems, estos
atributos claves se los representa subrayndolos.

CARDINALIDAD

Es el nmero de entidades con la cual otra entidad puede relacionarse. Existen diferentes tipos de
cardinalidad:

1a1
1aN
Na1
NaN

TENER EN CUENTA

Marcar palabras claves.

nico verbo en el rombo.
Las palabras claves tienen que ser nmeros o nmeros y letras.
SCRUM
Es un mtodo gil de trabajo en el que se busca facilitar la creacin de software realizando ciclos
cortos (llamados SPRINT) los cuales tiene una duracin de aproximadamente una semana.

En scrum se busca el trabajo en equipos por lo tanto tiende a ser equipos chicos (de al menos 9-10
personas). Se lo llama Equipo Scrum, tiene la responsabilidad de cumplir con los objetivos de cada
sprint y entregar el producto en condiciones.

En estos grupos se incluye al Dueo del Producto (o Product Owner) que es un empleado del
cliente que trabajara junto a nosotros, este se asegura de que el equipo Scrum trabaje de forma
adecuada desde la perspectiva del negocio cumpliendo con los trminos acordados.

Ademas en estos grupos debe de haber asignado un Scrum Master quien ser el encargado de
coordinar el trabajo y eliminar los obstculos que impiden que el equipo alcance el objetivo del
sprint. Llevar a cabo la tarea de LIDER haciendo que las reglas se cumplan pero NO DE JEFE!

El sprint backlog es el subconjunto de

requisitos que sern desarrollados durante
el siguiente sprint. Se utilizan las etiquetas
para definir tareas/objetivos a realizar,
estos van posicionadas en una columna en
la que se da una idea de donde se
encuentra esa tarea (pendiente/en
proceso/finalizados). Las tareas nunca son
asignadas, son tomadas por los miembros
del equipo del modo que les parezca
adecuado.

En el Burndown los tickets tienen que

disminuir con el paso de los das/sprint,
en caso de que estos aumenten puede
ser perjudicial para el equipo ya que
puede retrasar la entrega del producto
final. En pocas palabras, si el grafico
disminuye se est realizando un buen
trabajo, si el grafico aumenta hay un
problema serio.
El product backlog es el conjunto de todos los requisitos de proyecto, el cual contiene
descripciones genricas de funcionalidades deseables y priorizadas segn su retorno sobre la
inversin. Es abierto y solo puede ser modificado por el product owner. Contiene estimaciones
realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo
requerido. Esta estimacin ayuda al product owner a ajustar la prioridad de las diferentes tareas.
Por ejemplo, si dos caractersticas tienen el mismo valor de negocio la que requiera menor tiempo
de desarrollo tendr probablemente ms prioridad, debido a que su retorno sobre la inversin
ser ms alto

KANBAN
Se define como un sistema de produccin altamente efectivo y eficiente. El origen de esta
metodologa est en los procesos de produccin just-in-time (JIT) ideados por Toyota, en los que
se utilizaban tarjetas para identificar necesidades de material en la cadena de produccin.

Actualmente, el trmino Kanban ha pasado a formar parte de las llamadas metodologas giles,
cuyo objetivo es gestionar de manera general cmo se van completando las tareas.

Kanban es una palabra japonesa que significa tarjetas visuales, donde Kan es visual, y Ban
corresponde a tarjeta.

Las principales ventajas de esta

metodologa es que es muy fcil de utilizar,
actualizar y asumir por parte del equipo.
Adems, destaca por ser una tcnica de
gestin de las tareas muy visuales, que
permite ver a golpe de vista el estado de
los proyectos, as como tambin pautar el
desarrollo del trabajo de manera efectiva.
KANBAN VS SCRUM
SCRUM - VENTAJAS

Organiza el equipo en pequeos equipos auto gestionados y multidisciplinarios

Organiza el trabajo en una lista de entregables pequeos y concretos
Organiza el tiempo en iteraciones cortas, con cdigo demostrable, al terminar cada
iteracin
Optimiza la planificacin de versiones y actualiza las prioridades en colaboracin con el
cliente
Optimiza el proceso en cada iteracin

KANBAN - VENTAJAS

Visualiza el flujo de trabajo: al separar el trabajo en items, escribir cada item en una
tarjeta de la pizarra Kanban y utilizar columnas que ilustran el estado de la tarjeta.
Limita el trabajo en progreso: es recomendable asignar explicitamente cuantos items
podemos tener en cada estado, un estado es una columna de la pizarra de Kanban.
Mide el tiempo de iniciacin de un item: con el objetivo de optimizar ese tiempo

KANBAN VS SCRUM

Ambas son herramientas de procesos, pero Scrum es ms prescriptivo que Kanban.

Scrum prescribe roles y no as Kanban.
Scrum est basado en iteraciones, en Kanban, eliges iterar si te sirve para cerrar una
versin.
En Scrum, se usa el backlog del sprint para visualizar las tareas, entonces, si un equipo
tiene una velocidad promedio de 10, usualmente, no pondr ms de 10 puntos de historia
en un sprint. En Scrum, el trabajo en progreso (WIP - work in progress) es limitado por la
unidad de tiempo. En Kanban, el WIP es limitado por estados del flujo de trabajo.
Ambos son empricos, es decir, que necesitamos experimentar con el proceso y adaptarlo
a nuestro contexto. Uno de los puntos a tratar, en Kanban, es el lmite de trabajo en
progreso (WIP), entonces, podemos experimentar comenzando con un lmite de 1. O bien,
si trabajamos en pareja y el equipo Kanban es de 4 personas, usualmente podemos tener
2 items en progreso.
Scrum, en general, no hace cambios en medio de una iteracin. En el caso de Kanban,
podemos agregar un nuevo item en alguna de las columnas, pero si estamos en el lmite,
tenemos que remover algn item de esa columna.
En Scrum, cuando termina el sprint, los items se sacan de la pizarra y comienza un nuevo
sprint. En Kanban, los items persisten hasta que estn terminados.
En Scrum, se tiene un equipo con todos los conocimientos necesarios para completar los
items de la iteracin. En Kanban, no necesariamente hay un nico equipo relacionado a un
item.
 Ambos procesos estn basados en el desarrollo incremental.
En Scrum, los equipos estiman. En Kanban, lo decide el equipo.
Ambos procesos trabajan simultaneamente sobre mltiples productos. En Scrum, con
diferentes pizarras. En Kanban, se diferencian los productos en la pizarra.
Ambos procesos estn alineados con los principios y valores de "Lean" y el "Manifiesto
Agil".
Scrum prescribe priorizar el backlog. En Kanban, podemos elegir algn esquema de
prioridades.
Scrum prescribe reuniones diarias de no ms de 15 minutos. En Kanban, los equipos las
hacen de igual manera.
Scrum prescribe el grfico de trabajo restante, por cada iteracin. En Kanban no es un
grfico que tenga que usarse.

PRINCIPIOS DEL MANIFIESTO AGILES

1. Nuestra principal prioridad es satisfacer al cliente a travs de la entrega temprana y
continua de software de valor.
2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los
procesos giles se doblegan al cambio como ventaja competitiva para el cliente.
3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta
un par de meses, con preferencia en los periodos breves.
4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a
travs del proyecto.
5. Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el
respaldo que necesitan y procurndoles confianza para que realicen la tarea.
6. La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un
equipo de desarrollo es mediante la conversacin cara a cara.
7. El software que funciona es la principal medida del progreso.
8. Los procesos giles promueven el desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
9. La atencin continua a la excelencia tcnica enaltece la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
11. Las mejores arquitecturas, requisitos y diseos emergen de equipos que se auto-
organizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su
conducta en consecuencia.