Informe Postmortem Ciclo 2

Postmortem

Informe Postmortem ciclo 2

Mateo Quintero

Jennyfer Olarte

Jonathan Posada

Héctor Arias

Mabel Díaz

Contenido1. Resumen...........................................................................................................4

2. Reporte de roles................................................................................................4

2.1 Desempeño del líder del equipo..................................................................5

2.2 Desempeño del líder de desarrollo.............................................................6

2.3 Desempeño del líder de planeación............................................................7

2.4 Desempeño del líder de calidad..................................................................7

2.5 Desempeño del líder de soporte.................................................................8

3. Reporte de ingenieros.......................................................................................9

3.1 Reporte Mateo Quintero..............................................................................9

3.1.1 LOC planeadas vs LOC reales.............................................................9

3.1.2 Tiemplo planeado vs tiempo trabajado...............................................10

3.2 Reporte Jennyfer Olarte............................................................................10

3.2.1 LOC planeadas vs LOC reales...........................................................10


3.3 Reporte Jonathna Posada.........................................................................12



3.4 Reporte Hector Arias.................................................................................13

3.5 Reporte Mabel Diaz..................................................................................13



4. Postmortem.....................................................................................................15

4.1 Requerimientos trabajados.......................................................................15

4.2 Líneas de código planeadas vs Líneas de código reales..........................16

4.2.1 Líneas de código planeadas vs Líneas de código reales por clase....17

4.2.2 Líneas de código planeadas vs Líneas de código reales por integrante18

Technologies DEVTipo de documento:

PostmortemCódigo: 02

Grupo: Technologies DEV

Emisión: 28 Julio 2013

Revisión: 02

GoSurveys.comPágina: 2 de 29

4.3 Tiempo planeado vs tiempo real...............................................................19

4.4 Tiempo planeado vs tiempo real por integrante........................................19

4.5 Tiempo gastado por fase...........................................................................20

4.6 Productividad............................................................................................21

4.7 Defectos encontrados por fase.................................................................22

4.8 Metas de lanzamiento...............................................................................22

4.8.1 Metas de equipo.................................................................................22

4.8.2 Metas de cada rol...............................................................................23

4.9 Propuestas de mejoramiento del proceso.................................................26

4.9.1 Propuesta 1........................................................................................26

4.9.2 Propuesta 2........................................................................................27





Revisión: 02


1. Resumen

El segundo ciclo de este proyecto fue desarrollado bajo condiciones más favorables para el monitoreo y el control del proyecto, aunque esto no quiere decir que el ciclo funciono como se esperaba.

Se planeó un ciclo más ligero en tareas con respecto al primer ciclo. Las listas de chequeo que teníamos del primer ciclo nos sirvieron para aplicarlas en esta, así que no fue necesario planear actividades de creación de listas de chequeo y de revisión de dichas listas.

El esfuerzo estaba enfocado en terminar el producto, completando el ciclo para los requerimientos faltantes. Aquí la estrategia de desarrollo y de requerimientos fue muy eficaz en cuanto a que nos permitió desarrollar paralelamente los requerimientos que quedaban, asignar las especificaciones para la especificación en paralelo. La plantilla de TSP es una herramienta que permite definir una actividad para un ciclo con su respectivo tiempo, por tal motivo fue necesario ponernos de acuerdo sobre cómo íbamos a trabajar, para evitar que las dependencias de tareas no le impidieran trabajar a alguien en el tiempo que había dispuesto para esto, es decir que si dos personas iban a trabajar por ejemplo la especificación de un caso de uso y la implementación de dicho caso de uso respectivamente, teniendo en cuenta que la implementación depende de la especificación del caso de uso, era posible que la persona que iba a especificar dispusiera del tiempo para realizar tal tarea un día después del día que había dispuesto la persona que iba a realizar la implementación.

En cuanto al trabajo en equipo nos resultó más fácil está vez ya que todos sabíamos cómo y en que enfocar el esfuerzo debido a la experiencia del ciclo anterior.

2. Reporte de roles

Los roles fueron asignados de la siguiente manera:

