Evidencia 3 2 - en este trabajo te pide crear una empresa PDF

Title Evidencia 3 2 - en este trabajo te pide crear una empresa
Course Innovación y Nuevas Tecnologías
Institution Universidad Nacional Autónoma de México
Pages 12
File Size 576.3 KB
File Type PDF
Total Downloads 471
Total Views 933

Summary

Desarrollo:pEvidencia 3 – Administración de Proyectos de TIDescripción: En esta evidencia deberás retomar el proyecto que vienes trabajando en la evidencia 1 y 2 y aplicar la metodología ágil para planear el desarrollo de los primeros entregables.Retoma el caso de la evidencia 1, es el momento de en...


Description

p

Evidencia 3 – Administración de Proyectos de TI Descripción: En esta evidencia deberás retomar el proyecto que vienes trabajando en la evidencia 1 y 2 y aplicar la metodología ágil para planear el desarrollo de los primeros entregables. Desarrollo:

Retoma el caso de la evidencia 1, es el momento de entregar el primer sprint, en la reunión con el cliente se definieron las siguientes funcionalidades de los procesos de compliance como entrega para el primer y segundo sprint. Sprint 1. Compliance_Fábricas_Backlog Tablero de información de fábricas (must). Tablero de auditorías (must). Calendario de auditorías (Won´t have now but would be later). Sprint 2. Compliance_Producto_Backlog Tablero de pruebas de producto estándares internacionales ( must). Tablero de pruebas de producto nacionales (must). Tablero de aprobación Product Integrity por licencia (must). Calendario de renovación de pruebas nacionales ( should). Calendario de renovación de pruebas mexicanas ( should). Registro de marca nacional e internacional (could). Tablero de documentos para aduanas (Won´t have now but would be later).

1) Valida los roles del equipo y define los tres principales roles que se requieren para SCRUM. Siendo los responsables de que el proyecto sea implementado exitosamente utilizando las metodologías principales que son: 1. Product Owner Primer equipo estará al tanto de las necesidades del cliente ya que la voz del mismo es darle prioridad a los stakeholders como también a los clientes y usuarios. El Product Owner se responsabiliza de la seguridad que presentara el equipo de Scrum encargado ofrezca valor. En definición del equipo 1:  La visión del proyecto.  Identificar a los stakeholders.  Ayudar a determinar a los miembros del equipo Scrum.  Crear épicas y prototipo.  Aceptar/rechazar los entregables.  Asegurar los recursos financieros del proyecto.  Priorizar los elementos de la lista priorizada de pendientes del producto (Product Backlog.  Definir los criterios de terminado.  Ayudar a crear historias de usuario.  Representar a los usuarios del producto o servicio con un profundo conocimiento de la comunidad de usuarios.  Ayudar a finalizar la elección de Scrum Master para el proyecto.  Explicar las historias de usuarios al equipo Scrum, al tiempo que crea la lista de tareas.  Mantener la lista priorizada de pendientes del producto.

2. Scrum Máster Segundo equipo tendrá el deber de moderar y facilitar las interacciones del equipo como facilitaros y motivador este rol es responsable de asegurar un ambiente de trabajo productivo para todo el equipo, debe protegerlo de influencias externas, despejar los obstáculos y garantizar que se cumplan de principio a fin, los aspectos y procesos de la metodología Scrum. Objetivos definidos:  Ayuda a identificar a los stakeholders para el proyecto.  Facilita la selección del equipo Scrum.  Garantizar que los recursos de respaldo estén disponibles para un buen funcionamiento sin presentar problemas en el proyecto.  Ayudar al Product Owner en la creación de la lista priorizada de pendientes del producto y en la definición de criterios de aceptación.  Determina la duración del sprint.  Apoya al equipo Scrum en la estimación del esfuerzo necesario para completar las tareas acordadas para el sprint  Ayuda a actualizar el tablero Scrum y el registro de impedimentos.  Facilita las reuniones de revisión de la lista priorizada de pendientes del producto.  Se asegura que los problemas que afectan al equipo Scrum se discutan y se resuelvan.  Garantizar que exista un ambiente ideal para el equipo Scrum.

3. Scrum Team Tercer equipo llamado “equipo de desarrollo” son responsables del desarrollo, servicio o de cualquier otro resultado. Consiste en un grupo de personas que trabajan en las historias de usuario en la lista de pendientes del sprint para crear los entregables del proyecto. Nadie, ni siquiera el Scrum Máster, indica al Scrum Team como cumplir los objeticos del sprint, es un equipo auto gestionado y multifuncional que cuenta con todas las habilidades necesarias. El tamaño optimo de un equipo Scrum es de seis a diez miembros. La responsabilidad del equipo 3 son:  Asegurar una comprensión clara de las épicas y prototipos.  Entender las historias de usuario en la lista priorizada de pendientes del producto.  Estar de acuerdo con los demás miembros del Scrum Core Team sobre la duración del Sprint. Estimar las historias de usuario aprobadas por el Product Owner.  Asignar las historias de usuario que se hacen en un Sprint.  Desarrollar la lista de tareas en base a las historias de usuario ya convenidas y las dependencias.  Crear entregables.  Actualizar el registro de impedimentos y las dependencias.  Actualizar la tabla del trabajo pendiente y el tablero Scrum.  Realizar las reuniones diarias de pie (Daily Standup Meeting).  Identificar oportunidades de mejora en la reunión de retrospectiva del sprint.  Participar en la reunión de retrospectiva del proyecto. De forma general los tres principales roles de la metodología Scrum: Product Owner, Scrum Master y Scrum Team, son los responsables de cumplir con los objetivos del proyecto.

2) Para tu equipo de desarrollo define: a. La metáfora de usuario. - El rol de usuario al cual tiene una identificación única y la descripción del puesto u actividad asignada.

