archivo

Archivo de la etiqueta: Crisis del software

Desde mi punto de vista este antipatrón no tiene un nombre adecuado, ya que productividad es la capacidad de hacer más trabajo efectivo (que sirva) por unidad de tiempo, estando asociado a la eficiencia (capacidad de hacer más con menos).

El nombre que debería tener este patrón es ejecución a toda costa o lo que es lo mismo, conseguir avance en el proyecto como sea, independientemente de que esto sea a costa de la calidad del desarrollo, de tener que tirar para adelante, tomando decisiones que no corresponden al que las toma y de una condiciones de trabajo aceptables para el desarrollador (overtime, presión, aceptar decisiones sobre los trabajos que se saben que afecta al correcto desempeño del mismo y del producto, etc…).

Otro posible nombre, que podría ser complementario al anterior, es beneficio a toda costa, que incluye otras decisiones nefastas como utilizar en el proyecto personas que en cuanto a conocimientos y experiencia no son lo que necesita, quitar miembros del equipo en mitad del desarrollo o sustituirlos por perfiles más bajos, reducir el tiempo dedicado al testing, quitar funcionalidad de manera unilateral, etc…

Desgraciadamente, es otro antipatrón que se repite con demasiada frecuencia y otro culpable más de la crisis del software.

También olvidan los que aplican este antipatrón que tal vez en un proyecto consigan su objetivo, pero no se puede mantener una fidelización de los clientes con unas políticas tan nefastas hacia los mismos.

Las buenas prácticas recogen actividades de gestión general, de gestión de proyectos, de diseño, de gestión de la configuración, de programación, etc… que son el resultado de experiencias recogidas a lo largo de años en proyectos de desarrollo de software.

Estas buenas prácticas, son instrumentos, los puedes utilizar o no, evaluando su aplicación y utilidad en el proyecto en el que estás trabajando o en el proceso que quieres implantar.

Como he comentado, son el resultado de experiencias aplicadas en proyectos reales, por eso resulta más interesante que utilices aquellas que sean adecuadas, en lugar de intentar redefinirlas u obviarlas.

Pero también existen un conjunto de actividades que también resultan de utilidad reconocer y son precisamente aquellas que no se recomienda realizar porque la práctica indica que no ayudan a conseguir buenos resultados. Esto es lo que se conoce con el nombre de antipatrones.

Por tanto, el conocimiento de las buenas prácticas debe complementarse con el de las malas prácticas. No aprovechar las experiencias de otros, cuando éstas puedan ser convenientes aplicarlas, es condenarnos a volver a repetir los mismos errores que tuvieron ellos y no salir de la espiral de la crisis del software.

Resulta significativo que en la situación de crisis actual se premie el precio/hora y no la productividad y/o cualificación del equipo de proyecto a la hora de realizar una contratación software.

El triunfo del precio/hora es el triunfo de la mediocridad, es el triunfo de la crisis del software, es el triunfo de los que han provocado que los desarrolladores de software seamos todos medidos por el mismo rasero, es el triunfo de los que hacen sistemáticamente las cosas mal. Total, el que paga al final piensa: “Para el trabajo que me van a hacer, me quedo con el más barato”.

Aunque el triunfo sea precisamente de los que menos se lo merecen, la culpa de que se haya llegado a esta situación es de todos (clientes, proveedores, etc…) por no haber demostrado con suficientes hechos (proyectos que hayan superado las expectativas de los usuarios) que con equipos cualificados y productivos se pueden hacer mejor las cosas y que eso cuesta a la larga (y a la corta) menos dinero.

El triunfo de la mediocridad está llevando al sector a una situación insostenible ya que ese precio/hora no lo puede soportar nadie (tampoco los que los ofertan) y eso es algo que no solo afecta a la cuenta de resultados, sino que también afecta a la calidad de los proyectos, lo que no hace más que retroalimentar la situación.

