Mayo 20 2009

Charla: “Contratos ágiles: Vendiendo Scrum a tus clientes”

Categoría: EventosJuan @ 8:26 am

Otro evento relacionados con temas ágiles organizado por Autentia y con la colaboración de Agile Spain y Ángel Medinilla (Proyectalis).

La charla se dará el miércoles 3 de Junio a las 6:30 de la tarde en el Centro de Negocios Best Point. Av de Castilla 1, sala de reuniones. 28830 San Fernando de Henares (Madrid).

El evento es gratuito y la charla será impartida por Ángel quién es un gran orador donde los haya además de ser una de las personas que más sabe de estos temas en España. Podéis encontrar más información aquí.

¡No os la perdáis!

Etiquetas: ,


Mayo 18 2009

Reunión de Agile Spain en Madrid

Categoría: EventosJuan @ 1:50 pm

El próximo día 26 de mayo a las 6 de la tarde habrá que quedada organizada por Agile Spain en Madrid, exactamente en IPSA, C/ José Bardasano Baos, 9.

La idea es tener una reunión informal para compartir experiencias sobre el desarrollo de software ágil, conocer a la gente que está interesada en el tema en Madrid y alrededores, preparar futuras quedadas y temas a discutir y, por supuesto, tratar de potenciar esta manera de trabajar en España.

La agenda y mucha más información la podéis encontrar aquí. Podéis apuntaros en el foro de Agile Spain (mensaje “Agile Spain en Madrid”) .

Desde aquí y aunque no pueda asistir, mi agradecimiento a Agile Spain en general y Jose Manuel Beas en particular (le ha puesto muchísimas ganas al asunto) por organizar el evento y, por supuesto, y a los chicos de IPSA por poner las instalaciones.

Etiquetas:


Mayo 05 2009

¿Cómo debió ser el Desarrollo en Cascada?

Categoría: MetodologíasJuan @ 2:09 pm

Sí, lo admito, todo este tiempo y todavía no había leído el artículo al que se le da la autoría del llamado “desarrollo en cascada”. Hasta hace un par de días.

El artículo en cuestión se titula “Managing the Development of Large Software Systems” y su autor es el Dr. Winston W. Royce. Este artículo, como se ha dicho anteriormente, es el que se toma como el origen del desarrollo en cascada aunque este nombre no se menciona en el artículo y está citado más de 1200 según el Sr. Google.

Para mi asombro, el artículo es muy diferente de lo que esperaba porque en realidad NO propone el desarrollo en cascada (tal y como lo conocemos) como la panacea para el desarrollo del software sino que el autor lo presenta en la primera mitad del artículo como un acercamiento grandioso. Sin embargo, después, el autor trata de encontrar sus problemas y dar soluciones en la segunda mitad.

Waterfall model

-fuente: http://en.wikipedia.org/wiki/File:Waterfall_model.png-

Por ejemplo, el autor dice cosas como las que siguen sobre el típico desarrollo en cascada (ver imagen):

I believe in this concept, but the implementation described above is risky and invites failure.
[Creo en este concepto, pero la implementación descrita más arriba es arriesgada e invita al fallo.]

o esta otra

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required.
[El cambio requerido en el diseño es probablemente tan perjudicial que los requerimientos en los que se ha basado el diseño y los que proporcionan el fundamento de todo son violados. O los requerimientos deben ser modificados, o un cambio substancial en el diseño es requerido.]

… entre muchas otras.

Royce hace visible algunos de los problemas que tiene el desarrollo en cascada y da soluciones para mejorar el proceso en lo que queda de artículo (segunda mitad). Resumiendo y siendo muy breve, el autor da cinco pasos o mejoras para atajar los problemas. Éstas son:

  1. Incluir una etapa de diseño del programa entre las fases de requerimientos y análisis.
  2. Documentar mucho y bien.
  3. Hacerlo dos veces (iterar el proceso siendo la primera iteración una simulación)
  4. Planificar, controlar y monitorizar las pruebas. Es decir, poner énfasis en la calidad.
  5. Implicar al usuario. Royce, además, dice que la implicación debe ser formal, profunda y continua.

