diciembre 29, 2008

Cuatro años y feliz año nuevo

No todos estos últimos años he celebrado el cumple de este blog. Pero este año es (debe de ser) diferente.
Hace cuatro años ya que empecé a escribir: 200 posts, aunque no es mucho, este es un blog modesto :) . Empecé hablando de software libre, para dar a conocer mi tesina sobre ello. Después pasé a temas más de programación y que leía por otros blogs, pasando por temporadas de muy pocas publicaciones, y últimamente hablo especialmente de gestión de proyectos: me ha invadido el "gusanillo ágil". El año que viene espero seguir con un ritmo un poco constante de publicaciones, ahondando en este tema del desarrollo de software. Quizás entre todos podamos encontrar la nueva síntesis surgida de las metodologías ágiles y formales.
Así que aprovecho para felicitaros el nuevo año a todos, y desearos que descubrais el mejor camino a seguir!!

diciembre 15, 2008

Retrospectiva anual

Dos libros me tienen enganchado últimamente: "Software for your Head", y "Agile Retrospectives: Making good Teams Great". Y con estos, he preparado una retrospectiva anual, basándome en algunos conceptos y actividades interesantes que plantean.
Ya decía anteriormente que un concepto muy importante de las metodologías ágiles es la comunicación de banda-ancha entre los miembros del equipo. Sin duda, "Software for your Head" es uno de los libros que más te puede aportar en ese sentido.
Las retrospectivas en las metodologías ágiles son una práctica muy útil para la mejora continua de los procesos de desarrollo, del equipo, de las metodologías. Así que ahora que vamos introduciendo poco a poco metodologías ágiles en el desarrollo, se me ocurrio hacer una retrospectiva no ligada a una iteración o un proyecto, si no al año que termina. Una retrospectiva anual para establecer objetivos de mejora por el equipo para el año siguiente.
Y por si a alguien le interesa, estos pueden ser unos buenos pasos para hacerse la suya en casa (al menos creo que a nosotros nos han sido útiles), basados en el libro de Derby.

  1. Set Stage:
    Actividad 1
    : Check-in. Los participantes comentan su estado de ánimo.

    Introducción a la retrospectiva: Objetivos: Aprender y mejorar.
    Actividad 2: ECRP (Decide your role in this retro: Explorador/Consumidor/Relajado/Prisionero)

  2. Gather Data:
    Actividad 3
    : Timeline. Se desglosan por equipos los eventos/hechos ocurridos el año 2008 en el equipo, pintándolos sobre una linea temporal.

  3. Generate Insights:
    Actividad 4: Brainstorming. Desglose de cosas que podemos mejorar. En resumen, y sin orden de importancia, todo lo que salga.

  4. Decide What To Do:
    Actividad 5
    : Definir objetivos SMART. Decidir qué hacer. Objetivos para el 2009 de todo el equipo, como equipo.

  5. Close:
    Actividad 6
    : +/Delta. Retrospectiva de la retrospectiva. ¿les ha gustado?
Esto es simplemente un esquema, los libros están realmente detallados. Se podrían hablar de muchas cosas de cada punto o actividad, pero me gustaría que me contaseis si haceis vosotros este tipo de cosas en vuestras empresas, o si creeis que sería interesante. ¿Haceis retrospectivas a todos lo niveles?

Actualización (30/12/2008): Acabo de descubrir que han hecho un pequeño resumen del libro sobre Retrospectivas en castellano. Utilísimo como referencia una vez que te has leido el libro! Gracias Juan por tu trabajo!

diciembre 07, 2008

El declive y caida de lo ágil

Un reflexión de tic-tac (sobre una frase: "El hombre que actúa con métodos, ignorando los principios, es seguro que tendrá problemas.") me hace pensar en la carga de profundidad que tiene este otro artículo de James Shore: The Decline and Fall of Agile.
Habla sobre los problemas que está dando la proliferación de implantaciones que se están haciendo del método Scrum, pero haciendolo sin preocuparse de los principios que lo sustentan.

"These teams say they're Agile, but they're just planning (and replanning) frequently.. ""Agile is hard, and you can't master it by sitting through a two-day course."
Ciertamente hay una serie de cuestiones que escapan al "método Scrum", que deben ser parte fundamental de una metodología ágil. En el mismo artículo comenta algunas:
  • shared workspaces: La comunicación en espacios compartidos fluye mejor, es más fácil compartir una visión y el trabajo.

  • high-bandwidth communication: El equipo debe mantener en todo momento un canal de comunicación de alta capacidad. No hay excusas para guardarse información, no preguntar, o no compartir.

  • on-site customers: Es muy importante la disponbilidad del cliente cuando sabemos que los requerimientos van a evolucionar, y el equipo necesita aclaraciones en cualquier momento.

  • work in cross-functional teams: Los equipos multidisciplinares deben estar intrgrados en la solución del proyecto, deben ser un equipo al completo, no una serie de grupos de personas que resuelven cada uno su papel. Así se pierde enseguida la visión compartida.

  • let alone deliver releasable software: El avance de los proyectos se mide por producto terminado.

  • use good engineering practices: El concepto de deuda técnica aclara muy bien este punto. Si te hipotecas tecnicamente, el futuro del software no será sostenible.

