Archives

En un mundo IT las arquitecturas basadas en servicios (SOA), cada vez tienen más relevancia. Se vuelve imprescindible para toda organización enfocada en el desarrollo de software, contar con una definición precisa y contundente de Service Level Agreement (SLA).

Un SLA es parte del contrato entre el consumidor de un servicio y quien lo provee y formalmente define el nivel del servicio, involucrando cuestiones como disponibilidad, performance y seguridad. Luego, dentro de un sistema basado fuertemente en SOA, donde los arquitectos y equipo desarrollador construyen su solución de software a partir de integrar y combinar distintos servicios, no contar con un SLA detallado y certero lleva irremediablemente al fracaso.

El Software Engineering Institute (SEI) [1] es un prestigioso centro de investigación y desarrollo enfocado en técnicas y herramientas para la Ingeniería de Software, y sus reportes tienen siempre un gran impacto en la comunidad. Uno de ellos [2] se aboca exclusivamente a analizar el rol de los SLA en arquitecturas SOA. A continuación se exponen los principales puntos de este reporte, presentando en primer lugar los lineamientos generales de los SLA y finalizando con la mención de algunas de las herramientas más utilizadas para el monitoreo y administración de los SLA.

SLA: Fundamentos

La importancia de los SLA es ampliamente reconocida. La organización TeleManagement (TM) Forum en su texto sobre SLA [3] profundiza estas razones: “un SLA define la disponibilidad, confiabilidad y performance de las comunicaciones entre servicios y canales de transmisión, al mismo tiempo que asegura que la información llega a la persona indicada, en el lugar y hora indicada.

Algunas de las razones por las que una organización debería definir SLAs para sus servicios son:

1 . Los servicios con SLA claros estarán en mejor estado para competir con otros en un mercado sobrecargado de servicios.

2. Su especificación permite establecer mejores conexiones con las metas de negocio, especialmente donde se entrecruzan distintas áreas de una organización, o incluso participan más de una organización.

3. Se refuerza el concepto de compromiso y calidad.

4. Permite monitorear y validar la calidad de los servicios.

5. Brinda mayor proyección a futuro: sobrevivirán aquellos servicios con reglas claras de uso. Esto permite por ejemplo, ofrecer distinta calidad de SLA a distintos actores. Por ejemplo, 1000 transacciones por segundo a usuarios VIP y 650 por segundo a usuarios estándar.

Ya establecido el marco necesario de un SLA se describe a continuación su aplicación dentro de arquitecturas SOA.
SLA en arquitecturas SOA

En una arquitectura SOA actual es común la integración con servicios externos con grandes compañías como Amazon, StrikeIron o Ebay. Se trabaja en un entorno hiperconectado en donde asegurar la calidad de los servicios prestados es un gran desafío. Esto se debe fundamentalmente a que Internet como fuente de comunicación es altamente dinámica e impredecible, en especial por los siguientes aspectos:

● Escasa presencia de protocolos estandarizados de comunicación.
● Vulnerabilidad a ataques de seguridad.
● Fallas de infraestructura, como la ocurrida con el daño de un cable subterráneo que detuvo toda actividad por días en el este europeo, África y Asia en 2008 [4].

Un SLA es crucial para asegurar la calidad del servicio brindado. Cuando es debidamente negociado y documentado es de gran utilidad al arquitecto SOA para testear y poner en producción nuevos servicios. Para lograr este efecto se debe proveer suficiente información o métricas validables para los consumidores del servicio para poder pre-seleccionarlos basados en los estándares de calidad deseados. Esta información le permite entonces al arquitecto no desperdiciar tiempo y recursos evaluando servicios que no se adaptarán a las necesidades del proyecto.
Las métricas más comunes para definir SLA en arquitectura SOA son la latencia, el número máximo de transacciones por minuto, el costo por invocación y el porcentaje de tiempo disponible del servicio (por ejemplo: 99% de tiempo disponible).

Expresar y monitorear SLA

Si bien para escribir SLAs suele utilizarse habitualmente texto en lenguaje natural utilizando "templates", existen tambien diversos estándares tales como Web Service Level Agreement (WSLA) language y WS-Policy que son utilizados por servicios web en ambientes SOA. Estos estándares son impulsados por companias como IBM, Oracle, Microsoft, SAP, Sonic y VeriSign.

Por otro lado la tendencia indica que es cada vez mayor el uso de herramientas para definir y monitorear SLA. A continuación se introduce una tabla con algunas de las herramientas más utilizadas, y una breve comparación de sus características:

Referencias:

[1] http://www.sei.cmu.edu/

[2] http://www.sei.cmu.edu/reports/08tn021.pdf

[3] http://www.afutt.org/Qostic/qostic1/SLA-DI-USG-TMF-060091-SLA_TMForum.pdf

[4] BBC News. Severed Cables Disrupt Internet (2008).

Decidí convertirme en un diseñador para hacer cosas que mejoren la vida de las personas. Tengo la creencia de que los pequeños detalles tienen gran valor, traen un significado profundo, y hacen una gran diferencia en nuestras vidas. Este es el poder del diseño. Los estilos pueden entretener, pero sin la verdadera empatía y conexión con el sentido humano, eventualmente pasan de moda. Es por este motivo que odiaba la publicidad y el mundo del marketing.

Sin embargo, en los últimos años las líneas se han vuelto más borrosas. Los mundos de la publicidad y el diseño de productos están convergiendo. Los CMO (Chief Marketing Officer) están invirtiendo más en tecnología que los CTO (Chief Technical Officer). La web es más importante que la televisión, los productos y servicios digitales son clave para la comunicación y el engagement con los clientes. Las conversaciones entre marcas y consumidores ahora se realizan de manera directa y los resultados se miden por la interacción en lugar de por el número de impresiones.

Nike, que asignó un presupuesto anual récord de 2,4 mil millones de dólares para su estrategia de marketing en el año 2011, decidió recortar su inversión en TV y avisos impresos en un 40% en los 3 años subsiguientes.

Esto demuestra que Nike se dirige hacia donde está el consumidor, invirtiendo casi 800 millones en publicidad no tradicional. Sistemáticamente, las encuestas marcan esta progresión, en que más de la mitad de los marketers planean aumentar su presupuesto digital, y que una gran parte de ellos planea relocalizar los esfuerzos tradicionales.

Este es un cambio permanente y no una moda pasajera. Hemos entrado en un nuevo mundo, en el que los productos y servicios deben entregar valor real mientras se mezclan con una multitud de dispositivos digitales y una red de diversas marcas y plataformas. El requerimiento básico de lograr una conexión humana y de generar sentido se mantiene. Sin este último punto, todo lo demás se cae.

Sinergias potenciales

El buen marketing se guía ahora por un excelente producto digital y una gran experiencia de servicio. Estos dos se encargan de comunicar la historia de la marca y también el valor de la misma. El producto es el marketing, y el marketing es el producto. Al final del día, si la experiencia de un producto es poco satisfactoria los consumidores lo sabrán, y se lo comentarán a sus círculos de contactos. Una compañía puede decir lo que quiera en una campaña publicitaria, pero lo que importa realmente es el valor de lo que produce. Los grandes productos posibilitan el gran marketing y viceversa. Este cambio ha traído importantes implicancias en la manera en que enfocamos nuestro trabajo.

Este cambio desafía a la manera en que las marcas se relacionan con sus consumidores y también modifica sus planes de negocios. Desafía al departamento de marketing y de producto a trabajar más en conjunto. Desafía a las agencias de publicidad para lograr esa preciada conexión con el cliente. Desafía a los diseñadores de interfaz, que ahora deben trabajar de manera integrada con el resto de la compañía.

Soy un diseñador con una mente práctica y orientada al producto, por lo que he tenido que resolver mis propios prejuicios y preconceptos hacia el marketing y el branding. A través de este lente, tengo una apreciación más profunda por las historias y el rol de las marcas. Puedo ver cómo una marca puede convertirse en la inspiración para nuevos conceptos y productos, además de orientar los detalles de la experiencia de usuario. La realidad es que existe un potencial para una sinergia entre los diseñadores y los marketers, que pueden amplificar su trabajo en conjunto. El marketer debe aprender a llegar directamente a sus usuarios y el diseñador debe preocuparse por generar experiencias con sentido para aquellos.

Los diseñadores de los campos de la interacción, usabilidad y UX deben abrir sus mentes a la colaboración con otras áreas. De hecho, creo que esto es indispensable si deseamos mantenernos relevantes en la nueva realidad del mundo de los negocios.

La creciente demanda de arquitecturas basadas en servicios (SOA) ha generado el desarrollo de técnicas para modelar y especificar las reglas de negocio que dirigen el comportamiento del sistema. En este sentido, al introducir una arquitectura SOA, una definición completa y apropiada de los procesos de negocio, pasa a jugar un rol fundamental. En pocas palabras, un proceso de negocio puede ser visto como una secuencia bien definida de actividades para lograr un objetivo de negocio en particular.

