Cómo crear una App: Metodologías y Desarrollo IBX

Una Metodología Ágil es un marco teórico que permite mejorar la eficiencia y calidad en el desarrollo de una App, tiene la capacidad de respuesta ante los cambios que suceden en todos los proyectos y brindan la mayor satisfacción posible al cliente a través de la entrega continua de valor y retroalimentación  sobre el desarrollo del producto.

Existen numerosas metodologías ágiles para el desarrollo de una App, pero las más representativas son las siguientes:

  • Lean Product Development: Basado en los principios de Lean usa los principios de eliminar pasos en los procesos que no agregan valor al producto final.
  • Kanban Development: Procesos con énfasis en la entrega justo a tiempo. Los desarrolladores toman trabajo de un backlog, y el proceso es visible por todos.
  • Crystal: Se enfoca en las personas, no en los procesos. Requiere liberaciones frecuentes de funciones a los usuarios.
  • Dynamic Systems Development Method: Enfoque iterativo e incremental que incluye la participación continua de los usuarios y clientes. Ocupa costos, tiempo y calidad fijas, y utiliza métodos de priorización para las entregas.
  • Extreme Programming: Mejora la calidad del producto; mediante programación entre pares, pruebas extensivas, priorización de componentes, administración sencilla y comunicación frecuente entre personal técnico y de negocio.
  • Feature Driven Development: Iteraciones cortas basadas en cinco actividades: desarrollar un modelo integral, construir una lista para planear, diseñar y construir por componente.
  • Adaptative Software Development: Consiste en series repetidas de especulación, colaboración y aprendizaje. Está enfocado en la misión, basado en componentes, es iterativo, en tiempos definidos, tiene un enfoque a riesgos y es tolerante a cambios.
  • Scrum: Metodología adaptativa, iterativa, rápida, flexible y eficaz, diseñada para ofrecer el máximo valor para el negocio en intervalos cortos de tiempo durante todo el proyecto.

Después de evaluar distintas metodologías agiles, en Ironbit optamos por utilizar Scrum, ya que es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