Sí y no. Sí, porque ya hay muchos desarrolladores y organizaciones que lo tienen en cuenta, dejando el ciclo de vida en cascada en un cajón y aplicando estrategias iterativas e incrementales en los desarrolladores. No, porque hay quienes conociendo el problema se rinden a la rutina de la cascada y al sentimiento de que el desarrollo de software es así y no tiene solución y lo que se hace es atacar a la incertidumbre y los riesgos incrementando el precio del desarrollo, desde el inicio y por supuesto también al final, para realizar ajustes a las expectativas del usuario y no es lo mismo hacerlo ahí que en etapas no tan avanzadas del desarrollo, donde se puede centrar los esfuerzos en problemas concretos.

No digo que no se tenga en cuenta el riesgo y la incertidumbre al valorar, sino que ese no debe ser el único camino ni mucho menos el más importante para combatirlo, ya que la clave está en la metodología y su adecuada ejecución en todos los ámbitos (gestión de las personas, gestión de los procesos y ejecución técnica).

La no adaptación a la naturaleza del desarrollo de software es una de las causas principales de la crisis del software y esto no solo es culpa de los desarrolladores, también lo es de los clientes y de las organizaciones de ambos (los implicados en el proyecto pueden tener muy buena voluntad, pero si sus jefes toman decisiones que no les permiten hacer su trabajo adecuadamente, los resultados del producto final se verán afectados).

La incertidumbre inherente a los proyectos de desarrollo de software requiere que el proceso de desarrollo pueda responder de manera ágil y flexible ante ella. De lo contrario estamos abocados a desarrollos que no se adaptarán a las expectativas del usuario o que para acercarse a las mismas requieran un sobrecoste importante, así como un incumplimiento de los plazos.

¿Qué estoy exagerando? Hace poco os puse los datos publicados por el Cutter Consortium, en el que quedaba patente que la crisis del software sigue sin superarse.

Barry Boehm, uno de los mayores expertos a nivel mundial en estimación de costes software y en la aplicación de estrategias de gestión económica en los proyectos de desarrollo de software, lo manifiesta de manera patente en la siguiente reflexión (traducción libre): “Será importante tener en cuenta a la hora de organizar proyectos en el futuro contar con la agilidad suficiente como para ser capaz de adaptarse a la aparición de nuevas fuentes adicionales de cambios imprevisibles”.

Y es que los datos del Cutter Consortium son escalofriantes:

– El 62% de los proyectos superan la planificación inicial en más de un 50%.
– El 64% cuesta más del 50% de lo presupuestado.
– El 70% tenía errores críticos tras su lanzamiento.

¿Puede aguantar nuestra industria estos datos? Hasta ahora muchas empresas de desarrollo han ganado mucho dinero con este caos a la misma vez que nuestra profesión se ha desprestigiado.

El manifiesto ágil fue un acto de rebeldía ante esta situación y fue, en mi opinión, el punto de inflexión hacia otro escenario. La aportación de Barry Boehm, muchos años antes, con la publicación de su libro “Software Engineering Economics” asociando conceptos asociados a la economía al desarrollo de software, también me parece decisiva.

Pese a esto, se tardará todavía mucho tiempo en superar la crisis del software porque supone un cambio absoluto en la cultura de los desarrolladores y de las empresas.

Estamos ante una de las causas de la crisis del software. El exceso de optimismo. Pensar que todo es más fácil de lo que parece. ¿Cuántas veces no es hemos arrepentido de decir que esto es fácil, esto es trivial o esto está hecho en una semana? Muchas. Y lo peor de todo es que nos seguiremos arrepintiendo de ello porque tarde o temprano volveremos a caer.

Somos así, es nuestra manera de ser. Es cierto que, como somos una profesión de extremos, también pasamos por períodos en los que todo es imposible o en lo que todo requiere un esfuerzo dos, tres o cuatro veces el real, pero nuestra falta de término medio nos lleva a eso, a comprometernos a plazos, dedicación, calidad, etc… que después por el motivo que sea (propio o ajeno) no podemos cumplir. A veces no tendrá repercusión, otras le costará mucho dinero al proyecto.

Mejor optimismo que pesimismo (es mi forma de entender el desarrollo de software, respeto quien piense y con razón que una actitud conservadora origina menos disgustos), pero también es mejor pensar que precipitarse.