Modelo Kendall

1. Instituto Universitario De Tecnología
“Antonio José De Sucre”
Extensión Guayana
Puerto Ordaz – Estado Bolívar
METODOLOGIA KENDALL Y KENDALL
Bachilleres:
Antonio Batista
Christiam Alfonzo
Eliosmary Torres
Ciudad Guayana, 2 de Diciembre de 2014

2. INDICE
INTRODUCCION........................................................................................................3
METODOLOGIA KENDALL ...................................Error! Bookmark not defined.
COMO TRABAJA KENDALL.................................Error! Bookmark not defined.
ROLES Y RESPONSABILIDADES......................................................................11
FLUJO DE EJECUCION DE KENDALL..............................................................13
ESQUEMA DE COMUNICACIÓN........................Error! Bookmark not defined.5
COMO IMPLEMENTARLO ...................................Error! Bookmark not defined.6
VENTAJAS................................................................................................................20
DESVENTAJAS ......................................................2Error! Bookmark not defined.
CONCLUSION..........................................................................................................22
BIBLIOGRAFIA........................................................................................................23

3. 3
INTRODUCCION
El software es el cerebro, el que permite la almacenar de datos, por lo
que es un componente muy importante, sobre todo en la sociedad actual,
que es altamente dependiente de la tecnología, y con el pasar del tiempo
cada vez más, pero las personas ajenas al tema de la informática no están
conscientes del trabajo que supone realizar este tipo de programas.
Para esto están los programadores, que se encargan de la labor, pero
no solo se trata sobre programadores, ya que estos al igual que cualquier
otro ser humano, son propenso a cometer errores, para disminuir este riesgo,
existe un tema interesante llamado “desarrollo ágil de software” que son
métodos de ingeniería del software basado en el “desarrollo iterativo e
incremental”, donde los requerimientos y soluciones evolucionan mediante la
colaboración de grupos auto organizado.
Se podría decir que estos son como una serie de pasos o consejos
que se siguen para la óptima realización de algún software, un método, pero
este tiene algunas particularidades, las cuales veremos a continuación.

4. 4
METODOLOGIA SCRUM
Scrum es una metodología ágil y flexible para gestionar el desarrollo
de software, cuyo principal objetivo es maximizar el retorno de la inversión
para su empresa .Se basa en construir primero la funcionalidad de mayor
valor para el cliente y en los principios de inspección continua, adaptación,
auto-gestión e innovación.
En Scrum se realizan entregas parciales y regulares del producto final,
priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,
Scrum está especialmente indicado para proyectos en entornos complejos,
donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está
entregando al cliente lo que necesita, cuando las entregas se alargan
demasiado, los costes se disparan o la calidad no es aceptable, cuando se
necesita capacidad de reacción ante la competencia, cuando la moral de los
equipos es baja y la rotación alta, cuando es necesario identificar y
solucionar ineficiencias sistemáticamente o cuando se quiere trabajar
utilizando un proceso especializado en el desarrollo de producto.
Scrum es un modelo de desarrollo ágil caracterizado por:
• Adoptar una estrategia de desarrollo incremental, en lugar de la
planificación y ejecución completa del producto.
• Basar la calidad del resultado más en el conocimiento tácito de las
personas en equipos auto organizados, que en la calidad de los procesos
empleados.

5. 5
• Solapamiento de las diferentes fases del desarrollo, en lugar de
realizar una tras otra en un ciclo secuencial o de cascada.
COMO TRABAJA SCRUM
Esta metódica de trabajo promueve la innovación, motivación y
compromiso del equipo que forma parte del proyecto, por lo que los
profesionales encuentran un ámbito propicio para desarrollar sus
capacidades. Desde el punto de vista de la entidad que maneja los datos,
existen amenazas de origen externo como por ejemplo las agresiones
técnicas, naturales o humanos, sino también amenazas de origen interno,
como la negligencia del propio personal o las condiciones técnicas, procesos
operativos internos. Desde un punto de vista general, dividiríamos los riesgos
entre tres grupos:

6. 6
Planificación de la iteración (Sprint Planning)
La planificación de las tareas a realizar en la iteración se divide en dos
partes:
• Primera parte de la reunión. Se realiza en un timebox de cómo
máximo 4 horas :
El cliente presenta al equipo la lista de requisitos priorizada del
producto o proyecto, pone nombre a la meta de la iteración (de manera que
ayude a tomar decisiones durante su ejecución) y propone los requisitos más
prioritarios a desarrollar en ella .El equipo examina la lista, pregunta al cliente
las dudas que le surgen, añade más condiciones de satisfacción y selecciona
los objetivos/requisitos más prioritarios que se compromete a completar en la
iteración, de manera que puedan ser entregados si el cliente lo solicita.
• Segunda parte de la reunión. Se realiza en un timebox de cómo
máximo 4 horas.
El equipo planifica la iteración, elabora la táctica que le permitirá
conseguir el mejor resultado posible con el mínimo esfuerzo. Esta actividad la
realiza el equipo dado que ha adquirido un compromiso, es el responsable de
organizar su trabajo y es quien mejor conoce cómo realizarlo.
• Define las tareas necesarias para poder completar cada
objetivo/requisito, creando la lista de tareas de la iteración (Sprint Backlog)
basándose en la definición de completado.
• Realiza una estimación conjunta del esfuerzo necesario para realizar
cada tarea.
• Cada miembro del equipo se autoasigna a las tareas que puede
realizar.

