Por Tomer Sagi
Existen 3 elementos clave que hacen que un proyecto sea exitoso:
- El factor “Hecho”
- Un proceso de proyecto repetible
- Una herramienta simple de colaboración en línea para respaldar el factor “Hecho” y el proceso del proyecto
Recientemente, mientras trabajaba en un nuevo proyecto que presentaba los siguientes riesgos:
- El cronograma es ajustado y el presupuesto no refleja el esfuerzo necesario para completar las tareas
- La plataforma de implementación es nueva para el equipo
He adoptado el enfoque de recopilar requisitos utilizando métodos ágiles y he definido Historias de Usuario apropiadas. Luego, estimé las Historias de Usuario con el equipo y pude asignar ciertos esfuerzos y presupuestos a cada Historia de Usuario. Esto me proporcionó una visión más realista del esfuerzo y el presupuesto general del proyecto.
Me di cuenta rápidamente de que, para asegurarme de que el proyecto se entregue dentro del cronograma acordado y para mantener los gastos bajo control, debemos ser capaces de determinar y medir cuándo comenzamos y terminamos una funcionalidad.
El énfasis clave está en “medir”. Me di cuenta de que si podemos determinar cuándo “terminamos” algo, entonces podemos evaluar el esfuerzo invertido en esa funcionalidad y proyectarlo en las Historias de Usuario restantes. Esto es, en esencia, la premisa de la metodología ágil y, a veces, más específicamente Scrum.
Entonces, me embarqué en un viaje para determinar cuándo algo está “Hecho”. El factor “Hecho”.
1. El factor “Hecho”
Es esencial determinar cuándo se ha completado una pieza de trabajo. Algo está “hecho” cuando el cliente lo “aprueba”. Eso es simple. Pero la gran pregunta es, especialmente cuando me pongo en el lugar del cliente, ¿qué significa eso?
Bueno, significa algunas cosas clave:
- Determinar que lo que se ha entregado funciona
- Determinar que lo que se ha entregado cumple con la “especificación” o los “requisitos”
- Como cliente, estoy contento de llevarlo conmigo y seguir adelante
Tomando lo anterior en el contexto del desarrollo de software, esto se traduce en una pregunta: ¿Qué “cosas” en el proyecto puede evaluar el cliente? ¿y cómo?
Entonces, en este proyecto en particular, tenemos las siguientes funciones:
- Wireframes
- Diseño
- Desarrollo
- Integración de diseño
- Pruebas
- Pruebas de aceptación del usuario (UAT, por sus siglas en inglés)
Las “cosas” que el cliente puede evaluar son simplemente:
- Wireframes
- Diseño
- Producto probado
Los wireframes y el diseño son entregables tangibles que aparecen en la pantalla o en un trozo de papel. Pueden ser revisados y “aprobados” fácilmente por el cliente. El producto probado es más complejo. ¿Cómo puede el cliente “evaluar” y “aprobar” un producto probado? Para mí, esto significa que el cliente debe tener las herramientas o técnicas necesarias para poder evaluar y aprobar. Las herramientas pueden ser herramientas de prueba y las técnicas podrían incluir personas que tengan las habilidades para evaluar el producto recibido. La evaluación del producto recibido se realizaría en comparación con los entregables tangibles (requisitos, especificaciones, diseños, wireframes, etc.).
Ahora que sabemos cómo obtener el factor “Hecho”, ¿cómo lo integramos en el proceso del proyecto?
Utilizando métodos ágiles, podemos crear y repetir un proceso de entrega de principio a fin varias veces a lo largo del proyecto. Utilizando versiones e iteraciones, podemos desarrollar Historias de Usuario y pasar por todo el “proceso” y completarlas “hechas” de manera oportuna. Un “proceso repetible” es la clave para habilitar esta forma continua y efectiva de entregar y aprobar Historias de Usuario.
2. Proceso de proyecto repetible
Es esencial tener un proceso cristalino que se pueda seguir una y otra vez al pie de la letra y que proporcione resultados tangibles y precisos. Basado en las funciones mencionadas anteriormente, aquí hay un ejemplo de “Proceso Repetible”:
- Requisitos, casos de prueba y diseños
- Aclarar requisitos
- Desarrollar casos de prueba
- Desarrollar wireframes
- Revisar con el cliente (el concepto de “Profundidad de Iteración” garantizará que se realice un número fijo de iteraciones con el cliente)
- Revisar con el equipo (factibilidad de los wireframes)
- Aprobación por parte del cliente
- Desarrollar diseños
- Revisar con el cliente (número fijo de iteraciones)
- Revisar con el equipo (factibilidad de los diseños)
- Aprobación por parte del cliente
- Actualizar requisitos
- Actualizar casos de prueba
- Aprobación de requisitos
- Aprobación de casos de prueba (ya que podrían ser utilizados por el cliente para probar el producto también)
- Desarrollo
- Desarrollo de funcionalidad de backend
- Conversión de diseños en plantillas HTML/CSS
- Integración de diseños y código
- Pruebas unitarias e integradas
- Cerrar versión
- Pruebas funcionales y otras pruebas (entorno de preparación)
- Implementar en un entorno de preparación
- Comunicar la versión al equipo de pruebas
- Realizar pruebas en el entorno de preparación
- Corrección iterativa de errores
- Pruebas de UAT
- Implementar en un entorno de UAT
- Comunicar la versión al equipo de UAT (equipo del cliente)
- Pruebas de UAT (en comparación con los requisitos y/o casos de prueba)
- Corrección iterativa de errores
- Aprobación de la versión
Lo anterior es solo un ejemplo y algunos proyectos pueden diferir ligeramente o en gran medida según las necesidades de ese proyecto en particular.
3. Herramienta simple de colaboración en línea para respaldar el factor “Hecho” y el proceso del proyecto
Ahora solo necesitamos una herramienta simple de colaboración en línea para facilitar el factor “Hecho” y asegurar que el proceso repetible se establezca y se siga en cada iteración y versión. ¿Simple, verdad?
Tomer Sagi es un Gerente de Proyectos de TI Senior que ha estado gestionando proyectos de software utilizando metodologías RUP, Prince2 y ágiles durante los últimos 4 años. Ha introducido a las empresas en métodos y prácticas ágiles, incluyendo Scrum, Scrum-ban, Lean y TDD. “Chaos Dimention” es una consultoría de gestión de proyectos y una empresa de servicios profesionales con sede en Wellington, Nueva Zelanda. “tProject” es un blog de Tomer Sagi que recopila y comunica métodos y prácticas de gestión de proyectos prácticos y probados en el tiempo. Echa un vistazo en http://www.chaosdimention.com/.
