Trabajo final

Este es el trabajo que se realizó en la actividad final muchas gracias a todos por su apoyo

• Artículo
• Material para actualizar el blog
• Preguntas lección evaluativa
• Documentos entregados por evaluación y seguimiento

Lección Evaluativa

Entrega trabajo colaborativo 3

Este es el resultado del trabajo colaborativo 3

• Cronograma
• Mapa conceptual
• Ensayo
• Consolidado
• Archivo en .rar

Estos son los archivos que se entregan

• Archivo de Cmaptools
• Actividad A
• Actividad B
• Actividad C
• Archivo en winrar

DECÁLOGO DE BERNAL

CONCEPTO	DESCRIPCIÓN
Cronología (¿Cuándo?)	El grupo Repromundo se ve en la necesidad de implementar correctamente las herramientas tecnológicas ya que se encuentran algunas falencias, ya que el soporte técnico a algunos usuarios se vuelve un proceso repetitivo y genera retraso en muchos procesos en la empresa.
Axiomas (¿Quién?)	El jede de departamento de desarrollo y los ingenieros de sistemas de la empresa identifican el problema, que los usuarios están tornando repetitivo muchos de los procesos de los cuales ya han sido capacitados.
Método (¿Cómo?)	Se realiza una investigación, ya que muchas veces las personas encargadas de realizar el soporte a usuarios que habían recibido capacitaciones se retrasaban en sus actividades cotidianas.
Ontología (¿Qué?)	Idear una forma en que el departamento de desarrollo e ingenieros impidan que los usuarios realicen procesos en los cuales ya fueron capacitados retrasando las actividades cotidianas de la empresa y de otros proyectos.
Tecnología (¿Con qué?)	Se implementara una aplicación Android la cual podrá ser descargada por los usuarios a sus dispositivos (Celulares, Tablet´s, PC o Portátiles) según su necesidad, dicha aplicación se conectar a una Date Base la cual será alimentada por los ingenieros.
Teleología (¿Para qué?)	Evitar que los usuarios realicen procesos en los cuales ya fueron capacitados.
Topografía (¿Dónde?)	En el grupo Repremundo se encentra ubicado en Bogotá DC está consolidada como un prestador de servicios en la cadena logística, a través de talento humano con soporte en estructura física y tecnología.
Ecología (¿Contra qué?)	Cuando la empresa realice una intervención con el soporte a los usuarios podrán ofrecer un mejor rendimiento en sus actividades cotidianas tanto para los usuarios como para los empleados.
Etiología (¿Por qué?)	Los usuarios podrán tener dicha información de los procesos en los que se le haya capacitado y no recuerde por lo cual podrán revisar cuantas veces sea necesario sin causar demoras en sus actividades como retrasar a los empleados encargados en sus proyectos
Experiencia (¿Cuánto?)	Este Proyecto está basado en una investigación de campo que se basa en herramientas de tecnología para solucionar los problemas de capacitación de los usuarios.

Mapa mental Scrum

Qué es SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

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.

Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y sus requisitos.

El proceso

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. 

Las actividades que se llevan a cabo en Scrum son las siguientes:

Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes:

1.         Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.

2.         Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas.

Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximos). 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 poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:

•           ¿Qué he hecho desde la última reunión de sincronización?

•           ¿Qué voy a hacer a partir de este momento?

•           ¿Qué impedimentos tengo o voy a tener?

Durante la iteración 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.

Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los objetivos del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de inversión.

y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:

1.         Demostración (4 horas máximo). 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. 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.

Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.

Herramientas

•           Lista de requisitos priorizada (Product Backlog)

La lista de objetivos/requisitos priorizada representa la visión y expectativas del cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien proporciona el coste estimado de completar cada requisito). Dado que reflejar las expectativas del cliente, esta lista permite involucrarle en la dirección de los resultados del producto o proyecto.

•           Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se suelen expresar en forma de historias de usuario. Para cada objetivo/requisito se indica el valor que aporta al cliente y el costeestimado de completarlo. La lista está priorizada balanceando el valor que cada requisito aporta al negocio frente al coste estimado que tiene su desarrollo, es decir, basándose en el Retorno de la Inversión (ROI).

•           En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por el cliente (los puntos en los cuales desea que se le entreguen los objetivos/requisitos completados hasta ese momento), en función de la velocidad de desarrollo del (los) equipo(s) que trabajará(n) en el proyecto. Es conveniente que el contenido de cada iteración tenga una coherencia, de manera que se reduzca el esfuerzo de completar todos sus objetivos.

•           La lista también tiene que considerar los riesgos del proyecto e incluir los requisitos o tareas necesarios para mitigarlos.

