Pensando qué probar

Anteriormente comenté sobre nuestra misión como testers. Entre las cosas que tenemos que hacer, obviamente unas muy importantes son:

• Cuestionar y evaluar el producto.
• Focalizar los riesgos, entender y gestionar los cambios.

Y pensando en cómo cuestionar y evaluar el producto, hay mucho que podemos leer, discutir, hacer o dejar de hacer, en relación a planificación, diseño, exploración, preparación de condiciones y casos de prueba, no preparación, no diseño, etc.

Sabemos que hay muchas opiniones y criterios a este respecto, y diferentes “escuelas” o tendencias, pero, en definitiva, escribamos o no las condiciones y casos de prueba, las escribamos a un gran nivel de detalle o no, lo primero que aparece es la necesidad de entender en qué consiste el producto que tenemos que cuestionar y evaluar, y cómo focalizamos los riesgos que hayamos identificado en el marco de nuestra misión.

O sea, tanto cuando nos sentemos a explorar un producto, como cuando nos sentemos a diseñar condiciones y casos de prueba formalmente, tendremos que seguir algún orden o lineamiento para encarar estas actividades.

Algunos lineamientos

Algunos obvios y probablemente explicitados, otros no tan obvios, o no tan fácilmente identificables, y en muchos casos no cuantificados (los números no implican orden):

1. Requerimientos que el producto tiene que satisfacer: lo que dice “la caja”, los manuales o las especificaciones funcionales, otros requerimientos regulatorios o normativos.

2. Usos típicos que el producto va a tener: lo que los usuarios tienen que poder hacer, en los distintos escenarios posibles; interacciones con procesos manuales, interacciones con otros sistemas.

3. Atributos de calidad establecidos para el producto, muchos relacionados con requerimientos no funcionales, por ejemplo, los caracterizados por las normas ISO de calidad de producto (Norma IRAM ISO IEC 14598, la serie ISO 9126, y la norma ISO 25000 actualmente en desarrollo), o simplemente, las restricciones que puede imponer un pedido de usuario en relación a una arquitectura técnica. Entre otros, performance, usabilidad, mantenibilidad, escalabilidad.

4. Posibles fallas, o cómo imaginamos, en base a experiencia, características del producto, arquitectura, catálogos de fallas conocidos, etc., que el producto puede fallar. (Esta técnica, llamada Risk Based Testing – RBT, será objeto de otros artículos más adelante. Como comentario, es más que una simple técnica).

Qué nos sirve de base para pensar más allá de la especificación:

1. El requerimiento.
Si no está escrito, cuál podemos imaginar o relevar que es, desde el punto de vista del negocio.

2. El contexto.
Qué parte de una función de negocio estamos viendo, en qué casos se utilizará, por qué tipo de usuario.

3. Interfaces posibles.
Con otros sistemas, con otras transacciones, con otros aspectos del negocio, dentro o no del sistema que estamos probando.

Cómo analizamos la especificación:

1. Pensándola como Caso de Uso (aunque no esté expresada así):

a. Requerimiento que contribuye a resolver.
El CU corresponde a un requerimiento completo o a parte de él?
Cuáles son las demás partes?
Las vemos de alguna forma?
Podemos graficar las interacciones?

b. Actores.
Quiénes, con qué permisos, tenemos que probar expresamente seguridad
(acceso, funcionalidad, datos)? 
Cómo llega el actor a esta funcionalidad?
Hay varios caminos posibles?
De qué dependen?

c. Precondiciones.
Qué se tiene que cumplir para entrar al curso normal del CU.
Qué pasa si no se cumple alguna precondición?
Todas son obligatorias? Si no, está claro por qué o cuándo se requiere cada una?

d. Poscondiciones.
Qué se tiene que cumplir para considerar que el CU terminó bien?
Qué pasa si esto no ocurre?
Cuál debe ser el estado final si se produce algún error? Está claramente expresado?
Qué pasa si no se cumple alguna poscondición?
Todas son obligatorias? Si no, está claro cuándo puede faltar cada una?

e. Curso normal: es único y bien definido?
Hay alternativas al curso normal que no sean por errores o cancelaciones?
Qué reglas de negocio aplican? Fórmulas? Decisiones?

f. Cursos alternativos:
“Positivos”, transacciones exitosas pero que se apartan del curso normal; “Negativos” debido a errores, interrupciones, cancelaciones, timeouts, reglas de negocio que no se cumplen, etc.
Podemos identificar qué los hace ser diferentes, y cómo debe terminar cada uno? (datos opcionales, mensajes especiales de error, distinto output, etc).

2. Pensándola como proceso: Entradas -> Actividades -> Salidas:

a. Cómo se inicia el proceso, o qué interfaces de usuario intervienen, reglas que aplican, consistencias puntuales de datos, obligatoriedad, puntos de menú… .

b. Actividades, qué se hace sobre los datos o con ellos, qué más se consulta o lee o modifica, bajo qué condiciones se hace cada cosa?

c. Qué tiene que dar como resultados el proceso (y qué no), qué vuelve al usuario y qué puede quedar oculto pero necesitamos validar (estadísticas, logs, archivos temporales, …).

Cómo decidimos qué se justifica probar: Pensando en los riesgos

