Muchas veces nos encontramos con estudios de desarrollo de software o fábricas de software que dicen utilizar Scrum para entregar a sus clientes proyectos ágiles sin mencionar que claramente se refieren a hacerlo más rápido que la competencia. He tenido la oportunidad de colaborar en diferentes de éstas fábricas y he compilado una serie de recomendaciones para aquellos que deciden iniciar su propio negocio en esta industria. El contenido será entregado a través de la categoría #AgileSoftwareFactory de éste blog. En éste primer post, te comparto algunas de las antiprácticas o antipatrones más comunes en ésta industria para las diferentes etapas del proyecto. Te invito a su lectura y al final saber si te sientes identificado.
¿Cómo cotizar un proyecto?
Lo primero que el cliente quiere saber es: -muy bonito y todo, pero ¿Cuánto me va a costar?. En este primer próximo post de la serie vamos a recorrer una serie de herramientas que nos van a permitir entender el negocio del cliente, el problema que quiere -y queremos- resolver y los beneficios que se esperan obtener con el resultado, lo que por supuesto nos ayudará a posteriormente establecer la visión y objetivos para medir y establecer entregas de valor.
¿Cómo identificar las historias de usuario y transmitir claramente éstas conversaciones entre ingenieros de software y usuarios del negocio?
Las historias de usuario nacieron como una sugerencia de lo que podrían ser y fuimos nosotros las que inmediatamente las aceptamos como una verdad, como si se tratarán de un formato distinto para hacer un caso de uso, pero, las historias de usuario son más allá de eso, son así de simples: un recordatorio de una conversación a tener en el futuro. En esta serie vamos a explorar las buenas prácticas de las historias de usuario, sus elementos, propósitos, encapsulamiento y métricas.
No hagas cascadas ágiles o cascágiles
Los seres humanos siempre pensamos de forma secuencial, tenemos un sólo cerebro, por lo que es justificable. Cuando comenzamos una fábrica de software creemos inconscientemente que debemos hacer las cosas de forma secuencial: analizar, diseñar, construir, probar y liberar en donde no puedes hacer desarrollo de software sin antes tener todo el diseño gráfico del sistema (y sin imaginar si quiera que debes hacer diseño y arquitectura de software). Por lo que usas scrum únicamente en la fase de desarrollo, déjame decirte que no, no eres ágil. Pero, ¿Cómo realmente se implementa Scrum si no he hecho todo el diseño del sistema? ¿Cómo implemento Scrum si Scrum no me dice cómo analizar? Creer que Scrum es exclusivo para programar es el error.
Manosear el sistema para ver si algo falla no significa probar software
Probar software es una disciplina de la Ingeniería de Software, existen métodos, prácticas y procesos para hacerlo y hacerlo bien. Una práctica común es colocar el sistema al que llamaremos «pruebas» y dejar que el líder del proyecto o su mal sinónimo scrum master, haga las pruebas del sistema únicamente basándose en los requerimientos que recuerda con la esperanza de encontrar todos los defectos para que se entregue un producto con una calidad aceptable. Pruebas hechas sin siquiera un plan es un error, pruebas hechas sin conocer cuales son los casos de pruebas es un error. En todo caso lo más parecido serían las pruebas exploratorias pero aún así, sin un plan solo estás manoseando software.
Liberar
Aquí es cuando al fin tu cliente se entera que después de 4 meses de tu promesa de terminar con el proyecto has terminado y ya le estás entregando, pero sucede que durante la demostración el cliente dice: Nada de eso fue lo que te pedí. Todos en silencio presenciando una discusión donde el cliente trata de ser no perder los estribos -y a veces lo pierde- y si tu mejor respuesta es decirle al cliente: Eso que dices no te lo coticé. Déjame decirte amigo, que tu proyecto acaba de fracasar.
Una fábrica de software no solo es un negocio que otorga buenos rendimientos, es poner al servicio de la sociedad una disciplina de la ingeniería de software y que dichas práticas, métodos y procesos deben ser pruestos en práctica comenzando por lo básico: sus reglas. ¿No tienes experiencia? No importa, comienza con lo básico y poco a poco contruye tus propias reglas de ingeniería que te diferencien de otras fábricas. Pero…
¿Te sentiste identificado? ¿Por donde debes comenzar?
Sigue visitando el blog para que conozcas cómo ir desarrollando tu propia fábrica de software. Compartiré todo lo que necesitas saber desde cotizar el proyecto hasta entregárselo al cliente, pasando por el análisis de requerimientos, construcción, pruebas y calidad, integración y despliegue continuo y herramientas que tu equipo requiere.
¡Hasta entonces y muchas gracias por leerme!