Antes de iniciar la primera iteración, el cliente debe tener definida la meta del producto o proyecto y la lista de requisitos creada. No es necesario que la lista sea completa ni que todos los requisitos estén detallados al mismo nivel. Basta con que estén identificados y con suficiente detalle los requisitos más prioritarios con los que el equipo empezará a trabajar. Los requisitos de iteraciones futuras pueden ser mucho más amplios y generales. La incertidumbre y complejidad propia de un proyecto hacen conveniente no detallar todos los requisitos hasta que su desarrollo esté próximo. De esta manera, el esfuerzo de recoger, detallar y desarrollar el resto de requisitos (menos prioritarios) está repartido en el período de ejecución del proyecto. En el caso del desarrollo de un producto, la lista va evolucionando durante toda la vida del producto (los requisitos “emergen”). En el caso de un proyecto, conforme éste avance irán apareciendo los requisitos menos prioritarios que falten. Esto produce varias ventajas:

•           Se evita caer en parálisis de análisis al inicio del proyecto, de manera que se puede iniciar antes el desarrollo y el cliente puede empezar a obtener resultados útiles.

•           Se evita analizar en detalle requisitos no prioritarios que podrían cambiar durante el transcurso del proyecto, dado que el cliente conocerá mejor cuál ha de ser el resultado a conseguir, o bien por que podrían ser reemplazados por otros.

•           Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar los requisitos restantes, dado el poco retorno de inversión (ROI) que tienen.

Definición de completado (Definition of Done)

El cliente y el equipo tienen que acordar la “definición de completado” de los objetivos / requisitos en el proyecto:

•           Debe asegurar que el incremento de producto es potencialmente entregable al cliente al finalizar cada iteración, que no hay tareas pendientes que puedan impedir utilizar los resultados del proyecto lo antes posible. De este modo, el cliente podrá tomar decisiones correctas cuando al final de cada iteración el equipo le haga una demostración de los requisitos completados: cambiar las prioridades en función de la velocidad de desarrollo, solicitar una entrega del producto desarrollado hasta ese momento, etc.

•           Debe incluir lo necesario para considerar de manera clara que el cliente obtendrá lo que necesita según sus criterios de entregables y de calidad (producto construido, probado, documentado, refactorizado para conseguir calidad interna/mantenibilidad, etc.).

•           Además de esta definición de completado, a cada objetivo hay que asociarle sus condiciones de satisfacción, preferiblemente en forma de casos de prueba de aceptación, en el momento de crear la lista de requisitos priorizada (Product Backlog).

•           Notar que la definición de completado también sirve como base para identificar las tareas necesarias para conseguir cada objetivo/requisito, en la reunión de planificación de la iteración (Sprint planning). Para cada objetivo se crearán más tareas que la definición de completado (o menos) y con más significado. Por ejemplo, respecto a que el objetivo tiene que estar “construido”, pueden aparecer varias tareas, del estilo “construir el componente X”, “modificar la pantalla Y”, “modificar la BBDD”, “preparar el script de carga”, etc.

Iteración de entrega (release sprint)

 Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta ese momento, el equipo puede necesitar añadir una iteración de entrega, más corta que las iteraciones habituales, donde realizar alguna tarea que no ha sido necesaria o posible hasta el momento de la entrega final y acabar de corregir defectos detectados en la última demostración.

Uso de la lista

•           Para medir la velocidad de desarrollo del equipo, ver una progresión constante y extrapolar la fecha de las entregas, es conveniente seguir las siguientes recomendaciones:

•           Los requisitos deben tener un esfuerzo semejante para ser completados.

•           La estimación de un requisito no debe ser superior a 10 días (si las iteraciones son de 20 días laborables).

•           Cada requisito tiene asociado un factor de complejidad, que permite ajustar su coste estimado en función de la incertidumbre de la complejidad de su desarrollo en el momento de introducirlo en la lista. Este factor de coste se irá ajustando conforme las iteraciones avancen y el equipo conozca mejor el producto o proyecto, su contexto y su velocidad de desarrollo con las herramientas y tecnologías que utiliza.

•           Si un requisito depende de otro, se coloca en algún punto por debajo del que depende.

•           Si un requisito no se finaliza en una iteración, se le vuelve a poner en alguna de las siguientes iteraciones, indicando el coste pendiente de desarrollo.

•           El “origen” permite saber quién podría participar en la definición de un objetivo/requisito y sería conveniente que estuviese presente en el momento de su demostración.

  Lista de tareas de la iteración (Sprint Backlog)

Lista de tareas que el equipo elabora en la reunión de planificación de la iteración (Sprint planning) como plan para completar los objetivos/requisitos seleccionados para la iteración y que se compromete a demostrar al cliente al finalizar la iteración, en forma de incremento de producto preparado para ser entregado.

Esta lista permite ver las tareas donde el equipo está teniendo problemas y no avanza, con lo que le permite tomar decisiones al respecto.

Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para finalizarlas y la auto asignación que han hecho los miembros del equipo.

El progreso de la iteración y su velocidad con respecto a tareas u horas pendientes se muestra mediante un gráfico de trabajo pendiente (Burndown chart).  

 Uso de la lista

