"Tirar Código"

Entre los años 1999 y 2000 me inicie en el mundo del desarrollo de software. Desde esos años vengo escuchando la frase “tirar código”. La misma hace referencia al acto de escribir código fuente o “programar”. No tengo claro de dónde viene la frase, ya que en el idioma Ingles (lingua franca de la Ingeniería de Software), se utilizan las frases “to code”, “to write code”, las cuales podrían traducirse como “codificar” (programar) y “escribir código”. 

“Tirar código” es una frase común entre profesionales de distintas edades, se la he escuchado a personas nacidas en los 60 y llegando hasta el 2000. Un día, reflexionando sobre temas de calidad del software y mejores prácticas, me llego a la mente la frase y de pronto sonó inapropiada. En la República Dominicana cuando algo o alguien es “tirado” (adjetivo) tiene una connotación negativa: descuidado. “Pedro trabaja todo tirado”, o su versión más coloquial “Pedro trabaja to’ tira’o”, significa “Pedro es poco profesional o descuidado, no pone atención en los detalles”. 

Anoche mientras le hacia la observación, repetida en muchos círculos, a un grupo de estudiantes universitarios de que cambien la frase “tirar código” por “escribir código”; me puse a pensar sobre cuales podrían ser los orígenes de la frase. Realmente me da mucha curiosidad el saber 

¿Cómo pasamos de “to code / to write code” a “tirar código”?

Si alguien tiene, o cree tener, la respuesta o una idea favor escribir en los comentarios.

¿Por qué los equipos de Scrum tienen un tamaño limitado?

Visto desde distintos ángulos podemos ver diferentes explicaciones para la recomendación. Primero vemos cual es la recomendación (tomada de The Scrum Guide v2016, p6. Development Team Size):

El espíritu de la “regla”

"Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint."

El límite inferior: 3

"Fewer than three Development Team members decrease interaction and results in smaller productivity gains."

Tamaño mínimo de un equipo de Scrum

El límite superior: 9

“Having more than nine members requires too much coordination.”

Tamaño máximo de un equipo de Scrum

Integrantes: solo los ejecutores

"The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog." 

Así que, tendremos equipos con un mínimo de cinco (5) integrantes y un máximo de once (11). Debemos recordar que el equipo de Scrum se compone del Equipo de Desarrollo, el Scrum Master y el Product Owner. En este cálculo asumimos que el Scrum Master y el Product Owner no son ejecutores (no toman trabajo dentro del sprint backlog).

En este artículo nos enfocaremos en el tema de los canales de comunicación. Para saber cuántos canales de comunicación tendremos en un equipo se utiliza la formula CM = ( n * (n - 1) ) / 2, donde n es la cantidad de integrantes del equipo. Volviendo a nuestros límites tenemos que:

• Inferior n=5: CM = 10 dado por (5 * 4 ) / 2
• Superior n=11: CM = 55 dado por (11 * 10) / 2

Es decir, que en un equipo de Scrum pudiéramos tener que manejar entre 10 y 55 canales de comunicación a lo interno del equipo. A esto súmele la interacción con entes externos. Recordemos también que se recomienda que el área principal de trabajo para un equipo de Scrum sea un espacio compartido por todos los miembros (colocación), esto entre otras cosas para aumentar la comunicación osmótica. En otras palabras, se busca que la comunicación sea abierta y que permee, y haya un máximo grado de sincronización entre los miembros. 

Se busca que los miembros escuchen la mayor cantidad de información posible, aun esta no esté dirigida directamente a ellos. Dependiendo de la cultura del equipo esto puede suponer un alto grado de interrupciones a las labores individuales de cada miembro ya que fácilmente se puede romper su concentración cuando necesitan concentrarse en alguna tarea. 

La cantidad de canales de comunicación también dificulta la labor del Scrum Master. Este deberá poder gestionar impedimentos, mejorar la dinámica del equipo, llevar una bitácora mental de las distintas interacciones entre los miembros y sus oportunidades de mejora. 

En un equipo muy grande, la duración de las ceremonias tendría que extenderse para darle tiempo a cada miembro a tener una participación de calidad. Tomando el daily como ejemplo tenemos que cada miembro del equipo puede hablar hasta 1min:40secs en un equipo de 9 (máximo). A medida que la cantidad de miembros crece este tiempo se irá reduciendo.

Un tema que puede ser analizado por su propio peso y que se relaciona con los canales de comunicación son los medios utilizados. Yo y mis compañeros de equipo utilizamos mayormente la comunicación oral, cara a cara, pero también utilizamos canales electrónicos como Slack. Imagine ahora que además de tener 55 canales de comunicación posibles “cara a cara” ahora también podemos hacer lo mismo en Slack. Podemos tener también grupos cerrados donde se manejen temas que pudieran interesar a todo el equipo. 