La metodología nace de Scrum y da como resultado el siguiente proceso:

  1. Warmup: Junta interna con el equipo donde se explican los Antecedentes, Objetivos, Alcance, Requerimientos funcionales, Requerimientos no funcionales, Expectativas de calidad del cliente del proyecto y producto, así también una plática motivacional sobre el impacto que tendrá el producto en la organización y mercado que servirá como motivación a lo largo del proyecto en distintas áreas.
  1. Creación de Wireframes: Se realiza un acercamiento en maquetado de los requerimientos acordados en el contrato del proyecto para ser mostrados en el Kick Off y en base a ello iniciar a trabajar en un análisis y en un diseño más robusto.
  1. Kick Off: Reunión formal de inicio de proyecto con cliente, para dar a conocer los Antecedentes, Objetivos, Alcance (Funcional, No Funcional), Wireframes, Equipo de trabajo, Plan de comunicación, Metodología, Plan de trabajo, Riesgos y Pasos a seguir del proyecto.
  1. Creación del Product Backlog Epic: Se recauda los requerimientos del contrato y con ayuda de los Wireframes, se realiza el product backlog Epic que es básicamente los requerimientos definidos a alto nivel para después poder priorizarlo en base al resultado que brinda cada épica en valor de negocio para el cliente.
  1. Propuesta de priorización de épicas: En conjunto con el equipo, se realiza una propuesta de priorización de épicas, tomando en cuenta las expectativas de calidad del cliente, dependencias entre épicas y valor de negocio que brinda cada épica, para proponer los requerimientos que se verán reflejados desde los primeros Sprints (entregables).
  1. Validación de priorización de épicas: Se valida con cliente la propuesta de priorización de épicas realizada con el equipo. En esta reunión se debe de justificar el como el equipo llegó a esa priorización tomando en cuenta el valor de negocio en cada épica, complejidad, dependencias y esfuerzo. Una vez validada la priorización y épicas, se procede a los siguientes pasos.
  1. Creación de Plan de trabajo con Sprints y Priorización: Se crea un plan de trabajo de épicas creadas, con la priorización ya validada por el cliente de estas mismas épicas. En el plan de trabajo se debe de determinar la longitud y el número de sprints.
  1. Validación de plan de trabajo con equipo: Se gestiona una reunión con todo el equipo involucrado en el proyecto para realizar la revisión, ajustes y validación del plan de trabajo.
  1. Validación de plan de trabajo con cliente: Se gestiona una reunión con el cliente para validar el plan de trabajo de épicas y priorización ya previamente definida. Una vez validado el plan de trabajo, se procede a los siguientes pasos.
  1. Creación del plan de entregas: Basándose del plan de trabajo ya validado, se genera el plan de entregas donde menciona que funcionalidades serán entregadas por mes para ser gestionadas en costos con el área comercial para posible facturación.
  1. Sprint Planning: Se gestiona una reunión con el equipo, para planear cada sprint del mismo proyecto, esto con la finalidad de dar a conocer las funcionalidades por sprint, tiempos, responsables y fechas compromiso. En esta misma reunión se planifica la hora, lugar donde serán los daily meetings y el medio de comunicación interna.
  1. Pre análisis del sprint con equipo técnico: En conjunto con el equipo técnico, analista y con apoyo de la documentación existente, se documentan dudas respecto a las épicas para posterior aterrizarlas con el cliente.
  1. Afinación de análisis del sprint con cliente: En una reunión con cliente se plasman las dudas que tuvo el equipo Ironbit en el pre análisis, para que sean resueltas por el cliente y tener un análisis afinado para la creación de historias de usuario.
  1. Creación de historias de usuario y criterios de aceptación del sprint: Del análisis afinado se formalizan en historias de usuario en un product backlog por sprint, que representan a un requisito escrito en 1 o 2 frases utilizando el lenguaje común del usuario y se generan los criterios de aceptación, que son características que una historia de usuario tiene que tener para ser aceptada por el cliente.
  1. Creación del prototipo del sprint: Se realiza una representación gráfica de interfaz, experiencia de usuario y navegación de las historias de usuario y criterios de aceptación del sprint con el apoyo de la herramienta “Marvel”.
  1. Integración de historias de usuario y criterios de aceptación con prototipo del sprint: Se realiza la integración de las historias de usuario con criterios de aceptación y el prototipo para ayudar tanto al cliente como al equipo a una visualización más grafica de lo que se abarcará en el desarrollo y sea más ágil su validación.
  1. Validación del prototipo e historias de usuario con criterios de aceptación del sprint por el equipo: Se gestiona reunión con el equipo Ironbit para validar el prototipo con las historias de usuarios y criterios de aceptación.
  1. Validación del prototipo e historias de usuario con criterios de aceptación del sprint por el cliente: Se gestiona reunión con cliente para validar el prototipo con las historias de usuario y criterios de aceptación.
  1. Creación de matriz de pruebas del sprint: Una vez validado el prototipo con las historias de usuario, se crea el artefacto de matriz de pruebas, para la etapa de QA del sprint.
  1. Creación de insumos del sprint: Se crean los insumos de diseño que se requiere en desarrollo para el sprint.
  1. Distribución de historias de usuario y criterios de aceptación por el equipo: Reunión con el equipo técnico para distribuir las historias de usuario con criterios de aceptación entre ellos mismos, dado a capacidades y habilidades de cada miembro del equipo.
  1. Desarrollo de producto y pruebas unitarias del sprint: El equipo técnico realiza el desarrollo del producto e implementación de pruebas unitarias del sprint.
  1. Daily meetings: Reuniones que se tiene que llevar a cabo diario con todo el equipo involucrado en el proyecto con una duración de 15 minutos, para saber el estatus de la creación del producto con 3 simples preguntas ¿Qué hiciste ayer?, ¿Qué estás haciendo hoy? y ¿Qué impedimentos tienes para cumplir con tus tareas?
  1. Reporte de horas semanal del sprint: Reporte de esfuerzo en horas de todo el equipo, para llevar el control de presupuesto del proyecto y tener insumos para sacar indicadores necesarios para medir al proyecto.
  1. Reporte semanal de avance del sprint: Reporte vía correo o conferencia telefónica con cliente para dar reporte del avance que está surgiendo del sprint, como impedimentos, insumos y solicitudes que tienen que ser cubiertos por el cliente.
  1. Reporte quincenal de avance del sprint: Reporte presencial con cliente para dar a conocer los avances tangibles del sprint.
  1. Validación en calidad del sprint: Iteraciones de QA que ayudan a identificar posibles errores en el sprint concluido en desarrollo y poder ser corregidos antes de presentar al cliente.
  1. Validación de sprint: Una vez liberado el sprint por el equipo de QA, se procede a realizar la revisión final interna para verificar que se cumplan las historias de usuario, criterios de aceptación y las expectativas de calidad del cliente.
  1. Validación de sprint por cliente: Una vez aceptado el sprint internamente, se realiza la presentación al cliente para verificar que se cumpla todo lo definido en el sprint.
  1. Retrospectiva de sprint: Reunión interna de lecciones aprendidas del sprint, enfocándose a 3 preguntas principales, ¿Qué hicimos bien?, ¿Qué hicimos mal?, ¿Qué podemos mejorar para el próximo sprint?. Esta retroalimentación se deberá aplicar para sprints posteriores.
  1. Validación en calidad del proyecto: Una vez integrando todos los sprints conforme se vaya trabajando en el proyecto, se debe de realizar una validación de calidad de todo el proyecto, corrigiendo las incidencias que vayan saliendo en cada iteración de QA.
  1. Validación de proyecto por cliente: Una vez concluido con todos los sprint, y haber realizado la validación de calidad de todo el proyecto, se realiza una reunión con cliente para la demostración de que el proyecto cumple con todas las historias de usuario, criterios de aceptación y expectativas definidas por el mismo.
  1. Retrospectiva de proyecto: Reunión interna de lecciones aprendidas del proyecto, enfocándose a 3 preguntas principales, ¿Qué hicimos bien?, ¿Qué hicimos mal?, ¿Qué podemos mejorar para el próximo proyecto?. Esta retroalimentación se deberá aplicar para proyectos posteriores.

Si deseas conocer más visita superapps.mx

 

Texto: Denisse Arriaga.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *