archivo

Archivos Mensuales: diciembre 2013

Comenta Mary Poppendieck que: “Si quieres saber lo que el cliente quiere, dale lo que crees que quieren y escucha lo que te tienen que decir al respecto”.

Esa es la esencia del feedback: el usuario da una especificación, ejecutas según la interpretación que has hecho de la misma, obtienes un resultado y el usuario opina sobre el mismo, solicitando aquellos ajustes que consideres necesario.

En el caso de que desarrolles un producto y no te bases en especificaciones directas, el proceso es el mismo.

Recuerda que el sistema que desarrollas no es para ti. Tal vez las decisiones del usuario no te gusten, tal vez pienses que hay otras soluciones más adecuadas, si es así, exponlas, porque lo mismo ese punto de vista no se ha tenido en cuenta, pero no las impongas o manipules para que ese sea el camino elegido. Todos tenemos derecho a equivocarnos, pero más quien paga.

El objetivo es incrementar el valor del producto y la mejor forma de hacerlo es centrarnos en quiénes van a ser sus usuarios porque son ellos los que van a tener que convivir con él todos los días.

Anuncios

Como vengo haciendo al final de estos tres últimos años, os pongo la lista de los 25 artículos más visitados desde que empecé con el blog. Os pongo los enlaces de acceso, por si os interesa leer alguno.

1.- Desarrollo de software. El analista funcional y el analista orgánico.
2.- Desarrollo de software. Ciclo de vida RUP (Rational Unified Process).
3.- Mantenimiento adaptativo.
4.- Las precondiciones y postcondiciones en los casos de uso.
5.- Ciclo de vida clásico o en cascada.
6.- Orientación al producto.
7.- La importancia de un buen análisis funcional.
8.- Mantenimiento correctivo y mantenimiento evolutivo.
9.- Ciclo de vida iterativo incremental.
10.- Delimitar el alcance del proyecto.
11.- Ahora más que nunca hay que mirar al software libre.
12.- Testing de caja gris (Grey box testing).
13.- Ciclo de vida por prototipos.
14.- LCOM4 y la falta de cohesión en las clases.
15.- Reducción de tiempos muertos.
16.- El papel de los usuarios en un proyecto de desarrollo de software.
17.- Tarjetas CRC.
18.- Empresas de desarrollo de software: ¿estructura vertical u horizontal?.
19.- Ciclo de vida en espiral.
20.- La crisis del software.
21.- La autonomía y la motivación.
22.- Desarrollo de software. Programación extrema (eXtreme Programming: XP).
23.- Testing de caja blanca.
24.- Pruebas de regresión.
25.- Mantenimiento perfectivo.

Si queréis consultar las listas de los tres últimos años:

Los 25 artículos más leídos de mi blog.
Los 25 artículos más leídos de mi blog II.
Los 25 artículos más leídos de mi blog III.

Querer automatizar el caso, “flujos de trabajo indisciplinados” como indica Larry Bernsteian, es perder tiempo, dinero y requiere un importante desgaste personal para llevarlo a cabo.

Tal vez se consiga poner en producción un producto pero el coste posterior que tiene su explotación y mantenimiento será muy importante porque llegado el momento las diferentes áreas usuarias afectadas querrán que el sistema funcione como ellos entienden que debe hacerlo, con una visión localista y no con una visión global, necesaria para un sistema que pretende ofrecer una solución de carácter horizontal.

Dado que en este tipo de circunstancias los responsables funcionales no impondrán un criterio, se ejecutarán muchos cambios en el sistema sin haber pasado un filtro que determine si realmente la modificación era necesaria y si llevarla a cabo afecta al funcionamiento de algún área usuaria que, cuando descubra que se han hecho esos cambios, entrará en rebeldía, solicitando que se vuelva a la situación anterior, que se le de una solución local o dejarán de utilizar la aplicación.

El sistema, cada vez tendrá más hilos y tuberías, estará lleno de excepciones y casos particulares, será mucho más grande y complejo y por tanto, su evolución y capacidad de adaptación al cambio será costosa y lenta.

Sabiendo que todo eso va a pasar, lo mejor es no abordar el desarrollo del sistema hasta que los procesos que se pretenden informatizar hayan quedado definidos adecuadamente y existan unos mecanismos que velen por su cumplimiento y mejora continua.

