Saltar al contenido principal

Verificación de MVP y MBI's

La verificación de MVP y MBI consiste en una prueba uno a uno de las historias de usuario por parte de las autoridades de las competencias de desarrollo e implantación para evaluar el nivel actual de la competencia.

Esta dinámica tiene como objetivo que el alumno ponga a prueba todo su proceso de desarrollo así como la forma en que están utilizando el CMMI en su beneficio.

¿Por qué existen las verificaciones?​

Algo que hemos visto al hacer desarrollos escolares es que sirven hasta que el socio empieza a usarlos, pero como nunca consideran casos de crecimiento o de uso rudo del sistema todos sus proyectos son tan endebles que en la primera prueba fuerte dejan de servir, queremos que tengas la experiencia de como es en la industria y que al final en vez de decir que tuviste un proyecto escolar tuviste un sistema real que funciona y funcionará a futuro.

Reglas​

  • La verificación de MVP y MBI's afecta a todo el departamento, se asigna la evaluación más baja de los proyectos obtenida a todo el departamento.
  • Se puede realizar una verificación con las autoridades por semana previa cita durante el periodo de la clase de las autoridades o en el horario que dispongan.
  • Cada proyecto del departamento tiene un máximo de 3 intentos por MVP, MBI 1 ó MBI 2.
  • Una verificación se considera fallida con 1 solo error que afecte el uso de la plataforma o que no cumpla con las reglas de negocio.
  • Durante 1 verificación se tiene un máximo de 3 strikes antes de que se detenga la verificación, el hecho de continuar no significa que se pueda verificar, esto debido al punto anterior.
  • Las dudas y preguntas presentadas en verificación, deberán estar sustentadas en las minutas o documentos generados y firmados por el cliente.
  • Para segundas y terceras vueltas es obligatorio mostrar como se solucionaron los errores que generaron los strikes.
  • El equipo a validar deberá haber proporcionado los manuales, lista de requerimientos funcionales y no funcionales y en caso de ser necesarios las cuentas correspondientes.
  • Se deberá probar en un ambiente de pre producción o producción, cualquier entorno de pruebas será causa de fallar la verificación.
  • Si alguno de los requerimientos funcionales o no funcionales fue mal definido y no cubre con un uso real para resolver la necesidad del cliente será causa de un strike.
  • Se requiere de la presencia de todo el equipo a tiempo, en caso de no estar presentes al iniciar contará como intento de verificación.
  • Una actitud negativa por parte de algunos o todos los miembros del equipo o departamento es causa de detener y fallar la verificación.

FAQs​

¿La verificación como me afecta?​

  • Si tu departamento no alcanza la verificación se asignará el nivel correspondiente de acuerdo a las competencias de desarrollo e implantación.
  • Por ejemplo:
    • Somos 2 equipos y uno alcanzo MBI pero el otro no verificó MVP, se asignará a todo el departamento el nivel a no haber verificado MVP.
    • Tenemos validado MVP y alcanzamos a terminar MBI pero en la verificación solo falló 1 cosa, se asignará a todo el departamento el nivel de verificación de MVP.

¿Cómo puedo agendar verificación?​

  • Por mensaje directo al Discord de las autoridades de las competencias de desarrollo o implantación. Nosotros les daremos confirmación, en caso de cualquier conflicto de horario trataremos de resolverlo pero tengan paciencia.

Me prometieron una fecha pero me movieron​

  • Recuerda que no eres el único que quiere verificar, hay otros equipos y dependiendo del semestre otros departamentos, tratamos de dar oportunidad a todos pero da la oportunidad a que demos prioridad a quien va más bajo queremos que todos salgan bien.

¿Es necesario que esté todo el departamento?​

  • Para una validación solo es necesario que este presente el equipo, pero si es obligatorio que se encuentre todo el equipo.

Tengo una situación que me impide estar en la verificación​

  • Previo aviso de 24 horas en situaciones normales, y que sea justificada no hay problema, en emergencias no te preocupes por el proyecto, resuelve y platicamos después.

Mi equipo no logró verificar el destacado de la competencia pero yo me esforcé para ese nivel​

  • Las competencias no es cuanto te esforzaste, el nivel de dominio de una competencia es el resultado del trabajo presentado tanto por ti como por el equipo, por eso tiene un nivel de asignación departamental, el hecho que seas experto en desarrollo, programación o despliegue no asegura que obtengas el nivel más alto.