Integrante RolMateo Ocampo Líder del equipoJennifer Olarte Líder de planeaciónJonathan Posada Líder de desarrollo





Revisión: 02


Héctor Arias Líder de calidadMabel Díaz Líder de soporte

A continuación se describe el desempeño de cada uno de los roles.

2.1 Desempeño del líder del equipo

En este ciclo el líder de equipo sumó esfuerzos con el líder de planeación para realizar la planeación y la asignación de tareas. Como se habla anteriormente, se planeó un ciclo más ligero en tareas con respecto al primer ciclo. Las listas de chequeo que teníamos planeadas del primer ciclo nos sirvieron para aplicarlas en esta, así que no fue necesario planear actividades de creación de listas de chequeo y de revisión de dichas listas.

Las reuniones de seguimiento se siguieron haciendo por SKYPE y presencialmente y se siguió la misma estrategia de comunicación del primer ciclo. Todos estábamos conectados constantemente, así no estuviésemos trabajando en el proyecto, con el fin de resolver las dudas lo más rápido posible y continuar con el desarrollo del ciclo.

Como se menciona en el resumen, hubo necesidad de ponernos de acuerdo en realizar primero el trabajo que se necesitara de entrada de otras tareas posteriores para evitar que una persona se quedara esperando mucho tiempo para poder continuar con su respectiva tarea.

Por otra parte, hubo tareas que solo se realizaron hasta el final del ciclo en las que el compromiso era entregarlas antes. Esto se debió a que eran tareas no muy críticas para el desempeño del proceso, pero el compromiso de todos, incluyendo al líder era entregar antes del día en que al fin se realizaron dichas tareas.

En cuanto a la motivación del equipo, continuo igual que a la anterior debido a que a nadie le parece aplicar está metodología a un problema mediano y en el que el contexto de trabajo es el académico en donde la disciplina para aplicarlo es diferente a la de un ambiente laboral.

Con base a lo anteriormente planteado, para manejar mejor este rol en el futuro es necesario tener en cuenta los siguientes aspectos:





Revisión: 02


El líder debe dar ejemplo. Si el líder no cumple sus compromisos, no tiene autoridad moral para exigir que los demás miembros del grupo lo hagan también.

El líder debe proponer mecanismos para garantizar el cumplimiento de compromisos no usando la coerción como método para lograrlo. Si se ofrece un compromiso en el que ambas partes ganan algo que les provea valor, la probabilidad de que el compromiso sea cumplido aumenta.

Como se dijo en el postmortem anterior en cuanto al acompañamiento del instructor, se sigue pensando que en el lanzamiento y en el postmortem es donde más se requiere la presencia del instructor. En el lanzamiento se deben definir muy bien los objetivos y las metas con sus respectivas métricas porque entre mejor definidos estén, permiten sacar información de mayor calidad para ciclos posteriores. En el postmortem se muestra si se cumplieron las metas, que funcionó que no funcionó, como fue el desempeño de los roles y se describe el proceso cuantitativamente, y es allí donde el instructor debe hacer más presencia para proveer el apoyo necesario con el fin de sacar el mayor provecho a la información recolectada durante el ciclo.

2.2 Desempeño del líder de desarrollo

Basados en las falencias y mejoras identificadas en el primer ciclo de la ejecución del proyecto, se replanteo en la estrategia de plantación del segundo ciclo, con el fin de abordar de una manera más detallada todas las actividades involucradas teniendo en cuenta los artefactos, tareas y demás acciones que demandaran esfuerzo de los miembros del equipo. Como resultado de lo anterior y teniendo en cuenta que por la definición del esquema de trabajo que se desarrolló en el primer ciclo fue complejo por el número de tareas planteadas, se pudo obtener una planeación que cubría en la totalidad las tareas requeridas y con estimados de tiempo más cercanos a los tiempos ejecutados.

Vale la pena enmarcar que el desempeño de este rol, creció con respecto al primer ciclo gracias a la experiencia ganada en este, teniendo en cuenta que no se contaba con la experiencia posterior a la ejecución del rol.

