Mi charla en Madrid.rb sobre Refactoring

El pasado jueves hice mi primera charla en Madrid.rb. El tema que traté fue la refactorización de código, punto importante si queremos que nuestras aplicaciones se mantengan sanas y fuertes con el paso del tiempo y las nuevas funcionalidades. Está basada en el libro de Martin Fowler titulado Refactoring: Improving the Design of Existing Code y además de una introducción y unas pequeñas conclusiones, hay un ejemplo de refactorización que puede servir a aquellos que se inician en el tema para comprender la mecánica que se sigue durante el proceso de refactorización.

Para el que pueda interesarle dejo aquí las transparencias que hice:



Y el vídeo de la charla grabado por Madrid.rb:

Making code tastier through refactoring from Madrid.rb on Vimeo.


Algunos libros que se pueden consultar sobre el tema son:

Y algunas herramientas interesantes:

Si estuviste allí por favor puntúa esta charla:

blog
Comments

Primera edición de Spain.js

La primera edición de la Conferencia Internacional de JavaScript, Spain.js, tendrá lugar los días 5, 6 y 7 de Julio en Madrid.

En ella podremos disfrutar de desarrolladores tan destacados como Jeremy Ashkenas (creador de CoffeeScript y Backbone.js), Alex MacCaw (creador de Spine.js), Vicent Martí (Github) y Karolina Szczur (Nodejistsu) entre otros muchos.

El objetivo del evento es dar un empuje a un lenguaje que siempre ha tenido una consideración menor para los programadores, pero que cada vez está más presente en nuestro día a día.

¡Espero veros allí!

blog
Comments

Conferencia Rails 2011

I'm Attending Conferencia Rails 2011

Otro año más se vuelve a celebrar en Madrid la Conferencia Rails, encuentro anual de desarrolladores y empresas alrededor de Ruby on Rails, y este año vuelve más internacional que nunca con speakers tan destacados como Sven Fuchs, Paolo Perrota, Simon Tokumine, Nicolás Sanguinetti,.. y viejos conocidos como Javier Ramírez o Sergio Gil.

Si estás interesados en temas como la programación web, la integración continua, programación para dispositivos móviles, Node.js, Backbone.js, CoffeeScript... Te esperamos del 13 al 15 de Julio en el Retiro.

blog
Comments

Build Less

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

  • Less features
  • Less options/preferences
  • Less people and corporate structure
  • Less meetings and abstractions
  • Less promises

37 Signals - Getting Real: Build Less

blog
Comments

Siendo más productivo con Scrum

Scrum es una metodología de desarrollo de software enmarcada dentro de las metodologías ágiles y que propone un ciclo iterativo e incremental. Pero, ¿Qué son las metodologías de desarrollo ágiles?

Las metodologías ágiles se basan en 4 principios fundamentales recogidos en el manifiesto ágil.

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Scrum toma esos principios y propone los siguiente:

  • Divide las tareas en pequeños incrementos con una planificación mínima.
  • Estos incrementos son llamados Sprints y suelen durar entre 2 semanas y 1 mes.
  • Pone énfasis en la comunicación cara a cara.
  • Los equipos son multidisciplinares y auto-organizados de entre 5 y 9 personas.
  • El software funcional es la primera medida de progreso.
  • Se realizan periódicamente entregas del producto, lo que permite:
    • Evaluar el trabajo realizado.
    • Advertir sobre problemas que se detecten.
    • Sugerir mejoras.

Existen 2 tipos de roles: cerdos y gallinas.

Los cerdos son aquellos roles que están comprometidos directamente en el desarrollo del producto:

  1. Product Manager: Representa a la voz de cliente. Escribe y prioriza las historias de usuario.
  2. Scrum Master: Su trabajo es eliminar los problemas que impiden que el equipo alcance el objetivo del Sprint.
  3. Scrum Team: Responsables de la entrega del producto. El equipo debe reunir todas las habilidades necesarias para el éxito del proyecto.

