archivo

Archivos diarios: mayo 12, 2011

Cuando la hora de dormir se aproxima cada vez más a la de despertar, cuando el fin de semana se hace cada vez más pequeño y los días entre semana más largos, cuando cada vez entiendes menos lo que pasa, son síntomas de que el trabajo se ha convertido en una carga y que, por tanto, se está desmotivado. Con motivación, los kilos pesan menos de mil gramos y los obstáculos se hacen más pequeños.

Muchos hemos pasado o pasamos por ello, no quiere decir que siempre sea así, a veces son rachas, otras, invitaciones a explorar otros caminos.

Cuando nos encontramos en ese estado, nos podemos dejar ir y convertirnos en un autómata que se activa cuando entra a trabajar y que se va apagando desde que se pasa por la puerta. Otra posibilidad es hacerle frente a la situación e intentar aprovechar cada oportunidad para seguir aprendiendo, para hacerte mejor.

Puedes que te encuentres defraudado con tu organización, con quien te dirige o con los dos y que eso no te anime a dar lo mejor de ti mismo, porque si ellos no te tienen en cuenta, ¿por qué dedicarles lo mejor de ti?.

Puedes optar por no hacerlo pero antes de eso convendría analizar si realmente al que estás haciendo daño es a ti mismo ya que si tiras la toalla pierdes capacidad para convertirte en un mejor profesional y ser más competitivo dentro del mercado laboral.

Por eso soy de la opinión que si tu organización no pone remedio para que te sientas motivado, lo pongas tú y si ya no puedes más consideres en serio si te compensa continuar allí.

Estuvo muy acertado John Johnson cuando realizó la siguiente cita (traducción libre): “Primero, resuelve el problema. Después, escribe el código”.

Tendemos muchas veces a irnos directos al teclado antes de pensar la solución a aplicar y las posibles alternativas y esto le pasa a todos los perfiles que participan en el equipo de proyecto, empezando por los programadores y terminando por los jefes de proyecto o incluso los gerentes.

Ese atajo, se convierte en muchas veces en un callejón sin salida y en medio de las tareas que estás realizando te das cuanta que hay muchas cosas que no has tenido en cuenta. Esto te obliga a empezar de nuevo o a rehacer trabajo.

No es más productivo ir directo al teclado ya que ni el IDE, el correo electrónico o el procesador de textos te van a dar la solución, esa la tienes que encontrar tú y a partir de ahí tu rendimiento se multiplicará. ¿Qué te puedes equivocar? Sí, pero seguro que menos que si te tiras a la piscina sin mirar primero si hay agua.

De los cuatro principios o valores expuestos en los artículos anteriores (introducción al manifiesto ágil, principio primero, principio segundo, principio tercero y principio cuarto) emanan otros más concretos, algunos de los cuales, paso a analizar el siguiente artículo:

– Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.

El primer objetivo de todo desarrollo de software es la satisfacción de las necesidades de grupo de usuarios que van a hacer uso del sistema de información. Esto se consigue mediante una estrategia de desarrollo adaptativa, basada en metodologías iterativas e incrementales, en las cuales se vayan liberando versiones cada poco tiempo y se obtenga con cada una de ellas el feedback de los usuarios, de manera que en las sucesivas versiones se utilice dicha información para tener un sistema que cada vez más se aproxime más a lo que el usuario demanda.

– Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.

Este principio se basa en el mejor tarde que nunca, pero hay que tener en cuenta que para que sea efectivo la metodología utilizada en el proyecto debe ser ágil o bien haber sido pactadas estas circunstancias al inicio del proyecto, ser tenidas en cuenta en el presupuesto y en la definición de plazos e intentar que todas las partes implicadas comprendan que tirar trabajo hecho incluso en fases avanzadas del proyecto, se hace por el bien del mismo siempre y cuando exista una justificación y no se considere un capricho. Por encima de todo está la satisfacción del cliente y no el hecho de entregar un producto por entregarlo.

– Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.

Está relacionado con el primero de los principios que hemos visto en este artículo, pero en este caso se hace hincapié en que funcione, ya que de esta forma los usuarios pueden hacer uso del software en un entorno real de trabajo y es en esas circunstancias donde el feedback que se obtiene del usuario es más provechoso, ya que se enfrentan con la eficiencia, productividad y utilidad del sistema ante circunstancias derivadas de acciones que se tienen que realizar en el sistema como consecuencia del proceso o procesos que se han informatizado. Es decir, el usuario tiene que realizar un trabajo por el que se le van a pedir responsabilidades y la herramienta es el medio para llevarlas a cabo. Ahora más que nunca el usuario va a demandar que el sistema se ajuste a lo que realmente necesitan.

– Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.

El equipo de proyecto debe ser único, aunque estén en ubicaciones distintas. Todos deben colaborar para la consecución de un fin común. Si cada parte lucha por unas metas particulares y las consideran prioritarias, el proyecto se verá afectado.

– Construcción de proyectos en el que los individuos estén motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.

El motor de los proyectos es el personal que los lleva a cabo, si el equipo no funciona no hay metodología o buenas prácticas que valgan. Si queremos que un proyecto vaya bien, las personas que participan en él deben estar alineadas para conseguir los objetivos que se plantean y para ello es necesario que crean en lo que hacen y estén motivados.

Todos los participantes en el equipo de proyecto deben sentirse importantes y eso es así porque todos lo son, las cadenas se rompen por el eslabón más débil, los proyectos de desarrollo de sofware igual.

– La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.

Sobre este principio pienso que lo más importante es que exista comunicación y que los conflictos y problemas se discutan y no se dejen ir. El cara a cara aporta el hecho de la proximidad y de un mayor compromiso.

– El software que funciona es la principal medida del progreso.

Es la métrica más importante para medir el avance de un proyecto, no se trata de construir subsistemas o módulos funcionales, sino de que los mismos funcionen. Si se hace una estimación del avance del proyecto sin tener en cuenta de que deben funcionar superando los mínimos exigidos por el usuario o cliente puede dar lugar a que la planificación y expectativas con respecto al proyecto no sirvan para nada, una vez que te obligan a retocar o repetir secciones de la aplicación que considerabas finalizadas.

Desde mi punto de vista esta es una de las circunstancias más críticas que deberían controlar los proveedores de servicios de desarrollo de software para que los proyectos no se les desvíen de manera incontrolada porque una cosa es que exista desviación y otra que de la noche a la mañana te encuentres con que tu porcentaje de ejecución de un 70% es en realidad de un 45%.

– Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.

Se trata de mantener un ritmo a lo largo del proyecto. El desarrollo de software es una actividad aeróbica con ciertas fases de esfuerzo anaeróbico. Si no es así el resultado final se resentirá.

Todas las partes implicadas en el proyecto deben entender que independientemente de que en unas fases su participación sea más significativa o importante que en otros, deben estar siempre a disposición del mismo. La responsabilidad de que el proyecto salga bien o mal es de todos y si alguna de las partes falla, afecta a las demás.

En el próximo artículo continuaré con el análisis de los principios que surgen de los cuatro principios fundamentales o valores descritos en el manifiesto ágil.