Es casi una deformación profesional para los testers (o debería serlo), pensar en los riesgos para determinar qué se justifica probar. El objetivo es siempre utilizar los (escasos) recursos de prueba, en pasar por las funcionalidades o no funcionalidades críticas y/o importantes para la aplicación y para los distintos interesados y usuarios.
Normalmente trataremos de incluir en las pruebas, en base a dicha criticidad / riesgo, casos de prueba para estas situaciones / atributos:

1. Cursos normales bajo entradas habituales (mínimas obligatorias por ejemplo)

2. Cursos normales bajo entradas no tan habituales (todos los campos no obligatorios)

3. Cursos alternativos, al menos uno de cada uno, importante según las reglas del negocio

4. Situaciones que puedan no estar contempladas (fallas de HW o SW o aplicación en algún punto relacionado, entradas o resultados muy fuera de rangos, zapato sobre el teclado…)

5. Performance, seguridad, volúmenes, si se considera necesario o surge alguna duda

6. Procesos periódicos

7. Interacciones típicas y/o inesperadas entre procesos que se comunican

8. ….

Obviamente la lista puede ser ampliada y completada con muchísimas variaciones y enfoques, pero nuestro tiempo siempre será escaso, por lo que tendremos que recortarla en función a las necesidades de interesados, producto, proyecto, y a las herramientas disponibles.

Nuestra mejor recomendación: Riesgos, triage de ideas sobre qué probar, y sentido común!!!!!

Las habilidades “blandas” (soft skills) del Jefe de Proyecto – Conversaciones Difíciles (Difficult Conversations) –in spanish

Coincidiendo con la propuesta del American Management Association Handbook acerca de las habilidades requeridas en el Jefe de Proyecto, creemos que el desafío de este rol está en la combinación de dos áreas distintas de competencia:

· la Ciencia de la Administración de Proyectos (hard skills): planificación, WBS, Gantt, estándares, CPM / diagramas de precedencia, análisis de variaciones, métricas, earned value, administración de riesgos, reportes de avance, estimación y nivelación de recursos,

· y el Arte de la Administración de Proyectos (soft skills): comunicación efectiva, confianza, valores, integridad, honestidad, sociabilidad, liderazgo, desarrollo del equipo, flexibilidad, toma de decisiones, resolución de problemas, comprensión del negocio, negociación, relación con el cliente, manejo del cambio, manejo de expectativas, consultoría.

En este blog hemos dedicado entradas a ambas áreas y en esta oportunidad proponemos encarar el tema de “Conversaciones Difíciles”, qué son y cómo se manejan, aplicables a todos los temas de negociación, resolución de problemas y comunicación efectiva.

- oo -

A menudo, como Jefes de Proyecto debemos encarar situaciones complicadas que en la mayoría de los casos desembocan en lo que llamaremos “conversaciones difíciles”.

Sobre el tema de este tipo de interacciones, el Harvard Negotiation Project desarrolló varios trabajos hoy convertidos en los libros guía acerca de negociación y manejo de conflicto. En la bibliografía más abajo detallada mencionamos algunos de ellos.

En particular sobre el tema de conversaciones que tratan temas importantes y delicados para las personas que las están manteniendo, el trabajo de Stone, Patton y Heen, es esclarecedor. Como además lo consideramos crucial para aquellas personas que tienen el rol de conducción en un equipo de trabajo, comentaremos aquí los conceptos principales del enfoque.

Ejemplos de una conversación difícil:

· Dar una evaluación desfavorable a un empleado

· Juzgar y criticar el trabajo de un colega

· Comunicar a un amigo que está despedido

· Informar al Cliente que el proyecto en el que trabaja tomará el doble de lo que se le prometió.

· Hablar con un compañero de equipo que se comporta en forma inadecuada o hace comentarios ofensivos

· Darle feed-back al jefe acerca de su comportamiento

· Finalizar una relación

· Pedir a un amigo que nos devuelvan dinero que prestamos

· ………

La granada

Una comparación interesante de los autores sobre las conversaciones difíciles es la siguiente:

• No existe “tirar una granada de mano en forma diplomática”

  • Dar un mensaje difícil es como tirar una granada

    • Endulzada, lanzada más o menos suavemente, la granada siempre será una granada y hará daño.
    • No hay manera de arrojarla con tacto para evitar consecuencias.

  • Podríamos guardarnos la granada para nosotros

    • Por ejemplo no decir nada.
    • Tampoco es lo mejor. No dar un mensaje difícil es como retener una granada, sin el seguro colocado.

Cómo se gesta una conversación difícil

Qué queremos hacer

Dar un mensaje importante para la persona que lo recibe y para nosotros.

Por qué aparece

Los posibles orígenes son: conflicto de posiciones o intereses, opiniones distintas sobre un tema laboral o personal, dar una noticia que sabemos la persona no recibirá bien.

Por qué cuesta decidirse

Tememos que el resultado incierto nos haga perder algo, la confrontación no nos gusta y la posibilidad de fallar nos hace sentir mal.

Tratamos de evitar estas conversaciones a diario.

Análisis de una conversación difícil

En el análisis de este tipo de interacciones, los autores postulan la existencia de tres conversaciones que ocurren a la vez:

Acerca de qué sucedió (los hechos)