En cuanto a la estrategia de identificación de tareas, se utilizó la misma definida en el primer ciclo basándose en la Estructura Desglosada de Trabajo y realizando la respectiva asignación y balanceo de cargas del grupo de trabajo. Pero teniendo en cuenta las experiencias del ciclo anterior en cuanto a la identificación de





Revisión: 02


actividades adicionales o subyacentes a las definidas en el proceso de TSP y en el proceso de desarrollo del Equipo Technologies DEV.

En cuanto a los aspectos a mejorar definidos en el ciclo anterior:

- Manejar desarrollos en tareas críticas del cronograma del proyecto.- Ajustar los tiempos de ejecución de tareas, que requieran procesos complejos de pruebas y tareas de revisión.- Ejecutar más seguimiento del avance planeado del proyecto.

Fueron tenidas en cuenta en la fase de planeación obteniendo los resultados esperados, ya que en algunos casos los espacios fueron consumidos en su totalidad sin afectar los tiempos planeados para cada una de estas actividades y del proyecto en general.

2.3 Desempeño del líder de planeación

De acuerdo a la planeación y estrategia definida desde el primer ciclo del proyecto, se puede decir que los resultados son altamente satisfactorios, ya que el modelo de componentes establecido potencializo la productividad y redujo la complejidad de los desarrollos de este ciclo. Lo anterior permitió de igual forma, que cada desarrollador se especializara en una porción de la aplicación mientras estaba abstraído de la complejidad completa del proyecto.

Por otra parte, el éxito de la estrategia se debe al buen trabajo en conjunto del equipo Technologies DEV, ya que en base a los lineamientos, guías y revisiones desarrolladas a lo largo de la ejecución del proyecto, fue posible producir en el tiempo estimado y con la calidad esperada el resultado obtenido.

Como se ha dicho anteriormente, se puede decir que el segundo ciclo fue enfocado en un 80% a completar la funcionalidad de negocio definida en los requerimientos funcionales expuestos en el enunciado del proyecto, una vez mas según lo propuesto en la estrategia inicial, donde se decidió atacar la problemática fundamental distribuyendo el esfuerzo de implementación en el primer ciclo para componentes CORE y en el segundo ciclo la funcionalidad que cubría en su totalidad los requerimientos de negocio.





Revisión: 02


2.4 Desempeño del líder de calidad

En el primer ciclo se estableció que las estrategias planteadas para los procesos de calidad de todos los artefactos asociados al proceso y producto cumplieron con las expectativas planteadas; por lo cual para este ciclo se siguió con la misma estrategia.

Todos los integrantes del equipo registraron los artefactos necesarios y establecidos para respaldar la calidad del producto, tales como la ejecución de las listas de chequeo de los entregables y la respectiva revisión de pares para establecer los defectos de los mismos y en qué fase deberían removerse.

Así mismo se continuó usando los estándares establecidos para mantener un trabajo uniforme y fácilmente entendible por cualquier miembro del equipo que en cualquier momento necesitara hacer una revisión de cualquiera de los artefactos del proyecto.

Para este segundo ciclo se tuvo un mayor manejo del rol, ya que se contó con la experiencia del primer ciclo.

2.5 Desempeño del líder de soporte

El trabajo de soporte para el ciclo 2 en cuanto a las herramientas de planeación y desarrollo fueron mínimas, Project y TSP funcionaron correctamente, y el seguimiento de estas tareas por parte del equipo no tuvo inconvenientes.

El IDE de desarrollo: DreamWeaver es una herramienta bastante probada y fiable, no se reportaron inconvenientes, el servidor Google que funciona como repositorios funciono correctamente.

Al iniciar el ciclo 2, y como resultado de la reunión de seguimiento se detectaron nos riesgos sensibles: la pérdida de código fuente por trabajar en artefactos en paralelo, y un eventual caída del servidor al cual no tenemos control, como lo es el servidor de Google. Para manejar estos riesgos se plantearon las siguientes estrategias:





Revisión: 02


