archivo

Archivos diarios: enero 6, 2012

La cosa está muy mal, estamos perdiendo dinero, si queremos seguir funcionando sin echar a nadie o conservando la mayor parte de la plantilla hay que congelar los salarios o reducirlos e incrementar en algo la jornada laboral.

Cuando escucho esto (cuando sufro esto) me pregunto, ¿alguien se acordó de nosotros cuando las cosas iban muy bien y cuando se ganaba (o se disponía) de mucho dinero?.

Es solo una pregunta retórica.

Tal vez aplicando esa política se reduzcan gastos y tal vez (y con muchas dudas) se consiga incrementar a corto plazo (a largo plazo es otra historia) la cantidad de trabajo ejecutado por día.

Sin embargo la situación es difícilmente sostenible mucho tiempo, de ahí que a este antipatrón se le llame falsa economía, porque al final lo que te puedes ahorrar en gastos lo pierdas en productividad, ya que simplemente se ha ejecutado la política más fácil y no se ha atacado a la naturaleza del problema.

Si no eres competitivo hoy, tampoco lo serás mañana reduciendo salarios y/o incrementando jornadas laborales, lo único que se va a conseguir (y tal vez) retrasar lo inevitable porque finalmente el mercado te pondrá donde te mereces (ni más, ni menos),.

Yo he pecado en muchas ocasiones con este antipatrón. Lo reconozco.

Es el resultado de la presión que terceros te meten en el proyecto y/o la misma presión que se mete uno por intentar alcanzar los objetivos temporales marcados, aunque estos sean difíciles de conseguir.

A veces también son el resultado de la falta de confianza en el equipo de proyecto.

Este antipatrón consiste en solicitar estimaciones de avance del proyecto sin dar tiempo a que quien tiene que ofrecer la estimación realice un análisis medianamente objetivo de lo que se lleva realizado y de lo que se piensa que falta, todo ello teniendo en cuenta el contexto en el que hasta ahora se ha desarrollado el proyecto y el análisis de los riesgos actuales.

He leído últimamente en Twitter con relativa frecuencia una cita que refleja en gran medida lo que es el desarrollo de software: “Hasta que el producto (o su versión correspondiente) no se pasa a producción no se sabe realmente cuál ha sido el esfuerzo y tiempo necesario”.

Una gran verdad. Los métodos de estimación son eso, métodos de estimación. Después, a lo largo del proceso de desarrollo pueden pasar muchas cosas (incertidumbre) que echen al traste todo lo estimado y sea necesario ir realizando reajustes a lo largo de todo el proyecto (bienvenidos sean esos ajustes porque lo que no tiene sentido es seguir engañándonos con estimaciones irreales).

En las metodologías ágiles, independientemente de que podamos establecer un objetivo final (en cuanto a la delimitación del alcance del producto y el tiempo y esfuerzo para llegar a eso), nos encontramos ante la misma situación, si bien, en este tipo de desarrollos al factor incertidumbre hay que sumarle el factor feedback del usuario que pueden obligar a hacer ajustes continuos en determinadas funcionalidades hasta que consigamos ponerla a la medida de las expectativas creadas en la misma (e igualmente, bienvenidos sean esos ajustes, ese feedback y esos cambios).

Pero es que incluso a nivel de sprint, por muy cerrado que tengamos la carga de trabajo máxima (velocity) e incluso por mucha experiencia que tengamos a la hora de estimar y la estrategia de estimación sea adecuada (por ejemplo Planning Poker), también podemos equivocarnos. Lo importante en este caso es determinar la causa de la desviación para realizar, si proceden, las mejoras correctoras necesarias.

Otro artículo relacionado: “Desarrollo de software. Metodologías ágiles. Replanificar la fecha de entrega o cumplir con la misma“.

Este antipatrón se produce cuando ante la necesidad de persistencia de datos se utiliza una solución que no se basa en un estándar (por ejemplo, almacenamiento de datos en ficheros con un formato conocido exclusivamente por el desarrollador).

Este antipatrón se puede extender a la utilización de una solución que no resulte apropiada para el volumen de datos a almacenar y para el número de accesos de lectura y escritura concurrentes o no (y la proporción entre ambos).

Un ejemplo lo podríamos tener con la utilización de un directorio LDAP para persistir datos que se van a actualizar con relativa frecuencia.

También nos lo encontramos en la actualidad con el uso del XML para prácticamente todo.

Soluciones, generalmente hay variadas, nuestro objetivo será analizar la que resulta más conveniente al proyecto en el que estemos trabajando.