Pero, ¿realmente son necesarias todas estas prácticas anteriores para ser ágil? Pues... ¡quizás no! Hay que conocer los principios, y aplicarlos para cada problema, que necesita una respuesta adaptada. En un comentario del grupo de Yahoo de lean-agile-scrum, la genial Mary Poppendieck lo dice en una respuesta muy interesante:
It sounds to me like you are taking the Scrum recipe much too seriously. If you want to be successful, you have to spend some time thinking creatively about what will work in your world. Lifting recipes from others and expecting them to work in your environment doesn't have a good track record of success.
Creo que por aquí estamos bastante lejos de pensar en el declive de Scrum, cuando no me parece que esté demasiado implantado por estas tierras. Pero si podemos llegar a la lección antes de qué nos peguemos con los problemas, eso que habremos ganado.

noviembre 30, 2008

Libros de desarrollo de software

Creo que este es el primer post que recupero "bajo demanda". Me acabo de fijar que tenía empezado uno con el mismo título desde mayo... ¡del año pasado!.
En fin, que ya me he decidido a haceros un listado con algunos de los últimos títulos que tengo en mi biblioteca relacionados con el desarrollo/gestión de software. He seleccionado algunos y los he ordenado más o menos por lo que me han resultado de interesantes o productivos. De todas maneras, sigo con una lista interesante de libros por comprar, esto no se acaba nunca! :)
Otros libros que no son propiamente de desarrollo de software, pero que he comprado ultimamente, relacionados con lo que yo creo que es el mundo de la gestión de equipos:
  • Marcapropia: El mejor libro en castellano explicando el concepto de marca personal, por Andrés. El año pasado presté un libro a cada persona de mi equipo a la que hacía la gestión por competencias de la empresa, pensando en sus labores a desempeñar. Este año había pensado regalarles a todos una copia de este libro. (otra cosa es que ya no lo vaya a hacer en vista del poco éxito de la iniciativa pasada :( )
  • My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers). Relacionado con el concepto de marca personal, cualquier momento es bueno, para este libro pero sobre todo si no tienes muy claro por donde ir en tu carrera profesional relacionada con el software.
  • Certain to Win: Un libro sobre estrategia empresarial, pero basado en las estrategias militares de John R. Boyd. Viene a insitir en la idea de la agilidad y los ciclos de PDCA.
  • Fearless Change: Patterns for Introducing New Ideas: Otro libro de patrones, pero esta vez dedicados a la introducción de cambios en organizaciones. Es interesante ver como muchas situaciones las puedes reconocer en determinados elementos de la empresa.
  • Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers): Introducción a la gestión de equipos, cuando debes asumir esa responsabilidad. Me parecio un poco simplón, pero me gustó que te da ideas concretas para realizar.
Bueno, estos son algunos de los libros que he adquirido estos últimos dos años, posiblemente los que más me han impresionado o enseñado. Eso sí, todavía tengo que poner muchas cosas en práctica, que es con lo que de verdad se aprende... :)
Lamentablemente, ahora me fijaba lo poco que se traduce al castellano de todos estos temas. Me pregunto si es que no habría suficiente demanda para la traducción de un número mayor de libros.

noviembre 17, 2008

Calidad testeada vs calidad creada

La calidad de un producto software se puede medir, ahora bien, lo dificil es escoger la métrica adecuada. Pero además, también puedes tener la impresión de que se ha hecho con calidad, si se han seguido unos procesos correctos, el equipo ha cuidado sus diseños técnicos, se han seguido patrones de diseño,...
Desde que estuve en la jornada de testeo de software tengo la idea en la cabeza de como comunicar el mundo del testeo y el del desarrollo (eso claro, si cuentas con un equipo propio de QA, que no conozco muchos).
  • Los testeadores no se pueden quedar unicamente en encontrar fallos, además deben dar ideas desde su posición provilegiada de cómo mejorar el desarrollo del software.
  • Así mismo los desarrolladores no deben unicamente desarrollar, deben comprometerse con la realización cada vez más exhaustiva de pruebas y cómo facilitarla.
Podemos tener dos aproximaciones poniendome en el lugar de una empresa que desarrolla muchos proyectos de medio tamaño:
  • Equipo de testeo independiente de los equipos de desarrollo: Esta opción es la que nos contaron la gente de Google en las jornadas de testeo de sw. Podría existir un equipo que valide cada resultado de los sprint, realizando pruebas de caja negra sobre el sistema. Los posibles defectos encontrados, retrasarían la velocidad en el siguiente sprint del equipo de desarrollo.
  • Gente de QA integrada en el equipo: Los testeos más formales se realizarían dentro del sprint mismo de desarrollo, estas personas podrían realizar tanto testeo de caja negra como "blanca".
Pero una de las cuestiones más interesantes, y que en las jornadas de Valencia me parecio un mundo aparte, es la integración entre los dos equipos. Cuando hablamos de "Equipo=software", debemos incluir a todas las personas implicadas. Cada especialista puede aportar una visión muy importante al resto del equipo, que hace mejorar exponencialmente el trabajo en equipo.
Actualmente muchas pruebas se han trasladado a los desarrolladores, no solo por que no existen muchisimas veces equipos de QA, si no por que técnicas como el testeo unitario, se ha trasladado la responsabiliad del equipo de testeo a los desarrolladores.

noviembre 12, 2008

Framework, o esa palabra maldita

¿Qué piensa un desarrollador cuando le dicen que tiene que utilizar un framework inventado por la consultora MAJITICA SA para su nuevo proyecto web?

- J***d*r,... la que me ha caido... con la de frameworks libres que existen por el mundo y ahora tengo que usar uno que no tendrá más de 500 horas de pruebas y que no puedo ni ver su código.
Y es que mira que nos empeñamos en reinventar la rueda. Una cosa es desarrollar un API orientado al negocio, y otra sobreescribir el MVC de moda pegándole un IoC para que parezca que hemos hecho algo. ¿Cuantos de estos conoceis?