Como mecanismo de control de versiones implemento por la forma como se desarrolló este proyecto el siguiente mecanismo: El líder de desarrollo libero una versión estable del CORE del producto, y la distribución del trabajo se hizo de tal manera que cada miembro del grupo no afectara clases ni artefactos de otro. Con esto se mitigo el riesgo de la perdida de trabajo, además una vez terminada la funcionalidad asignada a cada desarrollador el líder de desarrollo fue el encargado de realizar el merge con el CORE.

El líder de soporte debe realizar un backup de la información del Repositorio una vez por semana.

Por la poca complejidad del software, no se hizo necesario realizar estrategias para hacer reutilización de componentes de software.

Terminado el ciclo se puede concluir que los riesgos se eliminaron, ya que nunca se presentaron, las herramientas funcionaron correctamente y el trabajo del rol de soporte disminuyo en comparación con el ciclo I.

3. Reporte de ingenieros

3.1 Reporte Mateo Quintero

El desarrollo se planteó para que pudiese ser en paralelo. El diseño detallado le permitió a cada miembro desarrollar los criterios de la creación de la encuesta que requiere la aplicación. En caso el caso del ingeniero en cuestión, el desarrolló el criterio de duración de la encuesta. El desarrollo de esta parte del sistema no requirió mayor esfuerzo. El Invirtió 3 horas para terminar el desarrollo contando con las pruebas de programación. La integración fue sencilla porque el diseño se planteó de tal manera que todos los criterios cumplieran con una interfaz y la clase encargada de consolidar los cálculos de los criterios, simplemente llamaban el método definido por la interfaz de cada uno de los criterios permitiendo una integración muy limpia. Una vez terminado el desarrollo el ingeniero procedió a subir el código realizado al Subversión. Los datos correspondientes a al desempeño del ingeniero son:





Revisión: 02


3.1.1 LOC planeadas vs LOC reales

A continuación se muestra un gráfico que describe el rendimiento de LOC planeadas vs las reales:

Planeadas Reales0

20406080

100120140160180

1700

1360

LOC Planeadas vs LOC Reales

LOC

Como se puede observar en el gráfico, se requirió 20% menos Líneas de código de las planeadas para poder terminar el desarrollo planeado.





Revisión: 02


3.1.2 Tiemplo planeado vs tiempo trabajado

Tiempo planeado Tiempo ejecutado0

0.20.40.60.8

11.21.41.6

150

120

Tiempo planeado vs ejecutado

Horas

Como se puede observar en el gráfico, se trabajó un 20% de tiempo menos de lo planeado..

3.2 Reporte Jonathan Posada

En general la estrategia planteada por el grupo para enfrentar el desarrollo, fue una muy buena elección ya que logro abstraer la complejidad del desarrollo en el segundo ciclo para las funcionalidades de negocio, que apalanco la productividad del equipo. Se encontraron algunas dificultades en el entendimiento de algunas de las reglas de negocio por falta de profundidad en el enunciado, lo cual creo fue un factor en contra de la productividad y la calidad en algunos momentos.







Revisión: 02


Planeadas Reales400

402

404

406

408

410

412411

404


LOC

Como se puede observar en el gráfico, se requirió 2% más líneas de código de las planeadas para poder desarrollar lo planeado.



0.51

1.52

2.53

3.54

4.5

30

45


Horas

Como se puede observar en el gráfico, se trabajó un 50% más de lo planeado.





Revisión: 02


3.3 Reporte Jennyfer Olarte

La estrategia planteada y el bajo nivel de complejidad en la implementación del criterio al cual fui asignado, permitieron que la productividad fuera maximizada. Por esto creo que se tomó una muy buena decisión al momento de establecer, planear y diseñar el enfoque de trabajo.

Por otro lado los procesos de soporte como listas de chequeo, revisión de pares y ejecución de pruebas unitarias, fueron un aspecto fundamental para lograr un producto de alta calidad y cumpliendo tanto con las expectativas del enunciado como con las expectativas de la ejecución del proceso.

Como se puede observar en el gráfico, se requirió 16% menos de LOC de las planeadas para poder desarrollar lo planeado.

Como se puede observar en el gráfico, se trabajó en el tiempo planeado.



Planeadas Reales170

180

190

200

210

220

230

240235

