La práctica se basaba en realizar un sistema para resolver tableros de shikaku, mediante el algoritmo de vuelta atrás. Mi solución es óptima pero no del todo correcta desde un punto de vista académico, ya que el uso del algoritmo (de backtracking) es menos usado de lo que debería.

Para poder ver el código, este puede descargarse a través de un cliente de Subversion, en sistemas Unix/Linux es tan fácil como:

svn co http://project.bosqueviejo.net/svn/shikaku/trunk

Explicación del código

Bueno, tengo que reconocer que, después de algo más de un año de haberlo hecho, he tenido que releer y revisar de nuevo todo para acordarme (y reaprender) cómo hace lo que hace.

Por ello, voy a escribir una documentación básica sobre el código en sí, para tenerla como referencia, cuando tenga que volver al mismo otra vez, y para que sirva a todos aquellos que lo necesiten.

En principio, el código se divide en las siguientes clases:

• shikaku.tablero.Combinacion: esta clase se encarga de almacenar combinaciones. Una combinación es un rectángulo que se sitúa ocupando un espacio de X*Y=N. La combinación debe de tener en alguna de sus casillas el número contenido, por lo que se almacena también la ordenada de N para comprobaciones.
• shikaku.tablero.Ordenada: es cada uno de los números que aparecen en el tablero. Se almacena su posición dentro del tablero y la representación numérica del mismo.
• shikaku.tablero.Tablero: almacena las dimensiones del tablero, la lista de combinaciones fijas (las que solo tienen una combinación válida detectada) y la lista de soluciones posibles para el tablero.

Una ejecución de shikaku tiene los siguientes pasos:

1. Entra en main de la clase shikaku, donde se detecta el origen de datos, hasta saber de donde se va a cargar el tablero.
2. En run se crea una instancia del tablero, y se ejecuta, para cada punto del tablero, el generador de la clase Combinacion.
3. El generador se encarga de buscar combinaciones válidas para el punto dado, dentro del tablero y validando su posición dentro del tablero (es decir, que no haya parte del rectángulo fuera) y con respecto al resto de puntos (que no tenga contenido nada más que el punto del que tiene que hacer la combinación).
4. El último paso para la resolución, es llamando a buscaSoluciones, de la clase Tablero, que se encarga de realizar el algoritmo de vuelta atrás para buscar las soluciones al tablero.

Estos son los pasos más importantes dentro del código para resolver el tablero de shikaku.

La depuración

Uno de los motivos por los que el algoritmo no es del todo de tipo vuelta atrás, es precisamente por el uso de tres algoritmos voraces que se ejecutan antes que el último, de vuelta atrás. Estos algoritmos realizan una criba sobre las combinaciones basándose en tres premisas que debe cumplir cada combinación para ser válida:

1. Que no haya nada fuera del tablero: esto se realiza mediante una simple validación a la hora de generar las combinaciones. Es simple y rápida, y quita mucho procesamiento al algoritmo final.
2. Combinaciones con un solo número: esto se refiere a que dentro del rectángulo que conforma la combinación, solo esté contenido el número objeto de la combinación y ningún otro. Esta validación también está incluida a la hora de generar las combinaciones, para lo que se necesita, en el generador, pasar todos los puntos del tablero.
3. Eliminar combinaciones imposibles: imposibles, además de las que se descartan en los puntos anteriores, son las que colisionan con todas y cada una de las combinaciones posibles de otro número vecino. Si la combinación de un número colisiona con todas las combinaciones posibles de otro número, como es lógico, no podrá ser posible.

Ciertamente, con estos algoritmos se llega a resolver un alto porcentaje de los tableros básicos, sin necesidad de realizar el algoritmo de vuelta atrás. Solo los tableros grandes y con dificultad alta, necesitan, además de estos algoritmos voraces, el de vuelta atrás.

Mejoras

En sentido académico, teniendo en cuenta uno de los requisitos que se pide, que es que sea un algoritmo de vuelta atrás, quizás sea más correcto que la depuradora actúe solo a nivel de rama y no en profundidad.

Hay que tener en cuenta que esto penalizaría el rendimiento y empeoraría en lo que a gestión de memoria se refiere, pero prima más cumplir con los requisitos

Entradas relacionadas:

1. Algoritmos heurísticos y algoritmos voraces

Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.

¿Qué es la calidad interna?