Para Bill Langley: “El plan de proyecto perfecto es posible si uno primeros documentos es una lista de todas las incógnitas”.

Quien no es consciente de eso realmente no es consciente de la realidad de un proyecto de desarrollo de software, ni.

Tampoco serán conscientes de que el objetivo final es conseguir el mayor valor posible del producto dentro del contexto en el que se ha desarrollado porque lo mismo el plan inicial impone restricciones que suponen una limitación o una resistencia si no se adapta a la realidad que nos estamos encontrando en el proyecto.

Y no solo se trata de que el contexto cambie y/o imponga una atmósfera diferente a la esperada, sino que también estamos las personas y no somos infalibles, los desarrolladores no lo son, los usuarios tampoco. Nos vamos a equivocar y por mucho que se pretenda prever eso, será muy complicado acertar cuándo, cuánto y cómo.

El equipo de proyecto debe aprender del negocio, de esta manera será mucho más efectivo. Saber para que sirve y la finalidad del producto en general y de las funcionalidades en las que trabajan en particular, permitirá abordar las tareas de manera más efectiva, con mayor perspectiva y hacer un testing mejor (es posible que el algoritmo parezca que funciona pero que después el resultado sea una barbaridad, el desarrollador si no entiende del negocio lo terminará dando probablemente por válido, integrándose en el producto y llegando también, en demasiadas ocasiones, a producción).

Esto rompe la línea tradicional de que el analista sea el único experto en el negocio. Tal vez sea quién más sepa pero, por supuesto, nunca debería ser el único, y en cualquier caso, la diferencia entre sus conocimientos y el resto debe tender a disminuir con el paso del tiempo.

No se trata de ninguna pérdida de tiempo, al contrario, los resultados demostrarán que este tipo de políticas es beneficiosa.

¿Se debe documentar ese conocimiento? Lo importante realmente es establecer unos mecanismos que permitan que el conocimiento llegue y que además se pueda constrastar su comprensión. El medio, si se consigue ese objetivo, será el que consideres más conveniente, efectivo y que requiera un menor esfuerzo.

Para Gordon Bell (traducción libre): “Todo gran desastre computacional es consecuencia de tomar demasiadas ideas y ponerlas en un solo lugar”.

O lo que es lo mismo, consecuencia de buscar soluciones demasiado complejas sin pasar por otras soluciones intermedias más simples y/o sin pasar por un proceso previo de filtrado que trate, tal vez, de ser menos ambicioso en alcance a cambio de un enfoque más realista y efectivo.

Tener un amplio abanico de ideas donde elegir es una situación preferible a la escasez de las mismas pero siempre y cuando se gestionen con moderación, a eso se refiere Gordon Bell con su cita.

Si se toman muchas de ellas de una sola vez, sin reflexionar suficientemente sobre las mismas (o incluso haciendo esa reflexión) corremos el riesgo de desperdiciar esfuerzo ya que es posible que la hipótesis o visión de partida sobre determinados aspectos del producto sea equivocada y nos haga tirar una gran cantidad de trabajo que se podía haber evitado realizar si se hubiera optado por un desarrollo centrado en lo realmente relevante.

Se hace testing para detectar defectos, por tanto, tendrán éxito cuando cumplen su propósito. Esta es la visión de Boris Beizer en la siguiente reflexión: “Un test que revela un bug ha sido exitoso, no al revés”.

Podemos centrar el testing en secciones del código o en funcionalidades donde existe menos probabilidad de que existan defectos y probablemente no estemos aprovechando de manera adecuada el esfuerzo o, al menos, no con la rentabilidad que supondría enfocarlo de manera adecuada.

Una versión de lo anterior es hacer un testing “cómodo” para cubrir el expediente, sin entrar en tareas de mayor profundidad.

La función del testing es encontrar errores, dado que los desarrolladores no somos infalibles, si no se detectan defectos deberíamos plantearnos si efectivamente el testing que estamos haciendo está siendo efectivo, sobre todo si después comprobamos cómo van llegando a producción en una proporción muy superior a la que debería ser y/o a la inversión realizada.