BPM (Business Process Management) se ha destacado como técnica para modelar y especificar dichos procesos de negocio. De manera similar, lenguajes y herramientas como BPMN (Business Process Model and Notation) y BPEL (Business Process Execution Language) se han impuesto a la hora de llevar adelante una arquitectura SOA con procesos de negocio bien definidos.

Sin embargo, desde la comunidad inmersa en el desarrollo de software se ha detectado un problema relacionado con la especificación de requerimientos no funcionales. Tales requerimientos como disponibilidad, performance, seguridad o modificabilidad, cuyo comportamiento es clave y define el éxito o fracaso de una arquitectura SOA, no son correctamente especificados en BPM. Esto tiene como consecuencia que no son agregados de manera apropiada en la especificación de los procesos de negocio, con la consecuente amenaza para una arquitectura SOA que esté guiada por dichos procesos.

Diferentes propuestas han surgido para aliviar este problema [1,2]. A continuación se describen los principales aspectos de las mismas, cuyo principal objetivo es la incorporación de requerimientos no funcionales en la descripción de procesos BPM de negocio en una arquitectura SOA.

Agregando requerimientos no funcionales a BPM

La primera de las propuestas los incorpora utilizando los mecanismos usuales de BPM a través de un tipo especial de anotaciones, mientras que la segunda define artefactos nuevos para su modelado. A continuación se describen cada una de las propuestas.

Requerimientos no funcionales a través de anotaciones

La propuesta presentada en [1] consiste en agregar los requerimientos no funcionales como anotaciones a las actividades que describen un proceso de negocio. Tales anotaciones se denominan “Artefactos QoS” (Quality of Service). A través de las mismas se pueden introducir cuestiones de disponibilidad (por ejemplo, una actividad que necesite estar disponible todo el tiempo), de seguridad (por ejemplo, una actividad donde se necesite protección y confidencialidad de datos), de performance (especificar el tiempo máximo que puede llevar una actividad). La siguiente figura esquematiza la propuesta, ilustrando la especificación de un requerimiento de performance.

Figura: Anotando requerimientos no funcionales como anotaciones

Finalmente, estos artefactos QoS son codificados utilizando el estándar WS-Policy [3], que permite introducir restricciones al comportamiento de los servicios en un formato XML. Para el ejemplo de la figura la restricción a introducir sería:

<Performance max_runtime_minutes="15"/>.

Dado este panorama los requerimientos no funcionales pueden implementarse luego en algunas de las herramientas BPEL disponibles, comoestas, oestas otras. Luego, de esta manera sencilla pueden especificarse requerimientos no funcionales a los diagramas BPM.

Requerimientos no funcionales con nuevos constructores

La propuesta en [2] ataca el problema de manera diferente. En vez de utilizar anotaciones, considera artefactos más complejos para darle más valor al requerimiento no funcional. La desventaja es que se debe conseguir una nueva herramienta que implemente y traslade los conocimientos propuestos para su utilización comercial.

La técnica propone acompañar la descripción de una actividad BPM con dos nuevos términos: Condiciones de Operación, y Control. Las condiciones de control establecen de manera declarativa las condiciones necesarias para desarrollar la actividad, ya sean de seguridad, performance, o cualquier otro requerimiento no funcional. La parte de control captura los riesgos de negocio asociados con la condición de operación, y los controles de negocio a realizar para mitigar el riesgo. Uno de los ejemplos presentados en [2] ataca el requerimiento no funcional de seguridad dentro del contexto de un cajero automático (pero es trasladable fácilmente a otro dominio). La actividad de calcular el saldo de una cuenta opera bajos ciertas condiciones de operación y control. Las condiciones de control simplemente establecen simplemente que deben manejarse datos con confidencialidad e integridad, ya que se tratan de datos sensibles. La parte de control puede detallarse con la siguiente tabla:

Conclusiones

Se han presentado dos técnicas para agregar requerimientos no funcionales a BPM. La primera, no introduce nuevos términos, pero tiene un alcance más limitado. El segundo enfoque es más poderoso, pero requiere de nuevas herramientas que implementen los artefactos correspondientes. Un enfoque razonable consiste de utilizar primero la opción más simple, y en el caso de necesitar mayor poder expresivo volcarse a la segunda opción.

Referencias

[1]Oliver Charles -Bernhard Hollunder ICSEA 2011: The Sixth International Conference on Software Engineering Advances.

