Y al 41º año resucitó

31 de octubre de 2016admin

Publicado en el diario La Verdad el 30/10/16)

Fue uno de los grandes nostálgicos del franquismo, el escritor Fernando Vizcaíno Casas, el que con un curioso juego de palabras y cambiando los días por los años, publicó un libro titulado “Y al tercer año resucitó”. Un breve y crítico recorrido por los primeros años de nuestra transición planteando la hipótesis de la resurrección de Franco tres años después de su muerte.

Muchos nostálgicos no tenían rubor en decir “con Franco vivíamos mejor”, aunque como me decía mi padre, aquello escondía la mayoría de las ocasiones un deseo de volver a tu juventud, a otros tiempos posiblemente peores pero que recordabas con cariño. Pero nadie olvida que lo mejor es que la libertad democrática permitía eso, que se criticara al poder con naturalidad y sin miedo a que los “grises” vinieran a buscarte a tu casa.

Esta nostalgia jamás se convirtió en una alternativa política. El partido que representaba ese franquismo sólo consiguió un escaño en las elecciones de 1978 y su más llamativa aportación fue la de votar de forma negativa a todos los Estatutos de Autonomía.

En la transición se pasó muy de puntillas sobre el recuerdo de su figura. Según unos de forma pragmática, según otros de forma cobarde. Pero ese modelo de transición sigue siendo admirado. Lo normal es que al igual que se olvidó la floja película que se rodó basándose en la novela, el recuerdo de Franco se fuera disolviendo en el presente y formara parte de la historia de España, con la valoración que cada uno considere. Franco encabezó un alzamiento contra un gobierno democrático legítimo, ganó una guerra y murió en la cama de un hospital de “viejo”. Estuvo gobernando durante casi cuarenta años España, y en cuarenta años se pueden hacer muchas cosas, buenas y malas. Pero cada vez que determinados partidos de izquierda no tienen propuestas de cierto interés la figura de Franco se engrandece. Ahora ha sido con la protesta por las reválidas educativas que el Partido Popular pretendía imponer.

El lema ha sido “No a las reválidas franquistas”. Quizá ignoren que fue en los últimos años del franquismo cuando las reválidas desaparecieron y que en la actualidad muchos países democráticos disponen de modelos similares. Por cierto, la mejor campaña a favor de la reválida la hizo una de esas jóvenes manifestantes que portaba un cartel diciendo “No a la rebalida”.

Lo vergonzante del tema es que el gobierno haya permitido que empiece un curso escolar en el que ni profesores ni alumnos supiesen hasta esta semana si iban a realzarse las reválidas o no al final del mismo. También es preocupante que la izquierda vuelva a resucitar a Franco una vez más. Franco está mejor donde está, y lo curioso es que los que lo quieren resucitar no son sus cada vez menos nostálgicos, sino unos partidos liderados por gente que nació mucho después de que él muriera, y que carentes de propuestas, parece que piensan aquello de que “Contra Franco vivíamos mejor”.

El PSOE en el reino de los cielos

24 de octubre de 2016admin

“NO es NO”, refleja lo que no quieres, pero esconde lo que deseas hacer.

(Publicada en el Diario La verdad el 23/10/16)

Allí estaba Balian de Ibelín debiendo cargar la responsabilidad de evitar que Jerusalén, la ciudad sagrada, cayera en manos del sultán Saladino en la época de las cruzadas. El director Ridley Scott consiguió realizar una gran película sobre la gesta, aunque parezca que no fue muy fiel a la historia real. Desgraciadamente en una decisión extraña los productores o distribuidores decidieron que la película era muy larga para su exhibición comercial y la mutilaron. Años después pudimos ver la versión extendida de la película en su versión DVD o BluRay, pudiendo disfrutar de una historia que no por menos fantasiosa dejara de ser intensa y emocionante.

Lo que promete ser emocionante e intensa es la jornada del comité federal del PSOE que debe decidir entre el “NO es NO” o permitir el gobierno del Partido Popular. Javier Fernández, presidente del Principado de Asturias y de la gestora que actualmente dirige los destinos del PSOE, es el que parece que asumiría el papel de Balian de Ibelín. De hecho, en prevención de un previsible “asedio” ya se ha pedido protección policial para que reunión del comité federal pueda desarrollarse con cierta normalidad. Aunque no deja de ser curioso, que algo que aparentemente es una decisión normal, difícil pero normal, pueda estar rodeada de tanta tensión. No es extraño, en un país en el que algunos políticos sonríen cuando a un ex presidente de la talla de Felipe González se le impide de forma violenta, dar una conferencia en una Universidad.

Cuando uno se encuentra en una situación complicada habitualmente se dedica algo de tiempo a pensar cómo has llegado a dicha situación. Los sitiados de Jerusalén al mando de Balian, mientras sufrían las penurias del asedio seguro que no olvidarían que la imprudencia e incompetencia del gran maestre de la orden del Temple, Gerard de Ridefort. Parece que fue este hombre el que convenció al rey a emprender una batalla en terreno complicado, los famosos cuernos de Hattin, que supuso una de las mayores derrotas para el ejército cruzado. De la misma forma, en el PSOE lo podrían equiparar a los dos sucesivos desastres electorales a los que condujo Pedro Sánchez a su partido. Si a eso le sumamos una gestión bastante negligente, sobre todo del segundo desastre electoral y el pánico de ciertos sectores socialistas a un posible gobierno con podemitas e independentistas de toda clase, la situación complicada está servida.