Esta conversación trata sobre la historia que cada una de las partes relata.

Normalmente cada uno piensa que el problema está en el otro.
El choque entre ambas historias genera la situación difícil.

Acerca de los sentimientos (los sentimientos)

Esta conversación trata acerca de los sentimientos. Las partes piensan que los mismos son irrelevantes y no es útil compartirlos, evitando así hablar de lo que sentimos en el momento de la conversación.
Estos sentimientos no expresados hacen muy difícil escuchar al otro.

Acerca de nuestra imagen (la identidad)

Esta conversación trata acerca de la propia imagen de cada interviniente. Se ve la interacción como una amenaza a nuestra idoneidad, soy competente o incompetente, soy bueno o malo. Es a todo o nada.
Nos enfrentamos a la otra persona y a nosotros mismos.

El entender esta dinámica, hará que al encarar una conversación de este tipo sepamos a que nos estamos enfrentando, más allá de lo que se dice.

Veamos un poco más detalladamente cada conversación en particular.

Conversación sobre los hechos

La historia de cada uno

Cada uno cuenta la historia de modo que tenga sentido su reclamo, sacando conclusiones que apoyan su punto de vista y que no tienen sentido en la historia de la otra parte, perdiendo objetividad. Las historias diferentes chocan y entonces la conversación de complica.

Además argumentamos, con lo cual bloqueamos la posibilidad de escuchar. Argumentar sin comprender no es útil ni persuasivo.

Todo esto no es la consecuencia, sino la causa del problema.

La intención

El primer problema son los supuestos que cada parte hace acerca de las intenciones del otro. Asumimos mala intención, la medimos por el impacto que causa en nosotros, ponemos al otro a la defensiva y se agrava la hostilidad.

La contribución de cada uno

Nos enfocamos en quién tuvo la culpa, miramos hacia atrás y evaluamos cómo debe ser juzgado y castigado el culpable. La búsqueda de culpas hace más difícil encontrar la verdad.

Un análisis positivo analizaría la contribución de cada uno al problema, mirando hacia adelante y viendo cómo evitar que se repita.

Conversación sobre los sentimientos

Como regla no escrita, tratamos de dejar los sentimientos fuera de la conversación, pensando que demostrarlos es un síntoma de debilidad.

Cuáles son esos sentimientos por ejemplo: frustración, temor, sentirse traicionado, enojado, ansioso, y muchos más.

Sin embargo, los sentimientos indefectiblemente se filtrarán en nuestro lenguaje corporal, tono de voz o expresión facial y fácilmente la otra parte podrá leerlos.

Estos sentimientos no expresados, harán que no escuchemos y bajarán nuestra autoestima.

Esta situación también se da, como en los casos anteriores, en ambas partes, haciendo difícil que se escuchen y se entiendan.

Conversación sobre la imagen

Las conversaciones difíciles amenazan nuestra identidad. Nos enfrentamos a la otra persona y a nosotros mismos.

No es raro que nos hagamos las siguientes preguntas: seré un tonto?, me veré como un incompetente?, etc.

Simplificamos demasiado nuestra imagen llevándola al “todo o nada”, soy competente o incompetente, soy bueno o malo, sin entender que lo que hacemos es que sus respuestas nos definan, blanco o negro, hábil o tonto.

- oo -

Habiendo ya desagregado la conversación difícil en sus componentes, hechos, sentimientos e imagen, cómo seguimos?

Las opciones que tenemos son dos, dejar pasar la conversación, o hablar.

Para decidir, evaluaremos la importancia del conflicto origen de la posible conversación, y si hay otro método de encarar el tema que no sea hablándolo.

Recordemos que, si lo hablamos, debemos darnos el tiempo para esta conversación, no “golpear y correr”.

Qué hacemos entonces, hablamos o no hablamos?

Dejar pasar la conversación difícil

Recordar que dejar pasar no quiere decir olvidar, sino que podremos retomarlo en otro momento.

Recordando el caso de la granada planteado al principio, no deberíamos guardar una granada sin el seguro puesto.

Encarar la conversación difícil

Lo primero es informarnos, conocer la historia del otro, cómo afecta el tema sus sentimientos y su identidad.

Expresar nuestros sentimientos y puntos de vista y encarar la resolución en conjunto.

- oo –

Cómo comenzar y mantener una conversación difícil

El comienzo de una conversación de este tipo es uno de los temas más complejos. Habitualmente comenzamos con nuestro punto de vista, vamos directo al problema y levantamos inmediatamente un problema de imagen o identidad en el otro, poniéndolo así a la defensiva.

Una forma alternativa de comenzar, recomendada por los autores, es iniciar el dialogo desde una “tercera historia”, es decir la situación vista desde el punto de vista de un tercero, como un mediador, que resume ambas historias y crea una tercera totalmente creíble para cada uno de los interesados. Esta nueva historia evita los juicios de valor y se centra fundamentalmente en las diferencias.

Enfocado así el comienzo, podemos invitar a la otra parte a buscar juntos la solución, viendo el punto de vista de cada uno y empezando por lo que importa. Recordemos que, si tenemos que dar malas noticias no deben quedar para el final, debemos decirlas sin endulzarlas. Si estamos pidiendo o reclamando algo debemos invitar a pensar si es justo el pedido y finalmente si ya hubo una instancia previa de dialogo y fracasó, invitar a revisar cuál fue la causa de esa falla.