Las gallinas son todos aquellos que aunque están involucrados en el desarrollo del proyecto, no está comprometidos, es decir, no forman parte directa del scrum. Este grupo está formado por usuarios, clientes y managers.

Por otro lado, scrum propone una serie de artefactos que nos permiten gestionar las tareas y tener más control sobre lo que está pasando en cada momento del Sprint.

Product Backlog Es una lista de requisitos priorizados, con estimaciones que son recogidos por el Product Manager en colaboración con el cliente. Normalmente estos requisitos son escritos en forma de historias de usuarios y deben ser lo más detalladas posibles para ayudar en la medida de lo posible ha realizar las estimaciones. Esta lista debe ser revisada con frecuencia con objeto de ajustar prioridades, estimaciones y re-priorizar las historias de usuarios.

Sprint Backlog El Sprint Backlog agrupa las tareas que se han seleccionado al inicio de la iteración del Product Backlog para ser desarrolladas durante la siguiente iteración. Las tareas deben ser más detalladas y las estimaciones más aproximadas. Ninguna tarea debe durar más de dos jornadas de trabajo, en ese caso debe dividirse en varias tareas más concretas.

Burn Down Es una gráfica que muestra el avance del equipo en el desarrollo de la iteración. En el eje Y se encuentras los puntos de historia a realizar durante la iteración, y el eje X los días disponibles. Cada día se va trazando una línea desde arriba a la izquierda hasta abajo a la derecha donde se podrá ver el trabajo restante. Un ejemplo de burn down lo podemos ver en la wikipedia.

Tablón de Scrum Es un poster, normalmente dividido en 3 o 4 columnas que nos permite de un simple vistazo saber en qué estado se encuentra la iteración. En la primera columna (ToDo) se agrupan las tareas que quedan por hacer, En la segunda las que se están desarrollando en ese momento (WIP: Work In Progress) y en la tercera las tareas terminadas (Done). En la cuarta podemos poner nuestro Burn down y las tareas imprevistas o impedimentos.

Finalmente, para reforzar la comunicación cara a cara del equipo, scrum propone 4 tipos de reuniones o ceremonias.

Planificación de Scrum Esta reunión se realiza al comienzo de una iteración y en ella el equipo debe seleccionar del Product Backlog las tareas que se realizaran en el siguiente Sprint y añadirlas al Sprint Backlog. Las tareas deben seleccionarse en función de su prioridad y el valor que aporten al negocio y posteriomente estimarlas para intentar predecir cuanto trabajo será posible sacar adelante en la siguiente iteración.

Daily Scrum Se realiza todos los días a la misma hora en el mismo lugar y todos los miembros del equipo deben permanecer de pie durante el tiempo que dure la reunión que no debe sobre pasar los 15 min. Pueden asistir todas las personas involucradas pero sólo pueden hablar los cerdos. Durante la reunión el Scrum Master pregunta a cada miembro del equipo qué hizo durante el día anterior, qué va a hacer ese día y si ha tenido algún impedimento para alcanzar su objetivo.

Revisión de Sprint En las reuniones de revisión de Sprint se revisa el trabajo planificado y se presenta a los interesados en forma de demo.

Retrospectiva Al final de cada iteración el equipo de trabajo se reúnen para discutir sus impresiones sobre el Sprint anterior y para proponer mejoras que puedan aumentar el rendimiento del equipo.

Además de todo lo anterior existen otra serie de herramientas que un equipo de desarrollo ágil pueden incorporar para mejorar su productividad. Las habituales suelen ser:

  • Test Driven Development.
  • Test de aceptación.
  • Integración Continua.
  • Refactoring.
  • Pair Programming.

Al final lo más importante es encontrar la metodología con la que el equipo se encuentre más cómodo y que les permita ser más productivos, realizar el máximo número de tareas posible y ser capaces de corregir errores e incorporar cambios durante el desarrollo del producto, para que finalmente el cliente obtenga el producto que mejor se ajuste a sus necesidades.

blog
Comments