¿Qué debemos hacer durante la verificación?​

  • Los miembros del equipo pueden estar haciendo otras cosas durante la verificación, pero recuerda que es una verificación de competencias y si no hay participación nos nos permite observar el nivel de dominio de la competencia, ayúdanos a evitar la asignación de un nivel independiente de acuerdo a la observación que tengamos.
  • Se recomienda que el equipo tome nota de las mejoras, muchas veces no es error de la implementación, sino del proceso de desarrollo o de las prácticas del CMMI que están siguiendo.

Me molesta que critiquen mi trabajo y se exponga frente al equipo​

  • La verificación no es responsabilidad de un miembro del equipo, si fallan es causa del equipo e incluso del departamento, recuerda que el objetivo es dar retroalimentación real.

Las autoridades hackearon nuestro sistema o dieron en un caso que no contemplamos​

  • Se siguen aplicando las mismas reglas sobre la verificación, pero también vayan más allá de lo que piensan, nuestras evaluaciones son estrictas más no es algo que no se vayan a encontrar con algún usuario o escenario real.

No somos Google​

  • No evaluamos más allá de lo que ustedes prometieron, sin embargo la verificación se vuelve más estricta cuando intentan eliminar cosas justificando la responsabilidad o ignorancia del cliente, se profesional.
  • Es una falta muy grave el querer manipular el alcance de los proyectos sin previo aviso a todos los stakeholders.

Ya probamos, en mi computadora y si funciona​

  • Vuelve a probar, el 100% de las veces los errores aparecen por que no probaron casos diferentes o raros, desde navegadores o dispositivos diferentes a formas raras en las que un usuario usaría la historia de usuario.
  • Prueba en todos los dispositivos, tamaños y navegadores que se prometieron al cliente.
  • Diseña tus pruebas para intentar romper el sistema, una mala práctica es considerar que tu sistema es como tu bebé y que no le va a pasar nada, si logras romperlo es el primer paso.
  • Intenta probar con usuarios que tengan las características del usuarios final.

¿Documentos necesarios para verificar?​

  • Manuales que ya tengan, lista de requerimientos funcionales y no funcionales y diagrama de despliegue.
  • Por lo general ustedes nos guían en como probar, piensen bien el orden.

¿Ya arreglamos el bug nos verifican?​

  • Aunque la solución al error sea simple, tienen que ser profesionales, las verificaciones son un proceso cansado para todos, por eso es 1 a la semana por equipo.

¿Cuánto duran las verificaciones?​

  • Normalmente son máximo 2 horas, a menos que truene, si pasan las 2 horas y no hemos terminado agendamos una siguiente verificación la siguiente semana y esa no cuenta como fallida.

Son muy pocas verificaciones no vamos a sacar el nivel​

  • Te damos las reglas para que desde el día 1 hagan como departamento la planeación tomando las verificaciones en cuenta.

Pero si funciona en windows​

  • Para los sistemas web no debe haber limitativa en el sistema operativo.
  • Para las aplicaciones móviles según la versión destinada y cualquier gama de dispositivo.
  • Cualquier caso no considerado lo revisaremos, pero ten por seguro que encontraremos algo más allá de lo normal.

Pueden usar producción pero ya son datos del socio no le pueden mover​

  • Danos un ambiente que si podamos usar y que no sea pruebas, si no podemos probar con libertad va a fallar la verificación.

¿Que pasa si mi cliente no quiere un servidor de pruebas?​

  • Es responsabilidad del equipo tener un ambiente para ello, deben convencer al socio de tenerlo, ellos están conscientes que su proyecto involucra una inversión, solo tampoco se pasen, nuevamente sean profesionales a lo que necesitan y que le de beneficio al socio.

Ya verificamos una historia de usuario y falla en otra verificación​

  • Cuenta como strike.
  • Si esto pasa es que su proceso de calidad está muy mal, revisen como están probando.

¿Podemos probar con ustedes sin verificar?​

  • No.

¿Es que no es una verificación, son pruebas de usuario experto?​

  • Tienes un equipo y departamento completo de desarrollo, apóyate en tus compañeros para probar antes de ir con nosotros, si necesitas apoyo de nosotros solicita una asesoría respectivamente.

Nadie nos enseña a probar​

  • No necesitas un curso para intentar romper tu sistema, solo es la voluntad de romperlo y no engañarte a que funciona.