archivo

Archivo de la etiqueta: desarrollador

Teniendo en cuenta que el desarrollo de software tiene una naturaleza colaborativa (participan personas y se necesita de todas ellas para sacar el trabajo adelante) se entiende que cuanto menor sea la separación (y no hablo de distancia física) entre las diferentes personas que participan en el proyecto, mayor probabilidad de éxito tendremos.

Por eso soy de la opinión de que los desarrolladores deben tratar con los usuarios en todas las etapas o ciclos de desarrollo de un producto. El feedback no solo se trata de palabras sino también de sensaciones y esto último te lo pierdes si no tratas con las personas que van a usar la aplicación. Por mucho que te lo cuenten no es lo mismo.

Es posible que existan proyectos donde la relación entre las partes sea tan mala que tal vez lo mejor sea utilizar intermediarios, en cualquier caso debería tratarse de una situación transitoria porque normalmente la mejor decisión que se puede tomar en estos casos, si no se consigue reconducir, es llegar a un acuerdo para dar por terminada la relación contractual.

Crear barreras e interfaces artificiales entre personas solo originan distancia y ese incremento de la misma afecta inversamente al conocimiento. Deja que el desarrollador tenga su propia perspectiva, deja que los usuarios interaccionen con los desarrolladores, dejan que compartan opiniones, deja que aprendan juntos.

Recordemos que se trata de ir eliminando esa distancia entre lo que los desarrolladores creen que hay que hacer y lo que los usuarios creen que quieren. Las diferentes versiones del producto irán aproximando esas visiones a la del producto que se espera y, como es lógico, es más efectivo si todas las partes contrastan sus perspectivas.

Que los desarrolladores tenemos gran culpa de lo que sigue siendo la crisis del software no nos debe caber duda.

Sé que no es justo que englobe a todos en esto porque hay muchas personas y muchos equipos que tratan de luchar contra esto y están invirtiendo poco a poco la tendencia, no obstante la realidad de nuestro sector sigue siendo esa y por ese motivo, entre otros, no tenemos el reconocimiento que tienen otras profesiones.

Ahora bien, también tienen gran parte de culpa los responsables funcionales, por lo menos para repartirla casi de manera igualitaria, por haber dado malas especificaciones de lo que realmente necesitan y/o por no implicarse de la manera que deberían en los proyectos.

Da igual que tu desarrollo sea perfecto si la orientación que se le ha dado al mismo no ha sido la adecuada.

Una vez puestas las cartas sobre la mesa, tenemos el atenuante de que desarrollar un buen software es una tarea muy compleja y también lo es traducir pensamientos e intuiciones abstractas en especificaciones.

Partiendo de esa base, la elección de una buena estrategia adaptada a las necesidades del proyecto y su contexto, la aplicación de buenas prácticas, la intención de todas las partes por tratar de sacar el producto adelante y la existencia de un presupuesto acorde a las necesidades resultan fundamentales para incrementar las probabilidades de éxito.

Supuestamente dentro de un proyecto de desarrollo de software todo el equipo tiene acceso al código que se está desarrollando y, por tanto, se podría considerar que existe una propiedad colectiva del mismo, sin embargo esa apreciación es más teórica que real, porque lo que suele suceder es que los desarrolladores pongan reparos en que otros toquen lo que han construido. Somos así, ¿qué le vamos a hacer?.

Considero un acierto por parte de XP que considere como práctica la propiedad colectiva del código, es decir, que se fomente que cualquiera pueda trabajar y mejorar con cualquier sección del código la hubieran desarrollado ellos o no. Y no lo comento solo por motivo de dar una mayor flexibilidad o disponibilidad al equipo, sino porque otro punto de vista generalmente suele ser positivo (por eso ese mismo enfoque de desarrollo tiene entre sus recomendaciones la programación por pares).

Para que este concepto se aplique de manera efectiva en un proyecto es fundamental el respeto. En el momento en que se pierden las formas por la solución en que una persona ha realizado un desarrollo, se empiezan a levantar muros. Y es que es fácil reirse o llevarse las manos a la cabeza por determinadas codificaciones pero realmente haríamos lo mismo si revisásemos código nuestro construido hace años (o tal vez no desde hace tanto tiempo).

También es importante no olvidar que se tiene que desarrollar con intención con propiedad colectiva o sin propiedad colectiva, es decir, no se trata de ponerme a retocar tal o cual funcionalidad o a refactorizar tal o cual clase o módulo, sin un propósito o poniendo en riesgo los compromisos que el equipo ha pactado para el sprint.

El retrabajo es volver a trabajar sobre un determinado desarrollo o la realización de nuevo de una serie de tareas (que puede ser de mayor o menor entidad) y que ha podido ser perfectamente evitable.

Tiene un impacto importante en los proyectos porque es tiempo perdido, esfuerzo que no ha proporcionado ningún valor al proyecto.

En el desarrollo de software estamos acostumbrados a hacer y a rehacer, la diferencia con el retrabajo es la diferencia entre la intención y la negligencia. Se ha podido desarrollar una funcionalidad con intención, de manera meditada y después el usuario descartarla porque una vez desarrollada no le termina de ver utilidad en el sistema.

Se ha ido con una idea concreta y se ha fallado, la negligencia es cuando sin esa reflexión necesaria u obviando soluciones más claras y probables se decide tirar hacia adelante.

Es cierto que entre intención y negligencia hay toda una escala de grises y que cada caso concreto merece su análisis. No obstante, las situaciones extremas son fácilmente identificables y cuando se mete la pata resulta complicado disfrazarlo.

El retrabajo puede ser motivado por el product owner pero también por los desarrolladores.