b. Pruebas unitarias. - encargadas de verificar el código y diseñado por los programadores tanto las pruebas de aceptación o pruebas funcionales destinadas a evaluar si al final de una iteración se consiguió la funcionalidad requerida diseñadas por el cliente final.

c. Prácticas. - requieren ser aplicadas en su totalidad para que el método sea viable: No disponer de requerimientos detallados escritos lleva a mantener un diseño simple.

d. Técnicas de refactorización. - mejorar la estructura interna del código sin alterar su comportamiento externo. La refactorización es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los posteriores cambios.

e. Propuesta de las parejas para Pair Programming. - 2 cerebros son mejor que uno. - El conocimiento del sistema se extiende entre todos los integrantes, mediante un -

-

aprendizaje cruzado, posibilitando la transferencia de conocimientos. Muchos errores son detectados conforme son introducidos en el código (inspecciones de código continuas), por consiguiente, la tasa de errores del producto final es más baja, los diseños son mejores y el tamaño del código menor (continua discusión de ideas de los programadores). Mayor cobertura de las pruebas, ya que 2 personas ofrecerán 2 perspectivas distintas.

3) Prioriza las funcionalidades del backlog de cada sprint y estima el esfuerzo requerido para cada ítem. El Product Owner se presenta en el sprint planning meeting con el product backlog priorizado y describe los ítems principales al equipo. El equipo determina qué ítems pueden completar durante el sprint que está por iniciar. El equipo mueve los ítems desde el product backlog al sprint backlog correspondiente. Al hacerlo, ellos expanden cada ítem del Product backlog en una o más tareas (sobre el sprint backlog). Así el equipo puede compartir el trabajo de forma más efectiva durante el sprint

4) Planea tu primer y segundo sprint, considerando el product backlog, sprint backlog y product increment. Para el sprint su duración no debe cambiar mientras está en marcha el desarrollo del producto, y se puede interpretar como una medida de ritmo constante a lo largo del tiempo, permitiéndonos reducir complejidad y comparar resultados a lo largo de diferentes Sprints. Sprint 1 (trabajado las primeras dos semanas) Se programará una junta de 2 horas a la semana con los programadores incluyendo los avances y objetivos cumplidos. Se programará la junta de 3 horas la Siguiente semana viendo los incrementos de las actividades del proyecto finalizados.

Sprint 2 (ultimo trabajo de las últimas dos semanas)

Los siguientes equipos como el 2 y 3 revisarán los avances en las juntas que se programarán diario con cada uno de los programadores en una reunión. El director de proyecto aceptara las actividades completadas durante el periodo del proyecto, así como también la retroalimentación implementada para un éxito completo.

5) Define la agenda del primer daily standup y sprint review, así como la primera retrospectiva. Reunión diaria de 15 min El product Owner se encargará de la decisión y se dedicarán a los recursos entendiendo que esto es critico para llegar al éxito del empleo de la organización que en este caso es la empresa FW. El primer daily standup será exclusivamente para development Team, es una reunión diaria de 15 minutos en la que participan. En esta reunión todas y cada una de las personas del area Team responden a las siguientes preguntas: 1. ¿Qué hice ayer para contribuir al sprint Goal? 2. ¿Qué voy a hacer para contribuir al Sprint Goal? 3. ¿Tengo algún impedimento que me impida entregar? Tendremos controlado y gestionado el trabajo motiva por un manager mientras referimos la practica inspeccionando y adaptando a través de la autoorganización del equipo

