· Que Repetir:
o Planificación y Estimación de Nivel 0 utilizando los elementos de juicio experto de los integrantes de PA (áreas de procesos) relevantes.
El problema con este punto es la no evolución de la Estimación de nivel 0 a estimaciones de mayor nivel. Esta actitud esta relacionada con la falta de seguimiento concreto de la evolución de la documentación y los distintos niveles de desgloses que se consiguen en fases de análisis, diseño y planificación QA. Las estimaciones terminan siendo exageradas o finalmente por recortes arbitrarios sin análisis concreto, las estimaciones terminan siendo cortas o subdimensionadas.
o Confección, evolución y seguimiento de documentación mínima e indispensable, que conforman las herramientas del proceso:
Minuta RQ / ERS / Documento de Análisis / Documento de Diseño y Arquitectura / Descripciones de Casos de Usos / Plan QA / Diseño de Pruebas (unitarias - integración - sistemas - UAT) / Seguimiento y métricas de pruebas / Matríz de rastreabilidad / Gestión del proyecto.
El segundo punto puede ser reemplazado por los conocidos “User Stories” pero de cualquier modo será necesario un buen grado de especificación para el desarrollador, donde se definen al inicio de la documentación los Puntos de Función (Interfaces Internas y Externas a nivel de procesos, funciones y eventos, Consultas a bases de datos que no ejecutan un caso de uso en si mismo, informes y reportes emitidos y otros elementos importantes que se deben detectar utilizando este tipo de análisis. El mismo tipo de análisis se hace en forma conjunta con SQA puesto que será la misma cantidad de entradas que utilizará para el desarrollo del Plan QA. Con esto desaparecerían los documentos de Análisis y Arquitectura & Diseño, puesto a que en el mismo “User Storie” estará descripto este tipo de elementos, sin que sea visto formalmente. Cada “User Storie” en si mismo será un UC descripto. A partir del reconocimiento de caminos alternativos y normales, mi equipo puede iniciar la fase de construcción de TC y los iremos evolucionando a medida que empecemos a disponer de prototipos de interfaces o maquetas del producto (versiones preliminares).
Es sumamente importante llegar hasta el punto de explotación de los Casos de Uso, ya que son los que le dan forma al componente a construirse y permiten al responsable de la planificación de la prueba determinar que pruebas podrían desencadenar un fallo en la estructura del sistema.
o Mejorar continuamente las iteraciones de desarrollo por módulos, de modo tal que favorezcan las planificaciones de ciclos de pruebas
El tercer punto solo puede ser atacado si hacemos buenas divisiones del producto. Inicialmente se arma un lote del producto con todos los entregables a nivel macro, pero sin dejar nada fuera. En una fase posterior se amplia la división pero se determinan grupos reducidos de entregables y se les pone fecha de inicio y fin para el desarrollo. Lo mismo para el testing. A medida que se entrega se prueba y a medida que se detectan fallos, se corrigen. El objetivo es que cada iteración se estabilice lo antes posible. Así con todas las iteraciones. A estos hitos solapados los usan mucho en metodologías Ágile.
Este punto apuntalaría a la mejora del proceso de formación de nuevos niveles de estimación.
Se que estas actividades son las que no aprecia nuestro cliente y tienen una gran carga horaria y los esfuerzos de formación de estos artefactos son importantes. Sin embargo no los podemos descartar de llano por que son los que reflejan cuanta inteligencia de ingeniería se le puso al proyecto y al producto.
· Que No Repetir:
o Desconocer avances reales en tiempo y porcientos
o No gestionar el proyecto y sus recursos por falta de interacción de la gerencia con miembros del equipo asignado. Implica: No gestionar con herramienta común para el conocimiento del equipo de los avances en horas y porcientos y prioridades
o Describir pobremente los casos de usos detectados
o No describir los casos de usos cuando se los detecta tardíamente. Implica: No ingresarlos a nuestro proceso por no actualizar la documentación
o No actualizar otra documentación relevante del proyecto como las ERS, Análisis y Diseño entre otras especificaciones del desarrollo
o Modificaciones significativas en las iteraciones al quitarse componentes y módulos en forma abrupta para alcanzar fechas límites establecidos. En caso de ser necesarias tales modificaciones todo el equipo debe reunirse para conocer los cambios y los impactos y no enterarnos sorpresivamente
o No evolucionar la estimación de nivel 0 a las estimaciones de nivel 1, 2 y 3 a pesar de que la documentación evoluciona en buen grado
o No utilización de una herramienta de gestión simple que permita tener distintas ventanas de información para los distintos niveles de personal de la empresa
o No generar anticipadamente los casos de pruebas del proyecto llegando a instancias medias y avanzadas del proyecto sin casos de pruebas
o No dejar Recursos Humanos disponibles para los ciclos programados de Pruebas Funcionales. El testing recae sobre una sola persona y eleva la Probabilidad de No Detección
o Ejecutar el testing en tiempos comprimidos sin que se respeten los ciclos planteados en la planificación. Esto hace que las pruebas no se hagan iterativas, incrementales ni regresivas. Testing/reporte defectos/resolución/verificación (sin ciclos)
o No confundir los distintos niveles de prueba, pretendiendo reemplazar pruebas de sistemas por pruebas de integración
o Corrección proactiva de defectos sin registración de los mismos y sin ingreso al proceso
o No carga de actividades en planilla de planificación
· Principalmente luego de que todos estábamos asociados al formato se hizo un gran esfuerzo en planificación y gestión
o Exceso de horas de trabajo para cumplir metas (no representa la calidad si la meta se alcanza)
· Es uno de los principales indicadores de la falta de calidad en el ciclo de vida de los proyecto y organizacional
o No establecer y definir el ambiente pruebas en los distintos niveles posibles
· Pruebas de Unidad solo son ejecutadas por algunos miembros y sin la utilización de criterios de la industria. No existe planificación antes de construir, ni se identifican fallos posibles o validaciones que son básicas y esa falta de proceso personal impacta directamente en versiones del sistema que prueba testing.
· Pruebas funcionales son diseñadas por los desarrolladores y aceptables sin dan la garantía necesaria para el desarrollador, pero no son el objeto de la prueba principal para el mismo. Son pobremente planteadas y se refuerza la falencia con la no generación de datos de pruebas y un ambiente pobremente desplagado (sin plan)
· No hay un plan de Integración para establecer con anticipación que elementos interactúan para generar un módulo testeable, donde se apliquen pruebas de regresión (funcionales) que aseguran que no se han degradado elementos anteriores a la modificaciones y que los cambios o construcciones nuevas son las correctas.
· Pruebas de sistema, en términos establecidos dentro de los ciclos planificados de testing, necesariamente previo a la implanntación del sistema en producción y en coordinación con el equipo designado en el plan.
· Que Considerar como factor de calidad
o Tiempo de Resolución por pedidos de Cambios, quejas o defectos
· En términos negociados según la verdadera capacidad de la organización
· Sin compromisos que requieran de esfuerzos extralimitados
o Características testeadas por puntos de función (cantidad de elementos que dan valor a las funcionalidades son testeados por cada Iteración en forma cíclica con un alto grado de control)
Conclusiones importantes
1. Se sugiere que todo el proceso debe ser vigilado y cumplido garantizando la circulación completa por el mismo.
1. La realidad es que el proceso sufre una gran compresión en las etapas de implementación y testing fuera de términos normales
2. Causas posibles son:
1. Innovación en momentos poco oportunos
2. Subestimación por desconocimiento de elementos más unitarios para estimar su construcción
3. Falta de aptitudes en el equipo de desarrollo
4. Mala gestión de La Gerencia que desconoce aspectos importantes como avances reales, esfuerzos consumidos entre otros factores
5. Mala distribución de tareas y actividades de implementación
6. Alta influencia de tareas de soporte que evitan que los recursos asignados tengan dedicación significativa
7. Falta de estimación de riesgos y sus impactos
8. Momentos de desconexión en la comunicación interna
§ No hay reuniones periódicas
§ Reuniones son llevadas a cabo cuando se detecta un riesgo que en realidad ya impactó en el proceso, proyecto y producto
§ No se sigue algún modelo aprobado por la industria
2. El equipo en general es altamente reactivo y muy poco gestionado
a. Las actividades de resolución de casos u Operativas se definen según el grado de importancia que le da el responsable del producto y suelen tener un gran margen de emotividad intentando en todos los casos transferir al resto del equipo, cuales serían las posibles reacciones el cliente o del Gerente (Julio)
b. La estabilidad en la participación de los desarrolladores involucrados en proyectos depende siempre del nivel emotivo que genere un incidente que requiera soporte, siendo removidos sin más durante horas o días sin considerar otros riesgos e impactos
c. Las prioridades de resolución de incidentes, liberación de entregables u operaciones de soporte, son definidas con el mismo grado de reacción emotiva y suele presentarse con demasiada frecuencia el pedido de ejecución de pruebas de verificación escuetas, rápidas o en “tiempo de ejecución de la solución”. Esta situación empobrece la independencia del área de Aseguramiento de Calidad y entorpece el accionar en contra de la liberación del entregable. La premisa parece ser “entregar a cualquier costo”.
d. Se suele proponer con rigurosidad la no resolución de defectos que pueden mal considerarse de severidad Leve o Mejora, cuando normalmente definen la calidad del producto a nivel de apreciación (primera impresión) del usuario. En situaciones de discusión se plantea la resolución en próximas versiones, pero no la exclusión.
Como verás hay una gran gama de elementos que hacen a nuestro día a día y creo que podemos hablar mucho tiempo sobre todo esto, pero lo más importante es tomar acciones para comenzar a eliminar vicios en primer lugar, falta de competencia luego y desconocimiento en tercer lugar. De este modo minimizaremos la apatía que existe en general, sobre todo cuando se proponen nuevos elementos de trabajo o modalidad u orden de prioridad, entre otro elementos que se suelen proponer.
El desconocimiento para mi es el principal enemigo. Pocos tenemos una idea de que es un modelo de trabajo y menos aún sabemos que hacer para implantarlo como parte de la cultura empresarial. Tal es así que no es posible ni encarar una conversación que inste a mejorar el proceso personal y general por que inmediatamente surge alguna cuestión que la desvía. Por lo general estas cuestiones tienen que ver con situaciones de fracaso permanente en el pasado.
