Avenida O

Hablemos de Software Innovador: episodio 3

Natalia C. Alfaro para El Observador En este tercer y último capítulo de la mini serie Hablemos de Software Innovador…

Por Blog

Tiempo de Lectura: 3 minutos
Hablemos de Software Innovador: episodio 3
Facebook Twitter Whatsapp Telegram

Natalia C. Alfaro para El Observador

En este tercer y último capítulo de la mini serie Hablemos de Software Innovador vamos a entender puntualmente el ciclo de desarrollo.

En caso que se haya perdido el episodio anterior sobre cómo la plataforma tecnológica exitosa va mucho más allá de programar código que falle poco no dude de dar click aquí para leerlo. 

Por excelencia la herramienta tecnológica que recomiendo para el desarrollo de software es la suite de Atlassian: Confluence, Jira, Service Management y todo su mercado de aplicaciones.

Estas permiten tener un ecosistema integrado que facilita el intercambio de información y tareas sin fricción alguna. 

Ahora, más allá de la herramienta y que se cumplan todas las ceremonias, lo principal es tener muy claro la visión de producto y que esta sea compartida por el equipo SCRUM.

Consejos prácticos

Entonces algunos consejos prácticos para la realización de un SDLC “Software Development Life Cycle” por sus siglas en inglés son los siguientes:

  1. Diseñar un flujo de trabajo que haga sentido para el equipo SCRUM tanto en cantidad de estados, transiciones y automatizaciones como en roles para que no exista traslape de funciones. Este flujo previo a implementación debe ser iterado por cada uno de los miembros del equipo y ser probado en un ambiente de pruebas.Algo importante a destacar es que este SDLC evoluciona conforme a la madurez y tamaño del equipo, así que preparese para hacer versionamientos del mismo. 
  2. Dividir la visión global de producto en temas generales (aún más grandes que las épicas) con el fin de definir el resultado que se espera de cada funcionalidad.  Aquí es muy importante haber utilizado las primeras 3 fases de design thinking empatía, definición e ideación vistas en el episodio anterior. 
  3. Mantener un tamaño y esfuerzo consistente para las diferentes épicas; las cuales en palabras sencillas se pueden definir como las fases en las que se ha pensado ir entregando el trabajo. Uno de los mayores errores aquí es tener épicas o subproductos muy grandes o muy pequeños con respecto al peso global del producto final. Un tip adicional es que podamos hacer uso de etiquetas para diferenciarlas fácilmente en el “backlog” del producto 
  4. Luego al descomponer esas épicas en historias de usuario que son una explicación de una función de software escrita desde la perspectiva del usuario final y que sumadas en su totalidad nos van a ayudar a poder entregar una parte del producto funcionando lo más importante son dos cosas: que queden claras como el agua para todos los miembros del equipo SCRUM y que hayan hecho bien las estimaciones. Una estimación mal hecha es el peor enemigo de un proceso de desarrollo, así que por favor invierta tiempo en instruir a todos sobre este tema y en que conozcan su velocidad tanto a nivel individual como en equipo. No tienen idea todos los problemas que se van ahorrar si su equipo estima basado en datos y no en expectativas, así que dueños de dueños de producto y lideres comerciales, no prometan entregas en fechas irreales sólo por cerrar negocios. 
  5. Tengan un proceso de calidad riguroso, donde se tengan manuales con estandares y escenarios previos de prueba, no nada más testeen dando “check” si una historia de usuario se cumple… vayan más allá y piensen en todas las posibilidades. Adicionalmente hagan uso baterías de pruebas automatizadas que permitan probar y prevenir errores que nosotros los humanos no detectaríamos.
  6. Usen diferentes ambientes para realizar pruebas antes de sacar la funcionalidad a producción porque recuerde… todo en el ambiente de calidad es seguro, es un ambiente muy controlado y dependiendo de su configuración no representa la realidad. 
  7. Hagan una demostración con entuasiasmo y confianza al cliente, ellos están emocionados del valor que usted le va a entregar y de la percepción que cada vez está más cerca de que su plataforma o aplicación finalice. 

Finalmente algo importante a destacar es que por el hecho que su empresa utilice SCRUM como marco de trabajo no significa que automáticamente la convierte en una empresa ágil. Agilidad es la capacidad de crear y responder al cambio, es una forma de lidiar y, en última instancia, tener éxito en un entorno incierto y turbulento. Lo cual hablaremos en más detalles en próximos blogs.