En resumen, la cantidad de miembros del equipo impacta de manera directa y positiva la cantidad de canales de comunicación totales. Con el aumento de los canales de comunicación vienen muchas complicaciones en cuanto a la autogestión de un equipo. Esta no es la razón única o principal para mantener un tamaño limitado sobre los equipos agiles, pero definitivamente es un factor de peso considerable.

Como ilustración aquí se presentan la cantidad de canales para equipos de dos a cinco personas.

Canales de comunicación: equipos de 2 a 5 integrantes

Requerimientos, Criterios de Aceptación y Escenarios

¿Qué son?, ¿En qué difieren?, ¿Cómo están relacionados?

Contexto

Estamos construyendo una calculadora básica, la cual solo soporta las cuatro operaciones básicas: Adición, Sustracción, Multiplicación y División.

Requerimientos

(tomado del SWEBOKv3 @ http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf)

¿Qué son?

- En su forma mas básica, un requisito de software es una propiedad la cual debe ser exhibida por algo (componente / modulo / sistema / etc), con el objetivo de resolver un problema del mundo real.

¿Que hacen?

- Expresan las necesidades y limitaciones colocadas sobre el producto de software, el cual contribuye a la solución de un problema del mundo real.

Propiedades:

• Una propiedad esencial de todos los requerimientos de software es que deben ser verificables como una característica individual como requisito funcional, o a nivel de sistema como un requisito no funcional.
• Deben ser estar priorizados.
• Deben estar identificados de manera única.

Tipos (Categorías) de Requerimientos

• de Producto: un requerimiento de producto es una necesidad o constreñimiento en el software a ser desarrollado (ejemplo, "El software debe verificar que el estudiante cumpla con todos los pre-requisitos antes de que el o ella se registre para un curso").
• Proceso: un requerimiento de proceso es esencialmente un constreñimiento en el proceso de desarrollo de software (ejemplo: "El software sera desarrollado utilizando el proceso RUP").
• Funcional: los requerimientos funcionales describen las funciones que el software debe ejecutar; ejemplo: formatear un texto o modular una señal. A veces son conocidos como capacidades o características. un requerimiento funcional puede ser descrito como uno para el se puede escribir un conjunto de pasos de pruebas finito, a ser utilizado para validar su funcionamiento.
• No-funcional: los requerimientos no-funcionales son los que restringen la solución. Muchas veces se les conoce como constreñimientos o requisitos de calidad.

Ejemplos

Vamos a tomar cada una de las operaciones aritméticas básicas como un único requerimiento, así que tendremos:

• Req-1: La calculadora debe soportar la operación Adición.
• Req-2: La calculadora debe soportar la operación Sustracción.
• Req-3: La calculadora debe soportar la operación Multiplicación.
• Req-4: La calculadora debe soportar la operación División.

Criterios de Aceptación

Conjunto de sentencias las cuales indican como sera juzgado (evaluado) un componente de software dado para ver si satisface o no un requerimiento. Cada elemento, criterio, es una sentencia especifica.

Ejemplos

Nosotros, como expertos en matemáticas, sabemos que las operaciones aritméticas básicas tienen ciertas "propiedades". Podemos pensar en esas propiedades como reglas o sentencias las cuales definen en mayor detalle algún aspecto del requerimiento (operación aritmética). Así que ahora tomaremos la operación (requerimiento) Adición como el sujeto de nuestros ejemplos. Tendremos un Criterio por cada una de las propiedades de la operación Adición.

• Cri-1-1: La calculadora debe cumplir con la propiedad Conmutativa para la operación Adición.
• Cri-1-2: La calculadora debe cumplir con la propiedad Asociativa para la operación Adición.
• Cri-1-3: La calculadora debe cumplir con la propiedad Elemento Neutro para la operación Adición.
• Cri-1-4: La calculadora debe cumplir con la propiedad Distributiva, respecto a la multiplicación, para la operación Adición.

Escenarios

Conjunto de ejemplos concretos utilizados para validar un único Criterio de Aceptación.

Ejemplos

Ahora tomaremos la propiedad Conmutativa para la operación Adición, como nuestro sujeto. Lo que necesitamos son ejemplos concretos de expresiones de suma los cuales validen la "presencia", o "implementación correcta" de la propiedad Conmutativa (Criterio de Aceptación), para la operación Adición (Requerimiento).

• Sce-1-1-1: 4 + 2 = 2 + 4
• Sce-1-1-2: 10 + 5 = 5 + 10
• Sce-1-1-3: 1 + 2 + 3 = 3 + 2 + 1