Cuando se desarrolla un software, se desarrolla con una calidad medida según sus requisitos que pueden determinar su alto grado de calidad, midiendo una serie de parámetros. Pero estos parámetros no reflejan ni tienen en cuenta la calidad del proceso de creación del software en sí, ni la calidad del software escrito, solo la calidad externa, es decir, la función que realiza el software.

La calidad interna, sin embargo, mide y tiene presente la forma en la que se ha desarrollado el código de modo que pueda mantenerse (corregirse, ampliarse y adaptarse) de forma rápida y sencilla, gracias a un diseño e implementación limpia, simple y clara.

La importancia que tiene este tipo de calidad se muestra de manifiesto en varios textos como Scrum y XP desde las trincheras (de Henrik Kniberg) y algunos blogs como el de José Manuel Beas, Joseba Enjuto, una entrada de Diego Gómez en la web Dos Ideas, o incluso en el propio estándar ISO/IEC 9126.

¿Por qué es tan importante?

Para un desarrollador, la calidad interna es tan o más importante que la calidad externa, puesto que si un software hace lo que debe, pero una de cada 1000 veces no funciona, puede deberse a un fallo interno difícil de detectar que, pueda incluso verse agravado por la mala calidad con la que se ha desarrollado (diseñado o implementado) el sistema en sí.

En base a tiempo, un software desarrollado con una calidad baja o nula, puede ser desarrollado en un tiempo muy pequeño, ya que no se tiene en consideración muchos aspectos necesarios y útiles, como por ejemplo, una buena orientación a objetos, modularización del código, reutilización, algoritmos excesivamente complejos u ofuscados, etc.

Cuando, por un fallo (mantenimiento correctivo) hay que volver al código para corregir un defecto, y se detecta un error de diseño, modificar un código mal oliente, es más complicado que corregir un defecto en un código que está mejor desarrollado en base a patrones y reglas básicas de análisis, diseño o codificación.

En otras palabras: un programa con calidad interna baja es un programa que generará deuda técnica.

No hay entradas relacionadas.

Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.

Creo que se ve claro que, programar rápido no significa hacerlo bien, en la mayoría de los casos, es raro hacerlo rápido y bien. Por otro lado, lo que puede haber funcionado (incluso de milagro) en una ocasión, si necesita mejoras o cambios, puede dejar de funcionar, teniendo que invertir mucho más tiempo del que habría costado hacerlo bien desde el principio.

¿Hacerlo bien significa gastar muchas más horas? No realmente. Si llevásemos un cómputo de las horas invertidas en hacer un proyecto de forma rápida, a priori, podría parecer que se han invertido pocas horas y el trabajo está hecho. El problema viene después, cuando toca corregir los errores de cualquier índole que no se han tenido en cuenta, o simplemente, por la rapidez, se han cometido.

Normalmente, las horas invertidas en mantenimiento, superan con creces las horas invertidas en un desarrollo basura. La comparación con el haberlo hecho bien, es que el tiempo de desarrollo planificado crece, pero el de mantenimiento es nulo o muy, muy pequeño. Por lo que, a la larga (o al medio plazo) compensa.

No hay entradas relacionadas.

Después de haber empleado métodos tradicionales como MS Word, OpenOffice Writer, LaTeX, DocBook… y otros más dinámicos como el wiki, aquella idea sonaba extraña, pero con cierto sentido.

Tras revisar el proyecto Knowledge Tree (árbol de conocimiento), llegué a ver más claro lo que comentaba mi compañero y comencé a verlo mucho más útil que toda la pila de documentación general que se realiza normalmente.

Los problemas

Cuando se realiza documentación, generalmente, se realiza un documento con una serie de apartados bien definidos y completados de la forma más completa posible.

El primer problema viene cuando hay que escribir el documento, el soporte. ¿Se hace en Internet a través de una página tipo wiki para que todo el mundo colabore?, ¿se hace en un sistema tipo foro para que se establezca en plan discusión?, ¿se hace en un sistema de control de incidencias para documentar tarea a tarea lo que llegue?

Este planteamiento deriva en otros muchos problemas. Cada uno, tiene el problema individual de que, cuando el nivel de información crece, la forma de buscar entre sus tripas para encontrar lo que se busca se hace más complejo y tedioso. Este sería el segundo problema de estos sistemas.

En el caso de que se haga una documentación formal. Tienes la posibilidad de imprimirlo cada vez que se haga una revisión del documento y dejarlo encuadernado y visible para uso de cada persona de la empresa o en un directorio compartido al que puedan tener acceso. Volvemos al principal problema de la búsqueda de la información dentro del documento, así como, cuando las personas vean que el documento excede de 20 páginas, seguramente lo mirarán con miedo.

El tercer y mayor problema… ¿quién lo mantiene?, en el caso de un documento wiki, hay que ir revisando sus páginas, al igual que en el documento formal escrito en formato de libro y es un trabajo que, una vez que el documento se extiende más allá de las primeras 20 páginas, se hace cada vez más dificultoso.

¿Y el blog lo soluciona todo?

Bueno, no es una panacea. Eso hay que tenerlo claro. Como comenté antes, el sistema Knowledge Tree tiene de bueno que comparte similitudes con los blogs, pero tiene la carencia de que los documentos escritos, siguen siendo los convencionales de procesador de textos, o cualquier editor que genere un PDF.

Por sus características, un blog tiene las siguientes ventajas:

• Los blogs tienen artículos. Pueden constituir recetas en las que poner datos necesarios que se vean importantes para proporcionar información al resto de la empresa.
• Un blog tiene categorías donde se agrupan todos los artículos escritos. En este caso, las categorías podrían delimitar áreas técnicas como: web, sistema, explotación, infraestructura, atención al cliente, administración, dirección…
• Cada artículo puede contener una o varias etiquetas (tags). Estas etiquetas pueden ser esenciales para localizar documentos que tengan que ver con temas tan diversos como: altas de clientes, facturación, despliegue, desarrollo, entorno de trabajo…
• Los artículos se escriben rápidamente y desde cualquier sitio, pueden contener media (imágenes, vídeos, presentaciones, audios…), que puede ayudar mucho a la documentación en sí.
• Los artículos tienen la posibilidad de agregar comentarios. Esto es muy útil porque se pueden agregar actualizaciones pequeñas por otras personas, o preguntas frecuentes que no se hayan recogido en el propio artículo.
• Los pingbacks o trackbacks, son referencias que hace un artículo contra otro cuando es referido por él. Esto es muy útil cuando queremos tener relaciones entre artículos, que quedan almacenadas en los mismos, a través de enlaces. E incluso actualizaciones a través de nuevos artículos.

Por todo ello, un buen sistema de blog puede ser empleado como sistema de gestión documental fácil de llevar a producción y fácil de implementar entre los trabajadores, sobre todo en el entorno de programadores, administradores de sistemas y similares.

Entradas relacionadas:

1. CouchDB: REST y Base de datos documental

El problema viene al querer aplicar escalabilidad al proyecto. Cuando no solo hay un equipo implicado, sino que existen dos o tres, los cuales hay que configurar bajo ciertas circunstancias.

Lo primero que pensé, es que, si le puedo notificar a la red de que sucede un evento en concreto, ya sea a una sola máquina o conjunto definido de estas (pero para todos los equipos la misma configuración), facilitaría la puesta en producción. Con lo que me puse a buscar y encontré MQ, message queue.

El encolado de mensajes

La comunicación de los equipos informáticos se basa en mensajes, en eventos, que deben de poder transmitirse de unos a otros cuando sucedan (si es que se quiere tener la máxima fiabilidad en la información que se trata).

Una forma es comunicar directamente al implicado, lo cual resulta un poco tedioso si los implicados son muchos y muy distintos.

Otra forma es mediante un sistema JMS o un MQ, como RabbitMQ.

El encolado de mensajes es un sistema que permite que un elemento perteneciente a un sistema de información, pueda comunicar un estado, evento o mensaje informativo o imperativo a otro conjunto de elementos dentro del sistema, para que interactúe con él.

Por ejemplo, si tenemos un servidor web, una interfaz, que controla un conjunto de máquinas encargadas realizar llamadas salientes, rastrear páginas de la web para almacenar información para un buscador o similar, y la interfaz quiere enviar parámetros nuevos de configuración a estas, puede hacerlo mediante el envío de un mensaje generalizado a ese conjunto de máquinas, y estas máquinas recibirán el mensaje en el momento que lo soliciten.

Esta utilidad es igualmente buena para cuando una interfaz web, por ejemplo de un estudio fotográfico, carga imágenes desde la web, las retoca con algún tipo de efecto, ajuste, etc. y más adelante permite su descarga. El sistema web puede enviar el evento al sistema de retocado de que hay una imagen disponible, y cuando la imagen ya está disponible, el sistema de retocado puede enviar otro mensaje de vuelta diciendo que ya está.