noviembre 02, 2008

¿Es SCRUM una ventaja competitiva en una empresa de servicios?

Como ya sabeis, estamos "tonteando" con Scrum en la empresa. Puede ser que sea un idilio largo o no. El otro día nos dieron un curso francamente bueno, fue la empresa Proyectalis. Podeis echar un ojo al blog de Angel Medinilla, quien nos impartio el curso de dos días, muy bien planteado e interesante.
Lo que ahora me pregunto es hasta qué punto Scrum puede ser una ventaja competitiva frente a las demás empresas proveedoras de servicios en este mundo del desarrollo de software. Tengo claro que no debemos de tratar únicamente de cumplir con los requisitos del cliente cerrados en el contrato y punto final, si no asegurarnos que esos requerimientos son los que hacen "feliz" al cliente. En esa filosofía, la base de las iteraciones ayudan: el cliente pone el foco en lo que quiere realmente mucho antes.
Sin duda Scrum en estos momentos puede suponer una diferenciación en el mercado actual. Pero eso sí, posiblemente especializandose en determinado tipo de cliente. La estrategia ganadora no puede ser en este momento una diferenciación para todo el mercado, sino una especialización en un nicho muy concreto de clientes. ¿Aceptarían todos los clientes un desarrollo "Scrum"? ¿podrías competir con grandes consultoras en mega-proyectos? ¿puedes dar servicio a administraciones públicas que te piden METRICA3 (o 2)?... ¿interesa hacer todo esto?

Esta es solo una entrada de dudas/preguntas, pero mi opinión es que SCRUM es el buen camino, hacia el "norte verdadero" que nos decía Angel en su curso.

octubre 20, 2008

El círculo proceso-persona

Leyendo esta entrada sobre la idea recurrente de que lo más importante para hacer software son las personas, me ha venido a la cabeza una reunión de hoy que hemos tenido en Biko. Las mejoras en el desarrollo de software no se acaban nunca, y cuando tienes a medio hacer algo (podeis echar un ojo al documento libre sobre la implantación de técnicas ágiles con CMMI) ya estás pensando en lo siguiente.
Como decía, el post referenciado, me recordaba lo que hacemos cuando intentamos mejorar las cosas. En la mente tienes que lo importante son las personas, pero lo más facil ¿qué es? ¡¡Definir procesos!! Te pones a pensar: si hacemos las cosas así, o de esta otra manera, y luego nos sale esta otra situación, entonces lo que hay que hacer es... definimos cómo se debe hacer esto, para que después se haga igual...

Así que nos hemos ido a los procesos y parecería que nuestra intención es implantar CMMI nivel 4 o 5. (uf, y por cierto, no os olvideis de la encuesta, gracia). Yo siempre acabo diciendo que lo mejor es usar el sentido común, conociendo bien las herramientas disponibles y con la experiencia, se pueden tomar decisiones acertadas que son totalmente diferentes en el marco de un proyecto u otro. Pero siempre parece que tiras a definir los procesos, más que a pensar que la gente que tenga que resolverlos ya sabrá hacerlos, o que precisamente, a los que no sepan les vas a formar.

Es una dialéctica complicada, la de procesos contra personas planteada en el manifiesto ágil. Y cuesta romper. Supongo que tenemos hecha la cabeza de una manera (dura) que es dificil de cambiar la forma de pensamiento.
Todo esto está relacionado con lo que ya he comentado en otras ocasiones: ¿buenas prácticas o procesos? Al final, depende de la gente, a unos los puedes matar de aburrimiento siguiendo procesos muy formales, y a otros perderlos por el camino si no les pones las luces de aterrizaje bien claras.

octubre 16, 2008

Encuesta sobre CMMI

A raiz de este post que menciona que hay 85 empresas más en España este año que han obtenido una certificación CMMI, me ha picado la curiosidad, yestoy montando una pequeña encuesta con intención de recoger información de aquellas personas que trabajen en una empresa con certificación CMMI. He reducido bastante el número de preguntas que quería hacer, para que no se haga pesada (que es lo que a mi me suele echar atrás para rellenarla, sobre todo, ;) si como en este caso no hay premio por hacerlo).

Si te apetece, aquí tienes el enlace: Encuesta sobre CMMI.

Y si conoceis a gente que pueda encajar en el perfil para rellenarla, por favor, me encantaría que les distribuyeseis el enlace.
Obviamente, después publicaré los datos y la información que pueda extraer de ellos en esta misma página. ¡GRACIAS!

octubre 09, 2008

Dos cosas

Ayer recogí del correo el libro de Andrés Perez sobre MarcaPersonal. Me hizo mucha ilusión ver mi dedicatoria escrita en papel "de verdad". Me imagino que será como volver a leer de nuevo su blog, que ahora estaba pensando, es uno de los primeros que sigo desde el tiempo que llevo leyendo blogs. !Gracias Andrés, eres un crack!
No deberíais dejar de echar un vistazo al blog de Andrés, sobre todo si ahora en época de crisis os encontrais dudando sobre vuestras opciones profesionales.

Por otro lado, otra conexión con el mundo real por el blog, me invitan !por fin! a escribir un post a cambio de dinero. :D Bueno, a cambio de una suscripción a GTDagenda, que la verdad, tiene buena pinta, pero de momento me quedo con lo que tengo, ya que necesitaría dedicar un rato que ahora no tengo para probar el sistema. Bastante tengo perfeccionando mi implementación de GTD... Si alguien lo usa sí que me gustaría conocer sus comentarios, a mi de momento RTM me funciona bastante bien, con su buena integración con GMail.