Una imagen vale mas que mil palabras

Aquí tenemos un desglose de los tres conceptos::

Desglose de Requerimientos, Criterios de Aceptación y Escenarios

Resumen

¿Qué son? ver definiciones anteriores.

¿En que se diferencias? 
Son descripciones de alto nivel de características de un sistema. Los Criterios de Aceptación son elementos utilizados para cumplir con la característica "verificable" de los requerimientos. Los criterios deben especificar como determinar si el sistema de software ha implementado correctamente el requerimiento.

Con frecuencia, los criterios de aceptación no tienen el detalle suficiente para ser útiles en la practica, así que tenemos que utilizar ejemplos concretos como Entrada-Salida, Entrada-Tiempo de Respuesta, etc.; estos son los Escenarios.

¿Como se relacionan?
De las descripciones anteriores, usted podrá inferir que son tres niveles de detalle de la misma cosa: que se espera que el sistema haga.

Y ¿Cual es el asunto de todo esto?

• Todos los actores del proceso de desarrollo de software deben entender que son, en que se diferencian y porque son necesarios los tres niveles.
• Los Requerimientos / Historias de Usuario, sin sus Criterios de Aceptación y Escenarios serian muy subjetivos para ser verificables.
• Los Criterios y Escenarios solos serian muy difíciles de manejar, sin un elemento de agrupación (requerimiento padre).

El uso de los tres niveles trae muchos beneficios, como mejores estimaciones de esfuerzo requerido para las Historias de Usuario, Criterios y Tareas. También traen algunos retos interesantes sobre como documentar o expresar automatizar todos estas esas validaciones. Podríamos revisar eso en otro articulo, aquí solo quise resaltar sus diferencias y dar algunos ejemplos simples de cada uno.

Valor de Negocio vs Esfuerzo