“NO es NO”, refleja lo que no quieres, pero esconde lo que deseas hacer. Hay veces que una mala decisión es mejor que otras peores. Eso debió pensar Balian de Ibelín, el que prefirió rendir Jerusalen en unas condiciones honrosas, que le permitieron salvar la vida de los sitiados, en vez de prolongar ser asediado con un previsible final.

Ahora le toca elegir al PSOE, susto o muerte, pensar con el corazón o dejar que cierto pragmatismo se apodere de la decisión. Cuestión de horas que deciden el futuro de muchos años.

El tripartito huyó con las botas puestas

17 de octubre de 2016admin

(Publicado en el Diario la verdad el 16/10/16)

El general Custer fue considerado un héroe durante muchos años en los Estados Unidos. Un enorme retrato con su última batalla colgaba en la pared de muchas cantinas de oeste a este del país. Un joven general de largo cabello rubio, vestido con chaqueta de flecos, luchaba junto con un puñado de soldados del séptimo de caballería contra enormes hordas de salvajes y pintarrajeados indios.

Aquella batalla ocurrió muy cerca del rio Litte Big Horn, que fue el que dio el nombre a la batalla que supuso el mayor desastre de la historia del ejército de los Estados Unidos contra tribus nativas.

Aquel suceso fue llevado al cine en multitud de ocasiones, pero sin duda Errol Flynn fue el que consiguió que el personaje fuera de nuevo idolatrado, consiguiendo labrar la imagen de un general simpático y valiente que sacrificaba a su regimiento para impedir que las importantes ciudades fueran arrasadas por los indios nativos en pie de guerra.

No obstante, la película, titulada “Murieron con las botas puestas”, que apenas contiene hechos históricos, no deja de ser una gran película de aventuras con una inolvidable historia de amor.

La realidad de la batalla de Little Big Horn fue otra muy diferente. Tres columnas de soldados, mandadas por Custer, el mayor Reno y el capitán Benteen se lanzaron sin ninguna coordinación en busca de la gloria. Formaban parte de una expedición mayor dirigida por el general Crook.

Parece que la falta de empatía y coordinación entre los jefes de las tres columnas fue la principal causante del desastre. Algo así le pasó al tripartito que gobierna Alicante desde 2015 al abordar el pleno del estado de la ciudad que se celebró el pasado viernes. Bellido, Pavón Y Montesinos portavoces de Compromis, Guanyar y PSOE plantearon discursos descoordinados que mostraron mensajes muy diferentes sobre más de un tema, sobre todo la posición de cada uno de ellos sobre la instalación de Ikea en la ciudad. Cada uno trató de salvar su trabajo y no se comportaron como un equipo en ningún momento.

Al igual que los soldados del séptimo de caballería fueron presa fácil de los indios muy superiores en número y con mejor estrategia, los portavoces del tripartito fueron machacados literalmente por la oposición. Populares, Ciudadanos e incluso, si me aprietan, los concejales tránsfugas dieron buena cuenta de los numerosos errores que acumula el tripartito en su, quizá, peor momento de la legislatura.

Custer tras darse cuenta de sus errores, trató de formar un círculo para esperar la llegada de las tropas del general Crook. Aquello nunca pasó, Crook llegó cuando Custer había caído con sus tropas con las botas puestas. Lo mismo pasó el viernes, cuando los portavoces del tripartito miraron hacia el alcalde con la esperanza de que su intervención salvara los muebles, éste prefirió salvar sus botas y dio por terminado el pleno.

Retrospectiva de Ciudadanos en Bannockburn

10 de octubre de 2016admin

Una oposición sensata, reivindicativa y preparada es muy necesaria en Alicante

(Publicado en el Diario La verdad el 9/9/16)

Sin duda alguna una de las escenas más emotivas de la película Braveheart es la que le pone el epílogo. El rey inglés ha ajusticiado a Braveheart, que había sido el líder hasta ese momento de los escoceses. Le toca a su sucesor, Robert the Bruce, negociar las condiciones de rendición en Bannockburn, ante los prepotentes jefes de un ejército inglés muy superior en número. Robert, prefiere invocar al orgullo de sus tropas y lanza una impetuosa carga que vence a los ingleses.

En la realidad, aquella batalla acabó con el rey inglés escapando hacia Inglaterra tras su derrota y con una Escocia dirigida por el rey escocés victorioso. Braveheart había realizado una notable lucha frente a la invasión inglesa, pero murió antes de ver cumplido su sueño de expulsarlos de su país. Le tocó a otro finalizar su cruzada.