7. 7
Ejecución de la iteración (Sprint)
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas
(iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene
que proporcionar un resultado completo, un incremento de producto que sea
potencialmente entregable, de manera que cuando el cliente (Product
Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el
producto esté disponible para ser utilizado. Para ello, durante la iteración el
equipo colabora estrechamente y se llevan a cabo las siguientes dinámicas:
• Cada día el equipo realiza una reunión de sincronización, donde
cada miembro inspecciona el trabajo de los otros para poder hacer las
adaptaciones necesarias, comunica cuales son los impedimentos con que se
encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint
Backlog) y los gráficos de trabajo pendiente (Burndown charts).
• El Facilitador (Scrum Master) se encarga de que el equipo pueda
cumplir con su compromiso y de que no se merme su productividad.
• Elimina los obstáculos que el equipo no puede resolver por sí mismo.
• Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.
Reunión diaria de sincronización del equipo (Scrum daily
meeting)
El objetivo de esta reunión es facilitar la transferencia de información y
la colaboración entre los miembros del equipo para aumentar su
productividad, al poner de manifiesto puntos en que se pueden ayudar unos
a otros.

8. 8
Cada miembro del equipo inspecciona el trabajo que el resto está
realizando (dependencias entre tareas, progreso hacia el objetivo de la
iteración, obstáculos que pueden impedir este objetivo) para al finalizar la
reunión poder hacer las adaptaciones necesarias que permitan cumplir con el
compromiso conjunto que el equipo adquirió para la iteración (en la reunión
de planificación de la iteración).
Cada miembro del equipo debe responder las siguientes preguntas en
un timebox de cómo máximo 15 minutos:
• ¿Qué he hecho desde la última reunión de sincronización? ¿Pude
hacer todo lo que tenía planeado? ¿Cuál fue el problema?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué impedimentos tengo o voy a tener para cumplir mis
compromisos en esta iteración y en el proyecto?
Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la
iteración, donde se actualiza el estado y el esfuerzo pendiente para cada
tarea, asi como con el gráfico de horas pendientes en la iteración.
Demostración de requisitos completados (Sprint Review)
Reunión informal donde el equipo presenta al cliente los requisitos
completados en la iteración, en forma de incremento de producto preparado
para ser entregado con el mínimo esfuerzo, haciendo un recorrido por ellos lo
más real y cercano posible al objetivo que se pretende cubrir.
En función de los resultados mostrados y de los cambios que haya
habido en el contexto del proyecto, el cliente realiza las adaptaciones
necesarias de manera objetiva, ya desde la primera iteración, replanificando
el proyecto.

9. 9
Se realiza en un timebox de cómo máximo 4 horas.
Retrospectiva (Sprint Retrospective)
Con el objetivo de mejorar de manera continua su productividad y la
calidad del producto que está desarrollando, el equipo analiza cómo ha sido
su manera de trabajar durante la iteración, por qué está consiguiendo o no
los objetivos a que se comprometió al inicio de la iteración y por qué el
incremento de producto que acaba de demostrar al cliente era lo que él
esperaba o no:
• Qué cosas han funcionado bien.
• Cuales hay que mejorar.
• Qué cosas quiere probar hacer en la siguiente iteración.
• Qué ha aprendido.
• Cuáles son los problemas que podrían impedirle progresar
adecuadamente. El Facilitador se encargará de ir eliminando los obstáculos
identificados que el propio equipo no pueda resolver por sí mismo.
Notar que esta reunión se realiza después de la reunión de
demostración al cliente de los objetivos conseguidos en la iteración, para
poder incorporar su feedback y cumplimiento de expectativas como parte de
los temas a tratar en la reunión de retrospectiva
Se realiza en un timebox de cómo máximo 3 horas (si la iteración es
mensual).

10. 10
Replanificación del proyecto - Product Backlog Refinement
En las reuniones de planificación de entregas y durante el transcurso
de una iteración (en el Product Backlog Refinement o Grooming), el cliente
va trabajando en la lista de objetivos/requisitos priorizada del producto o
proyecto, añadiendo requisitos, modificándolos, eliminándolos,
repriorizándolos, cambiando el contenido de iteraciones y definiendo un
calendario de entregas que se ajuste mejor a sus nuevas necesidades.
Los cambios en la lista de requisitos pueden ser debidos a:
• Modificaciones que el cliente solicita tras la demostración que el
equipo realiza al final de cada iteración sobre los resultados obtenidos, ahora
que el cliente entiende mejor el producto o proyecto.
• Cambios en el contexto del proyecto (sacar al mercado un producto
antes que su competidor, hacer frente a urgencias o nuevas peticiones de
clientes, etc).
• Nuevos requisitos o tareas como resultado de nuevos riesgos en el
proyecto.
• Para realizar esta tarea, el cliente colabora con el equipo.
• Para cada nuevo objetivo/requisito, conjuntamente se hace una
identificación inicial de sus condiciones de satisfacción (que se detallarán en
la reunión de planificación de la iteración).
• El cliente obtiene del equipo la re-estimación de costes de desarrollo
para completar los objetivos/requisitos siguientes, según la definición de
completado. El equipo ajusta el factor de complejidad, el coste para
completar los requisitos y su velocidad de desarrollo en función de la
experiencia adquirida hasta ese momento en el proyecto.

11. 11
• El cliente re-prioriza la lista de objetivos/requisitos en función de
estas nuevas estimaciones.
Hay que notar que el equipo sigue trabajando con los
objetivos/requisitos de la iteración en curso, (que de hecho eran los más
prioritarios al iniciar la iteración). No es posible cambiar los requisitos que se
desarrollan durante la iteración. En la reunión de planificación de la iteración
el cliente presentará la nueva lista de requisitos para que sea desarrollada.
ROLES Y RESPONSABILIDADES
En Scrum, el equipo se focaliza en construir software de calidad. La
gestión de un proyecto Scrum se centra en definir cuáles son las
características que debe tener el producto a construir (qué construir, qué no y
en qué orden) y en vencer cualquier obstáculo que pudiera entorpecer la
tarea del equipo de desarrollo.
El equipo Scrum está formado por los siguientes roles:
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el
equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio.
El Product Owner escribe historias de usuario, las prioriza, y las coloca en el
Product Backlog.
Sus responsabilidades son variadas:
• Se sitúa como representante de todos los interesados (clientes,
usuarios finales) en el proyecto, tiene capacidad para tomar decisiones
concernientes al mismo y actúa como interlocutor único ante el equipo

12. 12
• Define objetivos del proyecto, así como dirige sus resultados y se
preocupa por la priorización de los requisitos del cliente (ROI –Return Of
Investment-) para formar el Product Backlog . Además, colabora con el
equipo de manera activa, para llevar a cabo la planificación, revisión, etc…
de cada iteración o Sprint.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es
eliminar los obstáculos que impiden que el equipo alcance el objetivo del
sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-
organizan), sino que actúa como una protección entre el equipo y cualquier
influencia que le distraiga. El ScrumMaster se asegura de que el proceso
Scrum se utiliza como es debido. El ScrumMaster es el que hace que las
reglas se cumplan.
Equipo
El equipo tiene la responsabilidad de entregar el producto. Un
pequeño equipo de 5 a 9 personas con las habilidades transversales
necesarias para realizar el trabajo (diseñador, desarrollador, etc).