Hecho esto, recorremos el camino de las tres conversaciones, escuchando las historias mediante la escucha activa, parafraseando para mostrar interés, preguntando y siendo curioso.

Expresando los sentimientos y reconociendo los sentimientos de la otra persona, lo cual no quiere decir aceptarlos, y aclarando los problemas de identidad que surjan en el camino del dialogo.

Escuchar y expresarse son las claves de esta etapa.

Resolución del Problema

Una vez en esta etapa de la conversación, tratamos de extraer la esencia de las tres conversaciones, cuáles fueron los hechos, qué sentimientos hay involucrados y qué problemas de imagen se levantaron durante la interacción.

El objetivo es re-encuadrar, buscando la verdad en las diferentes historias, tratando de aclarar las intenciones y el impacto de las mismas, en lugar de buscar la culpa, ver la contribución que cada uno tuvo al problema. Todo es posible de ser reencuadrado.

Siempre escuchar y explicitar cómo se está dando la situación, qué se va descubriendo y acordando.

Finalmente buscar opciones, inventarlas, buscar salidas que sean justas para ambos, si existen soluciones estándar para el problema que se está tratando, proponerlas.

Pensar la salida que contemple el cuidado mutuo. El “salvar la cara” de ambos es crucial, las soluciones en una sola dirección, rara vez duran.

Finalmente si todo falla, tener paciencia, revisar las alternativas y buscar otras nuevas. Hablar de cómo mantener la comunicación abierta a medida que se avanza. Darse tiempo.

Conclusión

Las ideas aquí analizadas muestran los posibles componentes de una conversación difícil.

Una forma sencilla de corroborar la propuesta de los autores Stone, Patton y Heen es tratar de observar alguna interacción de este tipo y buscar las tres conversaciones, los hechos, los sentimientos y la identidad. Verán que se distinguen fácilmente, también detectarán que en la mayoría de los casos los conflicto se espiralizan por no reconocerlos y tratarlos.

Esperamos que las técnicas aquí propuestas ayuden a mejorar el desarrollo de los proyectos, ya que de acuerdo a nuestro punto de vista:

Un proyecto es una organización de personas, que aplica técnicas definidas para lograr un objetivo. No utilizar estas técnicas, o hacerlo pobremente, posiblemente conduzca a no lograr lo buscado, pero ignorar los conflictos que pueden surgir de las interacciones entre las personas, seguramente nos llevará al fracaso.

- oo –

Hasta la próxima.

Raúl

Bibliografía:

Difficult Conversations: How to Discuss What Matters Most, Douglas Stone, Bruce Patton, & Sheila Heen

Getting to YES, Negotiating an agreement without giving in, Roger Fisher and William Ury

Failure to Communicate, How conversations go wrong and what you can do to right them, Holly Weeks

Crucial Conversations, Patterson, Grenny, McMillan, Switzler

The Wisdom of Teams. Katzenbach, Smith

¿Control de Calidad y Control de Proyecto es lo mismo?

Transcripción del paper ¿Quality Control = Project Control? (Indicadores Objetivos para el Control de Proyectos de Desarrollo de Software), publicado originalmente como parte del PMI Global Congress Proceedings (2004, Buenos Aires, Argentina) y presentado posteriormente en el SEPG LA ESI/SEI (2005, Guadalajara, México). El material original pueden descargarlo desde aquí.

---

Introducción

El Problema

Es común que los proyectos de desarrollo de software terminen con importantes desvíos en costo y calendario o, en algunos casos, que no terminen. Existen muchas causas a este problema. Una de ellas es no contar con buenas herramientas de control, a pesar de que generalmente tenemos buenas herramientas de planificación. El objetivo de este trabajo es presentar algunas ideas que ayudan a tratar esta causa.

Como líderes de proyecto, nos hacemos muchas veces las siguientes preguntas:

¿Cuál es el grado de avance? ¿En qué fecha terminaremos? ¿Cuánto gastaremos realmente?

Normalmente no encontramos las respuestas o las encontramos y son muy poco confiables. Eso hace que no tengamos buenos elementos para tomar decisiones.

Problemas clásicos

Uno de los problemas típicos es el síndrome del 90% (figura 1), síndrome por el cual el proyecto avanza sin problemas hasta que llega al 90% y se estanca.

 

Figura 1 – Síndrome del 90%

Normalmente esto sucede porque utilizamos información subjetiva para registrar avance y cuando nos enfrentamos a la realidad, nos enteramos que el avance no era real. La realidad puede estar dada por una etapa de prueba o por un usuario enfrentándose por primera vez al producto. Si hubiésemos contado con información objetiva en el momento adecuado, tal vez hubiéramos sabido que el proyecto estaba al 20% cuando todos creíamos que estaba al 50%. Esto nos hubiera permitido tomar las decisiones correctas en el momento correcto.

Primer paso para una solución

Lo primero que debemos entender como líderes de proyecto es que no podemos basarnos en información subjetiva para tomar decisiones. Esto parece trivial, pero es muy común el “pensamiento mágico” en proyectos de desarrollo de software. Como líderes, no debemos concluir que hay avance sólo porque alguien dijo “avanzamos”, debemos reunir evidencia física.

