Páginas

31 ago. 2012

Publicar código fuente en Blogger

Tengo pensado escribir unos cuantos artículos que requerirán copiar código fuente, cosas en Java y xml para Android, y cosas en C# sobre TDD, tests unitarios, patrones de diseño, principios SOLID y GRASP sobre las que ya tengo ejemplos prácticos pero lo primero que necesito es una forma "bonita" de publicar código en cada artículo. 

Éste medio día en muy poco tiempo me he encontrado con SyntaxHighlighter, que es el plugin que recomiendan todos los bloggers desarrolladores o diseñadores gráficos para colgar código en su web. Éste sencillísimo tutorial de tan sólo dos pasos vale tanto para Blogger como para cualquier web o editor de contenido.

1.- Introducir el siguiente código encima del cierre de </head>, en blogger  vamos a Plantilla --> Editar HTML, aceptamos y buscamos </head>:



















2.- Una vez has guardado eso en la plantilla de tu página web tan sólo tienes que incluir tu código dentro de una etiqueta <pre> con el siguiente formato:
HTML:
Tu código HTML iría aquí
CSS:
Tu código css iría aquí
C#:
// Aquí tu código en C#
public class PosteandoConClase()
{
}

Añadiré un detalle, para ocultar los números de línea habría que añadir en class "gutter: false" y para mostrar los controles "showControls:true", el comienzo de la etiqueta que envuelve al código quedaría, para HTML, así:

Y nada más de momento, sólo decir que hay muchas maneras de personalizar como se muestra el código pero eso, por ahora, es lo de menos.

Un saludo.

30 ago. 2012

Gredos Virtual 3D 1.2

He seguido "jugando" con los mapas buscando optimizar al máximo y mejorar la usabilidad de las aplicaciones Android de las que hablaba en anteriores entradas. 

Como decía, Gredos Virtual 3D es un mapa en tres dimensiones muy detallado de 10 kilometros cuadrados en el que estan representados los alrededores del Circo de Gredos, Ávila, España. En éste mapa te puedes mover tan solo haciendo clic en la pantalla y deslizando el dedo por ella. No se me ha ocurrido una forma mejor de hacerlo y es la siguiente:
  • Cada clic es un movimiento en la dirección en la que estás mirando.
  • Una vez hecho clic, manteniendo la presión en la pantalla, puedes deslizar el dedo con lo que el ángulo de visión del mapa cambia.
Es muy simple aunque los usuarios las primeras veces que lo prueban no llegan a entenderlo del todo y les cuesta un rato cogerle el truco por lo que estoy abierto a cualquier sugerencia.