198


LOC





Revisión: 02


Como se puede observar en el gráfico, se requirió 16% menos Líneas de código de las planeadas para poder desarrollar lo planeado.



0.20.40.60.8

11.21.41.6

150 150


Horas

Como se puede observar en el gráfico, se trabajó un 100% de lo planeado.

3.4 Reporte Héctor Arias

Héctor tuvo pocas asignaciones de actividades de desarrollo y se centró más en los temas referentes a su rol de líder de calidad.

3.5 Reporte Mabel Díaz

La estrategia que puso en marcha el líder de desarrollo para el desarrollo del software fue muy buena, las funcionalidades asignadas fueron muy atómicas e independientes de los demás miembros del grupo, esta independencia permite maximizar el trabajo, ya que disminuyo la relación de dependencia de las tareas.

El líder de planeación tomo una buena decisión al asignarle al mismo miembro de grupo la definición de los casos de uso y su posterior implementación, con sus





Revisión: 02


respectivos controles. Esto disminuye la ambigüedad del entendimiento de los requerimientos.

Estos dos aspectos influyeron notoriamente para mejorar mi rendimiento, ya que para este ejercicio la diferencia entre lo estimado y lo real, no supero el 10 %.



Planeadas Reales190

195

200

205

210

215

220

200

218


LOC

Como se puede observar en el gráfico, se requirió 16% más Líneas de código de las planeadas para poder desarrollar lo planeado.





Revisión: 02




0.5

1

1.5

2

2.5

3

130

193


Horas

Como se puede observar en el gráfico, se trabajó un 63% menos de lo planeado.

4. Postmortem

4.1 Requerimientos trabajados

Los requerimientos desarrollados fueron los siguientes:

• Crear modulo operario• Asignar encuesta• Administrar Clientes• Generar reportes• Administrar encuestas

No se trabajaron los siguientes requerimientos, debido a que ya fueron desarrollados en el ciclo pasado:

• Crear modulo administrador• Administración de encuestas modulo admón.





Revisión: 02


71%

29%

Requerimientos funcionales completadosRequerimientos no trabajados

La información del desempeño de este ciclo se ve reflejada en las siguientes estadísticas:

4.2 Líneas de código planeadas vs Líneas de código reales

Planeadas Reales920930940950960970980990

100010101020

10016

5056


LOC





Revisión: 02


La estimación estuvo por encima de las LOC reales en un 5,9%.





Revisión: 02


4.2.1 Líneas de código planeadas vs Líneas de código reales por clase

0 20 40 60 80 100 120 140 160 18095

102

109

20

45

55

40

30

50

30

40

80

20

130

70

80

20

121

85

119

38

14

48

53

17

48

48

27

29

37

157

61

31

23

LOC Reales LOC Planeadas





Revisión: 02


.

4.2.2 Líneas de código planeadas vs Líneas de código reales por integrante

050

100150200250300350400450

0

235200

411

170

0

198 218

404

136LOC PlaneadasLOC Reales

LOC Planeadas vs reales por integrante

Una vez más se muestra el desempeño del grupo por integrante. Hasta este punto se podría decir que el rol del líder de desarrollo fue un rol muy cargado de actividades, pero al analizar la gráfica de Tiempo planeado vs tiempo real por integrante se evidencia que las actividades fueron distribuidas uniformemente. Aunque se podría pensar que Jonathan fue el miembro del equipo más eficiente en cuanto a producción de LOC, la gráfica que muestra la Productividad nos dice otra cosa.





Revisión: 02


4.3 Tiempo planeado vs tiempo real

Tiempo planeado Tiempo ejecutado

580

620


Horas

El tiempo mostrado por la gráfica anterior abarca el tiempo total que se planeó y se requirió para ejecutar todas las fases del primer ciclo. Se trabajó un 7,03% más de lo planeado.

4.4 Tiempo planeado vs tiempo real por integrante

0

2

4

6

8

10

12

14

16

10.511.8 12 11.75 11.95

10.28.75

15.78

11.95

15.4

Horas planeadasHoras reales





Revisión: 02


