La etapa de desarrollo dentro de un proceso


Hilando con el artículo publicado tan solo unos días, vamos a retomar el tema de la importancia de las siguientes fases o etapas de un proceso de trabajo en un proyecto.





Hablábamos de la etapa con la que comienza todo proceso, con el diseño de la funcionalidad, la toma de requisitos, la implantación de las bases técnicas y la importancia de ese consenso o comunicación entre los equipos de negocio y de desarrollo o técnicos. 





Una vez que esta etapa se ha cumplimentado y hemos dibujado un boceto o una buena línea de trabajo en un roadmap, podemos dar el paso a siguientes fases o etapas, como la del desarrollo y la validación. Esta etapa vendrá de la mano y a continuación, de manera obligatoria, de la etapa anterior y que ya habíamos hablado, comenzando una serie de pasos fundamentalmente técnicos y que serán el corazón de la funcionalidad que ya se ha diseñado y oficializado. 





En ciertos proyectos y dependiendo de la manera de trabajar del mismo, es posible que exista un paso intermedio de realización de análisis funcionales, aunque ya, ese paso se suele fundir y solapar con el de los requisitos y funcionalidades, aportando de una sola vez todo el paquete de datos, registros, documentación o lo que fuese necesario. Esto, sobre todo, queda más patente en metodologías más nuevas, dejando de lado grandes documentos, que posiblemente no se actualicen después y dando paso a una forma de trabajo mucho más ágil y rápida. Esta manera de trabajo aporta ciertas cosas pero nos hará perder otras, que quizá sean importantes, como un nivel de detalle más profundo.












El desarrollo de las funcionalidades ha de realizarse de una manera pulcra y siguiendo las especificaciones acordadas, tanto a nivel de detalles, como a nivel de negocio, intentando no salirse de lo establecido. Para que esto no suceda, se habló de que todo ha de ser consensuado por todas las partes implicadas, de esta manera no habrá nada que pareciera fácil y después de pudiera convertir en un imposible o cerrar tiempos y entregas mucho más acotadas. 





Cuando se comienza el desarrollo, las personas encargadas de las diferentes validaciones a realizar, ya tienen que haber estipulado una base que lo cubra y que nos pueda aportar que todo lo que salga de los equipos tenga la calidad adecuada. Una de las mejores prácticas que se pueden realizar, bajo mi punto de vista, es crear un "boceto" de casos de prueba basados en los requisitos, de esta manera, tenemos cubierto todo lo solicitado, al menos mínimamente y después, se  irán sumando y agregando otros casos basados en el resto de información aportada (análisis, documentación, criterios de aceptación...).


El desarrollo, como digo, se realiza en paralelo a todo lo descrito anteriormente, así cuando está ya finalizado, todo ese trabajo entrará en juego y se podrá realizar una validación exitosa.





La comunicación, en esta etapa, entre el equipo de negocio y el de desarrollo es obligatoria, además de muy recomendada, ya que se podrán ir ajustando ciertos flecos que, seguramente, quedasen sin resolver anteriormente o que no se vieron y, si surgiera, se podría rectificar el trabajo antes de que sea demasiado tarde, por algo que no se pensó adecuadamente o que en el papel quedaba espectacular pero a la hora de reflejarlo pudiera llevarnos a un error de cara a los clientes.





La etapa de desarrollo no solo la veo como una manera de plasmar esas funcionalidades de manera técnica o escribir el código, si no como una etapa, también, de rectificación, de consensuación, de validación más técnica (con pruebas unitarias y de integración), de demostración de lo realizado y de poder ser el punto de inflexión entre el poder parar algo antes de dar el siguiente paso o de ser demasiado tarde. 





También tenemos que pensar que en esta etapa hay que optimizar el desarrollo lo máximo posible, teniendo en cuenta posibles componentes comunes, código reutilizable, multidioma, multiplataforma, tipo de lenguaje que se utilice, basándose en los análisis técnicos que se hayan realizado anteriormente y que tendrán ya especificada la tecnología que mejor se ajuste a lo que queremos crear.





En relación a esta etapa, hay ciertas ideas o corrientes de trabajo con las que no estoy de acuerdo, porque he comprobado a lo largo de los años que no funcionan, como el subir por subir o el no levantar la mano para parar  la funcionalidad en concreto si se encuentra algún problema, haciendo una subida parcial o incluso asumir errores porque no son importantes o se pueden "ocultar" y solucionarlos más adelante.





Cuando trabajamos de este modo, lo que suele pasar es que se acaba por asumir cada vez más y se pierde el control de manera total, implicando una estabilidad y una inseguridad enorme en entornos productivos. Siempre tengo una máxima, si al realizar un despliegue a producción tenemos inseguridad de como quedará, puedo asegurar que las cosas no se están haciendo bien, por mucho que hagamos validaciones, casos de prueba, que los desarrollos se estén haciendo genial y tengamos un proceso férreo y ordenado. Si la máxima se cumple, repito, las cosas no se están haciendo bien aunque nos lo parezca.





Cuando mantenemos una etapa de desarrollo buena, con las pautas que hemos tratado y mantenemos cierto control, tendremos mucho ganado, implicando a otros equipos, manteniendo la comunicación y teniendo la seguridad de que lo que se está desarrollando sea lo que se quiere y no nos llevemos una sorpresa si al entregarse la funcionalidad no se ajusta a lo solicitado.





Por esto, dentro de un proceso completo, la etapa de desarrollo y de una primera o temprana validación tiene una importancia vital para continuar por el camino de la entrega de funcionalidades a nuestros usuarios.




0 Comentarios