jueves, 29 de septiembre de 2011

Cacheitis: otra enfermedad común del desarrollo software


Hoy hablamos de otra enfermedad habitual en el mundo del desarrollo software. Relacionada con las enfermedades "arquitectónicas", está especialmente relacionado con desvaríos de los arquitectos de software a la hora de implantar soluciones que por su ineficiente diseño, producen un mal rendimiento. Entonces la definición de Cacheitis vendría a ser algo así: "desorden transitorio del arquitecto o diseñador de software por el cual el uso inadecuado de la caché provoca como resultado una solución ineficiente".

¿Y cuál es la primera solución que se les ocurre? Sí señoooor: más caché. Caché por todos lados. Vamos a cachear todo lo cacheable.

En otras ocasiones, es al reves. Se parte con un exceso de caché desde el inicio del diseño, y esto deriva en un mal rendimiento. Para solucionarlo: como no...más caché.

Rodrigo corral en su blog ya hablaba de este problema, y aporta algunas buenas prácticas:
  • Asume que no puedes cachearlo todo. Esto es viejísimo: ya es harto conocido por ejemplo, que en el mundo de las bases de datos es absurdo tratar de indexar todo en la búsqueda del rendimiento. Pues esa mala práctica, la cacheitis la extiende al uso de la cache.
  • El cacheo temprano no es bueno. A menudo cuando diseñamos una arquitectura establecemos mecanismos de cacheo que luego son utilizados hasta el abuso. El peligro subyacente al cacheo temprano es que comencemos a cachear sistemáticamente elementos que nos parecen costosos sin tener evidencia de que realmente son los mejores candidatos para su cacheo. De nuevo, podemos establecer la comparación con el uso excesivo de índices en las bases de datos.
  • Tener en cuenta las otras cachés. Hay que recordar que existen muchos niveles de caché. El motor de base de datos, el servidor web, ADO.Net, etc, etc.
  • Una colección estática o global no es una caché: los desarrolladores noveles, y a veces los no tan noveles, utilizan datos estáticos o globales para simular el uso de la caché. Por desgracia, esto es una burda imitación de las múltiples características que deben incluirse en un mecanismo de caché como: acceso frecuente a los datos, políticas de refresco e invalidación, liberación de recursos de uso infrecuente, etc.
¿Qué es lo que hay que hacer? Pues recordar que somos ingenieros, y tratar de aplicar el sentido común (por desgracia, no el más común de los sentidos hoy día). Para ello, hay que relajar el usar la caché en las etapas tempranas del proyecto, y dejar para las etapas de optimización un uso combinado e inteligente de:
  • Optimización mediante caché
  • Optimización del acceso a datos mediante índices, su propia caché, vistas, datos calculados, etc.
  • Minimizar los accesos a servicios web, WCF, y a otras capas de la aplicación, de forma que las operaciones no hagan "excesivos viajes" para obtener la misma información.
De hecho, al final, no es sino hacer uso de los más básicos principios ágiles: simplicidad desde el diseño.

martes, 27 de septiembre de 2011

5 malas prácticas en la oficina


Bueno, hoy el titular es la metáfora del auténtico titular que ha inspirado este post: "The stupid things you do at work (and how to fix them)"

En este artículo, hace una magnífica reflexión de acciones que solemos llevar a cabo y son improductivas o contraproducentes. Me ha hecho gracia por dos motivos:
  • Vuelve a sacar el tema de la procrastinación en el trabajo. ¿Que no sabes lo que es?. ¿Es que no lees este blog? ;)
  • El otro motivo es que para ejemplizar la procrastinación, hace referencia a un refrán:
"y como dice el refrán español: mañana probablemente es el día más ocupado de la semana". Anónimo.
Soberbio. Sin palabras. En fin, al grano. Vamos a ver resumidas, las 5 malas prácticas en la oficina:
  1. Ponernos nerviosos. Cuando nos enfrentamos a tareas grandes, con alto riesgo, que nunca antes hemos hecho, o para las que no nos vemos preparados, suele ocurrar esto.
  2. Aferrarse a nuestras ideas y métodos, aunque estén mal. Hemos de aceptar que nuestros métodos o ideas no han de ser siempre los mejores. Punto. Quien lo confunde con ofrecer seguridad, tiene un grave problema. La seguridad consiste en poner los medios y medir los riesgos, para que podamos ofrecer la solución más adecuada al contexto.
  3. Procrastinar en lugar de hacer las cosas. El no afrontar las tareas inmediatas, y relegarlas en favor de lo que nos gusta más, o nos hace sentir más seguros, es un problema.
  4. Creerte mejor de lo que realmente eres. Tenemos una tendencia exagerada a ignorar nuestros fallos y hacer públicos nuestros éxitos. Es un mecanismo de conservación innato en nuestra especie. El miedo a qué dirán. La verguenza pública. Todo esto realmente nos limita y nos hace comportarnos muy por debajo de nuestras posibilidades. Nuestro rendimiento profesional y la calidad de nuestro trabajo, se ven afectados en consecuencia.
  5. Traer tu orgullo a la oficina. A la hora de negociar, mucha gente cuando obtiene un beneficio muy pequeño de la negociación, hace gala de su orgullo y prefiere no llevarse nada. Si pensamos con pura lógica, no tendría sentido este resutado. Sin embargo, la realidad nos hace ver cuán afectado puede verse nuestro comportamiento si nuestro orgullo hace acto de presencia.

Gestión de Proyectos Ágil


Se ha publicado recientemente el documento "Agile Project Management", que podéis descargar aquí.

El documento, resultado de la colaboración entre APMG-International y el consorcio DSDM, presenta un enfoque innovador en la gestión de proyectos. Ojo, no confundir con la gestión de equipos, que es el alcance que tienen muchas metodologías ágiles como SCRUM.

lunes, 26 de septiembre de 2011

Errores a evitar en la adopción de metodologías ágiles


En varias ocasiones, nos encontraremos que por muy convencidos que estemos de las bondades de las metodologías ágiles, vamos a encontrar una reacción de desconfianza o incluso de rechazo por parte de los clientes o de los responsables de proyectos cuando tratemos de que las adopten.

Incluso aunque los proyectos / clientes tengan problemas con sus metodologías actuales, el rechazo y desconfianza se mantiene, y se sigue trabajando una y otra vez manteniendo las mismas prácticas y cometiendo los mismos errores. Conclusión: los proyectos se siguen entregando tarde y mal.

El problema está en la cultura corporativa. Las ideas, los hábitos, son difíciles de cambiar. La resistencia al cambio es constante. Además, dicha resistencia debería ser inversamente proporcional a los argumentos proporcionados. Y no es así. ¿Cuál es la solución? Pues como todo en esta vida, la solución está asociada al problema, así que vamos a tratar de identificarlo.

No tenemos la razón.
La clave, está en que estamos tratando de vender una idea, un concepto: nuestra metodología es mejor. Y la percepción es precisamente ésa, de que estamos tratando vender. Y la gente no quiere comprar, quiere soluciones a sus problemas.

Es por eso que es necesario un cambio de enfoque. Hemos de conseguir que la gente sea consciente de la raiz de sus problemas, que sean capaces ellos mismos de darse cuenta de que necesitan un cambio. Los pasos serían algo así como:
  • Identificar los problemas
  • Identificar las causas
  • Identificar la necesidad de un cambio
  • Identificar alternativas
  • Evaluar alternativas
  • Encontrar una solución
Así de simple. De hecho, es posible que a pesar de creernos los poseedores de la verdad más absoluta ("que sí, que Scrum es la solución, que sí, que si 10 millones de usuarios usan Scrum, es que Scrum es bueno"), da igual. Hay que ofrecer soluciones adaptadas, no varitas mágicas. A continuación, veremos algunas técnicas útiles en la realización de los pasos comentados.