¿Se quiere mejorar la productividad en los desarrollos? No solo basta con simplificar o eliminar tareas que aportan un valor escaso o nulo con respecto a la inversión necesaria para realizarlas, también es muy importante evitar, en la medida de lo posible, el retrabajo.

No resulta positivo que los desarrolladores intervengan en exceso en la definición de las historias de usuario, más allá de dar salida a las especificaciones de usuario con prototipos (pantallazos) que permitan facilitar la comprensión al usuario del efecto que tiene la definición que ha realizado.

No debemos olvidar que el producto no es para los desarrolladores sino para los usuarios.

El otro extremo, en los que los desarrolladores son meros ejecutores de las historias de usuario tampoco es el mejor modelo, ya que los desarrolladores pueden detectar funcionalidades que no terminan de encajar en el sistema y/o que tienen una complejidad que está muy por encima de los beneficios o valor que va a proporcionar a los usuarios.

Alistair Cockburn lo resume bien en la siguiente reflexión (traducción libre): “Un proyecto sufre cuando los desarrolladores no mencionan los problemas que descubren. El proyecto pierde la interacción creativa de programadores ofreciendo sus conocimientos para perfeccionar las peticiones de los clientes”.

La mejor solución es la doble dirección, es decir, desarrolladores y usuarios realizando y conociendo sus responsabilidades y funciones, colaborando, ofreciendo conocimiento y abriendo debates cuando sea necesario.

Principio 5: Ya que las pruebas solucionan solo una fracción de los defectos, debes tener pruebas de calidad.

El día que los desarrolladores asimilemos esto, las cosas empezarán a cambiar.

Tenemos un mal endémico, no probamos. Esto es así y cuando lo hacemos nuestros resultados no suelen ser buenos ya que no le prestamos a esta actividad la importancia que merece.

Para muchos desarrolladores, lo que importa es parar el reloj y dar por completada la tarea. Esto es como si un jugador de ajedrez realizara un movimiento sin haber estudiado bien la situación, es probable que la partida la lleve bien de tiempo, pero probablemente la tenga muy mal en el tablero.

Después, cuando empiezan a aparecer errores, vienen las prisas por corregirlos, las cuales traerán nuevos errores, además de los que no se han terminado de arreglar, entrando en un ciclo que hace mucho daño al proyecto y al producto, porque no solo afecta a la velocidad de desarrollo o la confianza de los usuarios en nuestro trabajo, sino que económicamente puede tener efectos devastadores para el que desarrolla, al tener que rehacer una y otra vez diversas porciones del código y para el cliente, con un sistema en producción que no puede ser utilizado de manera adecuada y/o que no se adapta a las necesidades y expectativas puestas en él.

El testing se puede hacer de muchas maneras y a diferentes escalas, intercalando procesos automáticos y manuales, interviniendo desarrolladores, usuarios y personal independiente, de manera continua durante el desarrollo y como última barrera de defensa antes de la entrega.

Y no solo se trata de testing, es necesario gestionar las expectivas de manera continua.

El esfuerzo que sería necesario dedicar al testing es potencialmente ilimitado. En ese momento entra en juego las características del sistema que estamos desarrollando y el presupuesto disponible. Se trata de ser eficiente, productivo, de aprovechar de la mejor manera posible nuestro esfuerzo. Probar por probar no sirve de nada, se tiene que hacer con intención y sabiendo muy bien lo que se hace.

Uno de los motivos que dan lugar a deficiencias funcionales, problemas de integración, numerosos bugs, etc… es que los desarrolladores damos demasiadas cosas por supuestas.

También es un mal de los responsables funcionales pero debemos tener en cuenta que somos nosotros los que mandamos sobre nuestra cocina y por tanto, decidimos si tenemos suficientes ingredientes o no para poder elaborar nuestros platos. Otra cosa bien distinta es que nos “obliguen” a cocinar sin la materia prima necesaria, quienes toman esa responsabilidad deben saber que difícilmente de esta forma saldrá el plato esperado.

¿Por qué se dan por supuestas tantas cosas?

– Falta de comunicación. Es el principal motivo. Nos da pereza y/o pudor tener que estar consultando cosas, incluso en determinados momentos de manera continua. Tenemos que intentar evitar esas sensaciones, nuestro objetivo debe ser contar con toda la información necesaria para poder realizar nuestro trabajo con intención y de manera efectiva. No debemos cubrir los huecos que dejen los usuarios o nuestros compañeros salvo que sean cosas evidentes.

En el ámbito del equipo de desarrollo, las reuniones de tipo Daily Scrum ayudan mucho, si no lo has puesto en marcha, prueba y verás como mejora la comunicación del equipo; si ya la has puesto en práctica y piensas que no te funcionó, ¿realmente has llegado a obtener mejores resultados no aplicándola?.

En el desarrollo iterativo incremental la comunicación entre desarrolladores y responsables funcionales es intensa y es uno de los beneficios más importantes que aporta este enfoque. No solo obtenemos feedback en las demos o en las retrospectivas, no solo se revisan las prioridades en la preparación de la pila de sprint, sino que la comunicación debe ser frecuente para ir preparando el siguiente sprint mientras se desarrolla el actual (lo que se suele denominar refinamiento de la pila de producto).

No pongas muros, tíralos. La comunicación es esencial en el desarrollo de software.

– No rematar. Este es otro de los grandes problemas que tenemos los desarrolladores y uno de los aspectos que marca la diferencia entre un buen desarrollador y un gran desarrollador. ¿En qué consiste? Tendemos a relajarnos cuando estamos a punto de conseguir el objetivo, en ese intervalo entre el casi y el completo no se termina de hacer el esfuerzo final y se terminan dando por supuestas demasiadas cosas.