Se valen de metodologías ágiles reactivas para los desarrollos, tipo Scrum o Programación Extrema (XP). Enmarcados dentro de lo que se conoce como Ingeniería de Requisitos los profesionales buscan siempre resultados que cumplan con las expectativas de los clientes y los plazos de entrega cuantificados de antemano. La pregunta que deben formularse a priori es: ¿estarían dispuestos los clientes a pagar por esto?
Puede ser que la idea de negocio sea propia y los desarrolladores estén integrados dentro del equipo. En este caso les resulta sencillo identificar las características o factores de calidad que desean incorporar al software. Más complicado resulta cuando trabajan para terceros, cuando cuesta especificar la utilidad, sus valores y la viabilidad. Las metodologías ágiles se aplican 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 y la flexibilidad son fundamentales. En estos casos, esta suele ser la forma de trabajo de los equipos:
Historias de usuario
Las historias de usuario sirven para captar esos requisitos deseados describiendo, en frases concisas, los atributos de calidad o características que nos gustaría que incluyese el software. Aunque todo gire en torno al cliente, en estos casos no siempre se trata de salir a la calle y preguntar a cualquiera lo que le gustaría (en XP sí lo hacen), sino que, debido a la complejidad de las soluciones, son los mismos ingenieros o personas críticas de la organización, stakeholders, quienes se ponen en la piel del cliente en una especie de lluvia de ideas. Al final de la misma, cada uno de los participantes habrá plasmado un requisito en un post-it o una tarjeta, valiéndose de una o dos frases sencillas. La colección de todas esas historias se conocen en la metodología Scrum como backlog, expuestas luego como en una lista de deseos que harán de ese producto algo distinto y genial.
Cómo se hacen las historias
Según Juan Carlos Yelmo, profesor de la Universidad Politécnica de Madrid, las historias de usuario son descripciones concisas y con lenguaje sencillo que cualquiera puede entender. La fórmula habitual para crear una historia de usuario es Yo (entendido como un rol, por ejemplo usuario de una entidades financiera), necesito (describiendo la funcionalidad que me convendría, por ejemplo sacar dinero en cualquier cajero y a cualquier hora), con la finalidad (descripción del beneficio o valor que me aporta, por ejemplo evitar las limitaciones de espacio y tiempo). De esta manera, aunque el estilo sea libre, la recomendación es que cada historia de usuario responda a las preguntas de ¿Quién se beneficia?, ¿qué se quiere? y ¿cuál es el beneficio?
Cuando las historias son demasiado largas, se las denominan épicas y, en su caso, la recomendación es descomponerla en otras más pequeñas y reducir así la dificultad para comprenderla, estimarla y aplicarla. La suma de requisitos o historias de usuarios deberán reunir, según Juan Carlos Yelmo, seis criterios de elaboración: que sean historias independientes o con débil conexión entre ellas; ser negociables tanto por el resto del equipo como con los stakeholder, evaluables en el sentido del valor que aportan al cliente, estimables o cuantificables aportando alguna métrica de coste en su desarrollo, pequeñas, para que quepan en un sprint y comprobable, es decir que se pueda testar mediante pruebas y criterios de satisfacción.
El desarrollo
Dado que las historias de usuario representan el punto de partida, la preocupación no es todavía el cómo se van a conseguir esos requisitos. Es en una segunda fase cuando, con toda la lista de deseos, se abre la discusión entre los implicados y se analizan las propuestas, se valoran, se priorizan, se cuantifican y se encomiendan a los profesionales para su desarrollo.
A la lista ya priorizada de las funcionalidades importantes se la denomina, en la metodología Scrum, Product Backlog. A cada equipo se asignan distintos requisitos que deberán resolver en un determinado espacio de tiempo, sprint, el cual puede calcularse por horas, días o meses, aunque la media de duración es de 2 semanas. Cada sprint coincide con una iteración donde se presenta un resultado completo, un incremento del producto potencialmente entregable al cliente, conocido aquí como el Product Owner.
Asimismo, a cada equipo se le asigna un Scrum Master quien se encarga de facilitar el trabajo y atender las necesidades de los integrantes sobre la marcha. Mientras avanzan, el equipo celebra breves reuniones diarias para inspeccionar el trabajo del resto y compartir obstáculo y donde se actualiza el estado de la lista de tareas o requisitos pendientes (Sprint blacklog). Al final de cada Sprint, todas las historias en el Sprint Backlog deberían haberse completado, testeado y estar listas para ser entregadas al usuario. Las reuniones sirven también para sincronizar el proyecto e inspeccionar los plazos, el burndown charts, que permite la medición diaria de la cantidad de trabajo histórico y pendiente.
Así es como, en Scrum, se van realizando entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. La diferencia con la programación extrema XP es que incluye al cliente final como parte fundamental, que admite cambio de requisitos sobre la marcha y posterga las funcionalidades extra a la resolución primera de los requisitos.
vía Así desarrollan las startups un software