Tiempo promedio planeado por integrante: 11,64hTiempo promedio real por integrante: 16,4h

El tiempo mostrado por la gráfica anterior abarca el tiempo total que se planeó y se requirió para ejecutar todas las fases del primer ciclo por cada uno de los integrantes del equipo.

4.5 Tiempo gastado por fase

Lanzam

iento

Estrat

egia

Planea

cion

Requeri

mientos

Diseño

Implem

entac

ión

Prueb

as

Postmorte

m0.00%5.00%

10.00%15.00%20.00%25.00%30.00%35.00%40.00%45.00%50.00%

0.32% 0.81%6.93% 5.44% 6.44%

17.53%14.26%

48.28%Tiempo gastado por fase

Porcentaje

En la gráfica anterior se muestran los porcentajes de tiempo real que se requirió para llevar a cabo cada una de las fases. En la fase donde más se invirtió tiempo, fue en el postmortem, en la elaboración de la presentación y del respectivo informe.





Revisión: 02


4.6 Productividad

0.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

0.00

132.00

112.95

89.78

113.33

Productividad

LOC/Hora

La productividad nos muestra una producción de líneas de código en promedio de 112,0115 LOC en donde solo se tuvieron en cuenta la información de los miembros del equipo que tuvieron asignadas actividades de desarrollo.





Revisión: 02


4.7 Defectos encontrados por fase

Lanzam

iento

Estrat

egia

Planea

cion

Requeri

mientos

Diseño

Implem

entac

ión

Prueb

as

Postmorte

m05

10152025303540

0 1 3 610

37

10

0

Defectos encontrados por fase

Cantidad defectos

Defectos en total: 67 DefectosCantidad de defectos encontrados antes de la fase de pruebas: 30 Defectos que corresponden al 85,07%

4.8 Metas de lanzamiento

A continuación se muestra la evaluación de las metas definidas en el lanzamiento del ciclo:

4.8.1 Metas de equipo

Meta Resultado

El número de horas de trabajo del ciclo debe ser menor o igual a 270 horas

En realidad fueron 285,08h.





Revisión: 02


Porcentaje de información registrada en el repositorio del proyecto igual al 100% según los artefactos planeados a generar.

100% de los artefactos fueron subidos en el repositorio.

Requerimientos solicitados incluidos en el producto final mayor al 100%.

Se terminó de desarrollar el 100%.de los requerimientos

Porcentaje de defectos encontrados antes de iniciar las pruebas 80%.

Los defectos resultado de las revisiones de pares antes de iniciar la fase de pruebas corresponden al 85,07% de los defectos totales

4.8.2 Metas de cada rol

4.8.2.1 Líder de equipo:

Meta Resultado

Motivar al equipo para que las actividades estén registradas al 100% antes del 27 de Julio de 2013

Las actividades para el 27 de Julio faltaban 5 tareas que correspondían a 13,5% de las tareas totales (37)

Terminar todas las actividades antes del 27 de Julio.

Las actividades que tenían que ver con el desarrollo del producto fueron terminadas antes de la fecha de entrega, pero las actividades administrativas tales como el postmortem se realizó 10 días después de lo previsto.

El 100% de los miembros registran la información en la plantilla de TSP.

Aunque no hubo la disciplina esperada, todos los miembros del equipo registraron las actividades en la plantilla de TSP.





Revisión: 02


4.8.2.2 Líder de planeación

Meta Resultado

Incluir el 100% de las tareas en el plan de trabajo.

Al igual que en el ciclo uno para este en el inicio se elaboró una plantilla de Excel incluyendo en su totalidad los entregables del producto y del proyecto, en base a esta se generó el plan de trabajo. La meta se alcanzó en un 100%

Documentar el plan de trabajo y registrarlo a través de una herramienta de control como TSP.

A partir de la Plantilla y el plan de trabajo se creó la planeación de TSP.

Planear de tal forma que las horas de trabajo a la semana por cada miembro del equipo estén entre 8 y 18 horas.