Se dice que cada cambio de tu entorno es una nueva oportunidad que facilita períodos de reflexión para mejorar las cosas. El grupo municipal de Ciudadanos en Alicante se encuentra en esta tesitura de cambio ante la dimisión del que había sido su portavoz hasta la fecha, José Luis Cifuentes. En breve otra persona se hará cargo de la portavocía y en cierta forma del liderazgo del grupo. Toca hacer lo que se llama una retrospectiva, que no es más que analizar el trabajo realizado hasta el momento obteniendo conclusiones para analizar, aprender y mejorar el trabajo realizado. Yo les recomendaría que no se perdieran en debatir lo que pudo ser y no fue, sino en afrontar el mandato que queda con una adecuada planificación y sobre todo, con mucha ilusión.

Una oposición sensata, reivindicativa y preparada es muy necesaria en una ciudad donde el alcalde, Gabriel Echavarri, se preocupa más de los tuits de los alicantinos de a pie, que de que el coordinador de sus socios de gobierno le llame “Indigno e incompetente” en facebook.

Hay que debatir y tratar de aprobar unos presupuestos que definirán parte de lo que queremos que Alicante sea el año que viene y sentar las bases de los siguientes años. Pero el éxito en esta tarea no se consigue insultando a los concejales de otros partidos ni guiñando el ojo a los tránsfugas. Se consigue trabajando, y definiendo propuestas buenas para Alicante, que seguro que Ciudadanos y Populares apoyarían. Pero el tripartito sigue más empeñado en cambiar los nombres de las calles que de tenerlas limpias, buscar problemas a la instalación de Ikea que en buscar soluciones, de olvidar proteger el Monasterio de la Santa Faz, de dificultar libre competencia en concursos públicos, de organizar hermanamientos extraños y conciertos musicales ruinosos y tantas cosas más que viendo lo visto hasta ahora, es mucho más que probable que al que le urge realmente hacer una retrospectiva es a Echavarri y a su equipo de gobierno.

Mi primer BackLog con Trello

7 de octubre de 2016admin

cap-5-1

Imaginemos que deseamos realizar un proyecto sobre una tienda on-line para la venta de gafas de sol importadas. Para ello se definen una serie de tareas principales en forma de historias de usuario

Como jefe Comercial quiero poder dar de alta productos con sus precios
Como jefe Comercial quiero poder definir campañas de ofertas
Como Jefe Comercial quiero poder crear usuarios que puedan comprar en la tienda o modificar la lista de productos de venta
Como jefe Comercial quiero que los usuarios se puedan dar de alta a través de la web
Como jefe Comercial quiero poder conocer el estado de las ventas en cada momento
Como jefe Comercial quiero que exista una aplicación móvil para que los usuarios puedan comprar en la web

Lo primero que haríamos es dar de alta todas las tareas en forma de tarjeta y las introduciríamos en la columna del Product Backlog

La apariencia del tablero sería la siguiente

cap-5-2

Ilustración 2 Producto Baclklog relleno

En esta primera iteración sería suficiente con identificar y escribir las tareas, es sólo el primer paso pero muy importante en el sentido que nos permitirá hacer una primera estimación, muchas veces necesaria, y nos permitirá conocer todas las tareas cuyo desarrollo puedo iniciar.

Tableros Scrum con Trello

7 de octubre de 2016admin

Los artefactos fundamentales de Trello son los tableros, las listas y las tarjetas.

Un tablero es la parte central del proceso Trello y representa la situación y evolución de un proyecto.

Las tarjetas representan la situación de cada una de las tareas que conforman el proyecto que estamos realizando y por último las listas representan los estados por los que se encuentran las diferentes tareas.

Hay múltiples formas de definir un tablero Scrum en Trello en función del uso que quieras darle. Una posible propuesta es crear las siguientes listas que representas los estados siguientes.

Product Backlog. Representan todas las tareas que conforman el proyecto

Sprint Backlog Representan todas las tareas que forman parte del Sprint actual que no se han iniciado todavía

En desarrollo. Tareas del Sprint actual que se están realizando

Terminado Sprint actual Tareas finalizadas en el Sprint actual

Terminado Tareas que se han finalizado en cada uno de los Sprints

Impedimentos Problemas activos que se deben solucionar

Para crear un tablero y las listas, debemos inicialmente crear un tablero dándole un nombre y luego ir añadiendo cada una de las listas del tablero.

Trello también permite opciones de copiar definiciones de listas de otros tableros, para no tener que repetir todo el proceso.

Esta podría ser la apariencia de nuestro tablero

Ilustración 1Tablero con listas

Scrum. Historias de Usuario

6 de octubre de 2016admin

La comunicación

El proyecto software que un equipo de desarrollo va a realizar en la mayoría de los casos no responde a una idea suya sino más bien a las necesidades que alguien (los usuarios) tienen. Los usuarios deben indicar lo que quieren resolver a otra persona (en el modelo tradicional un analista), éste a su vez captura lo que él ha entendido como requisitos del usuario y describe en forma de análisis de requisitos o funcional u algún modelo similar, lo que él ha entendido. Ese trabajo acabará finalmente en unas indicaciones más o menos concretas para que el equipo de desarrollo finalmente implemente el proyecto.

Una de las mayores preocupaciones es que el analista que capta las peticiones del usuario, suele terminar transmitiéndolas en un documento de difícil compresión para éste. Así en general los completos documentos de análisis de una aplicación rara vez suelen ser entendidos por los usuarios, que en general suelen basarse en lo que ellos aseguran que dijeron más allá de lo que especifique el documento de análisis.

Además, otro de los problemas del modelo en cascada es que requiere de un análisis completo de los requerimientos para generar un documento completo antes de iniciar las posteriores fases de diseño y desarrollo.

Una alternativa a estos modelos es utilizar las Historias de Usuario, como mecanismo para ser mucho más ágil a la hora de captar los requisitos, así como acercar la definición final de los mismos al último momento que se pueda, para conseguir captar cualquier cambio en las ideas iniciales.

Según Mike Cohn, las Historias de Usuario describen la funcionalidad de algo que es valioso para un usuario de un sistema o software.

Las Historias de Usuario se componen de tres elementos:

Una descripción escrita de la historia usada para la planificación y como un recordatorio.
Conversaciones sobre la necesidad de la historia que sirven para profundizar en los detalles de la misma
Elementos de prueba que permiten determinar cuando las tareas que va a cubrir la historia está completa.

Así una historia debe permitir conocer la base de las necesidades del usuario, así como los detalles que después permitan fijar la batería de pruebas para poder determinar si un desarrollo es correcto o no.

Inicialmente se fijaba que esas historias de usuario se escribieran en unas tarjetas en vez de en una libreta, lo que hizo que Ron Jeffries lo llamara CCC Card, Conversation, Confirmation (Tarjeta, Conversación y Confirmación). Así la tarjeta almacenaba la historia del usuario, y a través de la Conversación y la confirmación. Hay autores que afirman que las tarjetas son la mejor forma de almacenar las Historias de Usuario.

Otro de los aspectos fundamentales es que la historia de usuario debe estar expresada en un lenguaje que el usuario pueda entender y que refleja una descripción sintetizada de lo que el usuario desea.

La descripción puede ser libre, aunque es generalmente el modelo propuesto por Mike Cohn es el aceptado. En él que se indican tres cosas, ¿Qué tipo de usuario es el que solicita? ¿Qué se quiere? ¿Por qué se quiere?

Un ejemplo de Historia de Usuario podría ser:

“Como responsable de almacén quiero conocer cuando se alcanza el stock mínimo para poder realizar más órdenes de compra.”

Atributos de las historias de usuario

Las Historias de Usuario son peticiones muy sencillas y claras que definen cuales van a ser los requisitos del proyecto. Es preferible tener un número mayor de historias simples que uno menor de historias más complejas.

Pero hay una serie de atributos mucho más concretos que las Historias de Usuario deberían cumplir. Bill Wake en su libro Programming Explored and Refactoring las denomina con el acrónimo INVEST que se basa en las iniciales de los seis atributos recomendables para las Historias de Usuario.

Independent
Negotiable
Valuable to users or customers
Estimatable
Small
Testable

A. Independendientes (Independent)

Es razonable evitar la existencia entre dependencias entre las historias, es decir historias que para estar finalizadas dependen de la finalización de otras. Esto añade un punto más de complejidad a la planificación de realización de tareas, obligando a estar muy pendiente de estar interrelaciones y definir una priorización en la realización de las mismas.

Imaginemos las Historias de Usuario a definir para que un cliente pueda realizar el pago con diferentes tarjetas de crédito:

Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard
Como Jefe de ventas quiero que mis clientes puedan pagar con American Express

Las tres historias están muy relacionadas, además el coste en horas de implementación de cada una de ellas es dependiente de las otras. Es decir el tiempo para construir la primera puede ser 4 horas y una vez realizada la primera, implementar las otras dos, tendrían un coste considerablemente menor. Existen dependencias entre las tres historias. La forma de evitarlas podría ser construir una historia que las englobe:

Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjetas Visa, Mastercard y American Express

Si las historias todavía tienen un tamaño elevado, se puede hacer una subdivisión, más equivalente cuanto a coste

Como Jefe de ventas quiero que mis clientes puedan pagar con Tarjeta Visa
Como Jefe de ventas quiero que mis clientes puedan pagar con MasterCard y AmericanExpress

Otra alternativa es que en la estimación de tiempo de cada historia se especifique el coste si se realiza antes o si se realiza después que otra (Aunque es un mecanismo algo complicado ya que añade un elemento más a los cálculos de costes).

B. Negotiable (Negociables)

Es una de las bases de la programación ágil, las Historias de Usuario no son unos requisitos cerrados que permiten cerrar un contrato que no se puedan cambiar. Una Historia de Usuario es una breve descripción de la funcionalidad que muchas veces se puede utilizar como un recordatorio. Los detalles de la historia se suelen retrasar hasta los últimos momentos para precisamente evitar cambios de última hora. Eso no impide que si en el momento de redactar la base de la historia, se conoce algún detalle se pueda anotar en la misma tarjeta toda la información que se conozca (aunque suele ser sensato contrastarla en el momento que sea necesario).

En este caso el cliente (el jefe de ventas) puede considerar en el momento de la entrevista que solo se admitan dos tarjetas aunque es razonable contemplar en la implementación que es posible que se incorporen más.

