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.