Luego de una encuesta rápida ( https://plus.google.com/+LorenzoSolano/posts/U6ZSU5t22vA ), en la cual se preguntaba sobre la relación entre los Puntos de Historia y el Valor de Negocio, quise hablar un poco sobre este mal entendido.

Definiciones Rápidas (contexto: Agile, Scrum, Desarrollo de Software)

Valor de Negocio [Entregado]

Incremento en cierto aspecto de una organización, fruto de un cambio en algún producto de software. Ese aspecto puede ser una fuente de ingresos, mitigación de algún riesgo, etc.

En palabras simples, el valor de negocio entregado luego de una iteración / sprint es el incremento en la capacidad del negocio para generar más dinero o evitar ciertas perdidas (financieras, de reputación, etc.).

Puntos de Historia

Esfuerzo percibido, por un equipo de desarrollo, como necesario para construir cierta característica en un sistema de software.

Las ideas principales aquí son: percibido y un equipo de desarrollo [especifico]. Lo que esto significa es que el esfuerzo es una medida subjetiva, y que ese “sujeto” es un equipo de software en todo el universo. Usted no puede comparar un equipo a otro en términos de cuantos Puntos de Historia (esfuerzo) ellos le asignan a una característica a ser construida.

Los Puntos de Historia y el Valor de Negocio no tienen Relación

Escenario

Imagine dos equipos de desarrollo de software, a los cuales se les da la tarea de estimar cuanto esfuerzo requieren (no horas / tiempo, no dinero), para construir la Característica X. Ambos equipos tienen exactamente el mismo contexto (imaginario por supuesto): ellos pertenecen a la misma organización, responden a los mismos interesados, trabajan con las mismas tecnologías y herramientas.

Donde ellos difieren es en su nivel de experiencia. Así que, tenemos un Equipo de Principiantes y un Equipo de Expertos. Si usted les pregunta a los principiantes acerca del esfuerzo requerido para construir la Característica X, ellos responderán con un estimado mucho más alto que los expertos.

Desde el punto de vista del dueño del negocio, el valor agregado a la organización por la Característica X (luego de ser construida), es el mismo sin importar quienes lo construyan. El negocio solo quiere su nueva funcionalidad, no importa cuán difícil o fácil sea para los constructores lograrlo.

Utilizando un ejemplo menos abstracto; piense en que la cantidad de valor de negocio agregado por la Característica X, es un litro de agua fresca en el desierto. Imagine que su familia vive a una milla (1.6 KM) de distancia de la fuente de agua,

( fuente de agua: contenedor del "valor de negocio" )
Bayuda Desert Well by Clemens Schmillen CC. https://commons.wikimedia.org/wiki/File:BayudaDesertWell.jpg

y que usted necesita ese litro de agua para cocinar las comidas del día. Ese es su valor de negocio, usted necesita el agua no importa como la consiga.

Ahora viene el esfuerzo: si usted debe ir caminando y traer el agua a su casa, el esfuerzo requerido seria alto.

( esfuerzo requerido por el "Equipo de Principiantes" )
Desert walk https://www.flickr.com/photos/maartmeester/5130198174 by Maarten van Maanen @ Flickr.com

Pero, si usted utiliza un camello para ir y buscar el agua, entonces la tarea se vuelve más fácil.

( esfuerzo requerido por el "Equipo de Expertos" )
Camel at desert https://pixabay.com/en/camel-desert-sand-mongolia-692648/ by hbieser @ pixabay.com

Conclusiones

De esta comparación, inadecuada, me gustaría puntualizar algunas observaciones clave:

• No compare equipos utilizando su velocidad promedio (Puntos de Historia por Sprint)
• No asuma que un equipo entrega más valor de negocio porque ellos tienen una “velocidad” más alta que otro
• La velocidad de un equipo es solo para su uso
• Usted puede comparar la velocidad pasada a la actual, analizar tendencias y responder a cambios bruscos en ella (incrementos o decrementos) como indicador de que algo está pasando: nuevos miembros, rotación, cambios en infraestructura tecnologías, etc. Obviamente, la comparación será entre medidas presentes y futuras DEL MISMO EQUIPO.

Profesionalismo o Suicido de Clases

En SoftTopia cada producto de software, desde la más pequeña utilería hasta la aplicación empresarial más grande, cuentan con un Sello de Calidad. Ese sello mide la calidad del release del producto tanto interna como externa. La externa indica el grado de cumplimiento de las funcionalidades del paquete comparado con los requisitos de los clientes. La interna indica que tan fácil es de mantener vivo el proyecto respetando los parámetros de tiempo y costo esperados por los involucrados (mantenedores, clientes, propietarios, etc.).

Supongamos que ese “sello” es una normativa obligada en SoftTopia, por tanto, ningún software puede ser liberado sin esta información.

Caso A

SoftTopia implemento esa normativa desde la creación del primer paquete de software pues ellos ya tenían una cultura orientada a la calidad cuando los alcanzo la revolución tecnológica.

Caso B (nuestro)

El primer programa de computadoras en SoftTopia fue creado en los 1840s. 175 años después, y con millones de productos de software en uso, los líderes de SoftTopia lanzan la normativa de calidad. SoftTopia es una sociedad de libre comercio, así que solo exigen que la etiqueta de calidad este presente, pero son los clientes quienes deciden cual software comprar y utilizar. Sin embargo, algunas industrias son reguladas por su impacto en los procesos sociales, algunas de esas son: el sector salud, hidrocarburos, gobierno, producción de alimentos, transporte público, aviación civil e instituciones de defensa.

¿Que pasara luego?

• ¿Qué harán los profesionales y empresas de desarrollo de software que no puedan crear productos con un nivel de calidad aceptable para el cliente regular?
• ¿Cómo manejara una empresa del estado al darse cuenta que casi todos sus suplidores entregan paquetes de software con una calidad por debajo de la exigida por la nueva regulación? 
• ¿Qué harán las empresas privadas cuando sus clientes se den cuenta que un gran porcentaje de sus costos operativos son causados por los costos de mantenimiento de software sin calidad?
• ¿Cómo venderán sus programas de clases las universidades e instituciones de formación para ingenieros de software al darse cuenta de que sus egresados no están capacitados para cumplir la nueva normativa?

Rompamos ahora el cuento de SoftTopia

Si poco a poco, los propios profesionales del software y las empresas del sector empezaran a publicar, voluntariamente, el nivel de calidad interno de sus productos: ¿Seria esto profesionalismo o suicidio? 

¿Qué piensas? …

Ultra secreto: Código Fuente o Ropa interior

Preguntas

¿Por qué luego de asistir a un coding dojo, los desarrolladores se reúsan a compartir su código en público (GitHub o similar)?

¿Es nuestro estilo de codificación tan secreto que no lo podemos compartir?

¿Sería vergonzoso si alguien mirara nuestro material de practica sin terminar y lleno de errores?

¿Solo se nos permite producir código “perfecto”?

¿Es tu código como tu ropa interior?

No conozco las respuestas a esas preguntas, pero si usted por favor comente al respecto: ¿Qué te impide mostrar tu código de practica en un repositorio público?

Ideas Locas

Imagina que los Dioses del Código te dieron una varita

mágica*. Esta impresionante herramienta te permite analizar, instantáneamente, una base de código y darle una puntación de 0 a 10 acerca de su mantenibilidad; donde cero (0) significa imposible de cambiar y diez (10) realmente fácil de cambiar.

De repente, recibes tres propuestas de consultorías de clientes distintos (A, B y C). Ellos te están requiriendo la implementación de nuevas funcionalidades en su producto principal. Utilizando tu varita mágica determinas que:

• El Producto A tiene un índice de mantenibilidad de 6,
• El Producto B tiene uno de 1.5, y
• El Producto C tiene un índice de mantenibilidad de 9

Tus clientes potenciales te aclaran que sus respectivos productos son de misión critica y que el impacto de introducir nuevos defectos podría ser catastrófico. Por tanto, ellos van a transferir ese riesgo a ti: cualquier defecto encontrado durante un periodo de validación de dos meses deberá ser resuelto lo antes posible y sin costo alguno.

Asumiendo una estrategia de precios X (basada en tiempo, basada en esfuerzo, etc.), ¿podríamos

• Cobrarle al Cliente C la tarifa regular?
• Cobrarle al Cliente A la tarifa regular ajustada (multiplicada) por algún factor basado en el riesgo (inversamente proporcional al índice de mantenibilidad)?
• Simplemente descartar el Cliente B y evitar el riesgo?

¿Me sigues?

• ¿Podríamos educar a nuestros clientes utilizando una estrategia de precios la cual refleje directamente el nivel de riesgo y esfuerzo que debamos asumir al trabajar con productos de software desordenados (baja mantenibilidad)?
• Con el tiempo, y algunas experiencias duras, ¿Estarán nuestros clientes más vigilantes acerca de la calidad de su base de código, y tal vez comiencen a requerir mayor calidad a todos los desarrolladores, tanto a lo interno como fuera de su organización?

* No esperes a los Dioses, puedes utilizar SonarQube, PMD, ReSharper, Checkstyle, y muchas otras.

Otra razón para hacer Pair Programming

Unas semanas atrás nosotros (el equipo de desarrollo) estábamos pagando un poco de deuda técnica, antes de iniciar la sesión de codificación hicimos una pequeña reunión de planificación. Durante la reunión, les comunique a mis compañeros que realizaríamos las mejoras (refactoring) en parejas (pair programming).

Yo asigné las parejas y establecí un sistema de dos (2) rondas, durante cada ronda una pareja debía completar una tarea por cada integrante (desarrollador). Luego las parejas debían cambiar (de integrantes). Al final de la segunda ronda si algún desarrollador tenia trabajo pendiente, el (si todos hombres, aburrido), debería completar su trabajo trabajando solo. De esa manera durante el día de trabajo cada quien trabajaría con dos compañeros.

Luego de mie explicación de dos o tres minutos, alguien pregunto:
- ¿Por qué debemos hacer pair programming?
- Porque quiero forzar la nivelación y transferencia de conocimientos, contesté

Esa pregunta se quedó en mi cabeza todo el día, primero porque para mí era tan obvia la respuesta y también porque había muchas otras razones: 

• Aprender trucos del IDE
• Doble chequeo de refactoring (complejo y con posibilidad de introducir errores)
• Formación de lazos: el sentido de que estamos arreglando “nuestro” trabajo, no solo tratando con mi propia basura privada tirada en algún momento pasado
• Etc.

Resultados y Ventajas

• Pudimos reducir las violaciones reportadas por la herramienta de calidad en un 17%
• En el proceso aprendimos nuevos trucos del IDE de los compañeros, o los descubrimos por vagancia (tratando de cambiar más código en menos tiempo)
• Mejoramos archivos HTML al remover atributos no necesarios o elementos deprecados (por la especificación de HTML5)
• Discutimos el por qué las violaciones, seleccionadas manualmente, para solucionar eran importantes y como podrían afectarnos en el futuro
• Al final de la sesión todos acordamos en apartar un día de cada Sprint para pagar la deuda técnica vieja
• Ahora todos estamos más vigilantes, durante las revisiones de código, ante nuevas violaciones a los estándares de codificación 

Desventajas

• Gran parte del tiempo lo gastamos en tareas tediosas y manuales
• Para las 3 pm todos estábamos extenuados
• Conflictos de sincronización: por el hecho de haber distribuido las “violaciones” por tipo, y no por archivo o clase, hubo una alta tasa de conflictos

Retrospectiva

Puede ser mejor asignar el trabajo por archivo, o grupos de archivos. Así solo ocurrirán conflictos cuando la interfaz publica (de las clases) cambie.

También, una sesión de limpieza de código realizada por archivo o clase no es tan aburrida pues se manejan diferentes tipos de violaciones.