Control de Proyectos basado en Control de Calidad

Una posible evidencia física que sirve como base para la registración de avance puede ser una porción de software construida. En un proyecto en donde existe un equipo de desarrollo y un equipo de prueba que trabajan en paralelo, podemos registrar avance periódicamente basado en evidencia física. ¿Cuál es la evidencia?

El producto desarrollado... pero también probado... y estabilizado (sin defectos críticos).

De esta manera estamos utilizando el resultado de Control de Calidad como información de entrada para el control. Adicionalmente podremos medir no sólo la velocidad de construcción, sino también la velocidad de corrección, obteniendo información sobre cuánto demorará la estabilización del producto.

 

¿Cuál es el grado de avance?

El Problema

Existen errores clásicos a la hora de medir avance en proyectos de desarrollo de software:

a) Avance por calendario: se mide avance sólo por paso del tiempo. Aunque parezca trivial, es algo muy común. Planificamos una tarea para que se complete en 20 días. Al décimo día informamos que estamos al 50% sin verificar que efectivamente hayamos realizado el 50% del trabajo.

b) Avance por código completo: se mide avance cuando una porción del código está completa, pero sin saber el grado de estabilidad que tiene. Decimos que un determinado módulo de la aplicación está al 100% porque el desarrollo ha terminado, pero ¿Tiene defectos? ¿Cumple con los requerimientos de los usuarios?

Ambos errores llevan al síndrome del 90% que nombramos anteriormente.

El Indicador de Funcionalidad Completa

El indicador de Funcionalidad Completa mide avance cuando una funcionalidad está completa, pero...

No hay avance si la funcionalidad no está completa

No está completa la funcionalidad si no está desarrollada, probada y estabilizada.

Paso 1 - Determinar las Funcionalidades

El primer paso para armar este indicador es encontrar las funcionalidades (Anderson, 2004, p. 184). Para ello dividimos el producto a construir en partes. ¿Cuántas funcionalidades? Debemos buscar una cantidad óptima que balancee el detalle necesario para medir avance con la carga administrativa para mantener el indicador.

Paso 2 - Asignar un Peso a cada funcionalidad

Hay funcionalidades más costosas que otras. Es indispensable conocer el costo de las funcionalidades, ya que en caso contrario, registraríamos el mismo avance por una funcionalidad simple que por una compleja. Dado que no es sencillo conocer el costo exacto de cada funcionalidad se propone para este indicador asignar un peso a cada funcionalidad. Cuando más detallado sea el peso, más exacta será la información de avance, pero más difícil será calcularlo. En la práctica suele alcanzar con clasificar a las funcionalidades en Simples, Medianas o Complejas.

Existen variantes para asignar pesos. La elección correcta depende del tamaño del proyecto y de la información que tengamos al momento de calcular el peso. Pero no debemos olvidar que tenemos que balancear exactitud con carga administrativa. Veamos algunos ejemplos de convenciones de peso:

a) Caso 1: Clasificar a las funcionalidades en Simples (1), Medianas (2) o Complejas (3)

b) Caso 2: Variante del anterior, pero utilizando 5 estados (Anderson, 2004, p. 187)

c) Caso 3: Utilizar como peso la cantidad de esfuerzo que se ha estimado para construir la funcionalidad. En este caso tendremos más exactitud y puede ser utilizable cuando ya disponemos de esta información en el momento de armar el indicador.

Paso 3 - Estimar la fecha en que la funcionalidad estará completa

Paso 4 - A medida que avanza el proyecto registrar las fechas reales de funcionalidad completa

Con toda la información registrada (tabla 1) obtenemos el Indicador de Funcionalidad Completa (figura 2).

Tabla 1 – Datos para el Indicador de Funcionalidad Completa

Figura 2–Indicador de Funcionalidad Completa

Obsérvese en el ejemplo que el eje vertical acumula los puntos de funcionalidad completa (PFC), sumando los pesos en cada fecha. En este caso la convención es: una funcionalidad simple equivale a 1 PFC, una funcionalidad media a 2 PFC y una funcionalidad compleja a 3 PFC.

Información adicional

a) Curva de código completo: muestra cuándo el equipo de desarrollo entrega código nuevo al equipo de control de calidad. Ese código aún no está probado ni estabilizado. Se debe tener especial cuidado con las conclusiones que se obtengan con esta curva ya que no está basada en evidencia física validada y suele ocultar el síndrome del 90%.

b) Curva de funcionalidad aprobada por usuario: marca la funcionalidad que además de estar completa ha sido validada por el usuario final. Indica el avance más seguro ya que posee una aprobación de usuario. A diferencia de la funcionalidad completa, es imposible lograr avance semanal con esta curva, pero debería aumentar escalonadamente cada vez que el proyecto realice una entrega al usuario. Es muy útil graficarla, especialmente si trabajamos con un esquema de entregas incrementales al usuario (Pussacq Laborde, 2003, p. 12).

c) Productividad: se obtiene dividiendo los PFC reales sobre la unidad de tiempo. En la figura anterior, la productividad es 3 PFC x Sem (15 PFC reales / 5 semanas reales). Esto nos permitiría hacer la siguiente extrapolación lineal: necesitaré 13,33 semanas para obtener los 40 PFC restantes (40/3). Puede servir para predecir el futuro (figura 3).

Figura 3–Indicador de Funcionalidad Completa con proyección

Consideraciones sobre este indicador

a) Validez: este indicador sólo es válido en etapa de construcción. No se utiliza en el período final de estabilización ya que durante ese período la funcionalidad real es similar a la planificada.

b) Proceso: este indicador no generará avance si el equipo no se focaliza en cerrar temas. El indicador es binario, la funcionalidad está completa o no está.

c) Síndrome del 0%: si se considera completa a una funcionalidad cuándo no tiene ningún defecto, evitaremos el síndrome del 90%, pero caeremos en el síndrome del 0%, es decir, no registraremos avance porque siempre habrá algún defecto pendiente. Es por eso que una funcionalidad está completa cuando no posee defectos críticos, pero sí tiene defectos pendientes.

d) Funcionalidad = código: es su forma más pura, este indicador sólo considera funcionalidad al producto final para el usuario. Una especificación no es producto final. Sin embargo, en algunos proyectos en donde hay una marcada etapa de análisis al principio y un equipo de control de calidad que verifica el análisis, puede considerarse funcionalidad a la especificación para poder utilizar este indicador como una herramienta de control.

El Indicador de Nivel de Calidad

Como vimos hasta ahora, el indicador de funcionalidad completa divide al producto en dos estados: funcionalidad completa o no completa. Algunas veces necesitamos utilizar estados intermedios. Estos estados muestran el ciclo de vida por el que va pasando el producto desde el punto de vista de la calidad (figura 4) y permiten tener un indicador más detallado que denominamos Nivel de Calidad (tabla 2, figura 5).

Figura 4–Estados utilizados por el Indicador de Nivel de Calidad

Tabla 2 – Datos del Indicador de Nivel de Calidad

Figura 5 – Indicador de Nivel de Calidad

Análisis de Avance

Si clasificamos cada funcionalidad de diferentes maneras, podremos hacer distintos análisis de avance con mayor o menor nivel de detalle. Por ejemplo por: Tarea, Producto (figura 6), Sub nivel de Producto, Equipo, WBS, Ciclo de Negocio, etc.

Figura 6 – Funcionalidad Completa dentro de cada Producto en un Proyecto

Si bien la funcionalidad completa es binaria (está completa o no), podemos obtener un porcentaje de avance si agrupamos en un nivel superior. El producto Administración de Clientes (figura 6) puede contener 100 funcionalidades de las cuales hay 41 que ya están completas.

 

¿En qué fecha terminaremos?

El Problema

Como dijimos, es muy común que los proyectos de software se desvíen. Con el indicador de funcionalidad completa podemos obtener una tendencia que nos permite predecir el futuro y en consecuencia la fecha de fin. Pero siempre es una incertidumbre conocer cuánto costará en tiempo y recursos la estabilización (Microsoft, 2002, p. 34-40) de un producto. La etapa de estabilización comienza cuando el indicador de funcionalidad completa deja de tener validez. En este punto ya está todo construido, sólo resta corregir los defectos remanentes y encontrar los que no encontramos aún. La pregunta entonces es ¿Cuándo liberaré?

El Indicador de Evolución de la Prueba

El indicador de Evolución de la Prueba se basa en una idea simple: medir los defectos, cuántos aparecen y cuántos se cierran por día (McConnell, 1996, p. 384):

Paso 1 - Registrar los defectos nuevos a medida que aparecen

Paso 2 - Registrar los cambios de estado de los mismos hasta que se cierran definitivamente

Cumpliendo esos dos pasos, podemos obtener el Indicador de Evolución de la Prueba (figura 7).

Figura 7 – Indicador de Evolución de la Prueba

Analizando el comportamiento de los defectos a lo largo del proyecto este indicador nos permite obtener estadísticas que determinan la velocidad de corrección y por lo tanto el tiempo estimado para estabilizar el producto. Podemos saber cuántos defectos se encuentran y cuántos se cierran en un determinado período de tiempo, por ejemplo las últimas dos semanas. Si la muestra es representativa y se elige el período correcto de análisis, se pueden obtener algunas conclusiones:

- Buenas conclusiones: el proyecto está bajo control, el proyecto finaliza en tres semanas.

- Malas conclusiones: aparecen más defectos por día de los que cerramos, no terminaremos nunca.

Cuando aplicamos un proceso de prueba en paralelo, el volumen de defectos es alto, lo que nos permite que las muestras analizadas en general sean representativas. Teniendo en cuenta esto y tomando con cautela las proyecciones lineales, el indicador nos puede ayudar a tomar algunas decisiones como las siguientes: agregar más recursos para corregir defectos, recortar funcionalidad, priorizar el orden de corrección, no corregir todos los defectos (suspender), etc.

Consideraciones sobre este indicador

a) Validez: este indicador es válido durante todo el proyecto cuando hay prueba en paralelo al desarrollo. Si sólo hay prueba al final, el indicador es muy útil durante la etapa de prueba final y estabilización.