octubre 07, 2008

Organización del tiempo: GTD

Hace unas semanas, tras leer el famoso libro de David Allen "Getting Things Done" (también está en castellano), me decidí a poner en marcha mi aproximación al que parece uno de los mejores métodos de organización existentes a nada que consultes un poco en Google. En realidad, había leido el libro a principios de año, y lo volví a releer para empezar con el método.

Si no sabes de qué va GTD, brevemente te explicaré que trata de un sistema para la organización personal. Un sistema muy metódico, que tiene muchos seguidores por la red. No te voy a explicar aquí de que va, si no lo conoces, aparte del libro, te recomiendo este magnífico post de David Santo Orcero sobre GTD. Dice que es el primero, así que siguele la pista por que es una de las mejores explicaciones sobre una implementación concreta que puedes encontrar en castellano que no sea el libro mismo.
Mi aproximación no es tan completa todavía como la que puedes leer a David Santo, pero ahí vamos poco a poco.

Mis bandejas de entrada son el correo electrónico, y una bandeja tanto en la oficina como en casa. Utilizo rememberthemilk para gestionar mis listas, y me va muy bien la integración que tiene con GMail, ya que es el correo tanto personal como en el trabajo. Tengo mis listas (proyectos, acciones siguientes, en espera,...) organizadas por contexto con los tags de cada tarea, usando @xxxx cuando se trata de separar por trabajo, personal, telefono,... y les pongo +yyyy para indicar con qué persona está relacionada. Luego tengo creadas "SmartList" para las más usadas. El plugin de RTM además me relaciona las tareas con el correo electrónico desde el que las cree.
Estoy intentando rematar mis sistemas de ficheros, de momento me he organizado mejor las carpetas en los ordenadores, que no es poco, y veremos como voy haciendo las de papel, que en realidad son las que menos uso.

Suelo llevar una Moleskine encima cuando me acuerdo (y me cabe en algún bolsillo) para llevar notas, y que sirva también de bandeja de recopilación en cualquier parte. El problema que le veo precisamente es que necesito demasiado estar "online" para conocer todo el tema, creo que voy a empezar a imprimir las listas en mis revisiones semanales para poder llevarlas encima.

¿Funciona el método? Bueno, si eres un poco desorganizado por naturaleza: ¡pruebalo! Aunque únicamente apliques tres o cuatro cosas, seguro que te mejora la organización, y para mi, es un alivio ver que llevo el correo al día (¡¡llego a tener el INBOX vacio!!), y que sé que no se me escapa nada debido a un despiste.
Estos son un par de blogs sobre organización y productividad interesantes:

octubre 04, 2008

Confianza Mutua, equipos y desarrollo

Uno de los posts que más visitas me ha traido, es en el que hablo sobre la confianza y las metodologías ágiles. Comentaba el porqué de que la confianza es básica para las metodologási ágiles. Ahora he encontrado un "post-it" que apunté hace tiempo, cuando leía un libro -lo malo es que no recuerdo cual, no sé si era uno de John Boyd o alguno sobre "Lean Software"- sobre que la clave de buen funcionamiento de un equipo es la confianza mutua, que basaba en cuatro pilares fundamentales:
  • Visión compartida: Uno de los típicos problemas en un equipo de desarrollo es que cada uno va a su aire, y demasiado tarde se dan cuenta que van hacia ideas diferentes del producto o de su implementación. Para Scrum, por ejemplo, este es un punto muy importante que intenta reslver con la implicación de todas las personas afectadas en el royecto con reuniones periodicas, y con los desarrolladores en reuniones diarias.
  • Comunicación: Una buena comunicación es fundamental para que puedas confiar que lo que entiendes te ha llegado de la manera adecuada y por tanto has entendido lo que la otra parte de verdad te ha intentado transmitir: que no es fácil.
  • Toma de decisiones compartida: Obedecer ordenes predispone a la desconfianza de los datos con los que se ha tomado, o por qué se ha tomado. Que el conjunto del equipo asuma las decidiones que tienen que afrontar, implica que también asumen su responsabilidad, y que pueden confiar los unos en los otros, por que la decisión es de todos.
  • Ética: No es sorprendente que un punto que pueda parecer que técnicamente no influye en una gestión de equipos, sea una clave fundamental para su buen funcionamiento. La falta de ética de uno de sus miembros corrompe cualquier atisbo de posterior confianza en esa persona, y por tanto, aumenta las suspicacias. No recuerdo ahora haber leido ningún libro sore metodologías ágiles que hablase explicitamente de este punto, pero cuando lo lei aquí, me parecio bastante básico y de sentido común. Una mala persona es capaz de envenenar cualquier equipo.
Y tú, ¿confías en los miembros de tu equipo? ¿confían ellos en ti? ¿crees que sois un equipo si esto no es así?

octubre 02, 2008

A la carga

Bueno, pues desde mi última entrada ayer... ah no! en Abril! hablaba sobre SpringSource, y ahora resutla que van a cambiar el modelo de licencias de Spring. Parece que no es tan fácil hacer dinero con el software libre.
Pero Andrés no me deja estarme quieto, y tiene toda la razón. Así que vuelvo tras los San Fermines, las vacaciones, la tranquilidad de Agosto y el agobio de trabajo de Septiembre. Tras el inicio del cole para mi hijo, mis primeros pasos en la implantación de GTD, varios libros leidos y releido y algún disgusto importante, pero superado. De estas y otras cosas espero volver a hablar con más asiduidad por aquí.
Hoy tenía planeado haber ido al evento "Por propia experiencia", al que habíamos enviado un trabajillo, sobre implantación de metodologías ágiles con CMMI. Podeis descargaros el documento y echarle un vistazo: Metodologías ágiles sobre CMMI. Tenemos mucho camino por hacer en este sentido, espero poder ir reflexionándolo por aquí. Ahora espero impaciente a leer los comentarios de Julen sobre el evento.