Si se dispone de más información del requisito es bueno tomar nota de él. El reverso de la tarjeta es un lugar ideal para acompañar detalles útiles en la implementación.

La tarjeta es un recordatorio, personalmente yo recomiendo apuntar detalles que generan duda o incertidumbres a contrastar directamente, hay que olvidar el famoso dicho de “no hace falta apuntarlo ya que ya lo recordaré”. Es bueno tomar nota, e incluso subrayar si es necesario realizar una consulta a otras personas. Estas pequeñas notas en el reverso pueden ayudar en la segunda entrevista al usuario.

C. Valuable (Con valor para el usuario)

Es uno de los aspectos más controvertidos sobre las Historias de Usuario. Hay quién indica que las historias deben aportar valor al usuario y por eso es razonable que el usuario las pida directamente. Yo considero que todas las historias que se implementen deben tener valor para el usuario aunque éste inicialmente no lo sepa.

El usuario debería estar seguro que todas las historias le aportan valor. En general, temas de seguridad a muchos niveles no les preocupan (no porque no lo consideren importante, sino porque a veces lo dan por hecho). Las Historias de Usuario deben aportar valor, en general se definen en base a peticiones del usuario, no obstante cabe la posibilidad de definir historias de usuario a partir de criterios técnicos por parte del equipo. Es estos casos es necesario que se explique correctamente al usuario los motivos de necesidad de estas.

D. Estimatable (Estimable)

El equipo de desarrollo debe poder estimar el coste (al menos aproximado) de desarrollar cada una de las Historias de Usuario. Es un requisito fundamental para poder planificar de manera razonable las historias que se pueden desarrollar dentro de un Sprint. La forma de medir el coste puede ser las horas de desarrollador o los puntos de historia (tratados en capítulos anteriores)

Es posible que el coste de una historia no pueda ser calculada con un nivel de precisión razonable, los motivos habituales por los que esto pueda ocurrir son

El equipo de desarrollo no conoce el dominio. Ya se comentará en el tema de la entrevista. Obviamente el equipo de desarrollo no puede pretender tener el mismo conocimiento que tiene el cliente del entorno de trabajo de éste. Aun así, es conveniente adquirir unas bases que permitan, en primer lugar dar confianza al cliente, y en segundo lugar abordar con el suficiente conocimiento los desarrollos a realizar.
El equipo de desarrollo no tiene conocimientos técnicos del entorno. También puede ocurrir que el equipo de desarrollo deba trabajar en un entorno de programación o base de datos novedoso (al menos para ellos) que puede hacer que estimen sin un nivel de confianza lo suficientemente alto. Es este caso se agradece la aportación de expertos en el entorno que pueden hacer ver las comparaciones de costes con entornos mejor conocidos por el equipo de desarrollo. Si no se dispone de ningún experto, es razonable que algunos miembros del equipo profundicen de manera rápida en el tema. Esta profundización debe contar como una historia más, ya que tiene su coste en horas.
La historia es demasiado compleja o tiene un tamaño muy grande. Este caso es el más sencillo de resolver, se debe dividir la historia en dos o más historias de menor tamaño que puedas ser estimadas con mejor precisión.

E. Small (Pequeña)

El concepto pequeña es muy relativo, pero entendemos como que la Historia de Usuario debe tener una duración que la haga lo suficiente manejable para el equipo. Pequeña no debe confundirse con microscópica, ya que tener un sinfín de cientos de historias microscópicas puede convertir en un infierno la planificación y la integración de todas en el proyecto final.

Es razonable que el equipo de desarrollo defina un coste razonable para las Historias de Usuario estándar con las que van a trabajar. Algunos hablan de semana/programador como el tiempo máximo, mientras otros equipos prefieren definir como un día/programador como un coste medio razonable.

Una historia que fuera como jefe de ventas quiero una “gestión web de las ventas para incrementarlas” tiene una dificultad considerable para ser estimada.

Debiera poder dividirse inicialmente en gestión de usuarios, de productos y en sí de la venta. Aun así cada una de ellas tiene una complejidad elevada. Es posible que la gestión de usuarios al ser bastante estándar pudiera (quizá no debiera) quedar como una historia.

Es más razonable definir historias del tipo:

Como jefe de ventas quiero poder dar de alta un producto para venta
Como jefe de ventas quiero poder modificar características de un producto o eliminarlo
Como jefe comercial quiero poder añadir campaña comerciales que afecten al precio de venta del producto

Un modelo de historias de este tipo es que permite de manera sencilla estimar el coste de cada historia e incluso permite que el cliente pueda priorizar entre las mismas. Así podemos iniciar una página de venta con productos y más adelante permitir la incorporación de campañas comerciales de diverso tipo.

La gestión de usuarios, bastante estandarizada puede ser considerada como una única historia de usuario más allá de historias del tipo:

Como jefe de ventas quiero poder dar de alta un usuario
Como jefe de ventas quiero poder modificar un usuario
Como jefe de ventas quiero poder dar de baja un usuario
Como jefe de ventas quiero poder consultar un usuario