Por lo demás, en ésta versión de Gredos Virtual 3D, se ha mejorado la calidad de la textura del mapa, la cual ahora incluye:
  • Tonalidades verdes, curvas de nivel y sombras que le dan al conjunto la sensación de mapa en 3D.
  • Las 5 lagunas, coloreadas en azul.
  • El parking de la plataforma y la carretera a Navarredonda, en gris.
  • El Refugio Elola ( http://www.refugioelola.com/ ), junto a la Laguna Grande de Gredos, en rojo.
  • El Refugio Reguero Llano (http://www.reguerollano.com/), también en rojo.
De nuevo quiero dejar aquí alguna captura de pantalla. 


Las dos primeras imágenes muestran las lagunas pequeñas y en las dos siguientes vemos la laguna grande desde dos puntos de vista diferentes. Para los amantes de ésta zona del Sistema Central dejo el mapa que he utilizado como textura para la aplicación y les invito a marcar en dicho mapa las distintas rutas y las fuentes.


28 ago. 2012

Parque Nacional de Ordesa y Monte Perdido en 3D

A lo largo de la tarde y siguiendo las directrices de la anterior entrada de éste blog he publicado dos aplicaciones en el Market, en Google Play.

La primera de ellas es de la que trataba la anterior entrada, la he llamado Ordesa Virtual 3D.

(Actualizado el 29/08/2012)
Esta mañana siguiendo algunos consejos he oscurecido las imágenes y he añadido curvas de nivel a éste mapa, mientras lo hacía he probado algo con el heightmap y he conseguido una compresión mucho mejor del bpm con lo que la calidad y el realismo del 3D se ha incrementado muchísimo a la vez que disminuía el peso del heightmap.

Os dejo algunas capturas del resultado de hoy:


¿No ha quedado genial? 


(Actualizado el 29/08/2012)
A partir de esa, con el mismo heightmap y la misma estructura interna he creado otra aplicación en 3D cuyo realismo me ha sorprendido muchísimo. Para lograr una textura lo mas cercana a la realidad posible he utilizado el Sistema de Información Geográfica de Parcelas Agrícolas (SIGPAC) y el editor GIMP. Me ha costado alrededor de un dos horas conseguir entrelazar las imágenes necesarias y girarlas un poco, 3 grados en el sentido de las agujas del reloj para ser más exactos, para que encajaran a la perfección con el heightmap que tenía de la versión anterior. Insisto en que me ha asombrado lo realista que ha quedado ésta versión en 3D del valle de Ordesa. La app para andriod se llama Ordesa 3D y auqnue ya la he subido al market aún no está disponible paara su descarga, tardará entre dos y tres horas.


Voy a dejar aquí un par de capturas de pantalla que acabo de hacer ahora mismo:


 

Espero que os guste éste trabajo, por supuesto la aplicación es gratuita y espero que os sea útil tanto para entreteneros como para planificar vuestras próximas excursiones. 

Un saludo.

Juan García Carmona

Mi primera aplicación Android: Gredos 3D

Gredos 3D es mi primera app para Android. Tenía ganas de meterme de lleno en el mundillo de la programación de aplicaciones móviles y sin habérmelo propuesto he aprendido mucho sobre mapas, cartografía y modelos digitales del terreno así como de OpenGL y la programación 3D.

En un primer momento la intención de la investigación inicial era aportar valor añadido a una app desarrollada por mi amigo Ricardo Vallés, Cimas de España,  pero después de varios estudios y análisis de requisitos vi que "el peso" de la información necesaria para crear un mapa de alturas o heightmap lo suficientemente detallado era tremendamente alto. No tomé nota de los pesos exactos pero estoy trabajando justo ahora mismo en otra representación 3D de otra zona montañosa y para que os hagáis una idea de los pesos os puedo decir que una imagen bastante detallada que cubre una zona de 10 kilómetros cuadrados, con una resolución de 2070 x 2071 píxeles pesa exactamente 12.564KB. Ésta imagen la he generado a partir de un modelo digital del terreno, que he descargado ésta vez del Instituto Geográfico Nacional, utilizando el programa MicroDEM. Del Modelo Digital del Terreno Original (MDT) he recortado justo el área con la que quiero trabajar, éstos 10 kilómetros cuadrados, y he exportado la imagen en formato BMP de la que hablaba hace un momento. Esa imagen la retocaré porque gracias al software que estoy utilizando puedo añadirle curvas de nivel y modificar la escala de colores que utiliza para representar la altura. Guardaré cada cambio pero siempre trabajando  sobre el mismo área. 

Al final lo único necesario para generar un mapa en tres dimensiones es una textura para el suelo y los datos de altura de cada punto del terreno. A éstos datos se los conoce como heightmaps o mapas de altura y la mejor y mas intuitiva forma de representarlos, y la más eficiente en cuanto a almacenamiento físico, es utilizando una imagen en escala de grises donde el negro sea la altura base y el blanco puro sea el punto más alto de toda la proyección en 3D. 

Al final trabajando con el programa MicroDEM sobre el mismo área acabo generando unas cuantas texturas sobre las que si quiero luego puedo jugar con el GIMP para superponerles ortofotos y genero también un heightmap.

El heightmap en el programa se utiliza para generar una malla de planos, que, en resumidas cuentas, es una matriz que contiene un plano, es decir, tres puntos, por cada punto con la altura en escala de grises del heightmap. Ésta malla es la que representa los triángulos que, unidos unos con otros, forman la representación del terreno. Posteriormente sobre esa malla se proyecta la imagen de la textura utilizando OpenGL y se crea así el mundo virtual.

Hoy estoy trabajando para generar una representación en 3D del valle de Ordesa y creo que puede ser interesante ir documentando aquí los pasos que he seguido. El código de la aplicación ya lo tengo y vale para cualquier terreno, tan sólo tengo que generar un nuevo proyecto, generar el heightmap y las texturas que va a utilizar y ajustar unas cuantos parámetros para crear una nueva aplicación 3D con la zona que quiera. 

Aquí podéis ver la primera imagen con la que estoy trabajando:


Así quedaría en escala de grises:


Ambas imágenes las he reducido y tienen mucho menos detalle que las que yo voy a utilizar para no ralentizar la entrada y por si alguien se las quiere descargar. Las originales pesan 12 y 3 MB respectivamente y éstas de aquí 794 y  187 KB. En la siguiente imagen se ve cómo he añadido a la textura las curvas de nivel.


Ahora voy a recortar las imágenes para que tengan un tamaño manejable, 1024 x 1024 el heightmap y 2048 x 2048 la textura. Bueno, antes de eso voy a generar las curvas de nivel incluyendo un la leyenda de la altura de cada línea. El proceso de renderizado de ésta imagen lleva muchísimo tiempo pero de ésta imagen si que os voy a dejar la original porque es un mapa muy detallado del valle de Ordesa al que seguro que más de uno puede sacar provecho si va a dar un buen paseo por allí... 

Bueno, ha tardado algo más de media hora en generarse y creo que las fuentes son demasiado pequeñas pero aquí os dejo la imagen original. Mientras se sube al blog voy a ir recortándola y voy a generar la primera versión de Ordesa 3D con ésta textura.


Os dejo unas capturas de pantalla de lo que he conseguido... Voy a seguir trabajando en ésto y cuando acabe lo subiré al Market y publicaré otra entrada en el blog.



Me gusta mucho, voy a oscurecer un poco el terreno porque creo que brilla demasiado y voy a subir ésta aplicación, la llamaré Ordesa Virtual 3D. Ésta tarde si tengo tiempo seguiré "jugando" un poco y, en vez de utilizar éste terreno, voy a construir una ortofoto a partir de las imágenes de Sigpac y creo que va a quedar espectacular. 

(Actualizado el 29/08/2012)

El resultado de mi trabajo aquella tarde es Ordesa 3D. Está bastante bien pero deja de ser útil como mapa y es más una especie de juego o aplicación vistosa de entretenimiento.

La aplicación ha evolucionado mucho en tan solo dos días. Primero publiqué Gredos 3D, que para mí no debeja de ser un experimento y una prueba de concepto, y después de optimizar la calidad, tanto de la resolución y la optimización del peso de la aplicación como de la calidad visual, he decidido crear otra aplicación muy similar a la primera pero en la que el mundo virtual tiene 10km cuadrados y la textura es en blanco y negro con sombras autogeneradas y con curvas de nivel. Ésta aplicación la he llamado Gredos Virtual 3D y es el mapa en tres dimensiones definitivo del circo de Gredos y sus alrededores. Dejo unas capturas de pantalla de Gredos Virtual 3D:


Aquí tenéis los enlaces a las cuatro aplicaciones 3D que llevo hechas hasta el momento:


Y desde aquí podéis acceder a todas mis aplicaciones en el Google Play.



24 ago. 2012

SCRUM: Planificación de un Sprint

El objetivo de un Sprint es entregar cierta cantidad de producto con cierta calidad y en cierto intervalo de tiempo. Si hablamos de software estamos hablando de funcionalidades, si por ejemplo hablamos de ventas o de marketing podríamos hablar de alcanzar ciertos objetivos o comenzar ciertas campañas. En el fondo el Sprint busca convertir pequeños objetivos en grandes logros.

Pero volvamos al Desarrollo de software. Un Sprint debe comenzar con un Sprint Planning, una reunión entre el jefe de producto y el grupo de trabajo, incluido el Scrum Master. El objetivo de ésta reunión no es otro que determinar las funcionalidades en las que se va a trabajar durante éste Sprint. El jefe de producto presenta un listado de funcionalidades deseadas y es el equipo quien, de acuerdo a sus experiencia y sus conocimientos sobre el estado actual del desarrollo, elige las funcionalidades que cree que puede desarrollar completamente dentro de dicho Sprint.

En ésta reunión suele haber dos partes. En la primera parte el equipo selecciona del Product Backlog las historias de usuario que irán al Sprint Backlog. Una vez seleccionadas el jefe de producto puede abandonar la reunión si lo desea. En la segunda parte el equipo cuantifica las historias, primero analiza la arquitectura y los requisitos necesarios para desarrollar cada historia y divide la historia en distintas tareas de acuerdo a dicha arquitectura, a los requisitos, a su experiencia con historias pasadas y a su metodología interna de trabajo. Esta parte suele ser muy particular en cada grupo de trabajo y es lo que hace que cada historia sea distinta. Por ejemplo, el grupo de trabajo podría decidir dividir una historia en las siguientes tares: modificar el modelo lógico, aplicar dicha modificación a la actual base de datos, definir las pruebas de aceptación, generar las vistas necesarias para la historia, generar los view-models necesarios para la historia, crear cierto servicio o adaptar un controlador anterior al nuevo modelo.

Una vez que las historias del Sprint han sido divididas en tareas lo que se hace siempre es cuantificarlas, quiero decir, medirlas o "pesarlas". Me quedo con el término "pesar" porque es el que mas he usado durante el día a día. Pero: ¿cómo se pesa una tarea? 

Las tareas se pesan en puntos (a veces también se pesan en tallas de camisetas) y el proceso de pesado de cada tarea se realiza en una especie de partida de poker. La relación entre puntos y horas de trabajo no es ideal, hay que tener en cuenta varios factores a la hora de asignar puntos a las tareas. El primer factor, lógicamente, es el tiempo estimado, claro, pero también hay que tener en cuenta la dificultad de la tarea en cuestión, una tarea difícil puede suponer un desgaste de quien esté con ella y eso supondrá un incremento de las horas, es decir, de los puntos que pesa. Otro factor es la duda, si se duda entonces en la dificultad o la cantidad de horas que llevará hay que tenerlo también en cuenta, generalmente al alza. Otro factor es el riesgo, si la tarea supone un alto riesgo en la planificación global también habría que estimar al alza. Generalmente se pesan las tareas utilizando 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 y 100 puntos. Habrá quien ponga más puntos, habrá quien los quite. Yo soy de los que quito. Siempre suponiendo que la tarea la realice una sola persona la relación entre puntos y tiempo sería la siguiente:


0 puntos: como mucho una hora en realizarlo.
1/2 punto: no debería suponer más de medio día ideal, es decir, 4 horas.
1 punto: alrededor de un día de trabajo, unas 8 horas.
2 puntos: entre 1 y 2 días.
3 puntos: entre 2 y 4 días.
5 puntos: entre 3 y 5 días de trabajo.
8 puntos: algo más de una semana, entre 5 y 8 días de trabajo.
13 puntos: alrededor de 2 semanas.
20 puntos: entre 2 y 3 semanas.
40 puntos: alrededor de un mes.
100 puntos: demasiado grande.
? puntos: no tengo ni idea de lo que implica esta tarea.

Como se ve, cuantos más puntos pese una tarea más incertidumbre hay sobre el tiempo que llevará realizarla. Antes he dicho que soy de los que quita cartas y es exactamente por éste motivo. He trabajado con Sprints de dos y Sprints de 3 semanas de duración y en ambos me han sobrado las cartas de 20 y de 40 puntos. Una tarea de 100 significa que esa tarea está mal planteada, seguro que se puede dividir en subtareas y planificarlas y pesarlas por separado. Además de éstas cartas muchas barajas de Scrum Poker incluyen una taza de café cuyo significado es evidente: estoy cansado y necesito un descanso, os invito a un café.

Entonces, ¿cómo se hace ésto del Scrum Poker? Bien, hemos dividido, de acuerdo con nuestra manera de trabajar en grupo, con la arquitectura, con los requisitos, etcétera, cada historia en tareas. Cogemos una tarea, hablamos un poco sobre ella y procedemos a "pesarla". Para ello, cada miembro del equipo coge la carta que cree que representa lo que pesa esa tarea en puntos, teniendo en cuenta lo que ya he mencionado, el tiempo estimado, la dificultad y el riesgo o las dudas. Una vez que todos los miembros del grupo han seleccionado su carta se procede a enseñar las cartas todos a la vez

Con las cartas sobre la mesa lo suyo es que se llegue a un consenso, generalmente la diferencia entre la carta mas alta y la mas baja suele ser poca y hay que preguntarle a quien ha mostrado la carta mas baja y al que ha mostrado la carta más alta por qué piensan así. Si no se llega a un consenso se somete de nuevo a votación. Ésto propicia un intercambio constructivo y detallado de opiniones y saca a relucir aspectos sobre el desarrollo de cada tarea que quizá no todos los miembros del equipo tuvieron en cuenta y reduce el impacto negativo que suelen tener en las planificaciones los optimismos y los catastrofismos desmesurados.

El Scrum Poker es una buena práctica en la planificación por todo lo mencionado antes pero ojo, siempre hay alguien que enseña sus cartas demasiado pronto:


Una vez acabado el Scrum Poker con cada tarea del Sprint Backlog no hay que dar por finalizada la reunión. Si el Scrum Master ha hecho bien su trabajo habrá ido tomando nota de todo lo que se ha hablado y de los pesos de cada tarea. Antes de terminar hay que ver si, de acuerdo a medidas anteriores, el grupo de trabajo es capaz de enfrentarse a la cantidad de puntos que han salido en total. Si resulta que el total de puntos de las tareas está por encima de los puntos que se estima que el grupo puede realizar con éxito entonces hay que llamar de nuevo al jefe de producto para pedirle que nos ayude a descartar alguna historia de usuario pero si la suma de puntos está por debajo deberemos pedirle que nos dé más historias de usuario para alcanzar el límite de puntos que sabemos que podemos realizar como grupo. 

Se han escrito artículos muy extensos e incluso libros sobre la planificación de Scrum pero en mi opinión no hay mucho más que decir, tan sólo añadir algo que ya he dicho y es que las metodologías están a nuestro servicio y no al revés.

Para acabar el artículo de hoy os dejo un par de juegos de cartas de Scrum Poker, juegos de cartas hay muchos, aquí os dejo tan solo un par de muestras que he encontrado por Internet:
También existen muchas aplicaciones de escritorio y apps Android, quizá hasta haya demasiadas.

Juan García Carmona

23 ago. 2012

SCRUM BOARDS

Al anterior artículo, "Mi resumen de SCRUM", le ha faltado, y ha sido a propósito, una parte muy importante: la Scrum Board. 

La Scrum Board o pizarra Scrum es uno de los elementos mas importantes en SCRUM ya que sirve como punto de unión entre todos los integrantes del grupo de trabajo y el Product Owner y es donde el Scrum Master va representando diariamente el estado del flujo de trabajo del Sprint en curso. Las reuniones diarias deberían hacerse frente a la Scrum Board y, si es posible, el resto de reuniones también. 

En su modelo mas básico la Scrum Board constaría de dos columnas, a la izquierda una columna "To Do" con cosas que hay que hacer y a la derecha una columna "Done" con las cosas que se han hecho. 

La evolución lógica es añadir una columna intermedia "In progress" donde se irían colocando las cosas en curso.

Si nos ponemos meticulosos, o como dicen algunos, talibanes del Scrum, la columna "To Do" ha de llamarse "Sprint Backlog" y a la izquierda de ésta columna ha de haber otra columna con el "Product Backlog", columna en la que el Product Owner iría desarrollando sus ideas, casos de uso y demás. 

Yo, además, añadiría, y de hecho ya lo he hecho en dos proyectos Scrum en los que he trabajado, una columna entre "In-Progress" y Done. Esta columna estaría reservada para el proceso de testing, es decir, para las pruebas de aceptación. Además de ésta columna, a la derecha y para rizar el rizo en la calidad del producto y, buscando la satisfacción del product owner, podemos poner otra columna reservada para que el product owner verifique las cosas que los miembros del grupo de trabajo dan por acabadas y listas para pasar a "Done". 

Resumiendo, y de izquierda a derecha, las columnas de mi pizarra ideal serían: Product Backlog, Sprint Backlog, In-Progress, In-Testing, Product Owner Verification y Done!

Pero las pizarras de Scrum o Scrum Boards no se componen solo de columnas, hasta ahora he hablado de "cosas" cuando debería haber hablado de Historias de Usuario o Casos de Uso, Tareas, características técnicas, Errores, Bugs y problemas o bloqueos.

En la primera columna, el Product Backlog, debería haber tan solo historias y junto a cada historia las tareas en las que se subdivide. Una historia, junto con sus tareas, pasará al Sprint Backlog al comienzo de un Sprint y los miembros del equipo irán acometiendo las distintas tareas de la historia pasándolas de la columna de Sprint Backlog a la columna "In-Progress". Si las tareas son testeables, es decir, pueden pasar algún tipo de prueba de aceptación, pasarán, una vez completadas, a la columna de Testing y de ahí a la de Product Owner Verification para ser verificadas por el jefe de producto. Si pasan ambas verificaciones entonces pasarán a Done. Por lo general ésto no es del todo posible, mi experiencia me dice que las tareas supuestamente acabadas pasan a la columna de testing pero no son testadas hasta que no se han completado todas las tareas de dicha historia ya que van encaminadas a la consecución de una historia de usuario que es la que de por sí define las pruebas de aceptación que utilizarían los testers y a posteriori el jefe de producto para testar y verificar dicha historia antes de pasarla a Done. ¿Suena a jeroglífico?

Volvamos al principio de éste artículo:

1º.- Dos columnas: "To Do" y "Done":



2º.- Tres columnas: "To Do", "In-Progress", "Done":


3º.- Cinco columnas: "Product Backlog" "Sprint Backlog", "In-Progress", "Verification", "Done":
(La imagen no es exáctamente lo que digo pero te puedes hacer una idea de a lo que me refiero)
4º.- Seis columnas:  "Product Backlog" "Sprint Backlog", "In-Progress", "Testing", "Verification", "Done":
(podría ser parecida a ésta)
5º.- La pizarra completa: "Product Backlog", "Sprint Backlog", "In-Progress", "Testing", "Product Owner Verification", "Done" mas una zona para bugs y errores y otra para bloqueos y características técnicas:

Os dejo una imagen de una propia que acabo de hacer con la herramienta de dibujo de Google Docs, es un documento público para el que encontraréis un enlace dentro de un rato para que la adaptéis a vuestra situación si os resulta interesante o útil, además tengo que explicar de donde me ha surgido la idea de ésta Scrum Board:


Ésta Scrum Board es una evolución de ésta de aquí. Gracias a ese tutorial os podéis crear la vuestra personalizada, yo lo he que hecho ha sido añadir las columnas que me han hecho falta (la de testing) y dos apartados bajo las columnas de los backlogs para ubicar ahí bugs, errores, características técnicas y bloqueos. Abrid en una ventana nueva Mi Scrum Board Virtual y os la explico encantado.

Hay un código de colores:

Rojo: Bug
Naranja: Error
Amarillo: Tarea
Verde: Historia de Usuario
Morado: Bloqueo
Azul: Característica Técnica

Con esa pizarra delante os puedo contar de un simple vistazo que hay una tarea pendiente en el Product Backlog, ésa la cogeríamos el próximo Sprint junto con alguna más que probablemente esté preparando el jefe de producto. Ahora mismo, durante éste Sprint se está trabajando en una historia de usuario de tamaño XL (ya trataré en otro artículo cómo se "pesan" las tareas e historias) compuesta de tres tareas, una sin empezar, una In-Progress que la está haciendo Juan y otra en Testing. Además hay una historia de usuario pendiente de verificación del jefe de producto, es decir, ya ha pasado las pruebas de aceptación.

Vemos, además, que en la columna del Produc Backlog, abajo, de izquierda a derecha y de arriba abajo, tenemos un bug, en rojo, un error, en naranja, una característica técnica, en azul y un bloqueo en morado. Están ahí a modo de ejemplo pero gracias a las columnas, a conocer el código de colores y a la experiencia podría deciros prácticamente lo mismo mirando la pizarra desde unos cuantos metros de distancia y sólo tendría que acercarme a ella si quisiera ver detalles más específicos.

Algo que se suele utilizar en las Scrum Boards son avatares, es decir, pequeñas representaciones de cada miembro del equipo que se ponen encima de la tarea que esta realizando cada uno en cada momento. En éste ejemplo en cada tarjeta, al final, pone: "Asignado a: ALGUIEN", pues eso sería sustituido por un avatar imantado, por ejemplo, o un post-it con formas (yo he sido durante un año una flecha de color verde).

Bueno, creo que por hoy ya he dicho bastante sobre Scrum, me apunto en mi backlog personal algunas cosas sobre las que aún no he hablado como son la cuantificación de historias y tareas mediante el Scrum Poker en el Sprint Planning (si, hay una reunión en la que la gente juega al poker, es cierto) o la gestión de errores, bugs o marcha atrás de historias o tareas por no pasar las pruebas de aceptación o la verificación del jefe de Producto.

Juan García Carmona

Mi resumen de SCRUM

Para empezar éste artículo tengo que decir que no soy SCRUM Master ni tengo ninguna certificación en SCRUM. Creo más en las capacidades reales de la gente que en sus certificaciones. No quiero hacer comparaciones porque las comparaciones son odiosas pero he tenido compañeros, físicos  de carrera, que ejercían increíblemente bien de arquitectos de software y de desarrolladores sin tener ninguna certificación en la materia. Aunque no soy un experto en SCRUM ni estoy certificado como tal mis conocimientos sobre la materia me los dan la experiencia y la práctica en dos implementaciones de SCRUM distintas en dos equipos de desarrollo distintos. 
Mi resumen de SCRUM

SCRUM es una metodología ágil basada en la filosofía LEAN que, originariamente, estuvo enfocada a la gestión de proyectos de desarrollo de software pero que actualmente está siendo aplicada a otros ámbitos donde la aplicación de metodologías ágiles se han visto necesarias para la mejora de la eficiencia y la calidad.

SCRUM busca la optimización de la eficacia en la producción de cualquier grupo de trabajo, es decir, mejorar la eficiencia, sin detrimento de la calidad del producto final añadiendo para ello ciertos elementos que en anteriores modelos de gestión no existían como son las reuniones diarias, las retrospectivas, el método científico para la gestión de cambios propio de Kanban o la representación visual del flujo de trabajo y las tareas pendientes y en ejecución (muy parecido al tablero Kanban) que ayudan a informar y a involucrar a todos los integrantes del grupo de trabajo en el control, la gestión y la mejora de todo el proceso productivo.

El funcionamiento a grandes rasgos es el siguiente: 
  • Somos un grupo de trabajo y tenemos un producto que hay que ir entregando poco a poco, de forma regular e incremental
  • Éste producto lo podemos dividir en tareas y tendremos una lista de tareas de forma que uno o varios miembros del grupo podamos acometer una tarea. Éstas tareas tienen una estimación del esfuerzo en puntos que representan una suma consensuada entre el esfuerzo en tiempo y la complejidad que supone. 
  • El grupo como tal tiene una estimación de la cantidad de puntos que es capaz de realizar cada cierto intervalo de tiempo de entre dos y cuatro semanas. 
  • Cada día, a primera hora, se hace una reunión lo más breve posible en la que cada miembro del grupo nos cuenta que hizo el día anterior, lo que piensa hacer hoy y si tienen algún tipo de problema, bloqueo o queja. 
  • A la finalización de cada intervalo de tiempo se hace una reunión retrospectiva donde se evalúa que se ha hecho bien y que se ha hecho mal durante ese intervalo y se llega a conclusiones para el siguiente intervalo sobre cosas que hay que empezar a hacer o hay dejar de hacer y se planifican acciones concretas con el objetivo de evolucionar como grupo para ganar en eficiencia y calidad
  • Para terminar se prepara el siguiente intervalo de tiempo, para lo que se seleccionan nuevas tareas de entre la lista de tareas a realizar, las más prioritarias y, entre todos los integrantes del grupo, se estiman, en puntos, hasta alcanzar la cantidad de puntos que el grupo es capaz de acometer.

No he querido entrar en muchos detalles ni en nombres de los elementos intervinientes en SCRUM para no saturar al lector pues mi objetivo hasta aquí era mostrar que SCRUM es un método de trabajo ágil, evolutivo y autogestionado por un grupo de trabajo en constante evolución profesional en el que toman especial protagonismo la comunicación, el consenso y la autocrítica y cuyo principal objetivo es la entrega constante de valor al cliente.

Elementos de SCRUM

En SCRUM se distinguen claramente tres categorías de elementos: peridos de tiempo,  artefactos y roles.

Periodos de tiempo

Todo en SCRUM esta dividido en periodos de tiempo, esto nos ayuda a mantener el rumbo del proyecto y a entregar en las fechas previstas ya que cada reunión tiene unas pautas y unos límites de tiempo preestablecidos. Están prohibidas esas reuniones interminables, improductivas y tremendamente costosas.

Sprint es el período en el que estamos trabajando. Se establece una duración fija de entre de 2 y 4 semanas al principio del proyecto que se debe mantener para posibilitar la gestión del cambio evolutiva.

Hay 5 tipos de reuniones dentro de un Sprint. 

  • Sprint Planning: al comienzo del Sprint tenemos la reunión de planificación  que no debería durar más de una jornada de trabajo. En esta reunión se estiman en puntos suficientes tareas como para que el equipo alcance, al menos, su límite de trabajo.
    (8 horas máximo)
  • Sprint Commitment Meeting: es una reunión de compromiso. En ésta reunión, con la estimación ya hecha, se llega a un compromiso entre el equipo y el Jefe de producto sobre las tareas que se realizarán durante el Sprint.
    (4 horas máximo
  • Sprint Review: al final del Sprint se realiza una revisión de lo que se ha hecho durante el Sprint. Se evalua lo que se ha hecho y cómo se ha hecho y de ésta reunión podrían salir nuevas tareas o requisitos para el siguiente Sprint.
    (4 horas máximo)
  • Sprint Retrospective: una vez hecha la revisión se realiza ésta reunión de retrospectiva en la que se busca la autocrítica, individual y colectiva, enfocada a la mejora de la eficiencia y la calidad.
    (3 horas máximo)
  • Daily Meeting: todos los días tenemos el Daily Meeting, una reunión en el que cada miembro del equipo nos cuenta que hizo la jornada anterior, lo que piensa hacer en ésta y nos expone sus bloqueos si los tiene.
    (15 minutos máximo)


Artefactos

Existen tres artefactos, el Product Backlog, el Sprint Backlog y el Burndown Chart.

Product Backlog: es una "caja" con todos los requisitos del producto. éstos requisitos pueden ir cambiando y ésta "caja" se puede implementar de muchas formas, dependerá del tipo de proyecto, producto o servicio que se quiera entregar. El responsable de la gestión de ésta "caja" es el jefe de producto, es quien modificará requisitos o los priorizará cuando crea necesario y quien "encolará" requisitos para la creación en cada Sprint del Sprint Backlog.

Sprint Backlog: es un subconjunto del Product Backlog con los requisitos más prioritarios. Durante la reunión de planificación, el Sprint Planning, el grupo de trabajo subdivide éstos requisitos en tareas que se estiman en puntos. Una vez comenzado el Sprint el Sprint Backlog no cambia. Es el grupo de trabajo, acorde a sus posibilidades, quien a lo largo del Sprint van pasando dichas tareas desde un estado "pendiente", es decir, están en el backlog, a un estado "Done!", es decir, finalizadas.


Burndown Chart: es un gráfico que indica la cantidad de trabajo que queda en el Sprint. En el eje Y tenemos la cantidad de trabajo pendiente y en el eje X los días que quedan para la finalización del Sprint de tal forma que el gráfico siempre es un polígono o una curva descendente que ha de tender a cero, de ahí el nombre. Éste gráfico es actualizado a diario por el ScrumMaster después del Daily Meeting tras haber escuchado a todos los integrantes del grupo decir qué consiguieron acabar durante la jornada anterior.



Roles

Existen tres roles en SCRUM, el Product Owner o jefe de producto, el Scrum Master y el Scrum Team o equipo Scrum.

Product Owner: es el experto en la materia, el jefe del producto, quien se supone que sabe lo que quiere y cómo lo quiere y quien prioriza los requisitos  en las reuniones de planificación y quien aceptará si las tareas están hechas o no una vez que los miembros del equipo las dejan listas para verificación. 

Scrum Master: es un entrenador y un filtro. Como entrenador debe garantizar el cumplimiento de las funciones de cada miembro del equipo, adiestrar y educar a los miembros que lo necesiten en lo que necesiten en cada momento y garantizar la consecución de los objetivos. Como filtro debe eliminar los obstáculos y los llamados residuos de Kanban y proteger al equipo ante cualquier distracción externa. Es deseable que sea un trabajador altamente cualificado con dotes de liderazgo además de ser responsable, organizado y consecuente. Es importante que el Scrum Master forme parte del grupo de trabajo para que esté totalmente involucrado en el trabajo diario y las sensaciones generales del equipo.

Scrum Team: es el equipo o grupo de trabajo. Se recomienda que sea de entre 2 y 7 personas y debería estar compuesto por ingenieros, arquitectos, diseñadores y testers si el SCRUM es aplicado al desarrollo de software.

Para terminar mi resumen de lo que es SCRUM sólo quiero repetir una frase que más de una vez me dijo un compañero en uno de los equipos de SCRUM y es:
"No estamos al servicio de las metodologías sino al revés, las metodologías están a nuestro servicio."

Con ésto quiero decir que no debemos ser esclavos "de lo que dice el libro" sino que hemos de ir adaptándolo a nuestras necesidades en cada momento y si, por ejemplo, una reunión retrospectiva tiene que alargarse más de la cuenta porque ese sprint ha sido peculiar por algún  motivo, si va a ser beneficioso que se alarga entonces adelante. Si, en detrimento de la cantidad de trabajo que va a ser capaz de entregar el equipo durante éste Sprint existe la posibilidad de formar al equipo en cierta nueva tecnología que mejorará la eficiencia en próximos Sprints entonces formemos al equipo... Y se podrían dar muchos ejemplos al respecto.

Quisiera que éste resumen de SCRUM sirviera de base a distintos departamentos y organizaciones para aplicarlo como metodología en su flujo de trabajo diario.  Hay mucho más que decir sobre SCRUM, por ejemplo, no he mencionado la SCRUM Board, cosa que haré en un futuro pues he visto muchas. Además, en un próximo artículo tengo intención de mostrar algunos ejemplos que ya tengo recopilados sobre la aplicación de SCRUM en muy distintos ámbitos, todos ellos bastante lejanos al desarrollo de Software. Espero que os haya sido útil mi resumen. 

Juan García Camona

20 ago. 2012

Principios SOLID

Los principios SOLID son cinco principios enunciados por Robert C. Martin alrededor del año 2000 enfocados a la elaboración de software de calidad. Estos cinco principios hay que tenerlos siempre presentes si queremos desarrollar un software legible, entendible y fácilmente testeable. Se ha escrito mucho al respecto y ésta pequeña tabla quiere ser mi aportación sobre los principios SOLID:

InicialAcrónimoDetalles
SSRP
Principio de Única Responsabilidad

"There should never be more than one reason for a class to change." — Robert Martin

Traducción literal: "No debería haber nunca más de una razón para cambiar una clase."

Mi traducción: Una clase debería concentrarse sólo en hacer una cosa. Ésto no significa que sólo tenga un métido sino que todos los métodos, públicos o privados, deberían estar enfocados a un solo propósito.



OOCP
Principio abierto/cerrado

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." — Robert Martin parafraseando a Bertrand Meyer

Traducción literal: "Las entidades de software (clases, módulos, funciones, etcétera) deberían estar abiertas a la extensión pero cerradas a la modificación."

Mi traducción: Cambia el comportamiento de una clase mediante herencia y composición.



LLSP
Principio de sustitución de Liskov

"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it." — Robert Martin

Traducción literal: "Las funciones que utilicen punteros o referencias a clases base deben ser capaces de usar objetos de clases derivadas de éstas sin saberlo."

Mi traducción: Las subclasses deben comportarse adecuadamente cuando sean usadas en lugar de sus clases base.


IISP
Principio de Segregación de Interfaces

"Clients should not be forced to depend upon interfaces that they do not use." — Robert Martin

Traducción literal: "Los clientes no deberían ser forzados a depender de interfaces que no utilizan."

Mi traducción: Utiliza muchas interfaces de manera que éstas sean pequeñas y cohesivas, que puedan coexistir unas con otras.


DDIP
Principio de Inversión de Dependencias

"A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions." — Robert Martin

Traducción literal: "A. Módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.
B. Las abstracciones no deberían depender de los detalles. Los detalles deberían depender de las abstracciones."

Mi traducción: para conseguir robustez y flexibilidad y para posibilitar la reutilización haz que tu código dependa de abstracciones y no de concreciones, esto es, utiliza muchas interfaces y muchas clases abstractas y, sobretodo, expón, por constructor o por parámetros, las dependencias que una clase pueda tener.


Actualmente estoy trabajando en una serie de clases .NET enfocadas a sentar las bases de los principios SOLID desde un punto de vista TDD (Test Driven Development o Desarrollo Guiado por Pruebas) y la relación de éstos principios con los patrones de diseño. El curso se compone de cuatro "temas":


1.- "UML de batalla"

3.- TDD práctico, metodología AAA y nomenclaturas útiles para documentar

4.- Patrones de Diseño y TDD

Si os interesa éste curso, tanto particulares como empresas, no dudéis en poneros en contacto conmigo. 

Un saludo.

Juan García Carmona

14 ago. 2012

El tablero Kanban


Como ya he dicho, un enfoque Kanban, en términos de gestión, es un ejercicio constante de adecuar la oferta a la demanda para entregar un producto o servicio de calidad en el momento adecuado. Uno de los principios básicos de Kanban es hacerlo visible. Hasta ahora hemos hablado de pizarra pero cambiemos el término a tablero, del inglés Kanban Board. El tablero será un control visual y éste podrá ser físico o virtual. 

El sistema Kanban es una implementación de un sistema de extracción limitado o que limita el WIP. En software se utiliza un kanban virtual ya que no hay, en realidad, tarjetas de señal. Las tarjetas o pegatinas con insturcciones de trabajo (historias, tareas, características deseadas, etcétera) en la típica pizarra Agile no son tarjetas de señal. La señal se genera cuando existe una diferencia entre el límite WIP establecido y el número de tarjetas en cualquier sección dada del tablero.

¿Qué hay que hacer para diseñar un buen tablero Kanban? Karl Scottland lo describé de ésta forma (traducción del inglés):

¿Qué aspecto tiene un sistema de Kanban aplicado al desarrollo de software? 
Muy simple, hay una cola de trabajo, que pasa a través de una serie de etapas de desarrollo hasta que se termina.  Cuando el trabajo se acaba en cada etapa, entra en una "cola vertical" para la siguiente etapa. Cuando alguien necesita más trabajo que hacer lo extrae de su correspondiente cola de trabajos.


Esto se parece mucho a una Task Board (pizarra de tareas) ágil típica, con, tal vez, unos cuantos pasos más y aunque podría ser la pizarra de cualquier departamento de desarrollo sin embargo, hay un elemento más importante que realmente define un sistema Kanban, los límites. Hay dos límites básicos, límites de la cola de trabajo y límites de WIP.


Los límites de la cola cola de trabajo están diseñados para evitar el trabajo prematuro, antes de tiempo, de ésta forma se logra el tan deseado "Just-In-Time" o JIT.  El límite debe ser lo suficientemente grande como para mantener al equipo ocupado todo el tiempo, es decir, siempre habrá algo que hacer y en lo que comenzar a trabajar, pero lo suficientemente pequeño como para evitar una priorización y planificación prematura, es decir, evitar tener tareas pendientes en la cola de trabajo durante demasiado tiempo antes de empezar a trabajar en ellas. 
Lo ideal es que la cola de trabajo sea exactamente una estructura cola, es decir, FIFO, aunque esto es una pauta y no una regla. A veces hay componentes del equipo más hábiles en algunos campos o hay disponibles otros recursos y por eso no siempre se tiene porque aplicar FIFO.

Los límites de WIP están diseñados para reducir la multitarea, maximizar el rendimiento y mejorar el trabajo en equipo.

Se ve con la experiencia que mediante el uso de este enfoque organizativo es muy fácil saber a simple vista el estado en que se encuentra cada tarea, donde surgen cuellos de botella y qué fallos o vicios están apareciendo. 
Además, si se utiliza un código de colores, ésto permite a todo el equipo ver qué tipo de trabajo hay en curso, si son nuevos desarrollos, refactorizaciones, si hay bloqueos, si se están resolviendo bugs, etcétera.

En cuanto al trabajo urgente, James Shore lo aborda muy bien de esta manera:

Si hay una emergencia, esto es, una solicitud de soporte, un cambio o alguna necesidad urgente, hay un espacio vacío en una de las secciones del tablero marcada "urgente". El equipo se puede poner manos a la obra en esa cola de trabajo en cualquier momento sin tener que pasar por el cauce regular. El equipo ha de esforzarse en terminar los temas urgentes con rapidez y tratar de tener , y tratar de mantener la sección "urgente" vacía en todo momento.

Si la sección "urgente", por lo que sea, está llena porque se ha llegado al límite WIP y aparece otro elemento urgente, éste tiene que ser añadido a la cola principal. Si un error debe ser corregido de inmediato, el equipo utilizará la sección "urgente" y ésta podría llenarse durante una revisión de fallos, lo cuál sería un elemento a analizar.

Como ya he dicho, hay que revisar el flujo de trabajo en las retrospectivas para ver cómo eliminar residuos para mejorar el rendimiento, máxima Lean que también se aplica en Kanban.

13 ago. 2012

El corazón del método Kanban


Un poco de historia:

"Kanban" proviene del japonés, y se traduce como "cartel", "letroro" o "pizarra".  Kanban se remonta a los comienzos del sistema de producción de Toyota, ya hablamos de ellos en la entrada sobre Lean y metodologías ágiles. Taiichi Onho desarrolló kanban entre 1940 y 1950 para controlar la producción entre procesos y poder aplicar la máxima "Just In Time" (JIT) en las plantas de fabricación de Toyota en Japón. 

El método Kanban, tal como fue formulado por David J. Anderson, es una aproximación al proceso gradual y evolutivo de gestión de cambios a nivel empresarial. Se utiliza un sistema de WIP (Work-In-Progress) limitado como mecanismo básico para exponer problemas en el funcionamiento del sistema (o proceso) y estimular la colaboración para mejorarlo continuamente. Éste sistema se denominó sistema kanban y es por ésto que el método kanban lleva éste nombre.

Principios Básicos

1º.- Comience con lo que hace ahora

El método Kanban no describe un conjunto específico de métodos o etapas del proceso, no existe un proceso kanban de desarrollo de software ni un método de gestión de proyectos Kanban. El método Kanban se inicia con las funciones y los procesos que se tienen y se estimulan los cambios continuos, incrementales y evolutivos del sistema sobre el que se aplica el método.

2º.- Llegue a un acuerdo global en busca de un cambio incremental y evolutivo

El equipo o la organización debe estar de acuerdo en todo esto del cambio continuo, gradual y evolutivo, es la única manera de hacer mejoras en un sistema preestablecido y hacer que se prospere. Los cambios radicales pueden parecer más eficaces pero a menudo fallan debido a la oposición y el miedo en la organización. El método Kanban fomenta continuos cambios pequeños, incrementales y evolutivos sobre el sistema actual.

3º Respete los actuales cargos, sus actuales funciones y sus responsabilidades

Es probable que la organización cuente ya con unos elementos organizativos que funcionan aceptablemente y que vale la pena conservar.

También hay que evitar que cunda el pánico en la organización ante la implantación de un nuevo método de producción pues en general la gente tiene miedo a los cambios. Al aceptar y respetar las actuales funciones, responsabilidades y cargos se eliminan todos esos miedos iniciales y ésto nos debería permitir obtener un mayor apoyo en nuestra iniciativa de aplicar el método Kanban. Tal vez la presentación de Kanban en contraposición a un enfoque alternativo más radical que daría lugar a cambios en los cargos, funciones, responsabilidades y quizá la eliminación masiva de ciertas puestos de dudoso beneficio a nivel global ayudan a los componentes de la organización o del equipo a darse cuenta de los beneficios de un sistema gradual y evolutivo.

4º.- Busque liderazgo en todos los niveles

Se deben promover cargos de responsabilidad y liderazgo en todos los niveles de la organización, desde los puestos más bajos o menos valorados hasta en la cúpula directiva.


Seis prácticas básicas

En su libro, Kanban - Successful Evolutionary Change for your Technology Business, David Anderson identificó cinco prácticas fundamentales que se habían estado presentes en cada aplicación exitosa del método Kanban a las cuales se les añadió una sexta:

1º.- Visualice el flujo de trabajo

El flujo del conocimiento en el trabajo es inherentemente invisible. Visualizar el flujo del trabajo y hacerlo visible es fundamental para la comprensión de cómo avanza el trabajo. Sin entender el flujo de trabajo, hacer los cambios adecuados es siempre más difícil.

Una forma típica de visualizar el flujo de trabajo es utilizar una pizarra o un mural con tarjetas y columnas. Las columnas de la pizarra representan los distintos estados o pasos en el flujo de trabajo.

2º Limite el trabajo en curso (Work-In-Progress o WIP)

Limitar el trabajo en curso o WIP implica implementar un sistema de extracción de tareas en la totalidad o parte del flujo de trabajo. El sistema de extracción de tareas será a la larga uno de los principales estímulos para los cambios, incrementales y evolutivos en el sistema.

El sistema de extracción puede ser implementado como un sistema Kanban, un sistema CONWIP, un sistema DBR, o alguna otra variante. Lo fundamental es que el trabajo en curso en cada estado del flujo de trabajo esté limitado y que cada nueva tarea sea puesta en una "bolsa" de nuevas tareas, de tal forma que no se empiecen nuevas tareas hasta que el equipo no sepa, de acuerdo a su límite, es es capaz de acometer dicha tarea.

3º Maneje el flujo de trabajo

El flujo de trabajo en cada estado y respecto al conjunto debe ser controlado, medido y reportado. Gestionando activamente cambios continuos, incrementales y evolutivos se puede evaluar si dichos cambios han tenido efectos positivos o negativos en el sistema en su conjunto

4º Haga explícitos sus mecanismos

Hasta que el mecanismo de un proceso no se hace explícito, es decir, se pone por escrito, es difícil o imposible mantener una discusión sobre cómo mejorarlo. Sin una comprensión de cómo funcionan las cosas y cómo se hace el trabajo en la realidad cualquier discusión sobre cualquier problema en el problemas tiende a ser emocional, anecdótica y subjetiva. Con una comprensión explícita se puede pasar a una discusión más racional, empírica y objetiva de los problemas que puedan surgir. Esto está enfocado a facilitar el consenso en torno a sugerencias de mejora.

5º Implemente ciclos de retroalimentación

Para realmente conseguir un cambio evolutivo se debe colaborar en la revisión del flujo de trabajo y analizar las diferencias que haya podido haber entre la demanda, las distintas métricas e indicadores y la cantidad de trabajo que se ha conseguido acabar con éxito, Ésto, junto con una narración anecdótica de hechos notables acaecidos durante el ciclo que se está evaluando. Las organizaciones que no han puesto en marcha el segundo nivel de información - la revisión de las operaciones - en general no han visto mejoras en los procesos más allá de cada nivel de equipo y como resultado no han aprovechado los beneficios que el método Kanban ha dado en otras organizaciones.

6º Mejore colaborando, evolucione experimentando (usando modelos y el método científico)

El método Kanban anima a los pequeños cambios continuos, incrementales y evolutivos que se perduran. Cuando los equipos tienen una comprensión común de las teorías sobre el trabajo, el flujo de trabajo, los proceso y el riesgo, son más propensos a comprender de la misma forma un problema y a proponer acciones concretas y consensuadas de mejora que puedan.

El método Kanban sugiere que se utilice un enfoque científico al implementar los cambios, no especifica cuál y existen diversas posibilidades, algunos métodos usados son la teoría de las limitaciones, el Sistema Demin de conocimiento profundo y Lean IT.

En próximas entradas hablaré sobre la organización de las pizarras kanban y sobre algunas herramientas que existen actualmente en el mercado que facilitan la visualización del proceso.

Juan García Carmona



El método Kanban (Introducción)

¿Qué es Kanban?

Si se menciona el término Kanban en un contexto empresarial la gente dirá que se tratá de una pizarra o un mural que ayuda y facilita procesos del tipo Just-In-Time o JIT de todo tipo. También dirán que una tarjeta kanban es un símbolo que se utiliza en dichas pizarras para representar y ordenar una "tarea" de cualquier tipo ubicada dentro de uno de los procesos.  

Cuando Kanban se utiliza en el campo de la ingeniería del software se utiliza en un sentido mucho más amplio. Kanban, más que un proceso, es un método para desarrollar productos de software que hace énfasis en la entrega justo a tiempo (JIT) buscando sobretodo no sobrecargar a los desarrolladores que hace hincapié en que los desarrolladores vayan cogiendo el trabajo de una cola o lista de tareas. El proceso, desde la definición de una tarea hasta la entrega de todo o parte del producto al cliente, se muestra a los todos los participantes de una forma visual concisa y representativa de la situación en su conjunto en cada momento y para ello qué mejor que una pizarra. Alternativamente a la pizarra Kanban existen aplicaciones pero me centraré en ésta parte del método en otra entrada de éste mismo blog.

Podemos entender Kanban de dos maneras:

Kanban como proceso de gestión visual que nos indica qué, cuándo y cuánto producir, es decir, la pizarra de la que ya alguna vez nos han hablado y que quizá hayamos visto en algún departamento de desarrollo.

Kanban como método o un enfoque orientado a la gestión gradual del cambio, esto es, al proceso evolutivo de las organizaciones y empresas con afán de mejora constante.

El método Kanban es una aproximación tremendamente válida para cambiar un proceso de extremo a extremo de forma fiable en el que tiene especial importancia la calidad del producto y los plazos de entrega. Un conjunto limitado de reglas y principios ayudan a los distintos miembros de un equipo a centrarse en el valor del producto y por tanto en la satisfacción del cliente, lo cuál, es común tanto para la industria del software como para cualquier organización que ofrezca productos o servcios.

Una buena descripción del método Kanban podría ser la siguiente:

1º Comience con lo que hace ahora
2º Llegue a un acuerdo global en busca de un cambio incremental y evolutivo
3º Respete los actuales cargos, sus actuales funciones y sus responsabilidades y a continuación, adopte las prácticas básicas:

  1. Visualice el flujo de trabajo
  2. Limite el Work In Progress (trabajo en marcha, en adelante WIP)
  3. Maneje flujo de trabajo
  4. Aplique políticas explícitas en cada proceso
  5. Mejore la colaboración mediante el uso de modelos y aplicando el método científico

Estos pocos principios resultan ser una base muy potente para una organización que quiere mejorar drásticamente su flujo de trabajo para ganar con ello productividad sin perder eficiencia ni calidad.

Kanban hemos de entenderlo como un método orientativo ya que no describe cómo ha de aplicarse éste proceso y ha de ser adaptado a cada organización
lo único que hace el método kanban es cambiar las reglas a fín de ayudar a los equipos a centrarse más en la eficiencia y la calidad de extremo a extremo, y, al final, lo único que define el éxito a nivel organizativo es la cartera de clientes y a éstos no les preocupan tanto los títulos y cualificaciones de los empleados como obtener a tiempo un producto de calidad entregado

Debido a que Kanban no es un proceso sino un método evolutivo las personas, los empleados que acaban de descubrir el método Kanban, pueden percibir el cambio de una forma amistosa y sin temor. En la práctica, la forma de trabajar no va a cambiar mucho al principio, se sentirán, en el día a día, los principios que emplea éste sistema de gestión de un WIP limitado.  Esto poco a poco dará lugar a una evolución paulatina en el comportamiento que conllevará una mejora continua, tanto individua como colectiva, que repercutirá tanto en la eficiencia como en la calidad y mejorará por tanto la productividad a nivel global en la organización.

Así que piense en Kanban como algo más que una pizarra con tarjetas de colores y limitar el WIP. El método kanban busca facilitar el cambio organizacional con el objetivo de satisfacer mejor a los clientes. Todo esto suena muy ambicioso pero en épocas de crisis es la diferenciación propia de la calidad y la eficiencia lo que destaca un producto o servicio por encima de sus competidores y ésto es algo que la mayoría de empresarios buscan para sus organizaciones.

Más sobre kanban en próximas entradas. 

Juan García Carmona

12 ago. 2012

Lean, principios básicos de las metodologías ágiles

¿Qué es Lean?

Lean es el nombre de un método de producción y desarrollo creado y aplicado por Toyota. Los principios que subyacen a los métodos de Toyota son principios que funcionan en todas partes porque son universales y se basan verdades que no cambian con el tiempo o el espacio. Las prácticas, es decir, la manera de aplicar estos principios en una determinada situación pueden y deben variar con el tiempo y según la situación evoluciona.

Lean nos dice que hay que centrarse en mejorar el sistema que usamos para producir centrándose en la optimización de procesos

Un objetivo fundamental de Lean es crear un flujo rápido y flexible, es decir, es útil pensar en el proceso de desarrollo como un oleoducto y todo lo que ralentiza el flujo son residuos, deshechos. En desarrollo de software los residuos son los retrasos a los que estamos ya habituados, los errores que todos cometemos, los malentendidos, y las esperas y los retrasos por falta de recursos. Todo esto se traduce en el incremento del gasto pero al eliminar los obstáculos, estos residuos, mejoramos nuestro proceso.

El sistema en su conjunto es el origen de los errores. Lean nos dice que la mayoría de los errores son de naturaleza sistémica y por lo tanto el sistema debe ser mejorado. También nos dice que hay que respetar a los trabajadores con el fin de mejorar el sistema. y que hay que hacer las cosas justo en el momento que tengan que hacer, ni antes ni después. A esto se le llama llama comunmente "Just-In-Time" o "JIT" y Lean sugiere centrarse en reducir el tiempo de lanzamiento al mercado mediante la eliminación de las demoras en el proceso de desarrollo, utilizando métodos JIT.

Mejorar la comunicación es un objetivo fundamental de todas las metodologías ágiles, desafortunadamente las prácticas ágiles tienden a enfatizar la comunicación a nivel local, en el equipo, entre los equipos relacionados, y con el cliente. Agile ofrece pocas soluciones para mejorar la comunicación entre equipos no tan íntimamente relacionados y prácticamente ninguna para la comunicación de arriba a abajo o alto y ancho de toda la empresa.

Lean promueve la comunicación centrándose en la creación de valor de extremo a extremo, proporcionando un contexto común para todos los involucrados en el sistema de producción a lo alto y ancho de toda la organización. Esto obliga a los diferentes niveles de la organización a comunicarse con más frecuencia y con énfasis en la mejora continua de procesos, la optimización del conjunto y la entrega temprana y con frecuencia. El pensamiento Lean ayuda a eliminar los retrasos que causan los residuos.

Principios Lean

Los principios Lean se pueden aplicar en muchos ámbitos. Todos los componentes de una empresa involucrados en el flujo de producir o añadir valor al producto o servicio que se ha creado, mejorado o mantenido se pueden beneficiar de estos principios. En el ámbito del desarrollo de software, Lean se puede convertir en una guía para aquellos que quieren desarrollar un software más eficiente y de alta calidad.

Lean proporciona una guía para los equipos de desarrollo ágiles. De hecho la metodología Scrum puede ser vista como una manifestación de los principios Lean. Entendimiento Lean puede ayudar en la implementación de Scrum pero también se puede aplicar en toda la empresa, ayudando así a aplicar Scrum en toda la empresa.

1.- Respetar a las personas

En desarrollo de software, respetar a la gente incluye la noción de que el equipo que hace el trabajo es el responsable del proceso que sigue. El proceso se convierte así en la aplicación de sus ideas de cómo desarrollar buen software. Cuando hay cambios el proceso cambia. Por lo tanto, el proceso es la base por la que el equipo que construye software lo hace de la mejor manera que saben, dentro de las limitaciones que se dan. Respetar al equipo es respetar su proceso.

2.- Eliminar residuos

La eliminación de residuos, desperdicios, basura o en inglés "waste" es la pauta principal para el practicante de Lean. Residuos es código más complejo de lo que debería. Residuos se producen cuando se crean defectos. Residuos es esfuerzo necesario para crear un producto sin valor añadido. Donde quiera que haya residuos, el practicante de Lean analizará el sistema para ver cómo eliminarlos ya que es probable que un error en el sistema vuelva a repetirse tarde o temprano.

3.- Aplazar el compromiso

Aplazar el compromiso significa tomar decisiones en el momento adecuado, en el ultimo momento en que se pueda responder. No se deben tomar decisiones demasiado pronto, cuando no se tiene toda la información que necesita, ni demasiado tarde, cuando puede suponer un gasto extra. Aplazar el compromiso es una manera proactiva de planificar el proceso y así no trabajar en cierta funcionalidad hasta que no se necesite. Esto evita tener que tomar decisiones ahora que podrían cambiar más adelante cuando tengamos más información. Este principio se puede utilizar para guiar el proceso de toma de requisitos, el análisis y el diseño e implementación.

Al establecer los requisitos debemos preguntarnos dónde debo gastar nuestro tiempo. ¿Tengo que concretar todos los requisitos con el cliente? Es evidente que no. Algunos requisitos son más importantes que otros. Los requisitos más importantes para la empresa suelen ser los que representan mayor valor para el cliente. Es un error demasiado común. Las metodologías ágiles profundizan en los requisitos que los clientes consideran más importantes, esta es una de las justificaciones básicas para el desarrollo iterativo e incremental, pero sólo centrarse en las características importantes para el cliente no debería ser suficiente para decidir en qué trabajar en cada momento, Debemos prestar atención a los riesgos de la arquitectura y tener en cuenta qué requisitos pueden causar problemas si se ignoran. Éstos son los que deben ser desarrollados primero y no otros.

Durante las fases de diseño e implementación los desarrolladores tienden a tomar decisiones cuando tienen que resolver un problema pero les alta información o no lo tienen claro. Un enfoque suele ser hacerlo lo más sencillo posible, sin prever necesidades futuras. El otro enfoque es anticiparse a lo que pueda suceder. Ambos enfoques tienen diferentes retos, para el primero el resultado en el código es que es difícil de cambiar porque no ha tenido en cuenta la variabilidad del código mientras lo escribía. Para el segundo el código es más complejo de lo necesario porque, como los desarrolladores tienen un tiempo difícil predecir, se anticipan a las creando clases, abstracciones o métodos que en realidad no son necesarios, pero que agregan complejidad.

Un enfoque alternativo a estos dos es el llamado "diseño emergente", Diseño Emergente en desarrollo de software consiste en:

• Utilizar los bien conocidos patrones de diseño para crear arquitecturas de aplicación resistentes y flexibles.

Limitar la aplicación de patrones de diseño a aquellas características que estén completamente definidas.

• Escribir test de aceptación y tests unitarios antes de escribir el código, ambos mejoran el proceso y crean una malla de protección frente a previsibles cambios.

Utilizar patrones de diseño hace el código fácil de cambiar y nos limitamos a implementar sólo lo que realmente se necesita en cada momento además de hacer el código menos complejo. Las pruebas automatizadas mejoran el diseño y lo hacen seguro frente a posibles cambios de requisitos. Estas características del diseño emergente permiten aplazar el compromiso de una implementación en particular hasta que se entienda lo que realmente se necesita hacer.

4.- Crear conocimiento

El software tiene un valor inherente escaso, su valor viene de que permite y optimiza la entrega de productos y servicios. Por lo tanto, es más útil pensar en el desarrollo de software como parte del proceso productivo, es decir, del conjunto de actividades encaminadas a crear productos que satisfagan las necesidades de los clientes mientras se avanza en los objetivos estratégicos de la empresa.

En las empresas de software, el software se desarrolla para ayudar en el trabajo y las necesidades de los clientes que lo utilizan. El software es un medio para un fin y el fin es satisfacer un cliente, ya sea directamente con un producto o indirectamente al ofrecerle un servicio a través o mediante nuestro software. Cuando se ve de esta manera, es claro que el papel del software en las organizaciones de TI es apoyar a productos y servicios de la empresa y debe considerarse como parte de desarrollo de productos.

El desarrollo de cualquier producto tiene tres pasos:


1º Descubrir lo que el cliente necesita

2º Encontrar la manera de fabricarlo

3º Fabricar


En desarrollo de software, parece pasamos más tiempo hablando del tercer paso, sin embargo, los dos primeros pasos en realidad nos llevan la mayor parte del tiempo. Muchos al leer esto pensarán que no es así y yo les preguntaría cuanto tiempo tardarían en desarrollar un pequeño programa en el que estaban, supuestamente, trabajando y del que, supuestamente, acaban de perder todo el código fuente. La mayoría de los desarrolladores me dirían que gastarían entre un 20 y un 50 por ciento del tiempo que tardaron la primera vez porque en lo que verdaderamente gasta más tiempo un desarrollador es en "descubrir lo que el cliente necesita " y, sobretodo, en "encontrar la manera fabricarlo".

Crear conocimiento significa comprender el proceso que se utiliza para desarrollar software para satisfacer cierta necesidad del cliente. Mediante la comprensión de sus métodos, puede mejorar más fácilmente. Crear conocimiento significa documentar mínimamente y compartir diseños puntuales y también diseños globales y arquitectura.

También se crea conocimiento con una buena batería de tests unitarios con una nomenclatura concreta ya que una funcionalidad, un requerimiento del cliente debería traducirse en n tests unitarios que cubran al máximo el código implementado, el nombre de esos n tests debería ser suficiente para que cualquier compañero entienda cómo y por qué funciona y existe ese código.

5.- Entregar rápido y con frecuencia

Otra razón para hacer el desarrollo iterativo es entregar al cliente de manera rápida y continuada permitiendo una pronta inmersión en el mercado, una mayor credibilidad, una fuerte lealtad, etcétera. Aunque esto además supone una mayor rapidez a la hora de conseguir ingresos también supone un gasto previsible por la necesidad calculada de futuros desarrollos en sucesivas iteraciones.

Este principio, la "entrega rápida", debe entenderse también como una eliminación de retrasos. Las demoras representan residuos, son gastos innecesarios y se busca eliminarlos entregando más rápido y con más frecuencia. Los beneficios de la entrega rápida son claros pero también es esencial hacerlo de una manera sostenible.

6.- Producir con calidad

La calidad ha de estar estructurada, o lo que es lo mismo, el sistema debe basarse en la calidad a todos los niveles. A fin de mantener la velocidad de desarrollo los equipos deben desarrollar la calidad tanto en su proceso como en su código. La implantación de calidad en el proceso permite a un equipo mejorar mediante la eliminación de los residuos que él mismo crea. Una manera de conseguir calidad es definir, si es posible entre tester, desarrollador y cliente, pruebas de aceptación antes de escribir el código, esto implica una necesaria conversación en torno a los requisitos y ayuda a los desarrolladores a entender la funcionalidad que necesitan desarrollar.

También se puede conseguir calidad en el código mediante el uso de métodos descritos anteriormente para eliminar residuos. Muchos desarrolladores gastan gran parte de su tiempo investigando como resolver y resolviendo errores o bugs, sin pruebas automatizadas, los errores y los bugs son más frecuentes por culpa de un código de peor calidad además de que el código que es difícil de entender y eso contribuye a la pérdida de tiempo.

7.- Optimizar el conjunto

Hay que concentrarse en todo el proceso en su conjunto, desde el principio (concepto) hasta el final (consumo). Frecuentemente se busca, con toda lógica, optimizar cada paso, cada flujo de trabajo de cada departamento, el problema con la optimización de cada paso es que crea grandes "inventarios" entre los pasos y toda esa cantidad de información a menudo no es tarea fácil de digerir.

En el mundo del software, estos "inventarios" los representan tareas parcialmente realizadas. Entender el flujo como una sola pieza, como un todo, es decir, centrado en la construcción de un elemento en su totalidad, es un proceso mucho más eficiente que aquel que se concentra en la construcción de cada una de sus partes con mayor rapidez pues los "inventarios" ocultan errores en el proceso, o en la consecución de cada una de las partes o en el ensamblado. Pueden ocultar malentendidos con el cliente, diseños ineficientes, bugs, errores de integración, etcétera. Cuanto mayor sea el inventario o más partes haya más probable es que haya errores no detectados. Residuos. Gastos.

¿Por qué no muchas "equipos ágiles"obtienen los resultados esperados?
  • ¿Por su falta de experiencia?
  • ¿Por falta de atención durante el aprendizaje?
  • ¿Se olvida la gestión del cambio?
  • ¿No están siguiendo el libro?
  • ¿Es porque no han contratado a un tutor o un profesor con experiencia?
  • ¿Tal vez se olvidaron de las buenas prácticas y los patrones de diseño?
  • ¿Es porque no se ha dominado la complejidad o el pensamiento sistémico?
  • ¿Será que no se centran en la mejora continua?

Es posible que se deba a uno o varios de estos motivos pero muchos casos que he visto están relacionados con el diseño de la organización, con burocracia interna y con falta de comunicación interdepartamental.

Los equipos ágiles se centran en la entrega de valor a intervalos regulares. Cada dos o tres semanas trabajan en una lista de oportunidades de negocio expresadas en las historias de usuario o tareas y juntos trabajan a toda velocidad para analizar, desarrollar, probar y liberar todo el conjunto. Su enfoque es fuerte y simple y sus resultados suelen ser bastante bueno sin embargo dependen de personas fuera del equipo. Los gerentes, administrativos, ingenieros de sistemas, comerciales, etcétera, todos ellos individuos que forman parte de diferentes departamentos o entidades organizativas que aún perteneciendo a la misma empresa tienen otro enfoque y otra visión. Algunos se centran en mantener los sistemas actuales, otros en la gestión contable, otros en la captación de clientes, otros en minimizar el cambio, etcétera.

Si bien la principal preocupación del equipo de desarrollo es la liberación de elementos de valor a intervalos regulares ésto es sólo una preocupación menor para los demás integrantes del resto de departamentos y, aunque ésto no es ninguna sorpresa para nadie en realidad, tiene un grave impacto en la tasa de éxito de entrega del equipo de desarrollo.
  • Las historias de usuario no se acaban dentro de la iteración, porque el product owner no ha tenido tiempo para validarlas. 
  • La siguiente versión software no sobrevivirá mucho tiempo porque el servicio de soporte técnico no tuvo tiempo para formarse y está creciendo el descontento entre los usuarios.
  • Operaciones ha decidido aplazar la implantación de un nuevo desarrollo interno ya que se acaban de dar cuenta de que tenían un grave problema de almacenamiento.
¿Cómo podemos aprovechar los beneficios producidos por un cambio que abarca todo el proceso si el resto de la organización hace todo lo contrario? Las empresas deberían empezar a plantearse el coaching ágil a todos los niveles. Se ha visto que la formación en metodologías ágiles ha dado muy buenos resultados en equipos de desarrollo pero va siendo hora de ir formando en éste tipo de metodologías y formas de pensar a todos los niveles de la empresa.

Yo ya me considero "evangelista" de éstas metodologías, me encanta hablar de eficiencia y he conseguido que varias personas de distintos departamentos, amigos míos y trabajando en otras empresas, se quedaran encantados con éste enfoque organizativo. Si crees que sería interesante impartir un curso de formación enfocado a la eficiencia en tu empresa, no sólo en departamentos de desarrollo, tan sólo tienes que ponerte en contacto conmigo y lo adapto a tus necesidades y las de tu empresa.