Review es de 8 horas para sprint de 4 semanas En la primera semana del proyecto se tendrá una junta 2 días a la semana hablando de la retroalimentación y los puntos faltantes. En sprint Review siendo casi la parte final del sprint que será la junta el ultimo viernes donde el Product Owner y Scrum Team presentaras a los stakeholders el incremento terminado para su inspección y adaptaciones correspondientes.

nos debemos mentalizar que la retrospectiva proyecta el implementado sprint para la mayoría de las organizaciones, cuando les es difícil implementarlo tienen la diferencia de utilizar la gestión tradicional de proyectos, será siempre orientada a generar su máximo valor para finalizar con éxito.

6) Define al menos tres estados o carriles por los que deben de pasar las actividades de trabajo en los tableros Kanban, y mediante un software para monitoreo de proyectos genera el tablero Kanban que se va a implementar.

7) Para tu equipo de desarrollo, define al menos tres roles XP para que sean conocidos por los interesados del proyecto. Mi equipo de desarrollo tendrá los roles de:  Programador. El programador se encargará en la codificación del proyecto para ello ya se habrían establecido y delimitado las necesidad y requerimientos del proyecto, por ende, el programador ya va a tener una idea precisa y clara hacia el proyecto, y así poder generar la codificación en un lenguaje de programación ya sugerido o especializado hacia el proyecto.



Encargado de pruebas (Tester).

El encargado de pruebas llevara a acaba diferentes situaciones que se podrían llegar a presentar en el programa para así tener una mayor efectividad a la hora de la entrega del proyecto.



Encargado de seguimiento (Tracker).

El encargado de seguimiento tendrá el trabajo de supervisar los trabajos de ambos, requerirá reportes de trabajo en un delimitado tiempo para poder entregar el proyecto en la fecha ya delimitada

8) Elabora una proyección sobre la variación que puede presentar el proyecto en la fase final en cuanto a costos, alcance del proyecto y cumplimiento del plan de riesgos.

variacion de la fase final de costos 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0



Las variaciones pronosticadas por tipo de clientes muestran un mayor crecimiento de las ventas a mayoristas: esto surge de la intención de ampliar las zonas geográficas de atención de este tipo de clientes, y es congruente con el mayor crecimiento de los gastos de comercialización



El alcance del proyecto es logras que los clientes estén satisfechos con nuestro servicio teniendo toda la información necesaria para tener un control de calidad exitosa.



El plan de riesgos es un éxito cumpliendo con los estándares y teniendo una baja probabilidad de presentar riesgos en el proyecto. teniendo en cuenta las retroalimentaciones para tener una mejor presentación en cuanto a calidad.

9) Realiza un checklist que te apoyará al momento de cerrar el proyecto que incluya: los requerimientos del proyecto, un apartado para la aprobación final del proyecto, evaluación de la satisfacción del cliente con una pequeña encuesta, lecciones aprendidas. Requerimiento del proyecto

Puntuación del 1 al 5

Realizar interfaz gráfica en el programa.

1

2

3

4

5

Realizar un base de datos.

1

2

3

4

5

Migrar los datos de su data base.

1

2

3

4

5

Realizar los ajustes de seguridad pertinentes.

1

2

3

4

5

Realizar el Testing con los parámetros de seguridad.

1

2

3

4

5

Verificar la conectividad de su plataforma y la base de datos.

1

2

3

4

5

Realizar procedimientos para la automatización de procesos.

1

2

3

4

5

El tiempo de respuesta de la plataforma es menor de 0.899 ms.

1

2

3

4

5

Verificar que no pueda haber fallos en la plataforma. Aprobación del proyecto

1

2

3

4

5

Puntuación del 1 al 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

El proyecto finalizo de manera exitosa. Se cumplieron con todos los requerimientos. Cada requerimiento se satisfago de la mejor manera. Se ha finalizado el proyecto en dentro del tiempo límite. El proyecto satisface las necesidades del usuario.

El proyecto finalizó de manera exitosa Satisface las necesidades solicitadas Fue grato trabajar con el equipo del proyecto El equipo del proyecto fue respetuoso en todo momento Todo el equipo fue profesional El tiempo del proyecto fue igual o menor al solicitado Se entrego en tiempo y forma el proyecto Todos los datos fueron migrados

1 1 1 1 1 1 1 1

5 5 5 5 5

Satisfacción del cliente Puntuación del 1 al 5 2 3 4 5 2 3 4 5 2 3 4 5 2 3 4 5 2 3 4 5 2 3 4 5 2 3 4 5 2 3 4 5

Lecciones aprendidas.

En toda La evidencia y la materia hemos aprendido a como poder llevar a cabo un proyecto de la mejor posible, apoyándonos siempre de herramientas que nos serán útiles en el futuro cuando ya nos enfrentemos al mundo de la industria laboral. Fue interesante conocer como hay más de una manera de lograr gestionar los proyectos en los que nos involucremos. Y cada una de esas maneras puede definir el éxito o fracaso de nuestro proyecto. Del mismo modo, es importante destacar que no existe un solo método con el cual va a funcionar todo tipo de proyecto, y que un proyecto no es exclusivo de hacer por una sola metodología. Cada metodología tiene sus propios pasos para llevar a cabo cualquier proyecto o tarea que sea menester su realización, pero al final todas concuerdan en lo mismo que es poder llevar a cabo el proyecto que se le asigne en el menor tiempo posible y cumpliendo con todos sus requerimientos de la manera más satisfactoria posible. Ha sido muy Interesante trabajar en la evidencia con problemas de caso, donde nos hemos puesto a prueba junto con nuestros conocimientos para validar si lo aprendido en clase ha sido digerido y esta listo para aplicarse en cualquier momento.

Entregable: Documento electrónico que contenga la información de la evidencia 1, 2, así como la definición de los roles de acuerdo a SCRUM, priorización del backlog, planeación de los sprint, daily standup, sprint review, retrospectiva, el tablero Kanban, los roles XP, la proyección del proyecto y el checklist de cierre.

Criterios de evaluación: Revisa la rúbrica de la evidencia 3. Rúbrica evidencia 3 Administración de Proyectos de Tecnologías de Información Altamente Parcialmente Competente competente competente

Criterio de evaluación

20

1. Presenta los roles de acuer do a SCRU M.

1 2

1.

Define los tres principales roles de SCRUM para el equipo.

1. Define dos de tres roles de SCRUM para el equipo.

2. Para el equipo de desarrollo asigna lo siguiente: metáfora de usuario, pruebas unitarias, prácticas, técnicas de refactorización

2. Para el equipo de desarrollo asigna lo siguiente: metáfora de usuario, pruebas unitarias, prácticas, técnicas de refactorización.

6 1. Define un rol para el equipo de SCRUM. 2. Para el equipo de desarrollo asigna lo siguiente: metáfora de usuario, pruebas unitarias, prácticas.

Insuficiente desarrollo de la competencia

Tot al

0 1. No define ningún rol para el equipo. 2. No define actividades para el equipo de desarrollo.

20

y propuesta de pair programming.

2. Planea los primeros dos sprint.

20

1 2

6

1. Prioriza las funcionalidades del backlog de cada uno de los sprint, estima el esfuerzo para cada uno de ellos. 2. Planea el primer y segundo sprint considerando el product backlog, sprint backlog y product increment.

1.Prioriza las funcionalidades del backlog de uno de los sprint, estima el esfuerzo para cada uno de ellos. 2. Planea el primer y segundo sprint considerando el product backlog, sprint backlog.

1. Prioriza las funcionalidades del backlog de cada uno de los sprint.

3. Presenta la agenda del daily standup, sprint review y retrospectiva.

20

3. Presenta el tablero Kanban y los roles XP.

4. Elabora una

1. El tablero Kanban incluye al menos tres carriles para monitoreo del proyecto. 2. Presenta al menos tres roles XP y los comparte con los interesados.

2. Planea el primer y segundo sprint considerando el product backlog.

0 1. No prioriza el backlog. 2. No presenta la planeación de los sprints.

20

3. No presenta la agenda. 3. Presenta la agenda del daily standup, sprint review.

1 2 1. El tablero Kanban incluye al menos dos carriles para monitoreo del proyecto. 2. Presenta al menos dos roles XP y los comparte con los interesados.

20

1 2

Elabora una proyección

Elabora una proyección

3. Presenta la agenda del daily standup.

6

0

1. El tablero Kanban incluye al menos dos carriles para monitoreo del proyecto.

1. No presenta tablero Kanban.

20 2. No identifica roles XP.

2. Presenta al menos un rol XP y lo comparte con los interesados.

6 Elabora una

0 No presenta

proyecció n sobre la finalización del proyecto. 5. Elabora checklist para cierre de proyecto.

sobre el estado del proyecto al finalizar sobre los siguientes rubros: costos, alcance y riesgos.

sobre el estado del proyecto al finalizar sobre los siguientes rubros: alcance y riesgos.

20

1 2

proyección sobre el estado del proyecto al finalizar sobre los siguientes rubros: costos y riesgos.

6

El checklist contiene la siguiente información:

El checklist contiene la siguiente información:

El checklist contiene la siguiente información:

requerimientos del proyecto, evaluación de la satisfacción del cliente, aprobación del proyecto y lecciones aprendidas.

...


Similar Free PDFs