No sé qué os parece a vosotros pero el punto 3 y el 5 se han quedado por el camino (y en muchos casos el 4 que es lo primero que se recorta si se va ajustado de tiempo) y estos, precisamente, ¿no os recuerdan a algo? :-)

Recomiendo que leais el artículo original si podéis y tenéis tiempo. Realmente merece la pena.

Etiquetas:


Abr 27 2009

Tick the Code

Categoría: Desarrollo de softwareJuan @ 3:00 pm

Una de las prácticas más o menos comunes (por lo menos de las más conocidas) es la revisión de código en cualquiera de sus variantes (largas sesiones de revisión formal, revisión por pares, revisión con herramientas, etc) Dentro de esta categoría podemos añadir una nueva técnica de inspección de código llamada “Tick the Code“.

Esta técnica, resumiendo, se basa en revisar el código contra un conjunto pre-establecido (y siempre igual) de reglas. Por ejemplo, “no dividir por cero”, “todos los if deben tener else“, etc. El código se imprime y un revisor se aisla por un tiempo marcando (ticking) las violaciones de las reglas que está revisando (cada revisor se encarga de ciertas reglas, no de todas). Una vez finalizado el proceso, la revisión es entregada al desarrollador quien debe verificar si las violaciones son reales o “falsas alarmas”. Es decir, el desarrollador decide qué debe ser cambiado o arreglado y qué no.

Creo que esta técnica puede beneficiar muchísimo a los equipos para mejorar especialmente la calidad interna del código(mantenibilidad, entendibilidad, etc.) e incluso encontrar algunos defectos. Sin embargo, veo dos problemas en cómo se lleva a cabo esta técnica.

  1. Ciertas reglas son fácilmente automatizables por analizadores estáticos de código. No entiendo por qué estas reglas deber ser revisadas por una persona (que puede introducir errores, todos somos humanos) cuando pueden ser automatizadas muy fácilmente y sin errores. Claramente, creo que el valor que trae el revisar este tipo de reglas es menor que el gasto y esfuerzo requerido para hacerlo y, por tanto, creo que esto es contraproducente. Además, dentro de estas reglas hay algunas que generan más alarmas que errores con lo que el valor (del que hablábamos anteriormente) que obtenemos de la revisión es incluso menor.
  2. Las reglas que de verdad traen valor deberían ser tomadas como “guías de código” que todo el mundo debería seguir al escribir código. Por ese motivo, una revisión “normal” (en pareja o no) que también revisara si la “guía” se sigue eliminaría la necesidad de tener una sesión específica para “tick the code”. No estoy diciendo que se elimine, se podría tener sólo si es necesario y si no hay otra práctica de revisión de código que pueda contener también la revisión de estas reglas.

Sería interesante ver alguna métrica después de usar esta técnica como está descrita originalmente comparando el estado anterior y el posterior al uso de la técnica. Y lo mismo, usando una modificación de la misma.

Etiquetas: ,


Abr 06 2009

Charla: Introducción a Scrum

Categoría: EventosJuan @ 6:00 pm

Los chicos de Agile Spain en colaboración con Autentia han organizado una charla gratuita de introducción a Scrum para el próximo jueves 7 de Mayo a las 18:30 en el Centro de Negocios Best Point, Avda. de Castilla 1 (sala de reuniones) en Torrejón de Ardoz.

¡Espero que nos veamos allí!

Etiquetas: ,


Mar 23 2009

Artículos sobre TDD

Categoría: Test UnitariosJuan @ 2:30 am

Una de las preguntas (o mejor decir peticiónes) que normalmente me hacen cuando doy una presentación o seminario sobre TDD es si hay (y si los puedo mandar) estudios sobre cómo TDD mejora la calidad del software y el rendimiento de los equipos o los programadores.

No hay muchos artículos todavía si lo comparamos con otros métodos o técnicas, eso es cierto, pero sí que hay algunos. Además, cada vez hay más interés por TDD y por tanto más investigadores están trabajando en ello con lo que pronto, esperemos, habrá más estudios disponibles.

