Arquitecturas Ágiles

21 sep


El concepto de arquitectura de software se refiere, de forma genérica, al conjunto de módulos que se identifican como la solución software y todas aquellas implicancias técnicas referidas a la integración óptima de dichos módulos.

Definir una arquitectura nos conduce a reflexionar en una serie de decisiones que se toman detenidamente durante las primeras fases del desarrollo de un software como parte del denominado Diseño de Arquitectura del Software. Estas decisiones deben ser muy cuidadosas puesto que una vez definida la arquitectura se convierte en “cimiento” y el software se comienza a desarrollar sobre la misma. Encontrarnos con la necesidad de tener que cambiar por algún motivo puede llevarnos a un impacto importante en los tiempos y costos del proyecto.

Ahora bien, esta propiedad de previsibilidad que debemos considerar en esta etapa se contrapone un poco con la esencia ágil de abrazar los cambios. Entonces… ¿un arquitecto debe ser previsible para evitar dichos cambios o los aborda sin precuparse demasiado?.

Ante esta disyuntiva, aflora otra pregunta más: ¿podemos hablar de arquitectura en el sentido tradicional dentro de proyectos ágiles?. Al parecer…SI. Surge entonces el concepto de Arquitectura Ágil.

Sigue leyendo

Java 5, 6…7!

13 sep

Desde el pasado julio de 2011, Oracle ha puesto en disponibilidad la versión 7 de Java luego de aproximadamente 5 años de trabajo no solo de ingenieros de Oracle sino también de miembros de la comunidad Java mundial  a través del proyecto OpenJDK.

En este post les quiero presentar algunas de los cambios que nos acompañan en esta nueva versión.

Sigue leyendo

La deuda técnica

1 ago

En muchos proyectos de desarrollo software se suele presentar una disputa entre el satisfacer las restricciones de tiempo/costo versus el requerimiento de entrega de un producto de calidad.

Razones para esto son muchas entre las cuales tenemos:

  • Aspectos estratégicos: Las empresas buscan maximizar su rentabilidad estableciendo condiciones para que los productos se finalicen con tiempos y costos aceptables para el cliente (e ideales para la empresa) pero con niveles de calidad pobrísimos.
  • Aspectos Procedimentales: La calidad, no es correctamente gestionada durante el proceso de desarrollo del software.

Veamos algunos ejemplos gráficos que clarifican esta situación. Idealmente, tendríamos un esquema de avance en el proyecto como el siguiente:

Se espera que la totalidad de los requerimientos sean entregados en una fecha predeterminada.  Para lograr esto, el equipo trabaja a una velocidad planificada de entrega.

Comenzado el proyecto y con el correr del tiempo, aparecen los problemas debido al esfuerzo real que implica cumplir con un trabajo de alta calidad.  Son problemas puesto que las planificaciones iniciales subestimaron el esfuerzo de entregar calidad.

En el anterior gráfico se observa cómo se empieza desviar el avance real respecto al planificado.

Ante esta situación, el Project Manager (PM) acude a una presión extra sobre el equipo con el afán de que se pueda ajustar la fecha de entrega. Si esto funciona, tendremos un escenario como el siguiente:

Dicha presión sobre el equipo funcionó pero no es gratis, alguien tuvo que pagar y esa fue la calidad del producto. Se disminuyó en pos de poder cumplir con los tiempos y costos.