b) Proceso: el indicador es muy útil para detectar el síndrome del 90 %, por ejemplo cuando avanza el código completo, pero la funcionalidad posee gran cantidad de defectos pendientes. Asimismo ayuda a detectar si se está aplicando en forma correcta el proceso de desarrollo y prueba en paralelo. En el ejemplo (figura 7) el proceso se está aplicando adecuadamente.

El Indicador de Cobertura de la Prueba

Si se complementa la Evolución de la prueba con la Cobertura de la prueba, podemos obtener información más exacta. La Cobertura de la Prueba muestra cuánto habría que probar, cuánto se pudo probar y cuánto funciona bien. Está medición la realiza a partir de los estados (Kit, 1995, p. 135) de los casos de prueba (figura 8):

a) Planificados: cantidad de casos a ejecutar.

b) Disponibles: lo que realmente puedo ejecutar teniendo en cuenta lo que el equipo de desarrollo entregó al equipo de prueba.

c) Ejecutados: lo que el equipo de prueba pudo ejecutar.

d) Ejecutados OK: casos ejecutados sin errores. Es otra forma de ver avance del proyecto.

Figura 8 – Indicador de Cobertura de la Prueba

Este indicador puede ser utilizado para tener otra forma de validar avance del proyecto. El avance está dado por los casos de prueba que han sido ejecutados sin problemas.

Por otro lado, utilizando el indicador de cobertura para saber cuánto falta probar y tomando la información de defectos del indicador de evolución de la prueba podemos calcular cuántos defectos más aparecerán. Con este dato y la fecha de fin estimada podríamos controlar cuántos defectos deberíamos estar encontrando y cerrando por día. El objetivo: mantener bajo control la etapa de estabilización.

 

¿Cuánto gastaremos realmente?

El Problema

Ya conocemos el grado de avance y tenemos menos incertidumbre sobre la fecha de fin, pero... ¿Cuánto costará realmente? Consideramos útil para responder esta pregunta utilizar el indicador de Earned Value. Una de los problemas más importantes de este indicador es la dificultad para calcular el valor ganado en proyectos de desarrollo de software. La propuesta es utilizar el avance calculado por funcionalidad completa para calcular el valor ganado. Esto tiene algunas ventajas y algunas desventajas que analizaremos.

El Indicador de Earned Value

No es propósito de este trabajo explicar Earned Value (Durrenberger, 2003), sino mostrar un indicador de Earned Value creado a partir de un indicador de Funcionalidad Completa (tablas 3 y 4):

 

Tabla 3 – Earned Value basado en Funcionalidad Completa

Tabla 4 – Indicador de Earned Value resumido

Consideraciones sobre este indicador

a) Alcance: es necesario separar los costos que no están asociados directamente a la construcción de software. Por ejemplo, la adquisición de un equipo, la planificación inicial, el despliegue, etc. Otros costos, como la administración del proyecto, podrían distribuirse dentro de los PFC.

b) Validez: al igual que el indicador de Funcionalidad Completa, sólo aplica a la construcción, no a la estabilización.

c) Margen de error: existe cierto margen de error aceptable con el objetivo de no aumentar la carga administrativa debido a:

- Los pesos generan información inexacta

- El Actual está insumido en funcionalidades que aún no están completas

- Los costos indirectos que se distribuyen en los PFC pueden generar margen de error.

Conclusiones

Hemos presentado una serie de indicadores cuyo objetivo es controlar un proyecto de desarrollo de software. Cuanto más exacto es un indicador más difícil es su aplicación real, por lo cual hemos intentando balancear las siguientes características:

a) Objetividad: los indicadores deben registrar información objetiva, basada en evidencia física y no en una opinión subjetiva del que la genera.

b) Administración: si bien los indicadores tienen costo, no deben poseer demasiada carga administrativa si queremos que la implementación sea eficiente.

c) Foco en resultados: un buen indicador no mide inversión, sino lo que obtengo de ella.

d) Comprensión: deben mostrar información comprensible por el auditorio.

Todos los indicadores presentados tienen como objetivo mostrar el estado del proyecto, por ejemplo a través de un Tablero de Control (figura 9) y mejorar la toma de decisiones. Pero es importante tener en cuenta que además son muy útiles para detectar fallas en el proceso como por ejemplo: equipo mal enfocado, acumulación de código, casos de prueba poco eficientes, necesidades de priorización de defectos, etc.

 

Figura 9 – Tablero de Control

Los indicadores presentados han sido utilizados en proyectos reales demostrando su valor a los responsable de la toma de decisiones. Se debe tener en cuenta que no todos los proyectos necesitan todos los indicadores. Esto puede ser variable dependiendo de las características iniciales del proyecto y de los cambios que el mismo proyecto sufra a lo largo de su historia. Sin embargo, en líneas generales podemos recomendar que como mínimo se utilice el indicador de Funcionalidad Completa y el indicador de Evolución de la Prueba.

Bibliografía

Anderson, D.J. (2004). Agile Management for Software Engineering. Upper Saddle River: Prentice Hall.

Durrenberger, M. (2003). An Earned Value Tutorial. Retrieved 20/Jul/2004, from http://www.oakinc.com/pdf/EVTutorial.pdf

Kit, E. (1995). Software Testing in the real world. USA: ACM Press.

McConnell, S. (1996). Rapid Develoment. Redmond. Washington: Microsoft Press.