Pero no hay que olvidar que el concepto de Small (pequeño) es muy dependiente de como el equipo de desarrollo se sienta cómodo. En sí lo que si debe garantizar al cien por cien es que toda historia de usuario debe ser estimable y deba tener un coste mínimo algo más alto que el tiempo que se pierda en hablar de ella.

F. Testable (Se puede validar)

Otro de los conceptos que hemos visto como un tema fundamental es el de terminado. Una historia debe tener unos objetivos claros, y deben ser tan claros que deba ser posible comprobar que el trabajo ha cumplido las expectativas, es decir que se pueda validar el trabajo realizado.

Otro de los objetivos es que el mayor número de historias se pueda validar de forma automática, por lo que es muy interesante utilizar conjuntos de aplicaciones de prueba que así lo permitan. En ocasiones, esto es complicado, pero hay que definir claramente una batería de pruebas que pueda ser realizada para verificar lo correcto de un programa o módulo. El coste de realizar las pruebas se debe incluir en el coste de la historia de usuario, a menos que haya alguna historia que tenga como objetivo la realización de una serie de pruebas de conjunto.

Sólo los requisitos no funcionales como pueda ser “conseguir un Interfaz amigable o facilidad de uso para usuario novel” pueden evitar la definición de esas baterías de prueba. No obstante se pueden definir tareas más complejas que exceden al equipo de desarrollo y que permitan hacer una estimación del grado de resolución de algunos requisitos no funcionales.

Conclusiones

Las Historias de Usuario son una forma de acercar el lenguaje del usuario al desarrollador, de forma que se permita hablar un mismo lenguaje ambos y se eviten ambigüedades que puedan suponer pérdidas de tiempo notables.

Lo importante de las historias es que reflejen de forma sencilla lo que el usuario quiere, “El qué” y no “el cómo”. Es importante que sean muy claras y con criterios de validación muy concretos. Durante el proceso, las historias pasarán a ser grandes trabajos a realizar muy generalmente especificados, hasta ser tareas concretamente detalladas, pero es un proceso por fases, que permite detallar la tarea junto con el cliente cuando se van a implementar.

Trello (y II) Gestionando Equipos conTrello

6 de octubre de 2016admin

Los roles de los equipos ágiles

No hay metodología ni modelo de desarrollo, por bueno que sea que sustituya a lo más importante que es el equipo de personas que van a desarrollar el producto. En cualquier entorno de cierta complejidad el equipo es fundamental. Es prácticamente imprescindible que el equipo funcione bien para que el desarrollo tenga un final feliz.

Un equipo trello está formado por todas aquellas personas que tienen que ver con el desarrollo de una tarea, tanto de forma activo como aquellos que deben estar informados del grado de cumplimiento del desarrollo de la misma. Las metodologías ágiles como SCRUM incorporan una serie de roles que definen las acciones que deben o pueden realizar cada uno de ellos

Scrum aporta una serie de aspectos que potencian el grupo, que potencian el trabajo en equipo, porque todo es importante en un desarrollo software, pero no tanto como la gestión de las personas.

En los desarrollos software se identifican una serie de roles que son los responsables de que determinadas tareas se realicen. Las propuestas de Scrum al respecto de la organización del equipo varían en la definición de unos nuevos roles y un nuevo comportamiento entre ellos.

Tradicionalmente habremos escuchado los roles de Project manager, Program Manager, jefe de Desarrollo, gestor de Calidad, responsable de pruebas y gestor de versiones entre otros. Cada uno tiene sus responsabilidades muy específicas dentro del equipo.

Scrum hace una primera división (muy curiosa) de los miembros del equipo en base a su implicación con respecto al proyecto, y lo hace con un chiste sobre las ansias emprendedoras de un cerdo y una gallina, cuenta lo siguiente

Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice, “Oye, ¿por qué no abrimos un restaurante?” El cerdo mira a la gallina y le dice, “Buena idea, ¿cómo se llamaría el restaurante?” La gallina piensa un poco y contesta, “¿Por qué no lo llamamos “Huevos con jamón?” “Lo siento pero no”, dice el cerdo, “Yo estaría comprometido pero tú solamente estarías involucrada”.

Ilustración 1 Filetes de cerdo y huevo frito

La diferencia de compromiso es obvia, mientras en el plato de filetes de cerdo y huevos fritos, el cerdo pone su vida, la gallina se limita a poner huevos. Así en SCRUM tenemos equipos (SCRUM team) formados por cerdos y gallinas, o sea implicados e interesados, todos son tienen su importancia en el proyecto pero no la misma.

Dentro de los cerdos o implicados tenemos:

Product Owner
Scrum Master
Development Team

Dentro de las gallinas o interesados tenemos

Stakeholders (Interesados)

El Product Owner (el Dueño del producto)

El sueño de todo analista y/o desarrollador es tener al cliente disponible las 24 horas del día para que le pueda solucionar cualquiera de las dudas que surgen durante el proceso de análisis y desarrollo. Obviamente cuando hablo del cliente me refiero al responsable de la aplicación, no al responsable del equipo de desarrollo. Este es el Product Owner, la persona responsable de fijar que es lo que es el producto, cuales son las partes que lo van a formar e incluso fijar las prioridades dentro de la Lista de Producto (se verá más adelante).

