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.

Una de las labores más complicadas de un gestor de proyectos en aquellos casos en los que existen múltiples equipos de trabajo que pueden pertenecer incluso a proveedores diferentes (tampoco resulta sencillo hasta en aquellos casos en los que existe un solo equipo formado por pocos desarrolladores) es que todos comprendan cuáles son los objetivos y las restricciones que existen para alcanzarlos.

Resulta especialmente complicado sobre todo en aquellos equipos que están desarrollando funcionalidades o herramientas complementarias al núcleo el sistema, en primer lugar porque la atención del gestor estará más orientada a la línea principal de desarrollo del producto así como a eliminar o paliar las posibles resistencias que puedan existir en cualquiera de las distintas líneas y en segundo lugar porque, por el mismo motivo, se encontrarán a distancia del product owner y de los directores usuarios y contemplarán desde más lejos sus expectativas y su presión.

Hay proyectos donde el trabajo de estos equipos secundarios es igualmente secundario pero en otros casos el resultado de su trabajo puede ser esencial para el funcionamiento y/o para la puesta en marcha del sistema. Tanto en un caso como en otro (aunque por supuesto mucho más en el segundo) es necesario que esos equipos mantengan el enfoque y la tensión en el proyecto, de la misma forma que lo hacen aquellos equipos que están peleando con las partes más críticas del sistema.

Como decía, esto no es fácil, ya que resultaría fundamental que el product owner y los directores usuarios les expresasen directamente y de forma constante (continua) sus expectativas y eso es algo que resulta complicado en proyectos con una cierta envergadura. Ahora bien, si no es posible llegar a eso cualquier aproximación ya supone un avance. Si el equipo no termina de asimilar la situación, el gestor de proyectos debe actuar y en estos casos es mejor un falso positivo (pensar que el equipo no es consciente de la situación e insistir) que creer que se ha asimilado y no actuar.

Cuantas más personas se suban al barco más posibilidades hay de sacar el proyecto adelante, sin olvidar que hay que procurar que quien suba no vuelva a bajar (de ahí la importancia de las actividades necesarias para que los equipos y los desarrolladores mantengan el enfoque en el proyecto).

Uno de los problemas que nos podemos encontrar con frecuencia en un proyecto de desarrollo de software lo tenemos cuando el desarrollador piensa que sabe tanto del negocio como los usuarios y se olvida de que el producto no es para él sino para los usuarios.

Que un desarrollador conozca el negocio muy bien es algo muy interesante para el proyecto siempre y cuando no se caiga en el error de empezar a tomar decisiones sobre lo que le gustaría a él que hiciera el producto sin contar con la aprobación del usuario.

Siempre hay que contar con los usuarios. Un producto desarrollado a sus espaldas difícilmente se ajustará a sus necesidades reales. Generalmente cuando esto sucede es por culpa del área usuaria que se niega a dedicar al proyecto los recursos que son necesarios, dejando todo el peso a los desarrolladores. Esta situación es necesario revertirla cuanto antes y en caso contrario intentar cerrar el proyecto con el menor daño posible entre las partes, si bien, no siempre será posible una cosa o la otra porque el nivel de toma de decisiones al respecto se situará en otra escala de la organización que tendrán sus propias políticas y criterios.

Si contamos con la ayuda y dedicación del usuario y sin embargo tomamos decisiones funcionales por él, estamos cometiendo un grave error.

Al respecto me parece interesante la siguiente reflexión de Donald Norman: “Los diseñadores no son usuarios típicos. Llegan a ser tan expertos en el uso de los objetos que se han diseñado que no pueden creer que alguien más pueda tener problemas. Sólo la interacción y pruebas con usuarios reales en todo el proceso de diseño puede evitar eso”.

Puedes trabajar con factorías de software siguiendo el modelo que más pueda convenir: Offshore, Nearshore, Onshore y conforme exista más distancia entre los equipos que tratan las especificaciones y el equipo que las desarrolla más mecánico se convierte el trabajo del equipo de programadores: “toma las especificaciones, te las modelo y desarrolla según la arquitectura y framework pactado”.

Es posible que esa distancia la puedan reducir los equipos de trabajo aplicando distintos tipos de técnicas y herramientas porque como he dicho en otras ocasiones el impacto de la distancia depende mucho de la actitud de todas las partes. Sin embargo cuando por encima de los técnicos, hay jefes de proyecto o gerentes “contables” la actitud (si existe) queda difuminada y se entra en un peligroso modelo de trabajo basado en el antipatrón “arrojar al otro lado del muro”.

Como bien dice un amigo, no hacen falta factorías de software para caer en ese antipatrón, te puede pasar perfectamente con el proveedor incluso compartiendo oficina.

En el momento en que se entra en ese juego la programación desgraciadamente se convierte en una actividad mecánica: el programador se limita a ejecutar tareas, conociendo solo el sistema que se desarrolla a bajo nivel. Con esto perdemos el feedback del programador tanto a nivel técnico: tal vez sean recomendables ciertos cambios en la arquitectura o el framework para adaptarlos mejor a la naturaleza del software que se desarrolla, como funcional: Esto no termina de ser coherente con otros módulos del sistema y es necesario que las especificiones sean más claras o que se estudie esa falta de consistencia con el usuario.

En un proyecto todos suman, los programadores por supuesto también (y mucho). Todas las personas que están en el proyecto están capacitadas para aportar ideas y soluciones, tengan el rol que tengan, a veces estarán acertadas y otras se equivocarán pero lo que no podemos hacer es dejar de escuchar sus opiniones porque estaremos despreciando toda la capacidad y talento de los componentes de nuestro equipo.