abril 30, 2008

Escenarios ante "SpringSource Application Platform"

Tenemos una nueva plataforma de aplicaciones JAVA: SpringSource Application Platform. Es una plataforma que no cumple JEE completamente, y de hecho no parece que lo vayan a hacer. Soportan los módulos web como WAR, pero no se asoman los EJBs.
¿Necesitamos otra plataforma de aplicaciones en el mundo JAVA? Creo que no. El punto fuerte de esta nueva plataforma parece que va a ser la utilización de una plataforma OSGI. Esto puede ser un respaldo muy fuerte para esa arquitetura que no acaba de despegar en las aplicaciones reales. Pero tampoco es tan necesario, ni las ventajas que aporta son tan decisivas, nada que no se pueda hacer en el estandar JEE.
Como comenta Martín, esto podría ser un punto de inflexión en el mndo JAVA empresarial. Si se rompe la unidad sobre la plataforma JEE, podemos acabar con una de las ventajas más importantes: la interoperabilidad. Es cierto que ya hay muchas lineas de arquitecturas diferentes en JEE, pero la fuerza de Spring actualmente en muchos desarrollos pueden dar una fuerza muy importante a esta nueva plataforma.
De todas maneras, siempre es genial ver cómo hay gente que no se cansa nunca y tiene ideas novedosas y mejoras en un mundo en el que para algunos las cosas se han anquilosado demasiado. Y además, ahora ya tenemos un juguete nuevo para cacharrear :).

abril 29, 2008

Patrones y mejores prácticas

Una de las ideas que me rondaba la cabeza hace tiempo es cómo aprendemos, y cómo enseñamos. Los últimos libros que he leido plantean estas cuestiones en base al concepto de patrones. Y me gusta. Patrones de cómo hacer las cosas en determinados contextos, proponiendo determinadas soluciones. También puedes aprender las tareas a realizar para resolver algo, si alguien te dice qué pasos debes dar, los aplicas y listo.
Lo situo un poco en la linea de procesos vs. personas de las metodologías ágiles. Si quieres que alguien aprenda gestión de proyectos (¡de equipos!-tengo que hablar un día sobre "Software for your head"), ¿le das los procesos que debe seguir? ¿o le explicas las situaciones, las posibles soluciones, los problemas,...? Si quieres establecer cómo se deben de hacer las cosas, puedes establecer procesos, o puedes explicar las cosas, su porqué y su cómo, pero ¿cuando hacer una cosa u otra?
Acabo de leer un artículo que me parece muy clarificador, desde mi punto de vista, que solo llevo menos de un año con responsabilidades de jefe de proyecto, para aprender a enseñar y enseñar: Better Best Practices.
Plantea la evolución de las "buenas prácticas" en una empresa apoyándose en el modelo de Dreyfus del Aprendizaje. Este se basa en poner cinco etapas al aprendizaje, dónde cada etapa tiene unas necesidades para realizar bien sus tareas y aprender con ello. Hay cinco niveles, resumidos más o menos:
  • Novice - Needs to be told exactly what to do. Very little context to base decisions off of.
  • Advanced beginner - Has more context for decisions, but still needs rigid guidelines to follow.
  • Competent - Begins to question the reasoning behind the tasks, and can see longer term consequences.
  • Proficient - Still relies on rules, but able to seperate what is most important.
  • Expert - Works mainly on intuition, except in circumstances where problems occur.
La conclusión que he sacado después de leer el libro "Acerca de Internet" (que me compré por que ese artículo me picó la curiosidad), es que los procesos impiden la excelencia y la brillantez en los trabajos, pero que son necesarios para llegar a un nivel medio de desempeño, especialmente útiles en las fases de aprendizaje.
De aquí podemos llegamos a dos conclusiones de manera un poco más formal que creo ya he comentado otras veces, sobre las metodologías de desarrollo:
  • Sobre las metodologías ágiles, que es dificil integrar a gente más "novata" en ellas. No hay procesos, y la gente sin experiencia necesita una guía más centrada en qué hacer. No se desenvuelven bien en entornos que aún no controlan.
  • Sobre las metodologías basadas en procesos: Que impiden que la gente experta sobrepase el listón establecido de "media"(¿mediocridad?) en los procesos, y no sé aprovechan las experiencias completamente.

abril 08, 2008

Testeo, cerdos y gallinas

¿El equipo de testeo de software -si existe :)- tiene una implicación como cerdos o como gallinas desde un enfoque ágil del desarrollo?
En las jornadas de la semana pasada JTS2008, se habla mucho de equipos independientes de testeo de software, de equipos separados que hacen el testeo y se comunican con desarrollo prácticamente para comunicarles los bugs. Entonces, ¿qué implicación tienen como equipo? Si no recuerdo mal, salvo la persona de Google (Julian Harty), nadie más habló de implicar gente de testeo con el equipo de desarrollo para ayudarles a mejorar su proceso de creación del software. Y esto me estuvo dando vueltas toda las jornadas.
Cualquier proceso de calidad que se precie tiende hacia la mejora continua, pero esto no creo que se deba entender en software como simplemente la eliminación de bugs de los producto, si no como la búsqueda de la eliminación de las causas de creación de bugs. El equipo de testeo puede ayudar identificando areas donde el desarrollo mete más la pata, detectar dónde es más necesaria formación, o un rediseño, o un mayor hincapie en las pruebas unitarias...
Así que lo veo complejo, por que empiezo a creer que es genial tener un equipo externo que haga testeo del software, en plan gallinas,... pero también creo que deben estar implicados como cerdos para la mejora continua "hasta el infinito y más allá!", y para eso necesitan plena involucración con el equipo de desarrollo.
Algunas pruebas típicas de testeo las estamos moviendo poco a poco hacia el equipo de desarrollo, como las pruebas unitarias, por que realmente... ¿que % de proyectos cuentan con un equipo de testeo? y las metodologías ágiles nos han dado las técnicas necesarias para ello (al menos las han popularizado). Este es uno de los puntos por los que mejoramos el proceso para eliminar la creación de bugs, pero queda mucho por hacer...