Microsoft. (2002, Junio). MSF Process Model v.3.1. Microsoft Solutions Framework. Retrieved 5/Jul/2004, from http://www.microsoft.com/msf

Pussacq Laborde, J.P. (2003). Daily Build & Smoke Test - Administración. Retrieved 27/Oct/2004, from http://www.rmya.com.ar/Download/Daily%20Build%20and%20Smoke%20Test.pdf

Manejando la resistencia al cambio (Siempre hemos tenido éxito)

Si usted es CIO, CEO, Gerente, Jefe, Presidente, Líder o consultor como yo, seguramente ha estado involucrado alguna vez (o en este preciso instante) en la implementación de un cambio en alguna Organización. Y seguramente se encontró o se encuentra lidiando con al menos una persona que esté ejerciendo resistencia al cambio.

Estas personas, lejos de ser una anécdota, pueden convertirse en importantes obstáculos para el proceso de cambio que estamos liderando (consultar el artículo “Cambio? Qué cambio?” para una visión integral del proceso de cambio). John Kotter describe en su libro El Sentido de la Urgencia cinco métodos para manejar esta situación: dos que no funcionan  y tres que sí. Sobre estos métodos trata este artículo:

Introducción

Lo primero que debemos hacer es diferenciar a un escéptico del opositor al cambio. Un escéptico necesita más información y en algunos casos pueden ayudar a mantener un impulso entusiasta bajo control. De todas maneras, son algo molestos y no es bueno tener demasiados.

El opositor es diferente, hará cualquier cosa para obstaculizar el proceso de cambio, aunque no necesariamente lo hará abiertamente. Puede estar oculto, o puede trabajar en forma oculta generando y ampliando la resistencia vía técnicas como el contagio.

A pesar de la gravedad de lo que estamos diciendo, tendemos a restarle importancia a este tema, quizá pensando que se resolverá mágicamente, pero como siempre me gusta decir, Harry Potter no es parte del equipo.

Búsquenos cooperación en el opositor (no funciona)

Este tipo de acción es bastante típica. Surge luego de haber identificado claramente al opositor y luego de haber evaluado distintas alternativas, se opta por tratar de lograr que el opositor esté de nuestro lado. Parece ser la única estrategia realista, y bastante elegida cuando confundimos al opositor con un escéptico.

Casi nunca funciona esta estrategia y pueden herir a nuestra Organización. Se pierde mucho tiempo mientras tratamos de lograr la cooperación y el opositor parece estar cooperando.

Esta es la estrategia más fácil, la que menos nos obliga a tomar decisiones difíciles, pero también la que no funciona. No nos engañemos…

No tener en cuenta al opositor (no funciona)

La idea es simple, asilamos al opositor, lo dejamos de lado y avanzamos con el cambio. Otra de las más elegidas por su simpleza y por evitar caer en decisiones difíciles.

No olvidemos que el opositor, aunque esté aislado, habla con los demás, los preocupa, los asusta. Suele decir que el único curso de acción inteligente es hacer las cosas cómo las hacíamos antes: “Siempre lo hicimos así”. Los opositores trabajan organizando la resistencia, muchas veces por detrás. Encuentra puntos débiles con el único objetivo de impedir que se actúe.

Nuevamente…no nos engañemos…

Distraiga a los opositores (estrategia que funciona)

Asigne al opositor una misión especial, que lo mantenga muy ocupado en lo que él sabe hacer, lo suficientemente ocupado para no tener tiempo en trabajar organizando la resistencia.

No necesitará tomar decisiones drásticas. Simple y eficaz…

Deshágase de ellos (también funciona)

“Usted está atentando con nuestro negocio, o cambia o se va”. Esta es de las decisiones menos sencillas, que más riesgo creemos que generan y que tienen problemas legales y de ética.

Muchas veces nos preocupa cómo puede ser tomada esta decisión por el resto del grupo. Pero…¿no deberíamos preguntarnos también cómo nos vería el grupo si no tomamos esta decisión?

En cualquier caso, si vamos por este camino, debemos hacerlo ordenadamente y respetuosamente, y por sobre todas las cosas, preparando el camino para que el proceso sea lo más natural posible.

Haga que la presión social los inmovilice (funciona)

La idea es simple o parece: utilizar maneras socialmente aceptadas de identificar en público al opositor y esperar a que la presión social los inmovilice.

Es más sencillo neutralizar al opositor si hemos evidenciado públicamente que es un opositor. El ejemplo del libro del pingüino de peluche de 80 cm es muy interesante, aunque a uno le cueste imaginarlo implementado.

He visto otros ejemplos interesantes de este método en proyectos reales. Muchas veces es el único que podemos manejar, teniendo en cuenta las complejidades políticas de las Organizaciones y la situación de poder en que cada uno se encuentre.

Concluyendo

Este fue un breve resumen, hay más información en el libro con historias reales y muy didácticas. Desde luego no es un tema sencillo, y muchas veces nos encontraremos con decisiones difícil de tomar. Habrá que analizar cada caso, buscando la mejor alternativa, pero seguramente caeremos en un error si tratamos de ignorarlos…no seamos ingenuos.

Les dejo breve mapa mental de resumen gráfico:

Que lo disfruten y hasta la próxima…