Quizás esto último podría hacerse mejor con una base de datos, pero con el sistema de mensajería, se eliminan los datos en el momento que ya no se necesitan, mientras que con la base de datos, esos datos podrían permanecer ahí de forma indeterminada.

Conclusiones

Los sistemas de encolado de mensajes tienen su utilidad, sobre todo, en sistemas formados por varias máquinas, con roles bien definidos y en las que se quiere afinar lo que son las conexiones y comunicaciones entre las máquinas.

No hay entradas relacionadas.

Hay que tener siempre presente que, cuando se realiza un trabajo, ya sea el que sea, si lo realiza una persona ajena, no de la empresa, se paga una factura por sus servicios, en los que viene detallado, normalmente, la mano de obra, que suele cobrarse en factor de tiempo empleado.

El coste asociado de emplear a una persona que está en nómina, dentro de la propia empresa, puede ser menor, pero no cero. Si un empleado cobra en bruto unos 2000 euros mensuales y le mandamos hacer un trabajo para lo cual gasta todo un mes, es de lógica pensar, que ese trabajo me ha costado esos 2000 euros, ya que es lo que ha hecho el empleado. Si el proyecto al final solo hace ingresar a la empresa 200 euros, la empresa ha perdido con ese desarrollo 1800 euros.

En el caso de que un proyecto se desarrolle en dos semanas de ese trabajador, por redondear, damos que son 1000 euros el coste y se consiguen 1200 euros. La empresa ha conseguido con su labor 200 euros… pero si el desarrollo ha sido deficiente, por el poco tiempo empleado, y el programador tiene que ir invirtiendo horas, que al final resultan ser días (en suma) y llegan a ser otras dos semanas, tendremos que esos 200 euros se convierten en 800 euros de pérdidas.

El las metodologías ágiles se hace hincapié a dar valor, es decir, realizar el desarrollo por iteraciones, siempre haciendo lo que más valor dé al cliente. Por ejemplo, si tenemos 10 requisitos en un proyecto, impuestos por el cliente, pero los más importantes son los 2 primeros, podemos negociar con el cliente el hacer esos dos primeros, valorarlos con el tiempo que toma el realizarlos y, en caso de querer el resto de requisitos, o algunos más, volver a realizar otra petición.

¿Qué conseguimos con esto?

• Que el cliente pida lo que necesita, únicamente.
• Que el precio que se pague sea el justo y necesario, e incluso no muy desorbitado para el cliente.
• Que la estimación de tiempo sea más ajustada a la realidad, siendo los plazos de desarrollo más cortos.
• Que el cliente consiga su producto, su valor, antes.

Por lo que recomiendo a todos los que trabajan en nómina en una empresa, y su jefe (o siendo jefes) no se lleven el cómputo de horas invertidas en proyectos, incidencias, etc., que lo hagan, porque es una moneda de cambio muy útil para cuando se quieren conseguir cosas importantes, dentro de la empresa.

No hay entradas relacionadas.

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

• A los individuos y su interacción por encima de los procesos y las herramientas.
• El software que funciona por encima de la documentación exhaustiva.
• La colaboración con el cliente por encima de la negociación contractual.
• La respuesta al cambio por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Entre estas diecisiete personas estaban: Kent Beck, uno de los tres creadores del Xtreme Programming; Alistair Cockburn, padre de los Crystal Methods; Martin Fowler, gran defensor de la Refactorización; Ward Cunningham, estudioso de los patrones y antipatrones de diseño del software y otro de los creadores de Xtreme Programming; Ron Jeffries, otro de los creadores del Xtreme Programming; Jeff Sutherland, gran promotor de Scrum.

Individuos y su Interacción sobre Procesos y Herramientas

No hay que malentender estas palabras tomándolas en su sentido más radical. La expresión de esta frase se refiere que se valora más la comunicación humana, las reuniones y lo que una persona pueda transmitir a otra, que las herramientas.

Así mismo, se considera más importante la valía de la persona, del programador y del diseñador, que los procesos establecidos en sí.

Software que funciona sobre Documentación exhaustiva