abril 07, 2008

Usabilidad de los funcionarios

Biko2 ha publicado un informe sobre la usabilidad en webs de las Comunidades Autónomas. Podeis descargarlo en esta dirección de Biko2.

El equipo de consultoría y experiencia de usuario de Biko ha analizado los portales de las 17 Comunidades Autónomas españolas identificando aquellas que son punteras, presentando buenas prácticas e identificando los aspectos más críticos a mejorar.
Es un interesantísimo informe si te atrae el tema de la usabilidad o las administraciones públicas online. Lo que yo no sé es por qué nos preocupamos tanto por las situaciones online, cuando no sé si los de las ventanillas aprueban!
Veamos a la imagen típica de los funcionarios, tal y cómo es apreciada por multitud de nuevos aspirantes a un puesto "seguro para toda la vida", haciendo el paralelismos con lo que han aportado desde Biko2. :)
Posicionamiento. "Como me posicione en la silla con plaza fija no muevo el culo de ahí ni para levantarme al café... bueno, eso sí."
Servicios al ciudadano. "El ciudadano soy yo!"
Ventana al visitante. "Siempre y cuando no vengan a verme a la hora del café!"
Presencia Institucional. "Estaré presente siempre que venga el político de turno a llevarse las medallas"
Factores motivadores. "¿motivación? ¿para qué?"

Sé de buena tinta que la gran parte de los funcionarios curran de verdad, y lo que me preocupa no son los que ya están en el sistema sin pegar sello, si no la imagen que tienen muchos jóvenes de que irse de funcionario es el chollo, pero no por las buenas condiciones de trabajo o su interés, si no por que ya lo tienes todo hecho e incluso puedes aprovecharte de ello-forzando la situación-.

abril 06, 2008

Jornadas de testeo de software

El jueves estuve en el primer día de las jornadas sobre testeo de software JTS2008. La verdad que me han sorprendido la cantidad de conceptos que manejan en esta area, y que desconocía.
Hay varias cosas que tengo que analizar mejor. Me llama la atención que casi parece que son diferentes paralelos los procesos para la calidad mediante pruebas que la generada por los desarrolladores. Hablan de los testers por un lado, de sus pruebas, y no lo ligan demasiado a cómo eso afecta a los desarrolladores más que en que tienen que corregir los bugs que encuentran.
Y es curioso, por que yo tengo otro concepto más cíclico. Más que nada por que el concepto de fabricación con calidad, me resulta más atractivo que el de su control. Después de las pruebas, en algún momento se debería analizar lo que está pasando, para ver que se puede mejorar en el desarrollo que minimice en el siguiente ciclo de pruebas el número de errores.
Lo que sí coincido es que hace falta una persona (al menos) dedicada a diseñar/hacer pruebas de los sistemas en el equipo de un proyecto, y que no sea desarrollador.
¿Controlar la calidad, o fabricar con calidad? Yo que veo más cercano el equipo de desarrollo que el de testeo, me inclino a poner primero los medios en este primero para asegurar que hacemos software de calidad: lo que sea, pruebas unitarias, integraciones continuas, reuniones diarias, formación exhaustiva, mejores capturas de requerimientos, entregas iterativas,... y luego, pondría un equipo de test :)
Nos ha contado una persona de Google cómo tienen organizados los tests de sus apliciones: la palabra que más ha mencionado es "divertido". :) Curioso como cuenta que no tienen procesos establecidos, si no que cada uno es responsable de lo que hace y de cómo lo hace. Hay grupos de testeo en la empresa que apoyan a los creadores de productos, especializandose en las pruebas.

Anyway, bastante interesante la jornada, ya os daré más datos... o no,... :P os contaré más de la jornada del viernes, con más empresas contando sus experiencias. Idme contando, ¿teneis departamente de testeo de software?

marzo 11, 2008

Devolver el tiempo

Si hay una empresa que me guste ahora, esa es Atlassian. Buenos productos y una imagen envidiable en la red. Comparten sus ideas, y distribuyen sus productos con una licencia muy interesante para los usuarios.
Ahora acaban de publicar el "experimento" que van a realizar con sus ingenieros: "El 20% del tiempo". Y además van a blogear los resultados de sus experimentos, así que hay que seguir atentos. Este asunto trata de permitir dedicar a los desarrolladores el 20% de su tiempo en la dirección que elijan, de innovación, tecnologías o mejoras en los productos que soportan.
Me direis que esa es la famosa regla que Google aplica en su empresa, pero primero, tampoco dan tanta información, y segundo, tengo la impresión que es el 20% de 11 o 12 horas diarias de trabajo, no de una jornada normal. Atlassian reconoce que "copia" esa regla. :)
Dar esa confianza a los desarrolladores, puede significar sacar a flote grandes ideas que permanezcan escondidas tras la burocracia y las jerarquías. Supongo que se trata de recuperar, o no perder, la ventaja competitiva que tiene una "startup", a la vez que crecer de manera controlada.