Viendo entonces que fue posible reencauzar el proyecto, el discurso de fundamentación del PM ante el cliente es que “se ha podido retomar el camino ya que el equipo ha adquirido una mejor performance, lo cual le permite avanzar mas rápido”. La realidad es que pudimos cumplir con los plazos y costos cuando se redujo la  calidad del producto. Esta diferencia entre lo que se entregó y lo que se debería haber entregado se denomina deuda técnica (ver orígenes del término en http://en.wikipedia.org/wiki/Technical_debt). Ésta deuda se genera al hacer las cosas de forma rápida y mal.

La deuda técnica es el trabajo vinculado a las funcionalidades comprometidas y que es diferido o descartado para poder cumplimentar con los cronogramas. Que sea diferido implica que no es entregado, por lo tanto afecta la calidad total del sistema.

Ahora pensemos que sucede si tomamos como base el código de proyecto “cumplido” para ejecutar otro proyecto similar. Todo se complica aún más puesto que se parte de código que ya acumula deuda técnica. Ocurre así un efecto de generación de mas cantidad de deuda técnica ya que el nuevo proyecto acumula no solo la deuda nueva generada sino también la heredada

Ejemplos de deuda técnica son, entre otros:

  • Retraso de las actualizaciones criticas.
  • Retraso en el refactoring  del código complejo.
  • En aplicaciones web, codificar toda la lógica de negocio en la capa de presentación.
  • No utilizar logs o manejo de errores robusto.
  • No realizar pruebas o realizarlas de forma muy superficial.

Consideremos una cuestión extra: si este trabajo técnico no hecho es necesario para la salud del producto ¿qué pasa cuando no se hace nada con él? ¿qué pasa cuando se acumula y continúa acumulando deuda técnica y no se la trata?

Veamos un ejemplo. Para un determinado producto, solemos crear la primera versión con deuda técnica. Luego se siguen mas versiones y así sucesivamente. Cada versión introduce nueva deuda. Esto crece al punto que cuando alguien solicita realizar un cambio al producto, el equipo de desarrolladores estalla de rechazo. ¿El motivo?: el producto es inmantenible, es muy complejo para modificar, el código tiene miles de LOC, se requieren desarrolladores expertos para poder modificarlo y cientos de etcéteras.

Cuando esto sucede se dice que el código ya presenta un diseño muerto.  Ante un diseño muerto, la verdad es que no queda mucho por hacer.

Sin dudas existen muchos proyectos como estos. Yo tengo un par de nombres que recuerdo con mucho “cariño”.

Como párrafo final, uno de los grandes facilitadores de este tipo de situaciones es, a mi criterio, el tipo de contrato que se establece entre el cliente y el proveedor, que suele ser del tipo predictivo y precio fijo. Estos contratos se establecen definiendo el alcance del proyecto en etapas tempranas (controlando luego que no se realicen los cambios sobre el mismo o que sean mínimos) e imponiendo restricciones de costo y tiempo. Esta situación, combinada con empresas como las mencionadas al inicio, en las que términos como patrones de diseño, pruebas continua, formación al personal, control de calidad prácticamente no existen, forman un cóctel que sirve deuda técnica en vasos cada vez más grandes.

¿Cómo se evitan o disminuyen los riesgos de deuda técnica?. Pensando solo en la arista referida a los contratos (la otra arista, la de las empresas ávidas de rentabilidad a cualquier costo la dejamos para otro momento) deberemos considerar la adopción de contratos ágiles. Simplemente se los comento ya que esto será inspiración para otro post.

Espero que les haya sido de utilidad.

Seguimos en contacto. Gastón.

Basado en: http://www.scrumalliance.org/articles/14-technical-debt-and-design-death

Usabilidad, haciendo bello el cántaro

17 abr

Ha pasado un tiempito desde el último post pero aquí estoy de nuevo en el ruedo. Esta vez traigo un tema muy importante pero desprestigiado o subestimado al momento de llevar adelante proyectos de software: la usabilidad.

La usabilidad se define como:

Atributo de calidad que evalúa que tan fácil es la interfaz de usuario para utilizarla.
Este concepto también se aplica a los métodos existentes para mejorar dicha facilidad de uso durante el diseño del sistema.

- Jakob Nielsen -

Garantizar la usabilidad de un sistema informático representa un aspecto crítico, puesto que nos expresa el grado de satisfacción de uno de los interesados más importantes dentro de un proyecto: los usuarios.

¿Llegamos a 5?

Muchas veces se piensa que poder ir en búsqueda del cumplimiento de este requerimiento de calidad es algo tedioso o complejo, y que requiere muchos métodos de difícil aplicación. Para responder esto, existe un estudio realizado por Jakob Nielsen, uno de los gurús sobre la usabilidad que nos sugiere que la misma puede ser evaluada, con un importante grado de calidad, si consideramos…5 usuarios…si, solo 5 usuarios nada más.

Para ello, deberemos partir de una FORMULA, confeccionada a partir de la experiencia en gran cantidad de proyectos, que nos indica la cantidad de problemas de usabilidad que pueden ser encontrados considerando diferente cantidad de usuarios.

N = (1-(1-L)n)

En esta fórmula, N es el número de problemas de usabilidad detectados en el diseño, L es la proporción de problemas detectados con un solo usuario. El valor promedio de L es 31%. Para ir modificando la cantidad de usuarios utilizamos n.

n

L

N

0

0,31

0,00%

3

0,31

67,15%

5

0,31

84,36%

6

0,31

89,21%

9

0,31

96,45%

12

0,31

98,84%

15

0,31

99,62%

La siguiente tabla, rápidamente nos indica que para 5 usuarios, el porcentaje de errores que podremos detectar es de casi el 85%.

Así, podemos obtener las primeras conclusiones:

  • Con 0 usuarios, obtenemos 0 conocimiento. No conocemos ningún problema de usabilidad puesto que ningún usuario lo testea.
  • Con 1 usuario la cantidad de problemas alcanza casi un tercio de lo que podemos descubrir (30% aprox.)
  • Con 2 usuarios, muchos de los problemas descubiertos por ambos usuarios se comienzan a solapar, pero igualmente, el segundo usuario agrega un poco más información de utilidad.
  • Si continuamos agregando usuarios, lo nuevo que vamos a ir aprendiendo será cada vez menor, al punto que comienza a ser prácticamente insignificante.
  • Con el usuario 5 estaremos descubriendo un 85% de los errores de usabilidad.
  • Entonces, una primera conclusión es que la formula indica que más allá del usuario 5 estaremos gastando recursos en obtener problemas que, o ya fueron descubiertos, o son insignificantes.

Haciendo números

En cuanto a la cantidad de tests a realizar, se recomiendan muchos tests pequeños antes que un solo test grande.

Estos 5 usuarios encontraran el 85 % de los problemas en un primer test. Luego de modificar el diseño para solucionar lo reportado por dicho test, se realizara otro test.

Este segundo test estará verificando si los primeros problemas reportados han sido resueltos y si no se han introducido nuevos problemas.

Este segundo test encontrará la mayoría del 15% restante que quedo pendiente luego del primer test y será demás como un asegurador de la calidad del primero de los test. Además, este segundo test será capaz de poner sobre la mesa que tanto cubre la usabilidad el core del sistema (arquitectura de la información,  flujo de tareas, satisfacción del usuario, etc.).

No obstante el segundo test, necesitaremos un tercer test con un último lote de problemas  de usabilidad a resolver.

Usuarios de diferentes tipos o grupos
Los sistemas pueden tener diferentes tipos de usuarios (ya sea por los rangos de edad de quienes lo usarán o por los roles que contempla) con lo cual, lo analizado anteriormente deberá ser adaptado para contemplar esta situación.

Un primer y directo análisis seria resumir que si tengo dos tipos de usuarios diferentes, debemos considerar 5 usuarios de cada grupo y realizar 3  tests de usabilidad con cada uno de ellos.

No obstante, podemos mejorar esto si nos percatamos que cuando tenemos muchos grupos con diferentes usuarios, no necesitamos incluir tantos miembros de cada grupo como podría ser cuando tenemos un único grupo de usuarios.

Existe una superposición de las observaciones que los usuarios de ambos grupos aportan. Esto se debe hay que existen grandes similitudes entre las observaciones de los diferentes grupos, puesto que en el fondo, todos tienen algo en común: son personas. Así que, cuando tenemos diferentes tipos de usuarios, lo que se recomienda es:

  • Considerar 3-4 usuarios de cada categoría si estamos testeando con dos diferentes grupos de usuarios.
  • Considerar 3 usuarios de cada categoría si estamos testeando con más de 2 categorías o grupos de usuarios.

Conclusión

Podemos de manera sencilla y a bajo costo, apostar a identificar un lote de oportunidades de mejoras en materia usabilidad de nuestros sistemas informáticos.

Considerando solo unos pocos usuarios preparados podremos identificar muchos problemas de diseño y trabajar luego en su posterior resolución, beneficiando así, la experiencia de todos los usuarios con el sistema.

Siempre habrá entre nosotros cortadores de leña y sacadores de agua.
Nuestra maquinaria moderna no ha aliviado mucho el trabajo del hombre después de todo,
al menos, procuremos que el cántaro junto al pozo sea bello, y seguramente la labor de la jornada será más fácil.

- Oscar Wilde -

En la medida que podamos, procuremos que el cántaro junto al pozo sea bello haciendo que el software sea usable!.

Nos vemos, Gastón!.

Más información:

Construyendo proyectos en el aire

1 mar

Dicen que la agilidad es una de las nuevas características que se requieren en los equipos para afrontar los cambios que imponen los proyectos cada vez más dinámicos. Agilidad para adaptarse a los cambios de requerimientos, de tecnologías, de equipo, de contextos. En definitiva, agilidad para adaptarnos a aquellas idas y vueltas que el entorno exige y al cual deberemos seguir.

Si bien esto es real y válido dentro de la gestión de proyectos, existe otro tipo de agilidad que muchas organizaciones, empresas o equipos deben ejercitar como mecanismo para adaptarse a los cambios que ellas mismas imponen o generan (y posteriormente padecen!). Cambios que, más que provenir de una estrategia pensada y planificada tienen más relación con el propio desorden, el desconocimiento y no respeto por las técnicas y procesos, la incorrecta priorización de las tareas, los equipos ficticios, etc.

Para poder identificar aquellos escenarios que fomentan el ejercicio de este tipo de agilidad interna, les comento algunas situaciones que más de uno reconocerá como presentes en algún que otro proyecto (de software en este caso) en el cual haya participado:

Un día Otro día
Un gerente de proyectos dice:  Bien, vamos a implementar Scrum, protejamos los alcances de cada sprint, es una buena forma de ordenar las cosas… El mismo gerente de proyectos dice: Eso de Scrum, está bueno, pero ahora quiero que interrumpan todo lo que están haciendo y hagan esto. Mañana retomamos con el sprint activo.
Un gerente de proyectos dice: Necesitamos si o si estimar los nuevos requerimientos, consideremos todas las alternativas para disminuir los releases incompletos o con fallos, tomemos un tiempo para las pruebas, ordenemos las cosas… El mismo gerente de proyectos dice: ¿esos son tus esfuerzos? seguro que estimaron de más, acortemos el 10% por sobreestimacion y las pruebas no las hagamos tampoco, recortemos al 70% los tiempos…  ahora sí que llegamos!!!
Un programador dice: Las metodologías ágiles son el futuro, vamos a adaptarnos a los cambios, éstos suceden siempre y el cliente puede plantearlos… 

 

El mismo programador piensa: Otra vez cambiar eso!!!!??? Maldito usuario!!!  Tiene que firmar lo que pide, tiene que firmar lo que pide!
Un programador dice: Somos profesionales, usemos tecnología de punta, somos un equipo de una alta seniority El mismo programador dice: Bien, veo de hacerte esto que me pedís, pero necesito ponerme a estudiar un poco porque no es tan simple, hay que ver si se puede, no te puedo estimar un tiempo para esto, vamos viendo…
Un gerente general a un cliente le dice: Hacemos proyectos de calidad,  nuestros productos cumplen todos los requerimientos y los construimos con un alto nivel de estabilidad… El mismo gerente general a su equipo le dice: no probemos nada, el cliente no lo va a probar tampoco, eso sí muchachos, espero que el producto sea estable…
Una empresa vende que lo más importante en un proyecto es el equipo… La misma empresa vende como si sus empleados son todos Senior, trabajan como super Senior y les paga como si fueran Junior. 

 

Un integrante de un equipo dice: A ver, tenemos que trabajar como un equipo, sino este proyecto se nos cae, vamos!! El mismo integrante del equipo piensa: Éste me pide que le explique cada cosa, si no tiene ni idea de que hace acá….por favor…
Un líder dice: Nuestro equipo es sólido, están comprometidos, trabajan unidos… El mismo líder piensa: cuál era el nombre de este pibe? Y estos dos son perro y gato…
Un gerente de sistemas dice: nuestros productos son 100% estable, tenemos equipo para asegurar la calidad y confiabilidad de los entregables… EL mismo gerente dice ante el líder del equipo desarrollador: sé que ustedes desarrollan pero hicieron pruebas de stress no?

Conclusión

Dime como es tu práctica y te diré que tanto entendiste la teoría

Todas las frases anteriores son quizás exageradas, pero muy probables de presentarse en la realidad. Denotan el mismo síntoma: la no aplicación adecuada de prácticas probadas en la gestión de proyectos (sean de la industria que sean).

Del dicho al hecho hay un largo trecho dicen y es tal cual. La realización de proyectos exitosos es muy fácil en los papeles, pero en la práctica las cosas se relajan, se olvidan, se omiten, se anulan y hasta se reprimen.

Cada una de estas situaciones tiene que modificarse, es el agua que socava los cimientos, son los gusanos que se colaron en el cajón de manzanas y echan a perder, desde proyectos y hasta empresas completas.

Vean el siguiente video:

Así como dicha publicidad puede denotar algo positivo como ser una capacidad de adaptarse a los negocios, esta misma publicidad la puedo aplicar para analizar la agilidad interna: Así como hay empresas que construyen aviones en el aire, muchas veces construimos proyectos también en el aire…es decir, como vayan saliendo!!!: necesitamos acortar tiempos? resignemos calidad, necesitamos equipos competitivos ? reclutamos sin siquiera pensar en los roles de cada persona, y así muchos ejemplos mas.

Esta manera de gestionar un equipo, un proyecto, una empresa no es propia de algún tipo de mercado. A ella la conocen empresas privadas y organismos públicos, sean grandes o pequeños  Esta forma de gestionar tiene un muy alto riesgo para con el éxito de un proyecto: es jugar a la ruleta rusa, puesto que los riesgos que hay que enfrentar no solo vienen de afuera (que sería hasta lo más normal) sino que se gestan en el mismo seno interno y nunca sabemos cuando puede ser el momento en que se nos escape el tiro.

A modo de conclusión de este tema, los invito a que todos, desde el lugar que nos corresponda, hagamos mea culpa de nuestros aportes en situaciones como las descriptas y también a mejorar todo aquellos que vean que requiere mejora. Como dice un texto que alguna vez leí: Sé el cambio que tú quieres ver en el mundo. En este caso, yo lo adaptaría a: Haz el cambio que tu quieres ver en los proyectos. Basta de proyectos en el aire.

Espero haber sumado.

Saludos, Gastón

Cutteando el Scope

3 feb

De la misma saga que Creepeando el Scope aquí les traigo unas ideas respecto a como, en determinadas ocasiones, podremos acortar el alcance de un proyecto que estamos gestionando.

El alcance de un proyecto se refiere al conjunto de requerimientos (funcionalidades, documentos, capacitación, etc.) que se han acordado, tanto con el cliente, usuarios y demás interesados, para que se encuentren todos entregados al finalizar el proyecto.

Ahora bien, el camino desde que no tenemos ningún requerimiento concluido hasta tenerlos a todos suele ser un camino con obstáculos. Por diversos motivos, muchas veces, en las fechas en las cuales se ha planificado entregar parte de los requerimientos, nos encontramos con que NO tenemos lo que debíamos tener y ya nos vemos dando las explicaciones del caso.

Para gestionar estos escenarios donde debemos dosificar la entrega del alcance del proyecto y disminuir el riesgo de no cumplir con los plazos, les propongo una serie de pasos que pueden ayudar.

Lo primero que se debe enfocar, ante cada entrega, cual es el nivel de expectativa a cumplir en el usuario/cliente y los demás interesados. La siguiente figura refleja este punto:

Las primeras entregas suelen ser las que concentran la mayor ansiedad puesto que se desea comenzar a observar el verdadero avance de un proyecto, y esto tiene relación directa con acceder a funcionalidades implementadas, no prestandole demasiada atención a cuestiones “extras” para ese momento, como son las validaciones de datos o las mejoras vinculadas a la eficiencia del producto. Asi, como primera consideración podemos decir que los requerimientos acordados para una entrega pueden recortarse según el nivel de detalle que la expectativa de la entrega genere. Por ejemplo, en las primeras entregas, de los requerimientos mas importantes a entregar, se tendrá mayor expectativa que los mismos funcionen a que los mensajes de error se presenten en rojo.  Es decir, en las primeras entregas se esperará que todas las funcionalidades acordadas para dicha fecha se encuentren en el entregable y no tanto que para todas esas funcionalidades, sus respectivos manejos de errores sea el final.

Esta estrategia de recortar según el nivel de expectativa la podemos combinar con otras tres estrategias extras:

Reduciendo el Alcance de un Proyecto

La forma más común para que los equipos entreguen productos más rápido es reduciendo el alcance de cada producto. Sin embargo, esto no puede hacerse de manera arbitraria. Hay motivos de negocio reales (en teoría al menos!) para cada una de los requerimientos que se piden.

Para lograr que un equipo entregue 50% más rápido se puede:

  • Entregar 50% menos de requerimientos.
  • Entregar todos los requerimientos pero con un 50% menos de detalles en cada requerimiento.
  • Entregar todos los requerimientos con distinto nivel de detalle en cada requerimiento.

Entregar 50% menos de requerimientos

  • Usando un backlog priorizado de trabajo: el Dueño del Producto puede hacer que el equipo trabaje en orden de prioridad hasta que se haya entregado el suficiente valor para hacer una entrega razonable. El peligro acá es no ser lo suficientemente agresivo sobre cuánto es suficiente..
  • Este método es simple y efectivo, excepto cuando los equipos de ventas y marketing “prometieron” características que están con baja prioridad en la lista. Si un equipo entrega 25 de las 26 características prometidas, el cliente podría enojarse. Si entrega estas mismas 25 características cuando se habían prometido sólo 20 van a ser felicitados como héroes. ¡Hay que ser muy cuidadoso con los compromisos externos para poder cumplirlos!

Entregar 50% menos de detalles en cada requerimiento

  • Se entregan todos los requerimientos. Este método se basa en el hecho de que el 64% de las características se usan poco o nada (según el estudio de Standish Group). Para poder entregar un 50% más rápido, se debería eliminar en promedio el 50% de cada requerimiento, e igualmente no dañaríamos el “núcleo” del software, el cual será usado la mayor parte del tiempo.
  • La desventaja es que se trata por igual a cada requerimiento, y es probable que recortemos demasiado en algunos requerimientos, y no lo suficiente en otros. Lo que nos lleva al método final…

Entregar todas los requerimientos con distinto nivel de detalle en cada requerimiento

  • Desarrollar por completo los requerimientos de mayor prioridad, mientras que los menos importantes se construyen sólo lo suficiente como para poder decir que funcionan bien.
  • Esto salva el problema del primer método ya que se entregan todos los requerimientos, y también supera los problemas del segundo método porque se entrega el máximo valor para los elementos de mayor prioridad.
  • Propuesta: ABMC y Reportes, de baja prioridad y a recortar funcionalidades.

En resumen, y tomando un ejemplo entonces…la semana que viene digamos que tenemos una entrega!!!, con ésta estamos justo en la mitad del proyecto:

  • Según la expectativa del usuario podemos determinar que de los requerimientos a entregar, no solo el usuario deseará evaluar funcionalidades sino también validaciones de datos y escenarios alternativos.
  • Según el análisis de los 3 metodos presentados, optamos por el 3 de manera que priorizaremos los requerimientos a entregar y en los que se encuentren en el tope de la lista, el tridente funcionalidades-validaciones-escenarios sera implementado en su totalidad; para los que se encuentren al final de la lista dicho tridente será mas relajado.

Espero haber sumado. Nos vemos, Gastón.

L’emploi

24 ene

Revolviendo sitios encontré un video de esos en los cuales comulgan lo profesional con lo que cada uno espera de la vida y lo hacen de una forma tan intensa que sacuden un poco nuestra brújula interna.

Terminé de verlo y me quedé un rato con el mate tratando de desenredar una opinión al respecto. La verdad es que no pude avanzar demasiado ya que despertó tantas aristas que no las pude, por ahora al menos, resumir en algo que sume. Lo único seguro, es que no me gustaria verme yo en ese espejo al afeitarme.

Nos vemos, Gastón

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.