Es lógico que, si tengo un software que no funciona como quiero, da igual lo grande que sea la documentación. Es más útil un programa intuitivo, que hace única y exclusivamente lo necesario y tiene una calidad interna alta (código limpio, claro y con comentario concisos) que un software enrevesado que necesita un manual de no menos de 100 páginas para poder entenderlo.

Colaboración con Cliente sobre Negociación Contractual

La firma de un contrato ata a ambas partes a realizar un cierto desarrollo en un determinado tiempo con un gasto prefijado, solo que estos valores son solo estimados.

El contrato debe de existir, pero hay que colaborar con el cliente en realizarlo de forma más flexible, es decir, que los desarrollos sean de períodos cortos y vayan dando valor al cliente, de modo que, con esas cortas entregas, el cliente pueda decidir el curso a seguir entre iteraciones con sus peticiones y los desarrolladores realizar solo el esfuerzo necesario.

Respuesta al cambio sobre Seguimiento de un plan

Como comentaba, salvo para administraciones públicas, los desarrollos que se realizan a vista de un año o más, no suelen aportar valor al cliente hasta terminado ese período de espera. Una empresa que necesita un software, normalmente no puede dar unos requisitos fijos que, a lo largo de los siguientes meses, no cambien debido a un cambio externo o una necesidad de la propia empresa.

Por este motivo, la respuesta al cambio es vital y muy necesaria y, como indicaba el punto anterior, el hecho de poder hacer iteraciones y dar valor al cliente cada poco tiempo es lo que se persigue con el desarrollo ágil.

Conclusión

Esto se produjo en marzo de 2001, desde entonces ninguno de los diecisiete, más otros igualmente grandes, como Mary Poppendieck o Mike Cohn, no han parado de aportar bibliografía sobre el tema y métodos o matizaciones de los métodos ya existentes.

En este sentido, se puede decir que el desarrollo del software es un terreno vivo, donde no paran de descubrirse y crearse métodos y técnicas, para poder abarcar de una forma más exacta el desarrollo de un proyecto de software.

No hay entradas relacionadas.

¿Lenguaje funcional para la web?