Esta es la lista de artículos (en inglés) que doy como referencia:

  1. Test-Driven Development as a Defect-Reduction Practice“, Williams L. et al.
  2. Test-Driven Development: Concepts, Taxonomy, and Future Direction“, Jansen, D. and Saiedian, H.
  3. An Initial Investigation of Test Driven Development in Industry“, George, B. and Williams L.
  4. A Longitudinal Study of the Use of a Test-Driven Development Practice in Industry“, Sánchez, J.C. et al.
  5. On the Effectiveness of Test-first Approach to Programming“, Erdogmos, H.
  6. Realizing Quality Improvement through Test Driven Development: Results and Experiences of Four Industrial Teams“, Nagappan, N. et al.
  7. Software Architecture Improvement through Test Driven Development“, Jansen, D.
  8. Test Driven Development: Empirical Body of Evidence“, Siniaalto, M.

Si conocéis más, por favor, mandadme el enlace o el artículo en sí. Os lo agradecería mucho.

Etiquetas:


Feb 18 2009

¡Practica!

Categoría: Libros, Otros, Test UnitariosJuan @ 10:45 am

Hoy me ha venido a la mente una frase de Lasse Koskela por dos razones:

  1. Los chicos de Agile Spain mencionaban en un hilo del foro del libro de Koskela (”Test Driven -Practical TDD and Acceptance TDD for Java Developers“) en el cual me escribió como dedicatoria la frase a la que me refiero.
  2. Estoy preparando un curso de TDD para mis compañeros en Malasia y en una de las pocas transparancias que hay en el curso (es un curso muy práctico) quiero plasmar la misma idea con otras palabras.

La frase (traducida del inglés) es la siguiente:

Recuerda que el aprendizaje viene con la acción.
Aprender sólo con la lectura es un oxímoron.

Diría que lo mismo se aplica a muchas otras cosas donde, si bien dominar la teoría es muy importante, el no practicar equivale más o menos a perder el tiempo.

Hablando de TDD en particular. No hay cursos, entrenadores o libros que valgan si no se practica. Y eso sólo lo puede hacer uno mismo con esfuerzo y paciencia. Está claro que todo lo anterior ayuda, y mucho, pero al final la responsabilidad de hacerlo y aprenderlo recae en uno mismo y en el esfuerzo que se ponga en ello.

Quizá sea una reflexión obvia, pero me apetecia escribirlo.

Etiquetas: , ,


Feb 05 2009

Integración Contínua con Hudson, Ant, Svn y NetBeans

Categoría: Integración ContinuaJuan @ 7:59 pm

El post que siempre he querido escribir sobre integración contínua y Hudson y nunca he tenido tiempo lo ha escrito excelentemente Iván en su blog Bits y Bytes.

La entrada explica como montar un entorno de integración contínua desde cero usando Hudson, Ant, SVN y NetBeans. Para ser exactos yo lo quería haber escrito usando algo en C++ o Python pero para el caso es “casi lo mismo”. Como artículo introductorio me parece excelente y las sutilizas de C++ o Python ya las intentaré escribir poco a poco.

Enhorabuena, Iván, por tu gran anotación. ¡Gracias!

Etiquetas: , , ,


Ene 26 2009

Hudson (en Windows y como servicio) y CVS

Categoría: Integración ContinuaJuan @ 12:51 pm

Cómo es el sistema, lo primero: un Windows con CVSNT para acceder al repositorio y Hudson en Tomcat configurado como un servicio.

El problema viene cuando Hudson intenta acceder al repositorio por primera vez y la huella del repositorio no está en la caché. Como Hudson lo ejecuta no interactivamente no podemos escribir “yes” y darle al intro al ver el siguiente mensaje:

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is. The server's key fingerprint is:
ssh-dss 1024 4f:8...
If you trust this host, hit Yes to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, hit No.
If you do not trust this host, hit Cancel to abandon the
connection.SCM check out aborted

