archivo

Archivo de la etiqueta: cita

Interesante la siguiente reflexión de Steve McConnell en su libro “Rapid development”: “Un equipo existe cuando dos cabezas juntas son mejores que dos cabezas individualmente”.

Para llegar a esto es muy importante la actitud de las personas. Si se considera que gran parte de quienes trabajan contigo en el proyecto no son capaces de aportarte ideas estás perdiendo la posibilidad de descubrir nuevos puntos de vista y mejores soluciones que las que tenías pensadas inicialmente.

Trabajar en equipo no es fácil ya que los desarrolladores somos muy individualistas y muchas veces la presión dificulta todavía más este asunto, pero cuando se consigue funcionar de esa manera el rendimiento de las personas crece en gran medida, no solo porque todos sean capaces de aportar al colectivo sino porque se trabaja mucho más a gusto.

Anuncios

No se trata de improvisar, sino de ser flexible. Muchas veces los problemas en las arquitecturas y en el desarrollo de software son difíciles de resolver en tiempo de definición. No es cuestión de programar mediante prueba y error, de programar por permutación, siempre es conveniente reflexionar sobre la solución a aplicar tratando de reducir el nivel de abstracción con el que inicialmente se enfoca la solución.

Me parece muy interesante la siguiente reflexión de Christopher Alexander, Sara Ishikawa y Murray Silverstein en su libro “A Pattern Language”: “Todas esas decisiones de diseño detallado que nunca pueden ser resueltas con antelación en el papel, se pueden hacer durante el proceso de construcción”.

Esta cita está por encima de las metodologías o marcos de trabajo, es una forma de entender el desarrollo de software, de tratar de ser flexible y ser consciente de que no todo puede o debe ser predecible.

Peter Senge en su libro “The Fifth Discipline” realiza la siguiente reflexión: “No impulses el crecimiento, elimina los factores que limitan el crecimiento”.

Somos expertos en poner obstáculos, en crear resistencias, en hacer todo un poco más difícil. Muchas veces no se trata tanto de poner empeño en mejorar o de progresar (que efectivamente hay que ponerlo) sino de que te dejen hacerlo.

Como gestor de personas (y no hace falta estar muy arriba en una organización para que coordines el trabajo de otros) tienes la obligación de no empeorar su desempeño individual (en primera instancia, ya que además tienes que poner los medios para que puedan seguir creciendo) y hacer que funcionen de forma adecuada como colectivo. Esto parece fácil pero no lo es en absoluto.

Muchas veces los mimbres están ahí y solo hay que poner los medios oportunos para que puedan conseguir los resultados… o de eliminar las barreras o resistencias que los limiten.

Para Tom DeMarco en su libro “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency” (traducción libre): “Si identificas cualquier proyecto como libre de riesgos, o incluso relativamente libre de riesgo, cancélalo. Vas a necesitar los recursos y el plazo para hacer algo transformacional”.

Desde mi punto de vista, DeMarco trata de poner sobre la mesa la importancia de tener en cuenta los riesgos que se presentan en un proyecto de desarrollo de software y que van más allá de un análisis superficial del mismo.

Claro que hay proyectos con menos riesgos y donde se prevé una cierta estabilidad que facilite la gestión del proyecto, el trabajo de las personas y las relaciones entre los diferentes implicados, pero también lo es que la incertidumbre es una variable inherente en los proyectos de desarrollo de software y que se pueden producir situaciones que en un plazo corto de tiempo requieran hacer adaptaciones y ajustes sobre el proyecto y ahí es donde pueden aparecer problemas que afecten de manera sensible al mismo, entre otras cosas porque no se suele ir muy sobrado ni de presupuesto ni de tiempo y si el producto además se encuentra en producción, la presión que se recibe se incrementa considerablemente.

Es cierto que hay incertidumbre y circunstancias que no son sencillas de ser previstas pero también lo es que sí hay otras que pueden ser previsibles a corto, medio y largo plazo y ahí es donde entra la gestión de riesgos en los proyectos de desarrollo de software, en la capacidad de identificarlos y de tomar medidas o no en función del impacto del riesgo, del coste de las medidas, de la probabilidad de su ocurrencia, etc…

La identificación de riesgos debería comenzar desde incluso la etapa de conceptualización o definición del proyecto porque lo mismo, tras un análisis de los mismos se decide que lo mejor es no realizar el proyecto, buscar otras alternativas, plantearse alcances, presupuestos y plazos más realistas, etc…

Me parece muy interesante la siguiente reflexión de Donald Norman: “Cuando las cosas simples necesitan instrucciones, es una señal segura de un diseño pobre”.