A startup engineer must be all things - he (or she) is a full time software developer and a part-time product manager / customer support guru / internal systems maven.
As a company grows, an engineer spends more time doing the software development - but paradoxically he spends less time building the things he personally wants in the product.

Ahora le doy vueltas a cómo este tipo de resolución se puede aplicar a una empresa de servicios. Una empresa de servicios factura por horas, no hay un producto dónde se pueda producir un retorno de la inversión claro, ni donde centrar los esfuerzos personales-divergentes dedicados en ese 20% de tiempo. ¿Qué os parece? ¿cómo se podría trasladar este tipo de iniciativas a una empresa de servicios de software, que funciona por proyectos?

marzo 10, 2008

JIRA y CMMI

En nuestra empresa hemos implantando CMMI, acabamos de pasar un reluciente SCAMPI y pronto seremos nivel 2 oficialmente. Pero lo que ahora voy a hablar es del uso de JIRA como herramienta de gestión de proyectos. Quién conozca la herramienta y un poco de CMMI pensará que va ser un poco dificil conseguir que JIRA de soporte a algún tema de CMMI, si no que será más fácil usarla como herramienta PARA los desarrolladores, puesto que en realidad es una herramienta de "bugtracking".
Pero al final le hemos hecho algunos cambios, y JIRA nos va a dar soporte al EDT (Esquema de Descomposición de Tareas) para la fase de ejecución de proyectos. Cada incidencia creada en el sistema JIRA ahora podemos clasificarla en un tipo de Actividad (o Area de Conocimiento): Planificación, Desarrollo, Configuración, Sistemas, Implantación, etc,... Y con las versiones de JIRA podemos basarnos en desarrollo iterativo e incremental.
Esto nos da bastante flexibilidad tanto para desarrollar proyectos a precio cerrado, como para un día poder saltar a modelos más "ágiles" de desarrollo y comercialización.
Pero la gran mejora que podremos tener es obtener la verdadera visibilidad del desarrollo del proyecto, puesto que cada tarea puede ser reestimada en cualquier momento por cualquier persona implicada como responsable de sus tareas asignadas. Ahora tenemos que ir valorando la fecuencia de esas reestimaciones, la exactitud de las mismas dependiendo de la experiencia, y sobre todo, el impacto del cambio en la gente, que seguro será positivo.

marzo 05, 2008

Adopción ágil

Me envió Luis un enlace a una encuesta sobre la adopción de metodologías ágiles en las empresas.

Not aware 13% 26%
Not using 13% 16%
Investigating 14% 14%
Analysed and rejected 4% 3%
Pilot projects 8% 4%
Partial implementation (adoption of some agile practices) 17% 17%
Partial deployment (some projects are using this approach) 14% 12%
Deployed (all new projects are using this approach) 17% 8%

Según esta encuesta, obviamente han pasado dos años, el desconocimiento de las metodologías ágiles ha disminuido significativamente. Sin embargo de lo que no me fío, es de la fiabilidad de los ratios de adopción, parcial o completa, por que principalmente lo que decimos que es adopción de metodologías ágiles, no se trata más que de una aproximación a sus "buenas prácticas". Esta perfectamente explicado en este artículo de Version Cero: "Nosotros hacemos Scrum".
De todas maneras, si quereis más estadísticas:
Google Trends:
cmmi agile


Esta última comparo CMMI y ágiles, por que la semana pasada pase mi primer SCAMPI en una empresa, y ha hablare de ello en otro próximo post.

febrero 28, 2008

Los grandes programadores

Hace unos años me regalaron (a mi y a Virginia, fue un regalo compartido de un jefe) un libro que leí con mucho interés. Ahora el autor del regalo, escribe sobre él en esta entrada del CES Digital:
Los maestros programadores.

El hoy arquitecto jefe de software de Microsoft, Ray Ozzie, se explayaba así: “los proyectos complejos de programación dirigidos por directores que no son programadores están frecuentemente condenados al fracaso, porque ellos no comprenden los intricados entresijos de los componentes del proyecto, ni las personalidades de los trabajadores. Los directores de proyectos de software han de comprender a las personas que trabajan para ellos. Yo conozco lo mejor que puedo la situación familiar, el estilo de vida y los hábitos de trabajo de cada una de las personas que trabajan conmigo. Sé que no podemos trabajar jornadas de nueve a cinco y sacar el proyecto adelante. También sé que no puedo presionar a la gente para que trabaje 24 horas durante todo el proyecto. Pero sé que, cuando llega el punto decisivo, puedo contar con ellos para trabajar día y noche si es necesario. Ahora, también tengo que saber cuándo hay que aflojar”.

No voy a sacar el recurrente tema de si los jefes de proyecto deben tener un perfil técnico o basta con un perfil de gestión. Lo que me interesa destacar son dos puntos:
  • Hay que planificar los proyectos para que la gente los pueda hacer "de nueve a cinco", durante todo el proyecto. Ya vendrán problemas que no se te habían ocurrido. Seguro.
  • Al tomar la responsabilidad de dirigir proyectos me he dado cuenta que esto no es realmente la informática. Dejas de enfrentarte a problemas matemático-lógicos, para enfrentarte (otras veces, afortunadamente, para colaborar) con las personas.