Es importante destacar que siempre el Product Owner es una única persona, es la persona que asume la responsabilidad de determinar qué es ese producto, aunque obviamente pueda tener que hacer las consultas correspondientes a otras personas. Es decir, si es un comité el que decide los requerimientos de un producto, el interlocutor del comité respecto al resto del equipo es el Product Owner. La importante ventaja de este modelo es que se aísla al equipo de desarrollo de los pensamientos de cada uno de los miembros de un comité, pero por otro lado hace recaer todo el peso de la responsabilidad en el Product Owner.

En realidad el Product Owner realmente puede ser un miembro de la empresa que solicita el producto o puede ser alguien de la empresa de desarrollo que haga de interfaz con el cliente. En cualquier caso es la persona responsable de fijar los requerimientos del producto. Debe estar accesible por parte del Scrum Team en (casi) cualquier momento y debe formar parte activa de las reuniones en los que su presencia es requerida.

Entre otras sus tareas son:

Conseguir maximizar el valor del producto y del trabajo del Scrum Team. O sea maximizar especificaciones del producto al menor coste en número de horas del Scrum Team.
Conocer y validar los requerimientos del producto.
Asegurarse que los miembros del Scrum Team le han entendido perfectamente.
Marcar las prioridades y orden en el que los diferentes componentes del producto deben ser implementados.
Hacerse respetar. Si la organización no respeta el criterio del Product Owner los anteriores ítems carecen de sentido, e incluso si perdiera la confianza del Scrum Team sobre la importancia de su criterio, inevitablemente dificultaría las posibilidades de éxito del desarrollo.
Ante cualquier duda que surja en el equipo es el que actúa como árbitro.

Además se debe cumplir una máxima “Ninguna otra persona que sea el Product Owner puede modificar o añadir requerimientos al producto, el Scrum Team solo puede desarrollar en base al criterio fijado por el Product Owner”.

Scrum Master

Tenemos un equipo preparado (Scrum Team), tenemos al Product Owner que fija objetivos (controla costes) y solo falta el miembro del equipo que debe conseguir organizar al equipo para poder cumplir los objetivos fijados, este es el Scrum Master.

El Scrum Master es el responsable de que el equipo pueda trabajar según las reglas Scrum y también es el responsable de que así sea. Esto debe conseguirlo fundamentalmente:

Favoreciendo la auto-organización del equipo impidiendo interferencias y/o distracciones externas.
Resuelve problemas e impedimentos que puedan surgir (ya sean informáticos o de intendencia).
Debe mantener visibles los artefactos Scrum (más adelante comentaremos lo que son)
En cierta forma es el líder del equipo, lo que no implica la autoridad sobre el resto de miembros del equipo. Aunque inevitablemente el concepto de líder conlleva cierta autoridad sobre el resto.
Es el responsable de definir (o aplicar) los Timeboxes o límites de tiempo máximos para determinadas tareas.
Debe gestionar la Lista de Producto (lista de tareas que engloba un proyecto) de manera efectiva cumpliendo las peticiones del Product Owner, por ello debe ser capaz de hacerle entender la mejor forma de priorizar tareas.
Es el máximo responsable de que todos los eventos Scrum se realicen en tiempo y forma.
Debe conseguir que la lista de Producto sea clara y no tenga ningún tipo de ambigüedad.
Debe ser capaz de explicar el modelo Scrum al resto de la organización, haciéndole ver sus ventajas.
Y por supuesto, debe motivar al equipo, facilitando que consiga sus metas.

Development Team o equipo de desarrollo

El Equipo de Desarrollo está formado por un grupo de profesionales responsables en último plazo de diseñar e implementar el producto a realizar. Son los que llevan el peso de la realización de todos y cada uno de los Sprints, son los responsables de que el trabajo que realizan se pueda poner en producción.

La estructura del equipo de desarrollo les permite organizar y gestionar su propio trabajo. Esto rompe el esquema tradicional en el que cada uno de los miembros del equipo recibía por parte de un superior las órdenes concretas que determinaban el desarrollo que debía realizar. Las características principales que los definen son:

Los equipos son autoorganizados y son dirigidos desde el mismo equipo.
Los equipos son multifuncionales, es decir tiene miembros con diferentes habilidades desde desarrollo puro a testing e incluso análisis.
El equipo es autónomo, no dependen de nadie externo al equipo a la hora de tomar decisiones (algo a veces difícil de asumir). Es el mismo equipo el que toma las decisiones que afectan al proyecto que están desarrollando.
Se basa en el trabajo colaborativo. Es fundamental el trabajo en equipo abandonando el concepto de francotirador solitario.
Funciona mejor si físicamente se halla en el mismo lugar, lo que favorece además de las relaciones personales, ayudas puntuales y el propio seguimiento del proyecto.
Lo ideal es que los equipos Scrum se mantengan en el tiempo, en varios proyectos, lo que contribuye al conocimiento profesional y personal de los miembros del equipo.
Scrum no reconoce títulos para los miembros de un equipo de desarrollo, todos son desarrolladores, independientemente del trabajo que realice cada persona. No hay excepciones a esta regla.
Cada miembro del equipo puede estar especializado o destacar en algún tema en concreto, pero siempre la responsabilidad recae sobre todo el equipo como un todo.
No se deben definir sub-equipos de desarrollo especializados en alguna tarea, no hay excepciones a esta regla. Por ejemplo definir el equipo de análisis o de pruebas.
Los tamaños de equipo no deberían superar las 9/10 personas y quizá tengan poco sentido con menos de 4/5 personas.
Es ideal que todos los miembros del equipo tengan habilidades transversales imprescindibles en el desarrollo de proyectos informáticos (análisis, diseño, desarrollo, pruebas, documentación, etc).

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Se refiere a la gente que hace posible el proyecto en el sentido de la financiación o solicitud así como aquellos para quienes el proyecto producirá el beneficio acordado (usuarios de la aplicación). Solo participan directamente durante las revisiones del producto que va finalizando el equipo de desarrollo.