·       Los objetivos/requisitos están ordenados por orden de prioridad para el cliente.

• Por ello, signos de falta de foco, problemas o impedimentos serían que se estén completando objetivos que no son los primeros de la lista, así como tener demasiados objetivos/requisitos en progreso simultáneamente.

·         Si una tarea depende de otra, se coloca en algún punto por debajo de la que depende.

·         Las tareas deben estar identificadas de manera que tengan un coste semejante para ser completadas, entre 4 y 16 horas. Este tamaño permitirá:

·         Que las tareas sean suficientemente pequeñas como para poder detectar progreso o estancamiento de manera diaria.

·         Que las tareas no sean muy pequeñas, que sean suficientemente relevantes, no generen ruido ni microgestión.

·         Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas dentro de la iteración. 

El tablero de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar mediante un tablón de tareas (Scrum Taskboard). Al lado de cada objetivo se ponen las tareas necesarias para completarlo, en forma de post-its, y se van moviendo hacia la derecha para cambiarlas de estado (pendientes de iniciar, en progreso, hechas). Para cada miembro del equipo se puede utilizar adhesivos de colores más pequeños sobre cada tarea, de manera que se pueda ver en qué tareas está trabajando cada cual. 

El equipo elabora esta lista de tareas en la segunda parte de la reunión de planificación de la iteración. La lista va evolucionando (nuevas tareas, cambios, estado, esfuerzo pendiente, …) a medida que la iteración avanza, especialmente durante la reunión diaria de sincronización.

Este tablón o cuadro de mandos actúa como radiador de información tanto para el equipo como para cualquier otra persona relacionada con el proyecto.

En el siguiente artículo se muestra cómo construirlo y un ejemplo de su uso: Ejemplo de uso del tablero o pizarra de tareas (Scrum Taskboard).

Gráficos de trabajo pendiente (Burndown Chart)

Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se está completando los objetivos/requisitos. Permite extrapolar si el Equipo podrá completar el trabajo en el tiempo estimado.

Se pueden utilizan los siguientes gráficos de esfuerzo pendiente:

·         Días pendientes para completar los requisitos del producto o proyecto (product burndown chart), realizado a partir de la lista de requisitos priorizada (Product Backlog).

·         Horas pendientes para completar las tareas de la iteración (sprint burndown chart), realizado a partir de la lista de tareas de la iteración (Iteration Backlog).

Este tipo de gráfico permite realizar diversas simulaciones: ver cómo se aplazan las fechas de entrega si se le añaden requisitos, ver cómo se avanzan si se le quitan requisitos o se añade otro equipo, etc.

Tipos de Herramientas Scrum

He aquí algunas de las herramientas más populares para el manejo de gestión de proyectos Scrum.

Estas son apenas las más populares, si buscamos por internet por supuesto encontraremos infinidad de opciones.

• Kunagi: Herramienta Web que proporciona un sistema de gestión de proyectos basado en Scrum. Ofrece herramientas colaborativas y otras facilidades, como un cuadro de mando del proyecto, un panel interactivo para el Sprint o soporte a la estimación con Planning Poker.

• ScrumDo: Herramienta Scrum muy centrada en la simplicidad y en la facilidad de uso. Permite gestionar las listas de tareas e historias de usuario, crear y gestionar iteraciones, obtener gráficos de avance “burndown” y también dar soporte a la estimación con Planning Poker.

• SprintoMeter: Herramienta para la gestión, medición y seguimiento de proyectos Scrum y eXtreme Programming. Para simplificar el intercambio de datos permite exportar gráficos e informes a Excel. Posee gráficos de avance burndown en 3D.

• IceScrum: Herramienta Scrum y Kanban. Ofrece las opciones de operación, consulta y estimación de historias de usuario. Permite añadir historias de usuario a la pila de producto, dividir el tiempo en Sprints y mover estas historias de la pila de producto a cada uno de los Sprint. Posee la técnica de Planning Poker para la estimación y paneles virtuales.

• Pango Scrum: Otra de las herramientas Scrum online, con una interfaz sencilla y amigable que permite escribir, estimar y priorizar la pila de producto. Facilita en gran medida la planificación de Sprints y las reuniones.

 

Proceso y Roles de Scrum

El proceso

El desarrollo se realiza de forma iterativa e incremental. Cada iteración, denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio.

Product Backlog: Conjunto de requisitos denominados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint Planning: Reunión durante la cual  el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.

Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.

Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.

Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.

Roles

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:

Scrum master: Persona que lidera al equipo guiándolo para que cumpla las reglas y procesos de la metodología. Gestiona la reducción de impedimentos del proyecto y trabaja con el Product Owner para maximizar el ROI.            Product owner (PO): Representante de lso accionistas y clientes que usan el software. Se focaliza en la parte de negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). Traslada la visión del proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las reprioriza de forma regular.           Team: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.