13. 13
FLUJO DE EJECUCION DE SCRUM
Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un
proyecto. Esto se llama “daily standup”. El scrum tiene unas guías
específicas:
• La reunión comienza puntualmente a su hora. A menudo hay
castigos -acordados por el equipo- para quién llega tarde (por ejemplo:
dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)
• Todos son bienvenidos, pero solo los “cerdos” pueden hablar.
• La reunión tiene una duración fija de 15 minutos, de forma
independiente del tamaño del equipo.
• Todos los asistentes deben mantenerse de pie (esto ayuda a
mantener la reunión corta)
• La reunión debe ocurrir en la misma ubicación y a la misma hora
todos los días.
Durante la reunión, cada miembro del equipo contesta a tres
preguntas:
• ¿Qué has hecho desde ayer?
• ¿Qué es lo que estás planeando hacer hoy?
• ¿Has tenido algún problema que te haya impedido alcanzar tu
objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

14. 14
Scrum de Scrum
Cada día normalmente después del “Daily Scrum”
• Estas reuniones permiten a los grupos de equipos discutir su trabajo,
enfocándose especialmente en áreas de solapamiento e integración.
• Asiste una persona asignada por cada equipo.
La agenda será la misma como del Daily Scrum, además de las
siguientes cuatro preguntas:
• ¿Qué ha hecho tu equipo desde nuestra última reunión?
• ¿Qué hará tu equipo antes que nos volvamos a reunir?
• ¿Hay algo que demora o estorba a tu equipo?
• ¿Estás a punto de poner algo en el camino del otro equipo?
Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de
Planificación del Sprint” se lleva a cabo.
• Seleccionar que trabajo se hará
• Preparar, con el equipo completo, el Sprint Backlog que detalla el
tiempo que tomará hacer el trabajo.
• Identificar y comunicar cuánto del trabajo es probable que se realice
durante el actual Sprint
• Ocho horas como límite

15. 15
Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión
de Revisión del Sprint” y la “Retrospectiva del Sprint”
Reunión de Revisión del Sprint(Sprint Review Meeting)
• Revisar el trabajo que fue completado y no completado.
• Presentar el trabajo completado a los interesados (alias “demo”)
• El trabajo incompleto no puede ser demostrado
• Cuatro horas como límite
Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint,
en la cual todos los miembros del equipo dejan sus impresiones sobre el
sprint recién superado. El propósito de la retrospectiva es realizar una mejora
continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
ESQUEMA DE COMUNICACIÓN
La forma más eficiente y efectiva de comunicar información de ida y
vuelta dentro de un equipo de desarrollo es mediante la comunicación cara a
cara.
Sprint Planning
• Se priorizan las actividades contenidas en el Product BackLog.
• Se define la meta.

16. 16
Sprint Planning
• Reunión previa al Sprint en rint en donde el Product Owner muestra
las actividades contenidas en el Product Backlog, ya priorizadas, el Scrum
• Team en conjunto con el Scrum Master determinan las actividades
que contendrá el siguiente Sprint Backlo rint Backlog.
COMO IMPLEMENTARLO
Revisión del Sprint
Al final del Sprint haz una reunión para revisar el Sprint (Sprint
Review) . Invita a todo el equipo. Invita a todos los tomadores de decisiones

17. 17
del negocio. Invita a tomadores de decisiones importantes incluyendo
ejecutivos cuando sea apropiado.
Revisa lo que fue entregado con el Sprint. Haz una demostración del
software. Si es completo, software funcional antes de la entrega final o si es
un trabajo en progreso dentro de un proyecto de varios Sprints, haz la
demostración de lo que se ha completado dentro del Sprint. Deja que los
miembros del equipo demuestren las áreas en las que han trabajado.
El propósito de la revisión del Sprint es triple:
• Permite a los miembros del equipo mostrar lo que han logrado y
demostrar su contribución al producto.
• Permite a todos los tomadores de decisión ver lo que se ha hecho y
proveer valiosa retroalimentación en una base regular, mientras aun hay
tiempo de tomarla en consideración.
• Ayuda al equipo a permanecer enfocado en el tiempo del Sprint. -
nadie quiere aparecerse en la revisión del Sprint con nada útil que demostrar.
Retrospectiva del Sprint.
Siguiendo la revisión del Sprint, haz una reunión de retrospectiva.
Invita a todo el equipo. Invita al propietario del producto. Pero esta reunión no
es para todos los tomadores de decisión. Típicamente puede seguir
inmediatamente después de la revisión del Sprint.
El propósito de la retrospectiva del Sprint es reflexionar sobre como
fueron las cosas durante el Sprint. Es una oportunidad para que el equipo
discuta el Sprint y consideren como se pueden mejorar las cosas.
Juntos el equipo debería:

18. 18
• Revisar el gráfico de seguimiento: ¿Cómo fue? ¿Entregó el equipo lo
que se había comprometido en entregar al inicio del Sprint? Anotar las horas
empleadas en una hoja de cálculo para que la tasa de éxito del equipo pueda
ser graficada sobre el tiempo, para ver si está mejorando o empeorando.
Esta es una herramienta para que el equipo mida su progreso. No es una
medida para gestión.
• Revisa la "velocidad" del equipo: La velocidad es el número de
puntos estimados en la pila del producto original, para los items completados
en el Sprint. Solamente los items 100% completos y entregados, firmados, en
el software cuentan para la velocidad del equipo.
De nuevo, grafica esto para que la velocidad del equipo pueda ser
monitoreada sobre el tiempo, así el equipo puede ver si está entregando más
o menos en el transcurso del tiempo. La velocidad gradualmente se
establecerá cerda de una norma y entonces puede ser usada en la
planificación del Sprint como una medida de cuanto puede realmente un
equipo lograr, basado en la trayectoria.
• Discute lo que fue bien: (intenta asegurarte que se repita la siguiente
vez).
• Discute que podría haber ido mejor: (intenta entender por qué) .
• Decide lo que el equipo hará diferente en el siguiente Sprint: (Intenta
tomar un par de puntos de acción que en realidad puedan ser hechos de
forma diferente en el siguiente Sprint).

19. 19
Repetir
El equipo está ahora armado con valiosa información - sobre el
producto, sobre el rendimiento y sobre algunos impedimentos en su entorno,
ejemplo:
• Cómo se ve el software después del último Sprint.
• Retroalimentación sobre el producto desarrollado hasta entonces.
• Hasta qué punto el equipo capaz de entregar lo que se había
comprometido en la planificación del Sprint.
• La velocidad del equipo y lo que es alcanzable en una iteración
típica.
• Lo que fue bien.
• Lo que no fue tan bien.
• Lo que será hecho distinto para avanzar.

20. 20
Todo lo que le queda al equipo, es repetir el proceso, con el mayor
conocimiento ganado desde lo anterior.
De modo realista toma 3 o 4 Sprints para que el equipo entre en ritmo.
Para aplicar las mejoras y que sean usadas en el proceso. Para que la
velocidad se estabilice.
VENTAJAS
• Se obtiene software lo más rápido posible y este cumple con los
requerimientos más importantes.
• Se trabaja en iteraciones cortas, de alto enfoque y total
transparencia.
• Se acepta que el cambio es una constante universal y se adapta el
desarrollo para integrar los cambios que son importantes.
• Se incentiva la creatividad de los desarrolladores haciendo que el
equipo sea auto administrado.

21. 21
• Se mantiene la efectividad del equipo habilitando y protegiendo un
entorno libre de interrupciones e interferencias.
• Permite producir software de una forma consistente, sostenida y
competitiva.
• Las reuniones se dedican a inconvenientes recientes, evitando el
estancamiento.
DESVENTAJAS
• Requiere delegar responsabilidades al equipo, incluso permite fallar
si es necesario.
• Es una metodología que difiere del resto, y esto causa cierta
resistencia en su aplicación para algunas personas.

22. 22
CONCLUSIÓN
Después de una visión general de esta metodología, queda claro que
Scrum es muy útil para el desarrollo de proyectos ágiles software, en
particular para aquellos en constante cambio y con una necesidad de
feedback por parte del cliente constante.
Por otra parte, se trata de una metodología considerada como un
marco de trabajo, por lo que resulta en muchos casos imprescindible utilizarla
en conjunto con otras metodologías software, sobre todo con XP (eXtreme
Programming).

23. 23
BIBLIOGRAFÍA
http://es.wikipedia.org/wiki/Archivo:Agile_Software
http://es.wikipedia.org/wiki/Scrum
http://www.monografias.com/trabajos91/metodologias-desarrollo-agil-
mele-scrum/metodologias-desarrollo-agil-mele-
scrum.shtml#ixzz3KTHnFf9y