Bueno, no hay problema, podemos hacerlo desde la consola y añadir la huella a la cache manualmente… Pues no, ahora el problema es que Hudson es un servicio y ejecuta bajo la cuanta de usuario Local Service Account y yo, personalmente, no sé como puedo entrar al sistema con ese usuario (lo siento, no tengo tanta experiencia con Windows) Supongo (quizá erróneamente) que esta cuenta no se puede usar para entrar al sistema ya que es una cuenta especial y hacerlo con otro usuario no arreglaría nada ya que la caché es dependiente del usuario.

El siguiente paso es añadir la huella manualmente a la caché (un fichero) ya que sé que se puede hacer en Linux. Mal otra vez, Windows no tiene esta caché como un fichero sino que utiliza el registro. Buscando en el registro encontré una entrada para mi usuario (ya que previamente había accedido al repositorio y añadido la huella a la caché) donde estaba la huella guardada y la copié a HKEY_USERS para que cualquier usuario pueda acceder a ella. La entrada es algo así:

Key Name: HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys
Class Name: NO CLASS
Last Write Time: 23.01.2009 - 18:35
Value 0
Name: dss@22:bla_bla.com
Type: REG_SZ
Data: 0xb477b...

Desde la línea de comandos, se puede añadir la huella fácilmente como sigue:

reg add HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys /v dss@22:bla_bla.com /d 0xb477b...

Ahora Hudson, ejecutado como un servicio, accede felizmente y sin problemas al repositorio donde está el código.

Etiquetas: , ,


Ene 16 2009

Niveles de decisión

Categoría: Equipos, GestiónJuan @ 9:20 am

Cuando hablamos de organizaciones ágiles, métodos, etc., siempre suele haber distintos temas que aparecen regularmente en la conversación: integración continua, TDD, automatización, test unitarios… Sin embargo, cuando alguna metodología ágil es introducida en una organización normalmente hay confusión sobre que debería ser obligatorio y qué debería ser recomendado y quién debería promocionar o incluso exigir las nuevas prácticas o ideas. ¿Deberían ser la compañía per sé, los equipos, los gerentes (jefes de proyecto, dueños de producto…), etc.?

En mi opinión nada es blanco o negro y siempre hay muchos niveles de grises en el medio:

  1. Hay ciertas prácticas obligatorias que deberían ser decididas a nivel de compañía por alguien con suficiente poder de decisión al hablar de este nivel. Estas prácticas deberían ser seguidas por todo el mundo y los equipos o los individuos no deberían discutir sobre ellas. Por ejemplo, el uso de una herramienta de control de código (SVN, CVS, GIT, etc.) para cualquier proyecto de desarrollo de software. No creo que nadie esté en desacuerdo con la obligatoriedad de esta herramienta al desarrollar software. En mi opinión, lo mismo debería pasar con la integración continua, los test automáticos y un sistema de control de errores.
  2. Otras prácticas deberías ser decididas por el gerente de un producto aunque la idea pueda venir de abajo a arriba. En esta categoría, la decisión es tomada por el gerente ya que su decisión afecta a todo el producto (y no sólo un equipo si hay varios equipos trabajando para el producto) Esta persona debe decidir basándose en el esfuerzo que supondrá para los equipos, tiempo, coste, calidad, etc. En esta categoría se encontraría, por ejemplo, el configurar los equipos por componentes o por funcionalidades, la definición de aceptación, etc.
  3. Muchas otras son decididas por el equipo y no deberían ser impuestas por los gerentes o la empresa. Los gerentes puede pedir objetivos a más alto nivel (tener algo listo para producción al final de una iteración, ningún error abierto entre iteraciones, etc.) El equipo decide sus propias prácticas en base a estos requerimientos a lo que considera importante a la hora de producir software. El equipo decide la definición de hecho para sus tareas, si deben usar o no TDD. Si deben hacer UT para todo el código o sólo para las partes más importantes, trabajar por pares o no o cuando hacerlo, hacer revisiones de código sistemáticas, por relevancia o no hacerlas… El equipo debe darse cuenta por si mismo como llegar a ser (reflexionando sobre sus propios errores) un equipo excelente sin ser dirigido o impuesto en “como hacerlo” por el gerente.

Etiquetas: ,


« Página anteriorPágina siguiente »