Ahora tengo encima de la mesa este artículo sobre "A scalable concurrent malloc implementation for FreeBSD". Un artículo que desde luego no tiene nada que ver con la gestión de proyectos, ni siquiera con la programación que hago actualmente. Pero es interesante.
La informática intenta resolver problemas de la gente, mejorar sus procesos, automatizar trabajos,... etc... pero los problemas realmente interesantes para un informático-programador son los que la propia informática genera a bajo nivel. Esos que nos empeñamos en dejar cada vez más abajo y dejarselos a los frikis de las universidades, o de las grandes empresas.
Ahora que busco desesperadamente mi marca personal, he pensado muchas veces en que los problemas que más me gusta resolver son los que no resuelven problemas de personas, si no problemas de computación. Aunque ya no tengo la experiencia necesaria.
Me gusta ser responsable de proyecto, decidir estrategias, implantaciones, tácticas, técnicas... enseñar todo lo que sé al equipo, hacer que trabajemos todos coordinados... pero... me gusta programar.
Si no podeis conseguir leer el libro Programers at Work, al menos leete el artículo de C. Urtasun.

febrero 27, 2008

Scrum y XP desde las trincheras castellanas

No puedo dejar de recomendar y agradecer la traducción que se han trabajado en Proyectalis del magnífico libro publicado en InfoQ Scrum and XP from the Trenches. Ahora tenemos este libro en un primer borrador traducido a castellano en: Scrum y Xp desde las trincheras .
Si eres de los que le da pereza leer en inglés, ya no tienes excusa.

febrero 15, 2008

El producto es el equipo!

He empezado a leer "Software for your Head" siguiendo la recomendación de Mario, y la verdad es que promete. Lo recomendó comparándolo con "Peopleware", así que tiene el listón muy alto.
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:
Equipos = Software

Y buscan los patrones que hacen funcionar a un buen equipo para desarrollar software de calidad y en plazos. Ahora bien, la primera idea interesante es cuando sben de nivel en la jerarquía. Ahora que soy responsable de proyectos, o eso que llaman mando intermedio también, he seguido pensando que mi trabajo es desarrollar software. Con más responsabilidad, más radio de acción, etc... pero que básicamente me encargo de desarrollar software con un equipo de personas.
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.
Mi producto es el equipo
Y plantearte eso te hace cambiar bastante algunos conceptos. El primero y más obvio, ¿qué narices sé yo de fabricar buenos equipos? El segundo un poco , un poco desasosegante... si hasta ahora lo que me gustaba es producir software... ¿qué hago yo aquí? Aunque, ¿puedo producir equipos que produzcan software si yo no sabría hacerlo? Juraría que no, y por ahí también intuyo que va el libro cuando habla de que el equipo debe tener las características que le pedimos al software que fabrica: estabilidad, escalabilidad, que no tenga/cometa errores,...
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.

Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)

enero 22, 2008

La chispa de la vida

Hoy hemos acabado discutiendo si los proyectos de software son como los de construcción o los de hacer tortillas de patatas (sic).
La gestión "clásica" de los proyectos (tipo CMMI, con toda la literatura que eso implica) con todas las técnicas y procesos de gestión de requerimientos, gestion de riesgos, planificaciones,... pueden ser usadas para todos los proyectos que creamos las personas. Pero un nivel 5 de CMMI no implica un éxito garantizado de los proyectos de software.
Tampoco la gestión ágil de los proyectos (XP, o SCRUM,...), como contraposición al modelo anterior garantiza que el desarrollo del proyecto vaya a ser un éxito. Tiene otro enfoque, ni mejor ni peor, depende de la ocasión y el contexto.
Sin duda Juan Palacio lo presentaba acertadamente como la tesis y la antítesis, de la que saldrá una síntesis en gestión de proyectos. Pero ¿puede existir algo que haga exitosos todos los proyectos software? Quizás demasiado complejo para implementarlo, pero ¿podría existir? Unos pasos previos que nos pongan en alerta ante cualquier fallo de software ANTES de que ocurra.
Un arquitecto sabe si se le va a caer el edificio o el puente antes de construirlo, le basta con simularlo. Pero no podemos simular un software, su simulación real requeriría la construcción del propio programa, con lo cual no lo simulamos, si no que lo probamos.
Un cocinero sabe qué queda despues de mezclar los huevos con las patatas, pero un desarrollador no puede estar seguro como va a ser la integración de dos componentes interactuando juntos, si tendrán problemas de integración, hasta que no los prueba.
En definitiva, que sabemos que no existe la "bala de plata", y que esta no va a existir. Esto hace mucho más divertido e interesante nuestro trabajo, o ¿no nos reiríamos más si de vez en cuando se cayese un puente o la tortilla de patatas no cuajase por más que la cociesemos?

enero 16, 2008

Al final Oracle compra BEA, ¡y SUN mysql!

Pues al final la compró. Ahora solo hay que poner la cuenta atrás a ver cuando lo estropea :).
Y no sólo eso es interesante. SUN ha comprado mysql.
¿SUN puede hacer daño a Oracle con mysql en su mejor terreno, las bases de datos? Este movimiento me parece que puede tener mayor repercusión en el mercado que el de Oracle y BEA. Al final, Oracle volverá a cambiar de servidor de aplicaciones, lo que apostaría que echará a sus clientes más hartos, pero el mercado no cambiará demasiado.
Pero si SUN se plantea hacer frente a OracleDB con mysql, creo que estos se pueden poner algo nerviosos. ¿será casualidad que se comuniquen estas noticias el mismo día? SUN reforzará su mercado de software libre, e inyectará un buen capital para rematar algunos desarrollos que pueden hacer a mysql enfrentarse en grandes instalaciones a Oracle.

Me entero por Pensamientos.