Muchos se harán esta misma pregunta, si de siempre, los lenguajes imperativos han sido empleados para el desarrollo de aplicaciones web (Java, PHP, Ruby, Perl, C#, …), ¿por qué emplear un lenguaje funcional como Scala o Erlang?

Las ventajas son las siguientes:

• El lenguaje funcional obliga a pensar lo que se programa, realmente, en este tipo de lenguajes también es posible cometer errores y hacer barbaridades, pero en menor medida. Por regla general, lo que se programa en un lenguaje funcional, suele ser meditado, pensado y puede ser probado de mejor forma.
• Obliga a organizar el código, ya que todo gira en torno a crear funciones que se llamen unas a otras y a sí mismas, así como tener el código separado en módulos o bloques funcionales. Por ejemplo, en Erlang, para emplear OTP (gen_server, gen_event, gen_fsm…) se debe de crear un módulo para cada uno de ellos, con lo que todo queda bien organizado.
• El código resultante es más corto y más legible, ya que el código funcional no reutiliza variables, se basa en listas y tiene menos estructuras de control que los lenguajes imperativos, sí, resulta más fácil de comprender el lenguaje en sí y el código, una vez se va leyendo.
• Tienen ventajas cuando se habla de concurrencia, tiempo real y tolerancia a fallos. Obviamente, si no se permite la reasignación, no se permite cambiar el valor de un dato ya asignado y, por tanto, no hay cabida para la memoria compartida, con lo que la concurrencia se simplifica de forma sorprendente. Por otro lado, estos lenguajes han sido pensados y desarrollados para distribuirse en varios nodos y/o equipos, pudiendo migrar sus procesos entre nodos y sustituir al nodo principal en caso de no estar operativo.

En lo que respecta al lenguaje en sí, se ve claro y, hasta muchos pensarán: ¡mierda!, he perdido el tiempo aprendiendo y usando PHP (o Perl, o Ruby, o Java…); pero no hay que ser tan radical, estos lenguajes son muy útiles y ofrecen muchas ventajas a los lenguajes tradicionales web y, gracias a los frameworks desarrollados, las mejoras son increíbles.

Si tan bueno es… ¿por qué no se usa?

Seamos sinceros, la razón de uso de un sistema u otro se basa, íntegramente, en la popularidad, la costumbre y los malos usos. Cuando en tu entorno hasta 3 personas dicen que PHP es bueno para la web, ya sabes que es lo que hay que aprender si quieres hacer web, pero eso no debería de ser lo único a calibrar, y sobre todo si el conocimiento que se adquiera de PHP se usará para el desarrollo profesional de aplicaciones.

Erlang lleva muchos años usándose en el terreno de las telecomunicaciones y Yariv, el creador del framework Erlyweb, integra servicios desarrollados en Erlang para Facebook, con lo que, los grandes de Internet, ya se han dado cuenta de que hay que dar un paso hacia adelante. Por otro lado, Scala es usado en otros sitios como Twitter.

Ahora de verdad, ¿por qué usarlos?

El desarrollo de entornos web conlleva el uso de varias tecnologías que se usen de forma coordinada y limpia. Desarrollar un software en cualquier lenguaje mezclado con SQL y código en HTML con CSS incrustado y código JavaScript repartido por todos lados hace que el código sea difuso. Difícil de entender.

Sin embargo, con C# y Java se comenzaron a emplear soluciones que han ido trascendiendo a lenguajes de scriptting como Ruby, Python o PHP, en los que ya no se dejan ver consultas SQL, sino el uso de objetos y funciones, el código de presentación queda almacenado por separado con etiquetas especiales, helpers y otros añadidos, los códigos HTML validados, los CSS en sus respectivos ficheros aparte y agregados desde la sección pertinente e incluso el uso del JavaScript no intrusivo.

Llegados a este punto, nos encontramos con que, desarrollar web es, tan solo, desarrollar. Realizar el programa en un solo lenguaje y de forma fácil. Pero aún así, volvemos a encontrar lo que ya había tiempo atrás, nuestro lenguaje imperativo puede contener fallos lógicos y, si es un lenguaje de scriptting muy permisivo, algunos de esos fallos son difíciles de perseguir.

El uso de un framework como lift o erlyweb facilita el seguimiento de fallos, desarrollar en erlang y scala facilita el desarrollo propio de la aplicación y agrega factores determinantes de crecimiento de la misma, así como estabilidad, ¿qué más se puede pedir?

Entradas relacionadas:

1. Lenguajes de Programación
2. Reia: Ruby sobre Erlang
3. Desarrollo Web

Introducción

La estimación es una de las actividades del núcleo de Scrum y otros procesos ágiles. Este proceso se refiere a darle una duración a cada historia, p.ej. ¿cuánto tiempo tomaría?, ¿cuánto trabajo tiene su implementación?, ¿cómo de caro es?, o cualquier otra cosa que quieras poner.

En Scrum, la estimación es una actividad de equipo. Para cada historia, todo el equipo participa en el proceso de estimación.

La planificación de póker (a veces llamada Scrum Póker) es simple, pero una potente herramienta que hace la estimación de equipo más rápida, más precisa y más divertida. El término fue acuñado por James Grenning y popularizado por Mike Cohn.

Estimación sin Planficación de Póker

Aquí hay un problema típico con las estimaciones de equipo. Cuando estamos en la planificación de un sprint y el Dueño del Producto dice:

El equipo comienza a pensar acerca de la duración de la historia (en el caso ideal de hombres-día)…

El participante A cree que el sabe exáctamente lo que necesita para hacerse, así que él piensa que puede tomar 3 días. Los participantes B y C son más pesimistas. Los participantes D y E están fuera de la conversación. El participante A dice “3 días”.

Esto hace que los participantes B y C queden confusos. Comienzan a dudar de sus propias estimaciones. El participante E despierta y no sabe realmente qué está siendo estimado. El participante D está aún dormido.

El dueño del producto pide al resto del equipo su estimación.

Como se puede ver, el resto del equipo ha sido fuertemente influenciado por el participante A, solo porque él habló primero. ¡Esto es muy arriesgado!, Tanto B como C pensaron que podría tomarse mucho más de 3 días, ¡sus dudas deberían ser aireadas!

Estimación con Planificación Póker

Ahora imagina que cada miembro de equipo tiene una baraja de cartas, conteniendo las siguientes cartas:

Vamos a rehacer la estimación. El dueño de producto dice:

Una vez de nuevo, el equipo comienza a pensar sobre el tiempo que tomaría la historia.

Esta vez, nadie dice nada. En lugar de eso, todos tienen que presentar una carta, bocaabajo, conteniendo su estimación. Todo el mundo tiene que tener presente una carta, así que los participantes D y E despiertan. El participante D admite que estaba durmiendo y pide que se le repita la historia. Es difícil evadirse cuando se estima de esta forma

Cuando están todos, todas las cartas se destapan simultáneamente, revelando las estimaciones de todos.

¡Oooops! Gran divergencia. El equipo, en particular los participantes A y C, necesitan hablar sobre esta historia y el porqué sus estimaciones son tan diferentes. Después de la charla, el participante A dice que había olvidado algunas tareas importantes que necesitan incluirse en la historia. El participante C dice que, con el diseño que el participante A presentó, la historia parece ser más pequeña de 20.

Después de la charla (3 minutos en total) hacen otra ronda de estimación para la misma historia.

¡Convergencia! Vale, no hay una convergencia completa, pero están de acuerdo en que una estimación de 5 puede ser lo suficientemente cercana. Siguiente historia.

¿Por qué la extraña serie de números?

El más alto de los números tiene menos granularidad. ¿Por qué?, ¿Por qué no hay 21, por ejemplo?

Por varias razones:

• Acelera el proceso de estimación limitando el número de opciones (p.ej. número de cartas).
• Elimina una falsa sensación de precisión para estimaciones altas.
• Potencia al equipo a partir historias grandes en otras más pequeñas.

Una estimación alta (mayor de 20, por ejemplo) normalmente quiere decir que la historia no se entendió bien en detalle. Podría ser una pérdida de tiempo discutir si la historia tiene 19, 20 ó 22,5. Esta es, simplemente, una historia grande y un 20 debería reflejar eso. Si deseas entrar en detalle, rompe la historia en varias historias más pequeñas. Las pequeñas historias pueden ser estimadas en gran detalle.

Cartas Especiales

La carta cero significa esta historia está hecha o la historia es tan corta que se puede hacer en muy pocos minutos de trabajo.

La carta del signo de interrogación significa No tengo ni idea. Debería de ser rara. Si esta carta es usada demasiado frecuente, el equipo necesita hablar las historias más e intentar alcanzar un mejor conocimiento.

La carta del café significa Estoy demasiado cansado para pensar. Vamos a tomar un descanso.

Conclusión

Después de leer el artículo completo, saco en conclusión que, algo como es la capacidad de comunicación, es algo que hay que intentar potenciar en los equipos de desarrollo, a modo de que, no solo todos y cada uno se puedan expresar, sino emplear técnicas como esta para que su expresión no sea opcional, sino parte del juego.

Es importante que la opinión de un miembro del equipo no se vea afectada por la de otro, a menos, hasta poner toda la información sobre la mesa, que es cuando ambos, deben de afectarse por la información del resto del equipo, y llegar a un punto de comunicación e información que le dé consistencia a la estimación.

No hay entradas relacionadas.

Por ejemplo, el uso de un sistema BPM, puede ser compatible con un sistema REST como Ruby on Rails, mientras se mantenga la idea de REST… en cambio, si se modifica por intentar realizar un poco interoperatibilidad entre otros sistemas, a los cuales no se les quiere cambiar mucho la forma… se convierte en un infierno.

Al final, lo mejor, es mirar la piezas con las que queremos contar, por ser afines a los resultados que queremos obtener y, emplear única y exclusivamente, los patrones que se puedan ajustar bien a esas piezas.

En este caso, por ejemplo, Ruby on Rails, combina bien con sistemas BPM que sean REST, e incluso con bases de datos que sean REST, pero le quita características bastante deseables que sí tiene otro patrón como ActiveRecord, ante lo cual, se establece un sistema de preferencias y prioridades… ¿REST o ActiveRecord?… como es lógico, optando por ActiveRecord, desaparece BPM como tal, ya que ActiveRecord está hecho para su acceso directo a base de datos.

Pero al final, la base de datos, bien mirada, termina siendo nuestro sistema BPM y, con ayuda de procedimientos almacenados, triggers, usuarios y demás… es un sistema, no tan potente como otros, pero sí lo suficiente como para cumplir con las especificaciones básicas.

Bueno, al final, me doy cuenta de que, al igual que cuando se programa, se debe de decidir bien la estructura, los elementos a emplear, la forma y demás… cuando se desarrolla, se ha de tener especial cuidado con las metodologías, patrones de diseño y estándares, puesto que hay que comprobar que coordinen bien entre sí.

No hay entradas relacionadas.