Creando el equipo Trello

En la esquina superior derecha, justo al lado de nuestra foto aparece un signo “+” que nos permite acceder a una serie de opciones. Una de ellas es la creación de equipos. Si la seleccionamos nos pedirá el nombre del equipo y una pequeña descripción del mismo.

Ilustración 2 Menú de opciones

Ilustración 3 Dando de alta el equipo

Como no podía ser de otra manera, el equipo podemos configurar los aspectos gráficos de la foto que lo ilustre, así como lo importante de indicar las personas que forman parte de él. Para ello de vemos o bien introducir su nombre o (si no están dados de alta en trello) realizar una invitación a su correo para que así lo hagan.

Cada vez que se incorpora a un nuevo usuario al equipo, éste recibe un correo en el que se le informa de tal acción. Un usuario puede abandonar un equipo siempre que lo desee.

Todos los usuarios pueden actuar como usuario administrador o usuario normal. El primero es el único que puede gestionar los cambios en el equipo.

Ilustración 4 Equipo Trello

Ya tenemos el equipo, ahora ya sólo toca empezar a trabajar. 3, 2 1, ya¡¡

Errol Sánchez y la Brigada Ligera

3 de octubre de 2016admin

(Publicado en el Diario La verdad el 02/10/2016)

El mayor inglés Geoffrey Vickers (en la realidad, Lord Cardigan) se entera de que el malvado Emir Surta Khan se halla junto a las tropas rusas en Balaclava. El Emir había propiciado poco tiempo antes una espantosa masacre, la que según el mayor debía ser vengada a toda costa. Por ello, lanza a su brigada de caballería a una carga suicida a la caza del Emir a través del, como reza un famoso poema, “El valle de la Muerte” hacia las pertrechadas baterías rusas. Es la batalla de Balaclava, que se popularizó por el susodicho poema, que los niños ingleses estaban obligados a recitar. También por la película que dirigió Michael Curtiz en 1936 y que protagonizaron la famosa pareja Errol Flyn y Olivia de Havilland

Ante la carga, Flynn duda entre esperar las ordenes de sus superiores o poder cazar al Emir. Como no podía ser de otra manera, convence a su regimiento a iniciar una carga de caballería, que por mucho poema y película que se hiciera, acabó en la realidad como un completo desastre.

Pedro Sánchez emula a Errol Flynn pero en Ferraz, obviamente al que él considera como malvado emir se apellida Rajoy y se llama Mariano. Eso sí, Sánchez no dice claramente si su alternativa es un gobierno con Podemos, Esquerra Repúblicana, Bildu y demás tropa independentista o unas terceras elecciones. Como el mayor Vickers, su único mensaje es el del “No a Rajoy”. Pero en la gestión de las cosas, no vale decir que acciones son las que no quieres tomar, sino cuál es tu mejor alternativa a ejecutar.

Gracias a Pedro Sánchez, el PSOE se encuentra como la brigada ligera en mitad de la carga suicida rumbo a unas baterías rusas modernas, que bien podrían ser el Partido Popular, con Rajoy al mando esperando que se acerquen un poco más para dar la orden de disparar y masacrarlos totalmente.

Pablo Iglesias ahora mismo no podrá dar crédito a lo que está pasando. Justo cuando pasaba sus peores momentos y su promesa de liquidar al PSOE se desvanecía, Pedro Sánchez y los barones críticos le han echado un cable en forma de tiro al pie propio.

El final de Vickers con su brigada ni le permitió ver la película ni leer el poema que escribieron en su honor. Sánchez sí que puede estar orgulloso de que el hashtag #YoConPedro se repite entre los tuits de muchos militantes. De hecho, parece que hasta se han planteado autobuses de apoyo desde el Partido Socialista Catalán, para muchos un partido independentista más.

Habrá que estar atentos como acaba esto, aunque es probable que como el poema sobre la carga, que pasó de ser de obligado aprendizaje de los niños ingleses a olvidado, cuando detectaron públicamente que aquello más que una gesta heroica fue un craso error. Con las técnicas actuales el olvido es más complicado, ya hay socialistas que han iniciado el proceso de hacer capturas de pantalla de los tuits #yoConPedro o los que le atacan, para que nadie pueda pasar de bando simplemente borrando el tuit.

El último liberal

Mes: octubre 2016