El método de la abuela
A la hora de explicar una metodología (Scrum, etc.), hemos de hacerlo con el "Método de la Abuela". ¿Qué es? Pues elegir alguien que haga de "abuela". Si puede ser, coge directamente a tu abuela. Y tratemos de explicarle, en este caso, en qué consiste la metodología que queremos implantar. Repítelo N veces, usando cada vez un lenguaje menos técnico, hasta que cualquier "abuela" pueda entenderlo.

En este método, hay que evitar hacer sentirse tonta a la gente. Una abuela puede que no tenga un fondo técnico o relacionado con las TI, pero no es tonta. Así que acostumbrémonos a evitar hacer sentirse tonta a la gente.

Escuchar
Hay que saber escuchar, incluyendo lo que no nos dicen. Si detectamos rechazo o desconfianza, hay que ver la raíz de su comportamiento.

Conseguir empatía
Es más fácil que te "compren" una idea, si la otra parte siente que das confianza. Por ejemplo, no se trata de dar nuestras experiencias (que al final pueden ser subjetivas). En lugar de eso, demos datos reales de otros proyectos y empresas, y refrendado por métricas o datos verificables.

Detectar barreras en la organización
En ocasiones, las barreras están en la propia empresa, no en nuestras habilidades comunicativas. Si la cultura organizativa es resistente al cambio (burocracia, organigrama, reinos de taifas, etc.), de poco servirán nuestros bien pulidos "interpersonal skills".

jueves, 22 de septiembre de 2011

Por los expatriados

Por cierto, estoy teniendo visitas al blog desde Alemania...¿será Alberto Bolsa?

Ese Albertoooo...mucha suerte, tio.

miércoles, 21 de septiembre de 2011

xxx Driven Development

Desde hace ya tiempo, vienen desgranándose ;) diversos paradigmas de desarrollo con el nombre de "no-se-qué Driven Development".

Y aunque algunos de ellos son muy jóvenes y están aún en pleno arranque, no está de más echar a un vistazo a la evolución, no siempre lineal en el tiempo:

Database Driven Design (¿DDD?).
Es el diseño de una aplicación partiendo del modelo de datos. Durante muchos años explicado en las universidades y otros centros de enseñanza, al final es más una consecuencia de la forma de pensar que de una necesidad de arquitectura o diseño. La necesidad de establecer un modelo de datos como "base" en las fases más tempranas, conlleva que tratemos de definir al máximo los datos, su estructura y flujo. Al final, las pantallas no dejan de ser un mero reflejo de dicho modelo. Por desgracia, esta forma de trabajo con el tipo de aplicaciones actuales orientadas al usuario, donde la interfaz es el rey, y lo importante es hacer sentir cómodo al usuario.
    UI Driven Design (UIDD)
    He sido fan de este modelo de diseño, pero ha chocado con una realidad, y es que es relativamente sencillo definir un modelo de datos y una capa de negocio que cumplan con los objetivos. Sin embargo, las interfaces de usuario se resisten, en especial con la explosión del mundo web, que ha acabado barriendo los desarrollos de escritorio (en orden de magnitud). Ha tenido que llegar el año 2010/2011 para que tengamos que oir (otra vez) la promesa de que con nuevos estándares (esta vez HTML5 entre otros), la web será "como las aplicaciones de escritorio". Gracias por reinventar la rueda, pero seguiremos esperando. Mientras tanto, las aplicaciones (de escritorio o web), siguen fallando de forma habitual en la interfaz.

    Interaction Design (Goal-Oriented Design=GOD)
    Similar a la anterior, está apadrinada (entre otros) por Alan Cooper, experto en temas de interacción y usabilidad (os recomiendo su famoso "The Inmates are Running The Asylum", donde trata la metodología "Goal-Oriented Design"). Bajo mi punto de vista, es una metodología desaprovechada, y que sigue cubriendo aquello que muchas otras metodologías están buscando abordar: la satisfacción del usuario.

    Test Driven Development (TDD)
    Esta vez sin seguir secuencia cronológica, la TDD o metodología de desarrollo guiada por pruebas, nos invita a acelerar los desarrollos y mejorar la calidad de los productos, basándose esta vez en otra de las fases o actividades del ciclo de vida: las pruebas. De nuevo, una gran promesa, todavía sin caer en el desprecio, pero que exige por parte de los equipos de desarrollo de dos ingredientes no habituales: disciplina y mesura. Disciplina para crear con antelación los tests, y mesura para saber hasta dónde llegar con las pruebas.

    Domain Driven Design (DDD)
    Según el sitio web http://domaindrivendesign.org es una forma de pensar, en lugar de una metodología. Dejando aparte dogmatismos insondables, se centran en la parte del diseño de un modelo, de la capa de negocio principalmente. De esta forma, se pretende dar solución a los proyectos en los que la complejidad y el tamaño del software a construir haga inabordable la tarea. Bajo mi punto de vista, esta forma de trabajo, sigue adoleciendo de problemas similares a los que presentan otras técnicas. De hecho, si una de las causas del fracaso del software es la complejidad del software, tenemos un grave problema no metodológico, sino de análisis y de visión del producto.

    [Editado]: ¡me había dejado Feature Driven Development!
    Feature Driven Development (FDD)
    Es una metodología de desarrollo ágil, centrada en el modelo, y en la que el desarrollo está liderado por los requisitos. Es una metodología que parece encajar muy bien en equipos y proyectos grandes. Ya le dedicaré un post con más tranquilidad otro día.

    Requisitos y la importancia del diseño

    Revisando documentación, he encontrado esta imagen que resume la importancia de:
    • Los requisitos
    • El diseño de la solución
    • La coherencia en las comunicaciones hacia el cliente
    • La importancia del prototipo
    • Las carencias en la documentación, soporte e implementación
    Como la considero un clásico que todos los que nos dedicamos al desarrollo de software deberíamos conocer, ahí va para los que no la conozcáis.

    Los que decís que lo teníais muy visto...más os valdría recordarlo de vez en cuando (me incluyo), porque cometemos de forma constante errores como estos, y algún día habrá que dejar de echar la culpa a los demás.

    Para este tipo de problemas, existen varias soluciones o técnicas que nos pueden servir:
    • Prototipado. El cliente puede ver con anticipación, la solución final o partes de la misma. Sin embargo, esto se queda simplemente para formación teórica, ya que en la práctica, los programas de software son mucho más complejos que lo mostrado en la figura. El cliente, hasta que no USE realmente en su día a día el producto, no será capaz de detectar lo buen o mal diseñado que estará.
    • Ciclos de vida iterativos en general. Prometen tener soluciones parcialmente construidas, que el cliente puede validar. Tiene los mismos problemas que el prototipado.
    • Metodologías ágiles. Normalmente, las metodologías ágiles incluyen entregas frecuentes y un ciclo de vida iterativo que facilita evitar estos problemas. Sin embargo, en absoluto son garantía de evitar los problemas descritos en la imagen. Tiene también problemas
    Como vemos, no hay balas de plata. Al final, la mejor herramienta es la experiencia. Conocer el negocio del cliente, y conocer el negocio del desarrollo de software.

    Como ejemplo, voy a dar un caso real. Para una empresa, se solicitó una aplicación para rellenar unos formularios tipo. La primera aproximación que se tomó, y que coincidía con lo que pedía literalmente el cliente, fue mostrar en pantalla "el formulario tal cual". Así se hizo, y resultó un fracaso. El trasladar a la pantalla el formulario produjo múltiples problemas, ya que la metáfora usada (el mostrar el formulario tal cual), contradecía las metáforas de usabilidad que había en el resto de aplicaciones, y a las que estaban acostumbrados los usuarios. Además, resultó que cualquier cambio en el formulario físico (el report), obligaba a cambiar la pantalla de inserción de datos.

    lunes, 19 de septiembre de 2011

    La importancia del análisis

    Un análisis (funcional o técnico), es un punto importante, en el que el analista de turno "se moja" y decide implementar los requisitos de una forma implementable. El problema, como se ejemplifica a la perfección en la imagen siguiente, es que hay que tener antes la experiencia suficiente para (entre otras cosas), saber identificar si hay componentes o incluso sistemas enteros que implementan nuestra misma solución.



    Fuente: http://www.nosololinux.com/2009/03/27/la-nosolotira-grandes-ideas/

    jueves, 15 de septiembre de 2011

    TFS y las reglas de CheckIn de asociación a WorkItems

    Como ya sabréis lo que desarrolláis en Microsoft .Net, se pueden establecer reglas para que las operaciones de CheckIn en el repositorio de código de TFS, exijan asociar a cada subida de código uno o más WorkItems.

    Esta regla, es mucho más importante de lo que parece, ya que esconde por detrás un grave problema de gestión y visibilidad del estado del desarrollo.

    ¿Qué ocurre si haces un CheckIn, y no asocias ningún workitem?. Pues que la tarea no está planificada, no se puede detectar a qué se han debido los cambios. Si no es un desliz, y realmente no hay tarea (workitem) planificada,
    1. estamos haciendo algo innecesario, o bien
    2. estamos haciendo algo necesario no planificado, o bien
    3. estamos haciendo algo necesario, planificado, pero que está oculto.
    • En el primer caso,  tendríamos al típico programador que dedica su tiempo a tareas agradables, que le gustan, o que simplemente está probando algo que se le ha ocurrido. Sería un caso típico de procrastinación (ver entradas anteriores en este blog sobre este tema).
    • En el caso 2, hay varias opciones, pero una típica sería cuando hemos dado algo por cerrado, y recordamos un requisito de diseño, una funcionalidad que se habló pero no se incluyó en los workitems, etc.
    • En el caso 3, por ejemplo, un ejemplo habitual es cuando queriendo o sin querer, hacemos cosas planificadas en el workitem, pero se nos olvida asociarlo. Puede ser que se nos olvidara por ejemplo las pruebas unitarias, así que las pasamos, corregimos cosas de un workitem antiguo, pero no lo indicamos.
    En proyectos con metodología no iterativa, muchas veces estos casos quedan ocultos, y tienen un impacto menos apreciable en la planificación (aunque no dejan de ser importantes). Sin embargo, con metodologías iterativas, tipo Scrum, el impacto es mucho mayor. El hecho de que en una iteración de 1 o 2 semanas, tengamos tareas realizadas pero no planificadas, puede suponer una desviación importante. Si ya las tareas que se realizan encima no son necesarias, el desastre está asegurado.

    ¿Qué tiene que ver esto con la calidad? Pues mucho, porque como veremos en un próximo post sobre cómo medir la calidad, ésta no es sólo "nº de defectos". En el desarrollo de software, un factor clave es la trazabilidad. Si no somos capaces de saber en qué partes de nuestro programa están implementados los requisitos (o las "Historias de Usuario" en terminología Scrum), una de dos:
    • O alguien ha rellenado una matriz de trazabilidad (infame pero útil documento del cual algún día hablaremos)
    • O simplemente, no podremos identificar dónde están implementados esos requisitos. Como supuestamente estamos abiertos al cambio, cualquier cambio en los requisitos hará que tengamos que dedicar un tiempo precioso a rastrear el código para saber cuánto hay que cambiar y dónde. Y si no somos capaces de identificar el impacto de un cambio, me rio yo de las estimaciones que haremos.

    Test de habilidades profesionales

    Aún a riesgo de caer en el exceso de blogs con la etiqueta humor, hoy traigo otro, que por otro lado hará las delicias de los profesionales (incluyendo los ajenos al mundo del desarrollo del software).

    A continuación, presento un test de preguntas que utiliza Accenture para ayudar a entender tu forma de pensar. Las preguntas no son difíciles. Para ver las respuestas, basta seleccionar con el ratón el texto en el hueco que hay debajo de cada pregunta (sí, sí, es texto del color de fondo, por eso no lo ves).

    1. ¿Como meterías una girafa en el frigorífico?

    La respuesta correcta es: abre el frigorífico, mete la girafa y cierra la puerta.
    Esta pregunta comprueba si tiendes a hacer las cosas de forma excesivamente complicada.

    2. ¿Cómo meterías un elefante en el frigorífico?

    Respuesta incorrecta: Abre el frigorífico, mete el elefante y cierra la puerta.
    Respuesta correcta: abre el frigorífico, saca la girafa, mete el elefante y cierra la puerta.
    Esta pregunta comprueba tu habilidad para ser consciente de las repercusiones de tus acciones.

    3. El Rey León está en una conferencia de los animales, donde están todos menos uno. ¿Qué animal no está allí?.

    Respuesta correcta: el elefante, que está el pobre aún metido en el frigorífico.
    Esta pregunta comprueba tu memoria. Llegados a este punto, incluso si no respondiste correctamente las 3 preguntas anteriores, seguramente la siguiente sí lo harás.

    4. Hay un río que debes cruzar, pero está habitado por cocodrilos. ¿Cómo lo harías?

    Respuesta correcta: lo cruzas nadando y punto, ya que todos los cocodrilos están atendiendo la conferencia del Rey Leon!!.
    Esta pregunta comprueba si puedes aprender rápidamente de tus errores.

    Según Accenture, alrededor del 90% de los profesionales tuvieron todas las preguntas mal. Cuando se les hizo esta pregunta a preescolares, éstos tuvieron varias respuestas correctas.
    Según Accenture, esto concluyentemente contradice la teoría de que la mayoría de los profesionales tienen el cerebro de un niño de 4 años.

    Fuente: http://www.creativityatwork.com/articlesContent/creativity-quiz.html

    miércoles, 14 de septiembre de 2011

    9 maneras de lidiar con un jefe tonto


    Bueno, en primer lugar, y para tranquilizar a propios y extraños, diré que vamos a hablar de situaciones hipotéticas, de charlas habidas alrededor de un vaso de café, pero que en absoluto están relacionadas con situaciones reales.

    Por cierto, recordad que las imágenes como la que acompaña este blog, podéis ampliarlas sin más que hacer clic sobre ellas. Además la de hoy es una tira de Dilbert que os recordará más de una ocasión en vuestra vida laboral.

    En alguna ocasión, casi todo el mundo se ha encontrado con alguien que parece seguir el principio de Dilbert: alguien que ha ascendido en la escala laboral, de forma inversamente proporcional a su aptitud. Y que a pesar de esgrimir de forma evidente y constante dicha falta de aptitud, se las ingenia para seguir siendo jefe o incluso seguir ascendiendo. Si usted cree que su jefe es así, aquí van algunos consejos que quizá le hagan la vida más fácil.
    1. Intente hacerle quedar siempre por encima. Vamos, hacerle la pelota no le irá mal, y con suerte, conseguirá aumentar la estima de su jefe lo suficiente para que desaparezca (quizá, siguiendo con el principio de Peter, sea ascendido en base a su incompetencia).
    2. Documente su trabajo. Tome nota de qué le pide su jefe, en qué términos y condiciones, etc. Cuanto más sea lo absurdo o imposible que le pida su jefe, tómese más molestias en anotarlo, conseguir pruebas, guardar mailes, etc.
    3. No critique a su jefe de forma abierta. Si su jefe la caga en una reunión, asuma usted el rol de jefe, haciéndole a puerta cerrada sutiles comentarios acerca de lo desacertado de su, por otra parte, magnífica exposición.
    4. Evite saltarse a su jefe. Hágalo partícipe de todo, sobre todo de sus éxitos. Con un poco de suerte, se los atribuirá él, y al ascender, se librará de su supervisión.
    5. No espere que su jefe cambie.
    6. Manténgase alejado en público de su jefe. Por asociación, puede usted convertirse en "el tonto que es amigo del tonto".
    7. Cambie de dirección. Cuando su jefe trate de darle una orden, ofrezca una lista de problemas espantosos e insolubles, y pídale su opinión.
    8. Cambio gradual de objetivos. Consiste en diseñar una serie de objetivos en el tiempo para un proyecto que sean más fáciles de cumplir o, de hecho, que sea algo que usted ya haya realizado.
    9. Entrene a su jefe tonto. Ofrezca a su jefe un dulce cada vez que pase cerca de su mesa y hace un comentario positivo. Si el comentario es negativo, no le de ningún dulce. Observará cómo el número de comentarios negativos que su jefe le hace, decrece con el tiempo.
    Fuente: http://www.eltiempo.com/archivo/documento/MAM-1011314

    martes, 13 de septiembre de 2011

    Procrastinación (II)


    Visto el éxito de del anterior post sobre procrastinación, me he animado a ahondar algo más sobre el asunto. Si bien en un principio me hacía gracia la palabrita, si rascamos sobre la superficie, encontramos un tema actual y candente, una cruda realidad de estos tiempos que corren.

    Además, la viñeta de Dilbert que acompaña este post no tiene desperdicio.

    Es bien conocido que estos días se habla mucho de que la cultura de internet, twitter, facebook, blogging, etc., parece que está provocando que tengamos déficit de atención, que seamos incapaces de concentrarnos en un tema por tiempo suficiente hasta su resolución, o al menos hasta que tengamos un grado de análisis suficiente para continuarlo posteriormente. Las consecuencias, pueden ser pues:
    • baja productividad en nuestros proyectos y tareas
    • baja calidad en los resultados

    ¿Cuáles son las causas?
    • Psicológicamente, mostramos cierta resistencia a fijar objetivos, o al menos, nos cuesta afrontar la evaluación de su necesidad y la decisión de llevarlos a cabo.
    • Cuando lo hacemos, no ponemos los medios adecuados hasta su resolución. Como leí hace tiempo en una cita relativa a los malos managers: "el mal manager es el que mantiene los recursos alejados de los objetivos".
    • No somos coherentes a la hora de decidir "qué es importante" y "qué es urgente".
    • Usar el placer como brújula, dando satisfacción a nuestros deseos inmediatos, en lugar de realizar las tareas que por otra parte, ¡ya teníamos planificadas y priorizadas!
    ¿Cuáles son los resultados?
    • "Mañana me pongo". Vamos, fijo que me pongo. Pero segurísimo.
    • Uf, como evitar entrar a comentar fotos de gatitos en Facebook, cuando el informe mensual de resultados de xxxxx lo puedo hacer mañana.
    • Autosabotaje. Somos nuestros peores enemigos. Todos los años vuelta a los mismos objetivos de mejorar el inglés, ir al gimnasio, bla, bla, bla. Y antes de volvernos a poner los mismos objetivos, no nos paramos a analizar las causas de que no se hayan llevado a cabo.
    • etc, etc y etc otra vez.

    ¿Qué acciones podemos tomar para evitarla?
    • Olvida los detalles. Lo imperfecto es bueno. Utiliza la regla de Pareto: aplica el 20% de esfuerzo, para lograr el 80% del resultado. Normalmente será suficiente. En el caso del desarrollo de software, asegúrate que no estás creando requisitos artificialmente, o que el nivel de calidad es al menos el estrictamente acordado. A partir de ahí, hay que hacer un balance entre lo necesario y lo deseado.
    • Acepta lo planificado. No lo consideres una obligación. Acostúmbrate a disfrutar con lo que haces, ya que si no es así, el subconsciente se encargará de encontrar otra tarea que sí te haga disfrutar, y actuará de potente imán. Lo peor de todo es que llegamos al autoengaño, aceptando tareas de disfrute como planificadas, y eso no debemos permitirlo.
    • Asegúrate que entre tus actividades, hay actividades que te gusten. Pueden estar dentro o fuera del trabajo, pero asegúrate que están ahí. Planifica el ocio, de forma que se alterne en tu vida con el trabajo (el trabajo planificado y necesario).
    • Analiza las tareas que emprendas. Cada vez que emprendas una nueva acción plantéate: ¿estaba planificada? ¿la estás haciendo en el tiempo en que tenías ya algo planificado?

    lunes, 12 de septiembre de 2011

    Libro sobre TDD gratis y en castellano

    [Actualizado: parece que el enlace ya no funciona, pero mantengo la entrada por si acaso. Si llegas aquí y se te ocurre un buen libro que reemplace el que yo proponía, tu aportación sería bienvenida a la comunidad]
    Hoy tenemos un libro gratis y en castellano sobre el desarrollo según TDD en este link.

    En el link, además del propio libro (descargable en varios formatos), ofrece diversos enlaces que ofrecen blogs, información adicional, formación, etc., todo ello relativo a TDD.

    Para los perdidos, despistados, o los que no hayáis visto TDD en alguna de mis anteriores entradas, vamos a incluir un breve resumen.

    TDD son las siglas de Test Driven Development. Hoy en día, tenemos varias metodologías XDD, sustituyendo "X" por alguna de las facetas del desarrollo. En este caso, el desarrollo está dirigido o guiado a partir de los Tests. El objetivo es definir en primera instancia un conjunto de pruebas que recojan al máximo una verificación de los requisitos. De esa forma, el código se va desarrollando posteriormente contra unos tests ya establecidos. Los tests se suelen automatizar, ofreciendo un paradigma de desarrollo bastante estable. Por desgracia, y esto enseguida gustará a sus detractores, no es en absoluto perfecto, y tiene problemas relativos a la variabilidad de los tests, ya que éstos han de cambiar de forma síncrona con los cambios en los requisitos.

    Hoy en día, un  gran número de metodologías ágiles incluyen esta técnica de desarrollo, aunque hay que decir que como técnica, es totalmente ajena al desarrollo ágil, y puede ser implementada en cualquier otra metodología.

    Métricas: LOC

    LOC es un acrónimo de "Lines of Code". Se utiliza como métrica en diversas situaciones, en las que se mide el número de líneas de código. Usualmente, se utiliza la variante "KLOC", que son miles de líneas de código.

    ¿Que qué le pasa a esta métrica? Pues que está maldita. Sí, sí, maldita. Ni el exhorcista más aguerrido podría devolverle el honor a esta defenestrada medida. Pero en fin, como me gustan las causas perdidas...ahí vamos.

    ¿Porqué está maldita? Pues porque basta presentarla para que la gente ponga caras raras, empiece a generar excusas, exponga argumentos en su contra, etc. Sin embargo, esta métrica tiene cosas a su favor, al menos en apariencia:
    • Es fácil de medir. Pues sí, eso es cierto. Prácticamente cualquier entorno lo ofrece, y todos los plugins de métricas lo ofrecen.
    • Es fácil de combinar: muchas otras métricas pueden venir referidas a ella (Ejemplo: "nº de defectos por cada mil líneas de código").
    • Ofrece una medida aproximada del tamaño de un software, y de su complejidad. Pues vaya, esto también es cierto. Un programa de 1000 líneas no sé si será el doble de grande que otro de 500, pero más grande, sí.
    Sin embargo, en este mundillo se encuentran muchos argumentos en su contra:
    • No es una medida fiable de productividad personal. La respuesta obvia sería: "pues claro". En este mundillo de las métricas, uno aprende que lo primero que hace un programador es ver en qué medida la métrica puede valorar su trabajo. Es el caso típico de: "pensar mal". El problema es que las métricas están siempre para conocer el proyecto, y no siempre para ver el rendimiento de las personas. Sin embargo, sí puede obtenerse (y se debe, de hecho) métricas del estilo: LOC totales por persona, LOC modificadas por persona en un período, LOC nuevas por persona en un período, etc.
    • Penaliza a lenguajes de alto nivel. Toma, pues claro. Los lenguajes de alto nivel están para eso. Para que con menos líneas, se hagan más cosas. Lo mismo que los frameworks y las librerías: para ahorrar líneas de código. Pero de nuevo volvemos a lo mismo: esta métrica permite comparar sólo en el caso de que se pueda comparar. No podemos comparar solamente lenguajes similares, sino proyectos en que la arquitectura sea equivalente.
    • La complejidad de un software no depende de su tamaño. Hay programas muy pequeños, endiabladamente retorcidos, mientras que hay otros muy grandes, pero muy simples en concepción y ejecución. De nuevo, la respuesta es "pues claro". El problema es que una métrica no es más que un número. Para obtener conclusiones, normalmente hay que usar varias métricas e indicadores de los proyectos.
    La conclusión vendría a ser que esta medida es para lo que es, para apoyo, para dar una visión orientativa que por sí sola nunca puede ser concluyente (lo que no deja de ser cierto en general para prácticamente todas las métricas).

    Desde luego, si no podemos medir algo, no podremos decir que esté bajo control.

    El valor de lo predeterminado

    El encontrar nombrado a uno de mis referentes (Alan Cooper*), en un artículo de la revista MSDN, me ha hecho leerlo y recordar sus libros.

    Y es que como ya Alan Cooper hablaba en su libro "About Face", el tema de los valores por defecto (los valores predeterminados), son una de las principales claves de la usabilidad, y la causa del éxito o fracaso de una gran mayoría de proyectos software.

    Realmente, es un factor más importante que los propios requisitos y funcionalidades implementados, aunque esto se le resista hoy día a una gran masa de desarrolladores. Fijémonos por ejemplo en los teléfonos móviles. Se sacan constantemente modelos, pero el comentario que se oye es del estilo: "hasta la versión del firmware xxxxx, la cámara sacaba unas fotos penosas", o también: "la pantalla no respondía bien en las versiones anteriores a la xxxx".

    Hemos llegado a aceptar que los productos que compramos recién salidos al mercado, simplemente "no están ajustados". Salen con la funcionalidad (requisitos) que aparece en los catálogos, pero no satisfacen realmente a los usuarios, es decir, falla la usabilidad. Y ese fallo, está originado en los valores por defecto (firmware, parametrización, etc).

    Clippo, que tantos quebraderos de cabeza nos dio
    Algunos veteranos todavía recordamos la presencia de "Clippo", el famoso asistente que presentaron por defecto en versiones antiguas de Office, que acabó defenestrado ante su insistencia en frases del estilo: "Parece que estás escribiendo una carta". No es tan importante la ayuda ofrecida, como el crear una buena base de configuraciones por defecto, y saber asociar a cada perfil de usuario, su configuración más acertada.

    De hecho, es desproporcionadamente más importante el que las funcionalidades estén accesibles cuando se necesitan, y sea cómodo encontrarlas, que el hecho de que haya cientos de funcionalidades, pero estén tan ocultas y rebuscadas, que sólo ciertos perfiles de geeks, sepan dónde están. Una funcionalidad que introdujo Office hace ya varias versiones, es adaptar automáticamente su interfaz, para adaptarse al tipo de tarea que se está realizando, ofreciendo los botones y menús más usados, y llegando a esconder los menús y botones que con el tiempo se dejan de usar. Muchos ni nos hemos dado cuenta, y simplemente dejamos que los botones más usados o más apropiados al contexto, aparezcan ahí.

    Tampoco se trata de que hagamos las aplicaciones complicadas, sino de que pensemos en quién las va a usar, pensemos en 2 o 3 tipos habituales de usuarios, y las configuremos para ellos. Después de todo, recordad que el principal usuario de nuestros programas, no solemos ser nosotros.


    (*) Alan Cooper (http://www.cooper.com/) se hizo famoso por escribir varios libros sobre usabilidad, y ser el creador de una de las interfaces más usadas hoy día en los entornos de desarrollo (sí, del estilo de Visual Basic). Estigmatizado por ser "el padre de Visual Basic", hoy día es consultor y propietario de su propia empresa dedicada a las interfaces, usabilidad, etc. He tenido la suerte de disfrutar devorando sus libros:
    • About Face: The Essentials of User Interface Design
    • The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity

    sábado, 10 de septiembre de 2011

    ¿Más siglas? MDE, MDD, MDA

    Hoy tenemos más siglas de las que hablar:

    • MDA: Model-Driven Architecture.
    • MDD: Model-Driven Development.
    • MDE: Model-Driven Engineering.
    En general, los tres están relacionados con el paradigma de desarrollo que utiliza o propone el uso de modelos como el principal artefacto del proceso de desarrollo. O al menos, como el artefacto que dirige y sirve de arranque al desarrollo.

    Lo que se pretende, es que el código se genere de forma semi-automática, a partir de dichos modelos. Según estas metodologías, partiríamos de un modelo diseñado con un programa (por ejemplo, con Software Architect), y él solito nos crearía el código asociado. El lenguaje para el modelado, bien podría ser UML, aunque existen otras alternativas.

    viernes, 9 de septiembre de 2011

    El proceso de preventa

    Pocas veces (más bien ninguna), cuando hablamos de calidad en el mundo del desarrollo software, nos acordamos de la preventa. Parece que todas las metodologías arrancan cuando está firmado el contrato, y terminan tras el despliegue (con suerte, tras el mantenimiento).

    El problema es que se debe tener en cuenta también la preventa. Es decir, el proyecto realmente debemos gestionarlo desde que decidimos presentarnos a una propuesta, o cuando decidimos ir a llamar al cliente, etc.

    Muchos os preguntaréis ¿pero esto de la venta también tiene que tener metodología? Pues claro. Y por varios motivos:
    • Como toda actividad de gestión, debe haber un procedimiento habitual de trabajo, donde se definan responsabilidades, roles, actividades y entregables.
    • Debe hacerse un seguimiento. Normalmente la alta dirección querrá saber periódicamente datos de: posibles acciones de preventa, acciones en marcha, acciones realizadas, nivel de éxito de dichas acciones, etc. Esto nos lleva a las inevitables métricas, informes, etc.
    • Y lo que es más importante: debes estimar. Y no es cualquier estimación, es la primera, y precisamente la que se hace cuando tienes menos información de lo que hay que hacer. Por eso requiere de unas herramientas y técnicas distintas de las usadas para estimar cuando estas a mitad del proyecto.
    Al final, no deja de ser como un pequeño proyecto:
    • Tiene sus fases: por ejemplo podría hablarse de "Oportunidad", "Análisis", "Diseño y ejecución de la oferta", "Revisión y presentación de la oferta"
    • Tiene asociado una gestión: durante las fases anteriores, deberá haber una planificación, una estimación de esfuerzo (¿si debemos presentar una oferta antes del día x...llegamos?), etc. También habrá que registrar las horas invertidas, para controlar el tiempo dedicado.
    • Tiene sus entregables: el material que usemos para hacer la venta, presentación, etc. Si por ejemplo es una propuesta para un concurso público, ahí entraría toda la documentación a presentar. Otro entregable o documento a controlar podría ser el contrato, la estimación,....
    • Tiene sus roles y responsabilidades: alguien se responsabiliza de preparar el material, otra persona lo supervisa, otra (o la misma) presenta la oferta...etc
    Lo que no hay que perder de vista, es que la labor comercial, como cualquier otra...tiene un coste. Y como todo coste, sería una irresponsabilidad no darle un seguimiento y tener un mínimo control.

    Además, cuando hablamos de metodologías, parece que cuando el equipo de desarrollo comienza (bien con el análisis, diseño, o el propio código), es el PRINCIPIO DEL MUNDO. Es como el big-bang, el principio de la creación. No hay nada anterior, y si lo hay..."no queremos saberlo". Y no es así. No sólo hay que controlar esas acciones, sino que están relacionadas con el propio desarrollo:
    • ¿Se conoce la fecha de entrega? Pues claro: anda, léete el contrato.
    • ¿Y los requisitos me los invento? Pues tampoco: anda y léete la propuesta. A veces ahí están detallados los requisitos a un nivel impresionante.
    • ¿Y porqué esto está estimado así? Pues revísate la plantilla de estimación.

    jueves, 8 de septiembre de 2011

    Scrum y la motivación

    Parece ser que un equipo está motivado principalmente por dos factores:
    • Visibilidad (logros tempranos)
    • Reconocimiento
    Pero existe un peligro a tan fantástica conclusión, y es que al contrario, podría usarse Scrum para motivar al personal, simplemente porque "parece ser que los equipos que usan Scrum están más motivados". Es decir, olvidaríamos los requisitos, premisas y dogmas de Scrum, para centrarnos en "tener contentos a los programadores".

    Recientemente me he encontrado con premisas de este tipo: el seleccionar Scrum, como herramienta de motivación para los equipos de desarrollo. Después de todo, no parece una mala idea el motivar a los equipos mediante un cambio de forma de trabajo. Al final, el problema está siempre en necesidades contrapuestas. Por desgracia, al igual que tenemos un triángulo del software (calidad, tiempo, recursos), también tenemos un triángulo de actores que se relacionan con el desarrollo del software:
    • El cliente: tiene unas expectativas, y unos requisitos funcionales. No ve valor en el código, sino en necesidades de negocio resueltas.
    • La dirección (los jefes del equipo de desarrollo): la empresa no vive del aire, y para poder seguir desarrollando, hay que poder seguir emitiendo facturas. Tiene unos requisitos económicos y de negocio. Estas necesidades de la dirección está íntimamente relacionada con las labores "ingratas" o rechazadas por parte del equipo desarrollo (control, monitorización, documentación).
    • El equipo de desarrollo: En este caso, se trataría más bien de unos requisitos de satisfacción laboral, de bienestar social, reconocimiento, y algo que parecemos olvidar siempre: hay que cobrar todos los meses. No sólo de metodologías ágiles y buen rollito vive la gente.
    Hay que tener en cuenta estas interrelaciones entre los tres, ya que podemos encontrarnos con que la implantación de Scrum u otras metodologías ágiles, no consiga la motivación deseada, o lo haga de forma temporal.

    Es por eso, que en vez de buscar la mera implantación de una metodología, lo que hay que hacer es detectar las necesidades de los actores alrededor del desarrollo software, y lograr un equilibrio mediante:
    • Políticas de reconocimiento de logros
    • Metodologías que mediante técnicas ágiles obtengan logros tempranos, pero que no perjudiquen las necesidades de información de los clientes y gestores.
    • Sistemas de mejora continua, que satisfagan tanto a la empresa como a los desarrolladores.

    miércoles, 7 de septiembre de 2011

    Tipos de requisitos - no sólo de usuario

    A la hora de tomar requisitos, aunque nos enfrascamos siempre en lo que más nos gusta (recordad mi entrada sobre procrastinación), que suelen ser los requisitos que el usuario nos comunicada, es labor y responsabilidad de los buenos analistas el saber "rascar" la fachada y obtener una visión global de las necesidades a todos los niveles.

    Digo esto porque hay mucho más allá de los requisitos que solemos anotar al hacer las entrevistas con los usuarios. A continuación, una lista de tipos de requisitos, obtenida del libro que estoy leyendo (*):
    • End-user requirements
    • Software requirements, or functional requirements
    • Operational requirements
    • Platform requirements
    • Corporate requirements
    • Compliance requirements

    Aunque estemos tentados de quedarnos con los dos primeros, que son los más directos de obtener, es esa labor policíaca de "rascar" y obtener ese paquete de requisitos, restricciones, etc. lo que diferencia de un analista de verdad, de un señor que se limita a rellenar la ficha.

    Por poner algunos ejemplos:
    • Corporate: los requisitos corporativos pueden ser las normas de la empresa, la forma de trabajar (formalmente establecidos, o no). A veces una empresa es una filial de otra mayor, pues cuidado, que esa otra empresa mayor, puede tener requisitos corporativos que debamos tener en cuenta, y que quizá nos cueste descubrir a primera vista.
    • Operational: dentro de los operativos, podemos encontrar restricciones legales del negocio (legales a nivel local, regional, estatal, etc.) Por ejemplo, un software para una constructora debería tener en cuenta las restricciones legales, como pueden ser legislaciones locales de tiempo de conservación de documentos, de normas a cumplir etc.
    (*) El libro es: "Optimize Quality for Business Outcomes: A Practical Approach to Software Testing" (Andreas Golze, Mark Sarbiewski, Alain Zahn; (c)2008, John Willey and Sons),

    martes, 6 de septiembre de 2011

    Acelere sus proyectos: resumen de técnicas ágiles

    Voy a recopilar una lista de técnicas ágiles, o que de alguna manera pueden influir en acelerar la entrega de un proyecto en cuanto a calidad y funcionalidad:
    • Pair Programming. Programación por parejas.
    • Desarrollo Iterativo e Incremental.
    • Entregas frecuentes
    • KISS (=Keep It Simple, Stupid); simplicidad del código
    • YAGNI (=You Ain't Gonna Need It). Simplicidad general (funcional, arquitectónica, etc.)
    • Refactorización del código
    • Feedback rápido (realimentación)
    • Automatización de pruebas
    • Integración Continua
    • TDD (=Test Driven Development), empezar el desarrollo escribiendo los tests
    • FDD (=Feature Driven Development). Como el anterior, pero el desarrollo está guiado por los requisitos.
    • Prototipado
    • Peer Review. Revisión entre pares. Alguien de igual categoría (aunque preferiblemente de mayor experiencia), revisa el entregable.
    • DRY (=Don't Repeat Yourself)
    • HOLLYWOOD. Principio que favorece  la alta cohesión  y e bajo acoplamiento (facilitando el debug, pruebas y mantenimiento posterior del código)
    Algunas de ellas han sido absorbidas como suyas por ciertas metodologías ágiles.
    Para otro día, con tiempo y ganas, daré un repaso detallado de ellas, sus beneficios, y por desgracia, también sus riesgos/problemas.

    Desarrollar sin programar (II)

    Mira por donde, Microsoft ha sacado una herramienta llamada Visual Studio LightSwitch, que encaja con el tipo de aplicaciones que permiten crear aplicaciones "sin programar".

    Básicamente, permite hacer una completa aplicación en 3 capas en unos sencillos pasos:
    • Conectar a una base de datos
    • Definir las entidades de datos
    • Crear pantallas para las entidades (es posible crearlas automáticamente a partir de las entidades)
    • Faltaría ya solamente añadir código a la capa de negocio, aunque la validación y reglas básicas, pueden configurarse en el propio editor.

    lunes, 5 de septiembre de 2011

    Visión global de las redes sociales

    En la web http://www.elandroidlibre.com/, aparece una imagen que explica con un símil bastante gráfico, cómo son, y en qué se diferencian las principales redes sociales:



    ¿No anda muy desencaminada de la realidad?.

    ¿Por qué fracasa la formación en las empresas?

    En primer lugar, me gustaría aclarar que este post no está relacionado con mi empresa actual, ni con ninguna en particular. La información que ofrezco está basada en opiniones de diversos profesionales en diversas empresas.

    El tema, bien mirado, está relacionado con los dos principales del blog: calidad y desarrollo de software.

    Vamos a ver una lista de los problemas más habituales:
    • Una queja de los empleados, suele ser que la formación ofrecida, está pensada desde el punto de vista de las necesidades de la organización.
    • La formación ofrecida está obsoleta
    • La formación ofrecida no cubre las necesidades actuales de los proyectos
    • Las empresas cuentan con un presupuesto, una subvención, ...(en general, un dinero a gastar en formación), y se enfoca más en el qué (que se gaste ese dinero, se comunique y publicite, etc), que en el cómo (alineamiento de la formación, con las necesidades organizativas, de los proyectos, y de los empleados).
    • Las empresas, en general, no se preocupan de que el dinero en formación tenga resultados. (satisfacción de los empleados, grado de cobertura de necesidades detectadas, etc). Al no plantear objetivos medibles y no evaluar los resultados, no hay una visión global del rendimiento de la inversión en formación.
    • Los cursos no se asignan a los empleados que más partido pueden sacar de la formación, sino que se usan criterios subjetivos (amiguismos, etc.)
    • La empresa confunde el tener formación con el estar preparado para ofrecer soluciones. A veces se pretende sustituir la experiencia por formación, con escasos resultados.
    • En ocasiones, la alta dirección no le da la importancia que debería.
    • Las formaciones se contratan por precio y disponibilidad, lo que hace que a veces fracasen por ineficacia del formador, materiales, etc.
    • No siempre la formación está alineada con las expectativas y carrera profesional de los empleados.

    11 trucos para aparentar que siempre está ocupado

    He visto en un blog un tema que me ha parecido muy interesante, y está sacado en última instancia de Scott Adams, creador de Dilbert y todo lo que lo acompaña (tiras cómicas, libros, películas, etc):

    1. Quéjese constantemente de estar "abrumado". Utilice frases como "estoy hasta el cuello" o "saltando de un fuego al otro" para que su trabajo suene como sexy y peligroso.
    2. Lleve un pedazo de papel a todas partes. Para que sus gestos y lenguaje corporal cobren urgencia, imagine que es algo increiblemente importante, como una orden de ejecución firmada por el gerente.
    3. Nunca limpie su espacio de trabajo. Después de todo, si tuviera tiempo para malgastar, no viviría como un cerdo. De vez en cuando ordene u ojee papeles en su puesto. Simule leerlos con interés y preocupación.
    4. Simule un  lenguaje corporal como si estuviera estresado. Resople de vez en cuando. Rásquese la cabeza. Suelte alguna frase contundente del tipo “¿esto es imposible, no lo saco ni en un millón de años?". Así evitará que la gente le moleste.
    5. Mandar e-mails parece trabajo. Mande e-mails a sus amigos y familiares con frecuencia.
    6. Si tiene ganas de hablar, en lugar de trabajar, hable con su jefe. Eso cuenta como trabajo, sin importar de qué hablen. El tópico ideal para la conversación es el mal comportamiento laboral de sus compañeros de trabajo. Hay una variante de este último que es: "si su jefe va a tomar café, vaya y aproveche para tomar otro y hablar con él. Hay un punto extra si consigue
    7. Si utiliza gafas, deje unas viejas en su escritorio, como si usted fuera a regresar en unos minutos. Después, váyase a casa.
    8. Deje mensajes de voz a sus compañeros de trabajo a la 1:00 am, aún cuando sólo se haya levantado para ir al baño. Si realmente quiere despertar admiración, déjele un mensaje a su jefe con sus comentarios sobre el anticuado sistema de archivos usado en la empresa, a las 11:30 pm del 31 de Diciembre.
    9. Asegúrese de involucrarse en proyectos incuantificables. Escoja proyectos de consultoría, asesoría y participación. Evite cualquier cosa que tenga una fecha límite fija y cercana.
    10. Aprenda a dormir dando la espalda a la entrada de su espacio de trabajo. Tendrá que practicar evitar que su cabeza caiga de lado, pero vale la pena. Si no lo logra, cómprese un collarín del color de su piel.
    11. Despotrique de su trabajo tanto como pueda. Esto se considera trabajo, aún cuando es divertido. Como en el punto 1, su lenguaje corporal debe acompañar a la expresión oral.

    domingo, 4 de septiembre de 2011

    Desarrollar sin programar

    Imaginaos un futuro en que se pudiese crear software sin programar ni una sola línea de código (ojo, no he dicho sin saber programar, aunque tampoco quiero decir con ésto que sea obligatorio saber programar para crear este tipo de software).

    Imaginaos un futuro en que con sólo conocer el proceso de negocio, la interacción con el usuario y otros sistemas/procesos/bases de datos, se pudiese crear complejas aplicaciones.

    Imaginad que en ese futuro, en el desarrollo, se abstrajesen de forma totalmente transparente al usuario desarrollador:
    • lenguaje de programación
    • sistema operativo destino
    • arquitectura (MVC, N-tier, etc)
    • acceso a datos (ODBC, dataset, entidades POCO, etc).

    Imaginad en ese futuro, que las aplicaciones fuesen fáciles de mantener, y estuviesen actualizadas a las últimas tecnologías del mercado.

    Pues este tipo de software existe ya hoy. De hecho, existe ya desde hace muuuchos años. Además, uno de los entornos de desarrollo de los que me gustaría hablar se creó en su versión 1.0 en el año 1989! Me ha sorprendido, porque yo lo había oido hablar desde hace algo menos, los 14 o algo más de años que llevo en esta profesión. De hecho, me ha tocado trabajar con alguno de estos entornos (y ni siquiera es de los conocidos, pues es una plataforma para soluciones bancarias).

    Pues nada, a ver si saco un rato, y dedico un par de entradas en el blog a este mercado de aplicaciones, y a la que más me suena y conocía desde unos añitos.

    sábado, 3 de septiembre de 2011

    Cuando hablamos de CMMI

    Observo constantemente en blogs y comentarios frases como éstas:

    • "La metodología SCRUM es mucho más ágil que CMMI"
    • "CMMI es una metodología arcaica y excesivamente burocrática"
    • "No tengo claro qué metodología usar en mi proyecto: CMMI, SCRUM, xxx"

    ¿Nadie se da cuenta? El problema es que en todas las frases, se está hablando de CMMI como metodología, y no lo es. Por tanto, es absurdo compararla con cualquier otra (he usado por ejemplo SCRUM, pero podría haber puesto cualquiera).

    CMMI es un modelo de referencia. Según wikipedia: "es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software". Realmente, los que hayáis estudiado CMMI más o menos a fondo, veréis que en este modelo no se dice cómo se han de hacer las cosas, sino qué cosas deben hacerse.

    Os preguntaréis...¿hacerse...para qué? Pues para tener una metodología (conjunto de procesos) que cubran todos los aspectos necesarios, que cubran todas las necesidades de la gestión y el desarrollo. Es por eso que es absurdo comparar a CMMI con cualquier metodología (ya que no lo es). Es como lo de las peras y las manzanas: no se pueden comparar.

    Otra forma impropia de hablar de CMMI es cuando se usa para hablar de excesiva burocracia, métodos arcaicos, poco ágiles, o como cuando se vincula con metodologías en cascada (las famosas Waterfall Methods). Aquí hay varios problemas que provocan esto:
    • Excesiva burocracia: evidentemente, si algo no nos apetece hacerlo, pasará a segundo plano (ver mi reciente entrada sobre procrastinacion), aunque eso no signifique es es innecesario. Por desgracia, eso también ocurre si bajo nuestro punto de vista no es necesario. Por ejemplo, yo desarrollo software. No me gusta facturar al cliente, no me gusta hacer seguimiento de cobros...pero sin ello, ya puedo ser el mejor programador del mundo: no puedo vivir del aire. Yo, mi familia, todos necesitamos el dinero que cobramos. Luego el control de horas trabajadas, el control de pagos/cobros, y muchas otras actividades, son necesarias para la empresa. Cuando hablamos de burocracia, se nos olvida que no trabajamos para nosotros. Hay metodologías que por fin han involucrado a los clientes  (enhorabuena por el descubrimiento), pero siguen ignorando a la empresa en la que trabajan. Por desgracia, y es un mal endémico en nuestro sector, todavía hay quien cree que cobra por sus horas trabajadas, cuando en la mayoría de los casos, se cobra por cumplir un contrato.
    • Métodos arcaicos: algo es arcaico o antiguo en comparación o referencia a otra cosa. Resulta divertido ver cómo los defensores de ciertas metodologías, las consideran muy modernas para unas cosas, y luego para defender que están arraigadas y no son algo inmaduro, acreditan estar basadas en métodos, prácticas, y otras referencias de 10, 20, 30 años o más. Por desgracia, en nuestro sector se consigue que algo sea bueno o atractivo, en base a destruir la reputación de todo aquello que le pueda hacer competencia.
    • Agilidad: los métodos son tanto más ágiles, cuanto más rápidamente nos acercan a nuestros objetivos. Eso no significa que sean los más rápidos. Se nos olvida muchas veces, que para llegar antes, no es más importante correr mucho, sino tener claro hacia dónde debemos ir (y no desandar constantemente el camino). Esto me recuerda muchos proyectos en los que no se tienen claros los objetivos, ni qué hay que hacer, pero los jefes de proyecto insisten en "redoblar los esfuerzos". Por eso, las técnicas, prácticas y metodologías, serán sólo ágiles, cuando en las condiciones favorables, nos acerquen a nuestros objetivos de forma que se aumente el rendimiento.
    • Desarrollo en cascada. Esto casi lo dejo para otro post, tan grande es la confusión que observo respecto a este término, y su vinculación con CMMI y muchos otros conceptos.
     CMMI es desde luego un método imperfecto a la hora de evaluar la madurez de las empresas y los procesos, pero tiene muchos puntos a su favor:
    • No hay muchos métodos de evaluación de la madurez
    • Es un método en constante evolución y mejora. Actualmente CMMI DEV está en su versión 1.3.
    • Se integra muy bien con prácticamente todas las metodologías de ciclo de vida.
    • Es un modelo extendido a nivel mundial, y está diseñado para comparar uniformemente a organizaciones de todo el mundo.
    • Para las empresas, es un modelo de evaluación ventajoso: proporciona prestigio, y el "sello" de calidad queda referido a la empresa, no a sus individuos. Los individuos se van o vienen, pero los beneficios se quedan en la empresa.
    Bueno , hasta ahora hemos visto que usar CMMI en comparación con otras metodologías, no es adecuado, y que se desprestigia injustamente a este modelo (en la mayoría de los casos, por ignorancia o para crear prestigio por comparación), pero no pensemos que por ello, es perfecto, ni tiene defectos. Me guardo para un post el detallar los problemas y defectos de CMMI como modelo, y su mayor talón de aquiles: las pésimas implementaciones como metodología que se hacen a veces, cuando el único objetivo es "tener el sello de calidad".


    viernes, 2 de septiembre de 2011

    Procrastinación

    Interesante palabrita, que últimamente se está oyendo mucho. Una definición que encuentro:

    "Procrastinar: dejar para mañana lo que se puede hacer hoy."

    Básicamente, es no afrontar una tarea que tenemos pendiente, y que vamos retrasando horas, días o incluso semanas. La cuestión es que esa tarea, normalmente:
    • No nos gusta
    • No nos vemos preparados para llevarla a cabo
    • Sentimos temor del resultado de esa tarea
    Para eso no hacía falta una palabra tan rara, desde luego. Y viendo esta información, hasta parece que todos nos hemos visto alguna que otra vez en esta situación. Sin embargo, si vemos la definición en wikipedia:

    "Se trata de un trastorno del comportamiento que tiene su raíz en la asociación de la acción a realizar con el cambio, el dolor o la incomodidad (estrés). Éste puede ser psicológico (en la forma de ansiedad o frustración), físico (como el que se experimenta durante actos que requieren trabajo fuerte o ejercicio vigoroso) o intelectual."
    Ostras, aquí ya es algo serio. ¡Un trastorno del comportamiento! Va a ser que no es algo muy bueno (cosa que ya sospechábamos por otra parte). Lo que ya ha sido la guinda ha sido comprobar por mi parte que existe un portal http://procrastinacion.org/, dedicado exclusivamente a este innoble arte.

    Un punto que no veo mencionado es que este postergamiento de las tareas, está relacionado con el mundo del desarrollo software y especialmente con la calidad. En muchas ocasiones, el personal técnico se ve tentado de no afrontar las tareas asignadas, y en su lugar realizar alguna tarea (asignada o no), pero que es más atractiva, o interesante. Cuántas veces, alguien en un equipo no ha completado un desarrollo a tiempo, pero sin embargo sí ha tenido tiempo de añadir alguna funcionalidad que no estaba planificada, o ha implementado alguna nueva tecnología, etc, etc.

    Por desgracia, en el mundo del software (aunque ocurre también en general), esta "procrastinación" está asociada a la Ley de Parkinson. Básicamente, se trata de que la gente si para una tarea tiene 2 horas, si acaba en 1, se busca algo que hacer para llenar el tiempo que le sobra. Esto tiene una segunda revisión, y es que hay veces que ni siquiera han terminado la tarea en las 2 horas, y sin embargo ese tiempo no se ha dedicado íntegramente a la tarea. Más en detalle, la definición de ley de Parkinson en wikipedia extiende la ley de Parkinson a estos puntos:
    1. "El trabajo se expande hasta llenar el tiempo de que se dispone para su realización".
    2. "Los gastos aumentan hasta cubrir todos los ingresos".
    3. "El tiempo dedicado a cualquier tema de la agenda es inversamente proporcional a su importancia".
     El tercero, de nuevo, nos recuerda que somos proclives a hacer las cosas que nos gustan, no las que realmente importan.

    En el mundo de la calidad y el desarrollo software, estas afirmaciones son destructivas: no se dedica el tiempo a lo planificado, por lo que la calidad del software resultante no siempre es predecible. Siempre se obtienen respuestas de los equipos de trabajo del estilo: "es que no hemos tenido tiempo de probar", "los plazos son muy agresivos". Estas afirmaciones, por desgracia, son ciertas en muchas ocasiones. Pero también es cierto que no se utiliza el tiempo de forma adecuada (basta ver la relajación de los equipos de desarrollo, que va disminuyendo hasta convertirse en una sobrecarga brutal de trabajo conforme nos acercamos a la fecha de entrega...¿nos suena esto de algo?).

    jueves, 1 de septiembre de 2011

    Importancia de los requisitos

    En el desarrollo software, se suele hacer un énfasis enorme en metodologías, ciclos de vida, técnicas varias, frameworks, etc. Sin embargo, la realidad nos sigue diciendo que uno de los principales motivos del fracaso de los proyectos está en los requisitos (inadecuados, incompletos, etc).

    Recientemente leía el libro "Optimize Quality for Business Outcomes: A Practical Approach to Software Testing" (Andreas Golze, Mark Sarbiewski, Alain Zahn; (c)2008, John Willey and Sons), que trata todo el tema de pruebas del software. Aquí encontraba un ejemplo de cómo los requisitos y su gestión, influyen en una mala solución. Como puede verse, la falta de habilidad del analista para obtener la información no proporcionada por el cliente, junto con las falsas expectativas que éste se había hecho, hacen que la solución final sea una pérdida de recursos y un cliente insatisfecho.