Los usuarios y los desarrolladores somos expertos en complicar los sistemas de información, en lugar de centrarnos en lo que realmente resulta relevante se invierte un gran esfuerzo en funcionalidades complejas que no son necesarias (y que en muchos casos tienen una utilidad discutible en términos de coste/beneficio) o en ir complicando progresivamente funcionalidades que ya resuelven de manera solvente una problemática.

En lugar de pensar dos veces la solución o iterar desde lo simple para ir adaptando la idea a un resultado interesante se tiende a tomar decisiones que no solo dan lugar a una solución complicada sino que generalmente llevan consigo una deuda técnica que hace costoso hacer reajustes.

A posteriori se ve más fácil en qué aspectos del diseño y desarrollo del sistema nos hemos equivocado tanto usuarios como desarrolladores pero tenemos herramientas para tratar de darnos cuenta de que se han tomado decisiones erróneas en el propio proceso de especificación de las funcionalidades o historias de usuario o en la propia evolución del producto, para ello se debe tender hacia un enfoque iterativo incremental en el que mediante retrospectivas y análisis de los productos resultantes vayamos haciendo las adaptaciones oportunas para que el resultado que se va obteniendo se aproxime cada vez más a las expectativas.

Ron Jeffries, Ann Anderson y Chet Hendrickson en el libro “Extreme Programming Installed” hacen la siguiente reflexión: “Si tu cliente sabe ahora exactamente lo que quiere, y si en el momento en que haya terminado todavía va a querer lo mismo, puede ser la primera vez en la historia del software que esto ha sucedido. Probablemente habrá un premio para ti en algún sitio”.

Está bien que estos autores lo pongan en su libro pero probablemente tu propia experiencia te hará llegar a la misma conclusión.

La aparición de la agilidad y métodos de trabajo potencialmente ágiles (siempre os digo que realmente lo que la hacen ágil o no es la actitud de las personas en el proyecto) no fue un capricho, sino una respuesta a unos métodos de trabajo que no respondían a una realidad que se repetía de manera insistente en los proyectos de desarrollo de software y que se basaba generalmente en el ciclo de vida tradicional.

Pero las metodologías, marcos o estrategias de desarrollo son solo herramientas, es necesario entender el fundamento del enfoque iterativo incremental y se puede resumir perfectamente en la cita en la que se basa este artículo.

Los usuarios pueden tener claro lo que tienen (cosa que está por ver) e incluso que el contexto del proyecto se pueda mantener de forma más o menos estable y no influya excesivamente en la línea de desarrollo del producto pero lo más probable es que los usuarios vayan haciendo ajustes en su visión del producto conforme se trabaja con más detalle en el mismo y conforme van viendo versiones del producto mientras se está desarrollando o mientras se entregan sprints y eso es debido a que es muy difícil abstraer lo que se cree que se quiere, a algo concreto.

Si pese a que sois desarrolladores habéis sido usuarios (incluso vuestros propios usuarios) os habréis encontrado muy probablemente con situaciones en la que vuestra idea inicial del desarrollo ha sufrido cambios sensibles.

Hay una cosa cierta, de cada proyecto en el que trabajamos, si tenemos la intención, aprendemos más y por tanto, tenemos la posibilidad de adaptar mejor nuestra forma de trabajar a las circunstancias que se presenten y de poder hacer uso de esa experiencia para tratar de acertar más en nuestras decisiones.

Por ese motivo me parece muy interesante la reflexión de Lowell Lindstrom que si bien está centrada en la programación extrema es perfectamente extensible a cualquier otro esquema de trabajo (traducción libre): “XP no es el final del viaje, es sólo el pozo de agua corriente que es especialmente sabroso para muchos. Vamos a aprender más con cada proyecto que hacemos”.

Cada proyecto es diferente e incluso dentro de cada uno hay circunstancias que implican cambios más o menos sensibles en el enfoque, por ese motivo si nos limitamos exclusivamente a aplicar las mismas ideas, prácticas y métodos de trabajo probablemente estamos restringiendo nuestra capacidad de poder aplicar determinadas soluciones que pueden resultar más aconsejables al contexto del proyecto.

Ojalá todo fuera tan fácil en el desarrollo de software como seguir unas guías, de hecho si así fuera la mayoría de los proyectos tendrían éxito y el concepto de crisis del software estaría erradicado.

¿Tienen éxito la mayoría de los proyectos? Lo mismo tu respuesta es que precisamente no tienen éxito por no aplicar en ellos marcos de trabajo o metodologías. No quiero decir que no se hagan uso de ellas, sino de que sea excesivamente rígido con la forma en que se aplican y de que no se tenga en cuenta de que nuestro conocimiento y las técnicas que tenemos a nuestra disposición son herramientas que tenemos la posibilidad de aplicar o no en función de las necesidades del proyecto.