Arquitecturas Ágiles

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.

Java 5, 6…7!

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.

La deuda técnica

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

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)ⁿ)

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:

• http://www.useit.com/alertbox/20000319.html
• http://www.useit.com/alertbox/20030825.html

Construyendo proyectos en el aire

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

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

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

Muchos bichos, pocas balas

Lanzar una aplicación software a entorno de producción sin ser probada es como poner a vender una torta sin ni siquiera haberla probado al menos una vez.

Ahora bien, a diferencia de este ejemplo culinario, probar una torta es mucho mas sencillo (y rico!) que probar una aplicación. Tenemos probablemente cientos de escenarios posibles para validar. Por ello, el primer gran consejo es priorizar los casos de prueba a ejecutar. Ésto basicamente deberiamos realizarlo por dos motivos:

1. No sobre eltiempo para poder testear todo.
2. No conviene testear todo, ya que aqui tambien podemos aplicar la ley de Pareto: el 20% de los casos de prueba representa el 80% de los bugs de importancia que deberemos detectar.

Viendo estos dos puntos, entramos en una disyuntiva importante: ¿cuales son los casos de prueba que caen dentro del 20%? o lo que es lo mismo ¿que nos conviene testear?

Para responder esta pregunta se han definido varios tipos de heuristicas, las cuales buscan resumir en un grupo de palabras aquellas caracteristicas que deberemos fijar para priorizar la funcionalidad a testear.

Así, proponemos un ejercicio que parte de lo siguiente: en cada una de las siguientes categorias, asignar a cada funcionalidad del sistema, una puntuación según el grado de importancia de la misma respecto a la categoria. Las puntuaciones son:

1. Poco importante que funcione perfectamente.
2. Importante que funcione perfectamente.
3. Muy importante que funcione perfectamente.

Como categorias a considerar, proponemos:

Negocio
Que tan importante es para el negocio.

Críticas tecnicamente
Segun que tan criticas son las funciones desde el punto de vista de los aspectos tecnicos que involucra.

Frecuencia de Uso
Que tan importante es, segun la frecuencia de uso.

Intensiva en recursos
Segun que tan demandante de recursos sea la funcionalidad.

Obligatorias
Segun que tan obligatorias son las funcionalidades pedidas por los interesados.

Aspectos legales
Segun si haya requerimiento legales que deba respetar.

La siguiente tabla refleja este análisis para unas funcionalidades tipicas. Se colocan las mismas y por cada una se define la importancia según las categorias anteriores. Obtenido el total de puntos por funcionalidad, nos resta ordenarlas por importancia y concentrarnos en testear aquellas que agrupen el 70-80% de importancia.

Como dato no menor, podemos obviamente agregar mas categorias para hacer este análisis mas exhaustivo.

Por ahora nada mas amigos, me voy con una sonrisa.

Nos vemos, Gastón

Post basado en: http://searchsoftwarequality.techtarget.com/answer/Prioritizing-software-testing-on-little-time

El nacimiento de un proyecto

Buenas, feliz 2011 para todos!!. Para arrancar este nuevo año con la mejor de las ondas, les traigo una cuota de humor que espero que les arranque alguna que otra risa o al menos una reflexión jeje. Alguna vez se preguntaron como nace un proyecto en una empresa? bueno, aqui les va una posible respuesta:

Programador al responsable técnico:

“Es imposible que nosotros podamos hacer este proyecto. Supone cambios de diseño y nadie en nuestro equipo sabe como está hecho el sistema, además nadie en nuestra compañía conoce el lenguaje con el que se ha escrito el programa. Así que, si asignamos a alguien a trabajar en él, no podrá hacer nada. Si me preguntas mi opinión personal te diré que nuestra compañía nunca debería de realizar este tipo de proyectos “.

Responsable técnico a Project Manager:

“Este proyecto implica un cambio de diseño. En la actualidad no contamos con gente con experiencia en este tipo de trabajo. También el lenguaje es desconocido para nosotros, así que tendremos que organizar algún tipo de formación y un periodo de adecuación si se aborda el proyecto. En mi opinión, debemos evitar aceptar este proyecto. “

Project Manager a Director de Informática:

“Este proyecto implica un cambio de diseño en el sistema y no tenemos mucha experiencia en esa área. Tampoco tenemos mucho personal capacitado en este lenguaje. Creo que podemos aceptar este proyecto pero deberíamos pedir un poco de más tiempo. “

Director de informática a Directivo senior:

“Este proyecto consiste en una reingeniería de la aplicación. Tenemos algunas personas que han trabajado en esta área y algunos que conocen el lenguaje y que pueden entrenar a otras personas. En mi opinión, podemos aceptar este proyecto pero con precaución. “

Directivo senior a Director General:

“Este proyecto va a demostrar a la industria nuestras capacidades en el rediseño de un sistema complejo. Tenemos todos los conocimientos necesarios y las personas necesarias para ejecutar este proyecto con éxito. Algunos de nuestros técnicos ya han empezado a dar formación en este ámbito a otras personas. Creo que no debemos dejar escapar este proyecto bajo ninguna circunstancia. “

Director General al Cliente:

“Este es el tipo de proyectos en los que nuestra compañía se especializa. Hemos realizado muchos proyectos de la misma naturaleza en grandes clientes. Confía en mí cuando digo que no podrías estar en mejores manos. Te doy mi palabra que podemos realizar este proyecto con éxito y en el marco de tiempo dado.

Nos vemos, Gastón!.

Palabras responsables

La comunicación es una de las disciplinas mas importantes a gestionar durante un proyecto (el PMBok posee todo un capítulo para este tema) . En un nuevo emprendimiento existen usuarios, equipos, líderes de equipo, directores de proyectos, sponsores y otros interesados que tienen cada uno sus expectativas y objetivos que esperan que sean cumplidos.

Es ahi entonces, cuando todos los actores anteriores, cada uno en el rol que le corresponde, comienzan a interactuar para empezar a hacer rodar la pelota y lograr alcanzar el éxito cuando suene el silbato final.

Pero no es fácil, el proceso de la comunicación es complejo pues uno como persona (antes que como sponsor, lider o parte de un equipo) ya tiene una tendencia a comunicar las cosas en forma ineficiente. Causas de esto son muchas: intereses, influencias, sentimientos, conflictos, prejuicios, etc.

Puntualmente, dentro de un equipo de trabajo, una vez definidos los canales de comunicacion entre todos los miembros, lo que debe fluir por ellos es información que sea válida, clara y útil para el desarrollo y conclusión de las diferentes actividades. Debemos elaborar y adueñarnos de la necesidad de comunicar con responsabilidad.

Les dejo una anécdota de Socrates que grafica este punto de la responsabilidad e invita a aplicarla en nuestros proyectos profesionales, y nuestro proyecto mayor: nuestra vida.

En la antigua Grecia, Sócrates fue famoso por su sabiduría y por el gran respeto que profesaba a todos. Un día un conocido se encontró con el gran filosofo y le dijo:
¿Sabes lo que escuche acerca de tu amigo?.
Espera un minuto -replico Sócrates-. Antes de decirme nada quisiera que pasaras un pequeño examen. Yo lo llamo el examen del triple filtro.
¿Triple filtro?
Correcto -continuó Sócrates-. Antes de que me hables sobre mi amigo, puede ser una buena idea filtrar tres veces lo que vas a decir. Es por eso que lo llamo el examen del triple filtro. El primer filtro es la verdad.
¿Estás absolutamente seguro de que lo que vas a decirme es cierto?
No -dijo el hombre-, realmente solo escuché sobre eso y….
Bien -dijo Sócrates-. Entonces realmente no sabes si es cierto o no.
Ahora permíteme aplicar el segundo filtro, el filtro de la bondad. ¿Es algo bueno lo que vas a decirme de mi amigo?
No, por el contrario…
Entonces, deseas decirme algo malo sobre él, pero no estás seguro de que sea cierto. Pero podría querer escucharlo porque queda un filtro: el filtro de la utilidad. ¿Me servirá de algo saber lo que vas a decirme de mi amigo?
No, la verdad que no.
Bien -concluyó Sócrates-, si lo que deseas decirme no es cierto, ni bueno, e incluso no me es útil, ¿para qué querría yo saberlo? !!!

Saludos, Gastón