[2]Christopher J. Pavlovski and Joe Zou. 2008. Non-functional requirements in business process modeling. In Proceedings of the fifth Asia-Pacific conference on Conceptual Modelling - Volume 79 (APCCM '08), Annika Hinze and Markus Kirchberg (Eds.), Vol. 79. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 103-112.

[3]W3C, Web Services Policy 1.5 (09/2007) – Framework, Retrieved April 03, 2011.

Imagen: Alexandra Cavoulacos (Flickr bajo licencia CCommons)

Impact Mapping es una novedosa técnica de planificación y estrategia creada por Gojko Adzic, un reconocido consultor en Ingeniería de Software. Adzic es, además, autor de numerosos libros sobre metodologías, especificaciones y testing, entre otras áreas. Esta técnica tuvo una gran repercusión en la comunidad Agile, con especial aplicación en la iteración 0 de los proyectos o bien antes de su inicio.

Es una herramienta fundamental que permite, además, generar la versión inical de un Product Backlog.

En octubre de 2013 dio una charla como orador invitado en la quinta conferencia Agile Tour [1], conferencia que reúne a especialistas en el tema de metodologías ágiles. En la misma motivó el uso de Impact Mapping para mejorar la utilización de técnicas ágiles en el desarrollo de software. A continuación se presentan sus principales lineamientos, para luego exponer su impacto dentro del universo ágil.

Impact Mapping: ¿qué es y para qué sirve?

Impact Mapping es una metodología que propone concentrar esfuerzos en lo realmente importante, en hacer las preguntas correctas para lograr determinar con precisión qué es aquello que debe conseguirse para lograr las metas deseadas. Concentrar esfuerzos para ocupar la mente en aquello crucial, ignorando detalles superfluos. Hacer las preguntas correctas para detectar qué es necesario conseguir y cómo, para satisfacer las metas a alcanzar. Todo se combina, luego, a través de una visualización muy simple y efectiva de la información que permite realizar un análisis adecuado. Cuatro preguntas conducen la técnica:

1. ¿Por qué?
2. ¿Quién?
3. ¿Cómo?
4. ¿Qué?

Lo primero es responder por qué se está haciendo esto. Es la meta principal a conseguir. En las metodologías ágiles, se corresponde con el objetivo de negocio que persigue un determinado proyecto.

Luego, se debe responder quién puede lograr el efecto deseado, quién lo puede obstruir, quién se verá beneficiado (es decir, el conjunto completo de los stakeholders). A continuación, se responde cómo ayudarán los actores identificados en el punto anterior a lograr las metas, cómo impactará su comportamiento una vez logrado el objetivo. Finalmente, se responde qué puede hacer la organización o empresa para apoyar y consolidar los cambios necesarios para lograr la meta deseada. Toda esta información se estructura visualmente con un estilo de árbol y ramificaciones, tal como lo ilustra la Figura 1.

Impact Mapping en metodologías ágiles

Impact mapping puede tener un gran impacto positivo en las metodologías ágiles. En la mencionada conferencia, el autor de Impact Mapping expuso las principales razones, y la manera de adaptarla para ser utilizada ágilmente.

El principal aporte de Impact Mapping es que introduce un nuevo ciclo de feedback en las metodologías ágiles. Tal feedback es provisto desde un punto de vista de proceso, a través de gerentes, personal de marketing, y otros stakeholders de alto nivel en la organización. Sin este ciclo, una vez determinado el backlog de stories, la metodología ágil puede convertirse fácilmente en un proceso lineal, donde se termina un sprint, se eligen nuevas stories, se desarrollan, se eligen otras, y así hasta terminar el backlog.

¿Pero si este camino no fue el correcto? Si bien el usuario y Product Owner están involucrados en el proceso, hacer siempre todo lo que el cliente desea sin espíritu crítico, o sin hacer las preguntas adecuadas, puede llevar el producto al fracaso en muchos casos. En muchos otros, puede significar una gran cantidad de requerimientos para el Product Owner. Aquí, la técnica permite entender en etapas tempranas, que es lo que impactará más en el negocio, para poder realizar un Release Plan que maximice el valor de negocio en cada entrega.

Una visualización del estilo Impact Mapping permite introducir variaciones dentro del plan a seguir, evitando el temido “efecto lineal”. Tales variaciones permiten probar alternativas en escenarios manejables, donde esté permitido fallar para tomar otras opciones. Imaginemos que al terminar uno o dos sprints ya es posible validar que un camino elegido no funcionará. Tener planeadas otras alternativas permite girar a tiempo hacia nuevas propuestas. Poder evaluar tempranamente una opción, y elegir otro camino si fuera necesario es el decisivo nuevo ciclo de feedback que agrega Impact Mapping en el mundo ágil. La mejor manera de ver cómo es posible esto es a través del ejemplo expuesto en dicha conferencia [1].

En la práctica

Una organización IT recibió un nuevo proyecto. Un instituto educativo quería  desarrollar un sistema que permitiera la comunicación entre los alumnos, docentes y padres. Así descrito es un objetivo demasiado general, por lo que la utilización de Impact Mapping ayudó a clarificar requerimientos, facilitando así la generación del Product Backlog y del sprint inicial. Tras responder la pregunta “porqué estamos haciendo esto” quedó definido explícitamente el objetivo de negocio: generar un vínculo de comunicación entre los miembros de la comunidad educativa. En la  ronda del “quién” quedaron establecidos los jugadores: los directivos de la institución, los docentes, y también padres y alumnos. Para la parte del “cómo” se diseñaron estrategias para ver cómo cada uno de los involucrados  podía lograr el objetivo.  El mayor peso quedó del lado de los alumnos: que se involucren en el sistema era fundamental para el éxito del proyecto, ya que todas las principales vías de comunicación pasaban por ellos.

Esta conclusión permitió concentrar el foco del sistema a desarrollar en la participación de los alumnos. Este hecho resultó fundamental por varias razones. Primero, se decidió implementar una aplicación para teléfonos inteligentes, y no un sistema web u otro tipo de comunicación. La mayoría de los alumnos basa su interacción virtual en sus teléfonos, casi ignorando el clásico correo electrónico así como la navegación web tradicional. Segundo, ayudó a delinear el Product Backlog y el sprint inicial. Dado que se iba a utilizar una aplicación sobre teléfonos, se priorizó las User Stories relacionadas con la creación y usabilidad de la interfaz del usuario. Esto permitió tener rápidamente un prototipo para testear la funcionalidad de las pantallas de la aplicación.

Conclusiones

Impact Mapping introduce un nuevo ciclo de feedback en las metodologías ágiles. Fuerza a plantear de antemano varias alternativas para lograr la meta final, para así tener la posibilidad de cambiar a tiempo, y evitar caer en la trampa de una metodología. Permite también analizar qué es lo que otorga más valor al negocio, en función del impacto que se quiere obtener, y alinear el desarrollo en función de este aspecto.

En el ejemplo presentado, la utilización de la técnica ayudó a seleccionar la tecnología adecuada y fue particularmente útil para priorizar el primer release plan.

Cuando todos tienen claro para qué y porqué se está llevando adelante cada tarea, se deja de producir software por el simple hecho de producir, para lograr cambios reales con impacto nítido y comprobable en el negocio.

Referencias:

[1]http://www.infoq.com/presentations/keynote-agile-toronto-2013

La informalidad y uso del lenguaje natural para la captura de requerimientos a través de User Stories (US) no debe confundirse con un proceso laxo o ambiguo de desarrollo de software. Por el contrario, tal lenguaje acerca al usuario y cliente como acompañante del proceso en vez de posicionarlo únicamente bajo el rol de negociar un contrato. Este espíritu es uno de los puntos destacados del manifiesto ágil [1]. Si bien esto está claro para la redacción de US, muchas veces es dejado de lado al momento de especificar uno de los componentes fundamentales de una US: sus criterios de aceptación. Dichos criterios definirán si una cierta funcionalidad cumple sus objetivos o no, y como tal, es fundamental que sean redactados de manera clara, concisa, y sin subestimar su impacto. Siempre debe tenerse en cuenta que se debe abarcar los distintos escenarios de negocio, desde el principal pasando por las distintas alternativas y excepciones que puedan existir dentro del requerimiento. A continuación se describen consejos y heurísticas para la correcta especificación de criterios de aceptación que tienen respaldo y consenso dentro de referentes de la comunidad ágil comoRon Jeffries, uno de los fundadores de eXtreme Programming.

Criterios de Aceptación: definición y su rol dentro de las metodologías ágiles

Microsoft Press define a los criterios de aceptación como “las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o stakeholder. Para Google, son estándares pre-establecidos o requerimiento que un producto o proyecto debe satisfacer. Concretamente y yendo al mundo de las metodologías ágiles, en [2] se los define como un conjunto de sentencias redactadas de tal manera que conduzcan a una respuesta clara de “aceptado/rechazado”. Deben especificar tanto requerimientos funcionales como no funcionales. Un hecho importante es que una US bajo un dado criterio de aceptación, es un comportamiento binario: lo cumple o no lo cumple. No existe el concepto de cumplir parcialmente un criterio de aceptación. Este es, quizás, el aspecto a prestarle mayor atención al momento de especificar un criterio de aceptación: si bien son expresados mediante lenguaje natural deben ser “testeables”, es decir, conducir a una respuesta clara de funcionalidad aceptada o rechazada. Una buena heurística para ver si esto último se cumple es verificar que sea posible construir un caso de prueba a partir del criterio de aceptación. De no ser posible es un claro indicio de una mala redacción del mismo.

Es importante incluir en los criterios de aceptación tanto cuestiones funcionales como no funcionales. Es posible agregar, por ejemplo, un tiempo máximo para procesar una transacción como uno de los criterios de aceptación. Similarmente pueden agregarse cuestiones de disponibilidad (especificando por ejemplo tiempo máximo que puede estar caído un servicio), seguridad, mantenibilidad, o performance. Por último, es recomendable evitar cuestiones técnicas o de implementación. Una manera de lograr esto es expresar criterios de aceptación que denoten una intención, y no una solución. Por ejemplo: “el administrador puede aprobar o desaprobar el formulario de auditoría” en vez de una redacción como “el administrador puede hacer clic desde el radio button Aprobar/Desaprobar para aprobar una auditoría”. La segunda forma está atada a un tipo especial de componente (radio button) mientras que la primera es más flexible respecto a la implementación.

Tal como es mencionado en [3] el rol que juegan los criterios de aceptación de delimitar el alcance de una US le permite al equipo de desarrollo tener una noción más tangible de la funcionalidad detrás de cada US. También en [3] se enumeran los beneficios de acompañar una US con buenos criterios de aceptación:

• Fuerza al equipo a pensar una dada funcionalidad desde la perspectiva del usuario.
• Remueve ambigüedades de los requerimientos.
• Promueve la calidad del desarrollo desde el momento en que el equipo realiza las entregas de los requerimientos adhiriendo a los criterios de aceptación
• Constituirán la base para los casos de prueba que confirmarán si una dada funcionalidad está completa y se comporta como era esperado.

Finalmente, vale la pena mencionar la técnica de las tarjetas (en inglés es conocida como la regla de las 3 C´s [4]), propuesta por Ron Jeffries para redactar correctamente una US, incluyendo sus criterios de aceptación. Toda US debe surgir de aplicar las siguientes tarjetas:

• las US usualmente se anotan en tarjetas o stickers, las cuales contienen detalles adicionales, como los criterios de aceptación.
• conversar sobre detalles del alcance de la US que surgirán de la interacción con el Product Owner.
• los criterios de aceptación confirmarán la funcionalidad de una US.

A continuación se listan algunos posibles criterios de aceptación a modo de ejemplo:

1. Un usuario no puede enviar un formulario sin completar todos los campos obligatorios.
2. La información del formulario se almacena en la base de datos de participantes.
3. Está funcionando el filtro Anti-SPAM.
4. El pago puede efectuarse con tarjeta de crédito.
5. Se envía un mensaje de “Registración recibida” luego de recibir la información del formulario.
6. Un usuario no puede registrarse con la misma información de otro usuario.
7. Se deberá chequear por dirección de mail.
8. Se podrá acceder con el login de Facebook o Google+.

Referencias:

[1] http://agilemanifesto.org/

[2] http://www.seguetech.com/blog/2013/03/25/characteristics-good-agile-acceptance-criteria

[3] http://www.boost.co.nz/blog/2010/09/acceptance-criteria/

[4] http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

Las metodologías ágiles proponen iteraciones cortas para desarrollar software de manera incremental. En cada iteración los requerimientos a desarrollar se expresan mediante user stories. Una user story se expresa mediante una oración simple, siguiendo un formato clásico y busca mostrar las necesidades del usuario para con el uso del sistema de manera directa y precisa. Dicho formato es el siguiente: “Cómo quiero para ”. Cada user story es acompañada de criterios de aceptación, los cuales detallan qué condiciones debe cumplir el código que implementa la user story. Los criterios de aceptación serán utilizados tanto por los desarrolladores como por los testers para validar la conformidad de la aplicación con los requerimientos funcionales.

Escribir buenas user stories no es trivial. Es un ejercicio que requiere tiempo y experiencia. En particular, existen un tipo de user-stories que requieren especial atención: son aquellas denominadas “técnicas” o de investigación. Sobre las mismas surgen voces a favor y en contra. A continuación se detallan consejos para redactar buenas user-stories, y se da un panorama sobre las user-stories de investigación.

El arte de redactar

En la referencia [1] se detallan los cinco errores más comunes a la hora de redactar User Stories. En primer lugar se menciona el problema de describir user-stories muy generales, del estilo “Como usuario quiero manejar distintas cotizaciones para poder seleccionar la más conveniente”. Si bien a primera vista cumple el patrón esperado de una user-story, el rol de la misma no está bien especificado. ¿Quién es el usuario observando las cotizaciones? Es distinta la funcionalidad detrás si es el administrador del sitio, o un usuario visualizando datos.

Es fundamental por lo tanto especificar lo más detalladamente posible el usuario detrás de cada user-story. De manera similar para una user-story que comienza con “Como Product Owner….” o “Como desarrollador”. Una buena user-story refleja la visión desde el punto de vista del usuario del producto final, y no desde el líder o integrante del equipo de desarrollo.

Otro error común es ignorar la parte de para qué quiero la funcionalidad de la user-story. Parece trivial, pero poder justificar la funcionalidad pedida es un ejercicio útil para mejorar el proceso de identificar requerimientos. Si no es posible formular de manera simple para qué se quiere una determinada funcionalidad del producto, es probable que no sea necesaria implementarla. Finalmente, se destaca la necesidad de especificar criterios de aceptación. Una manera de verlos es como casos de prueba para el código que implementa la user-story, y por su papel debe prestarse atención en su formulación. Por ejemplo, para una user story que describe la funcionalidad de buscar un determinado producto en un catálogo, un criterio de aceptación podría describir el escenario donde no se encuentre el producto al realizar la búsqueda y especificar en este caso que se espera que aparezca en pantalla un texto del estilo “Actualmente no se posee el producto en stock. Vuelva a consultar pronto!”

User-stories técnicas o de investigación

En repetidas ocasiones surge la necesidad de contemplar user-stories un tanto particulares, donde no se refleja la necesidad de un usuario final, sino del equipo de desarrollo. Si el equipo necesita emplear avanzadas técnicas de encriptación de datos para desarrollar un producto seguro, ¿es una buena práctica ágil agregar una user-story “interna” del equipo donde se refleje la necesidad de estudiar técnicas de encriptación? En este sentido hay voces a favor y en contra.

En las referencias [2,3] se manifiestan en contra de su utilización. Los argumentos son que en realidad son requerimientos que se alejan de la noción de user-stories, lo cual produce un product backlog entremezclado y confuso. Proponen en cambio incluir los requerimientos técnicos como tareas dentro de user-stories, introduciéndolos de manera gradual y fiel a los conceptos ágiles.

Las voces a favor (ver [4,5]) argumentan que en determinadas ocasiones es provechoso tener explícitamente historias que reflejen la necesidad de investigar una tecnología, realizar un prototipo, etc. En especial, cuando son actividades críticas para el producto. Por ejemplo, si el equipo está desarrollando un proyecto de e-commerce es crítico que el equipo sea experto en cuestiones de seguridad. En caso de no contar con la suficiente experiencia, es posible emplear user-stories técnicas o de investigación que reflejen la inversión en tiempo y esfuerzo del equipo en investigar técnicas y herramientas de seguridad y encriptación. Muchas veces estas stories se conocen como user stories de tipo “spike”.

Conclusiones
Como siempre, mucho depende de la experiencia y del equipo llevando adelante el proyecto. Para redactar buenas user stories, el mejor consejo es seguir fielmente el patrón propuesto:“Cómo quiero para ”. El mismo es un proceso que tiende a mejorar a medida que se adquiere más experiencia. Sobre las user stories técnicas, son buenas en la medida que se justifique su utilidad, y tenga un output concreto. Por ejemplo, el algoritmo de encriptación que mejor se adapta al proyecto es un buen entregable de una user story técnica.

Referencias:

[1] https://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-make-writing-user-stories
[2] http://xprogramming.com/articles/technical-stories-we-dont-need-em/
[3] http://www.industriallogic.com/blog/as-a-developer-is-not-a-user-story/
[4] http://programmers.stackexchange.com/questions/140065/is-it-proper-to-have-investigation-task-in-sprint
[5] http://agileatlas.org/articles/item/spikes-in-scrum-the-exception-not-the-rule

El éxito de las metodologías ágiles se basa en un fuerte compromiso del equipo, trabajando y colaborando, donde el esfuerzo individual de cada persona contribuye al progreso de todo el conjunto. Existe un concepto clave detrás de todo desarrollo ágil que busca potenciar la consolidación del equipo: las retrospectivas ágiles. Cuando es bien empleada, una retrospectiva es crucial para mejorar y perfeccionar no sólo el producto desarrollado, sino el proceso detrás que lo concibe.

A continuación se detallan las características fundamentales de una retrospectiva, su utilidad y técnicas para su correcta utilización.

Retrospectiva: ¿Qué, cómo y dónde?

Un equipo ágil tiene entregas iterativas e incrementales, siguiendo distintas etapas o sprints. Al terminar cada una de ellas, el manifiesto ágil propone reunir al grupo y analizar qué salió bien, qué salió mal, motivos, sensaciones, emociones, y action ítems de mejora. El objetivo es claro: mejorar para el próximo sprint. Buscar potenciar el rendimiento y esfuerzo colectivo para que la próxima iteración resulte mejor. Esta actividad se conoce como retrospectiva.

Sin embargo, una retrospectiva puede tener efectos negativos si no está bien conducida ni tiene objetivos claros. El equipo puede sentirlo como una pérdida de tiempo, disminuyendo su moral y compromiso con el proyecto al sentir una inevitable “pérdida de tiempo”.  Por esta razón la comunidad ágil recomienda fuertemente [referencias 1,2,3] tener una persona dentro del equipo encargada de llevar a cabo esta actividad, siendo generalmente el scrum master. De la misma forma, para evitar que la retrospectiva no sea simplemente hacer catarsis es conveniente definir action ítems o accionables, cada uno con owner y deadline, que tengan acciones concretas para la mejora. El status de los mismos se puede revisar en la próxima retrospectiva así el equipo va viendo mejoras concretas.

Existen distintas actividades que buscan sacarle el máximo provecho a una retrospectiva. Las mismas buscan mejorar no sólo cuestiones técnicas o propias del desarrollo, sino también la dinámica del grupo, y por consiguiente, el proceso mismo encargado de llevar adelante el proyecto. En este sentido en [2] se menciona explícitamente que no sólo es necesario hablar de tecnología y plataformas, sino incluir el aspecto humano en el proceso. Las emociones y estados de ánimo son importantes para lograr un buen ambiente de trabajo. Avances por estos caminos tendrán indudablemente un efecto positivo. A continuación se describen técnicas para sacarle máximo provecho a una retrospectiva.

Técnicas para una buena retrospectiva

Una de las opciones clásicas es a través de cuestionarios dirigidos a todo el equipo. Es importante que las preguntas sean precisas para obtener respuestas claras y breves. Se puede avanzar gradualmente de cuestiones generales a más específicas.

La actividad de histograma de satisfacción es otra de las opciones clásicas. Cada miembro del equipo entrega una  tarjeta a la persona conduciendo la retrospectiva expresando su nivel de satisfacción en relación al trabajo con el equipo. Esto se denota numéricamente con valores entre 1 y 5, donde 1 expresa “No estoy nada satisfecho” y 5 “estoy 100% satisfecho”. Luego, se visualizan los votos finales en cada categoría y se analizan los resultados.

Otra posibilidad se conoce como “Estrella de mar” o Starfish. En esta modalidad se usa un círculo con 5 áreas para reflejar qué actividades el equipo debe dejar de hacer inmediatamente, cuáles mantener, cuáles empezar a realizar en el corto y largo plazo.

Una actividad que prioriza sensaciones y estados de ánimo se conoce como “Índices de Felicidad” o Happiness Index. Aquí cada miembro del equipo puntúa cada actividad reflejando cómo se sintió. Interesantes conclusiones pueden obtenerse con este método.

Otra actividad se conoce cómo “5 veces porqué”, donde el principal objetivo es profundizar las razones que llevaron al éxito o fracaso de cada ítem involucrado.

Es importante que la persona a cargo de la retrospectiva conozca estas y otras alternativas más para poder ir variando y viendo cuál o cuáles se adaptan mejor al grupo.  Esta flexibilidad es un factor relevante para el éxito de una retrospectiva.

Consejo final

Finalmente,  en [referencias 2 y3] se menciona un último consejo. Este mismo consiste en realizar retrospectivas de retrospectivas ocasionalmente, para sumar las experiencias pasadas en la próxima a realizar.

Referencias:

[1] http://www.benlinders.com/2013/whats-an-agile-retrospective-and-why-would-you-do-it/   

[2] http://www.techwell.com/2013/02/why-retrospectives-are-important-agile-software-development

[3] http://blogs.versionone.com/agile_management/2014/03/25/valuable-agile-retrospectives-how-to-do-them/

La decisión de implementar BPM en una organización es aplicable a una de cualquier tipo y tamaño. Continue reading BPM (Business Process Management) →