Esta meta se logró en un 100% ya que con las lecciones aprendidas del primer ciclo, para la planeación se tuvo en cuenta tanto los entregables del producto como los del proyecto, sin embargo en este ciclo los entregables del proyecto fueron mínimos debido a que en el ciclo anterior se realizaron la mayoría.

Proveer un reporte del estado del proyecto semanalmente.

Se utilizó la plantilla de TSP para la generación de reportes los cuales nos ayudaran a visualizar el estado del proyecto. Esta fue empleada en el ciclo anterior con buenos resultados.

Verificar que los miembros del equipo reporten el tiempo usado y estado de

El líder de plantación hacia seguimiento del reporte de actividades





Revisión: 02


las tareas asignadas. en la herramienta, en caso de encontrar faltantes o inconsistencias se comunicaba con el miembro del equipo para hacer revisión de estos casos.

Planear tareas de tiempo no superior a 5 horas.

Esta meta se cumplió a un 100%.

4.8.2.3 Líder de desarrollo

Meta Resultado

La estrategia es comprendida en un 100% por los desarrolladores.

Los desarrollos necesarios para este ciclo fueron muy atómicos, por consiguiente a cada desarrollador se le asigno requerimientos de granularidad fina, lo cual contribuyo a que la estrategia fuera comprendida fácilmente.

100% de los requerimientos desarrollados por ciclo

Se realizaron el 100% de los requerimientos para este ciclo, el cual comprendía los diferentes criterios y el cargue de la información.

Líder de calidad

Meta Resultado

Todos los miembros del equipo registran la información del proceso en el 90% de los casos.

Todo el equipo contribuyo, para que de acuerdo a la distribución realizada del trabajo, cada entregable fuera entrada para otra parte del proceso, y para cada artefacto se definió un par revisor esto nos sirvió para controlar la elaboración de los entregables del proyecto y del producto. El 95% de los casos fueron registrados en el





Revisión: 02


repositorio los artefactos generados que respaldan la calidad del producto y del proceso.

4.8.2.4 Líder de soporte

Meta Resultado

La sumatoria de los problemas reportados por los desarrolladores sobre el funcionamiento de las herramientas no debe superar 4.

Las herramientas, por su nivel de madurez permitieron alcanzar la meta solo se reportó una caída temporal del servidor de versiones de Google.

Realizar un plan para el manejo de versiones con el fin de lograr que se pierda 0% del código fuente.

Se implanto una estrategia para el manejo de las versiones del software, la meta se cumplió, porque se presentó 0% de pérdida de trabajo.Además se implementó una política de Backup para mitigar el riesgo de caída parcial del servidor de versiones de Google.

4.9 Propuestas de mejoramiento del proceso

A continuación se describen las propuestas de mejoramiento registradas en los formatos PIP:

4.9.1 Propuesta 1

4.9.1.1 Descripción del problema

Todo el equipo de trabajo no fue muy disciplinado con el registro de actividades.





Revisión: 02


4.9.1.2 Propuesta de mejoramiento

El líder del equipo debería motivar e Incentivar al equipo al equipo para que sea disciplinado con el registro de actividades. El líder debería demostrar la importancia de llevar un registro de actividades actualizado y de poder monitorear y controlar la ejecución de un ciclo basado en esa información. Se podría proponer un sistema de multas o penitencias para el que no tenga las actividades que haya completado registradas hasta antes de un día determinado.

4.9.2 Propuesta 2

4.9.2.1 Descripción del problema

Cuando un miembro del equipo terminaba una actividad que generaban artefactos que servían de entrada para la actividad de otro miembro, a veces no se comunicaba la finalización de dicha actividad y el otro miembro perdía tiempo esperando a ser comunicado.

4.9.2.2 Propuesta de mejoramiento

Se debería plantear desde un principio que cada vez que un miembro del equipo finalice alguna de sus actividades asignadas, reporte por correo con copia al líder del equipo y de planeación la finalización de las actividades. Esto sirve no solo para comunicar al interesado en continuar con una actividad, sino que también sirve para que el líder de planeación y del equipo lleve un control sobre las actividades.





Revisión: 02


Informe Postmortem Ciclo 2

Documents

Transcript of Informe Postmortem Ciclo 2