Libro: Luis Scola, El abanderado

Estuve a punto de titular esta entrada como un offtopic, pero fue un pensamiento muy fugaz porque el hecho de que Scola sea un basketbolista es solo un detalle, Scola es mucho más.

Hecho el disclaimer, vamos al tema en cuestión. Hace un par de semanas terminé de leer este libro que curiosamente me regaló mi hermano. Digo curiosamente porque mi hermano no es regalarme libros, pero ¡que buen regaló metió!. En algún momento comenté en este espacio sobre mi afición al basket y quienes me siguen en Twitter seguramente han visto pasar algún like a alguna publicación basketbolística. Me sincero, estoy usando el hecho de haber terminado este libro para hablar sobre Luis Scola.

Creo que no me equivoco si digo que Luis Scola es un referente para todo aficionado al basket en Argentina, pero es posible que la audiencia de este espacio apenas haya escuchado alguna vez de Scola. De todas formas creo que hay algunas frases y ejemplos de Scola que son «para la vida».

Luis Scola es el jugador más importante del basket argentino y no tengo la más mínima duda de esto. Alguno dirá que no, que es Ginóbili, pero no. Ginóbili posiblemente sea al día de hoy el mejor jugador pero no el más importante. De hecho creo que el mismo Manu Ginóbili reconoció el lugar de Luis.

En fin, este libro cuenta la vida de Luis Scola, en cierto modo es una biografía y si bien tiene testimonios de mucha gente allegada a Scola, no es una autobiografía. O sea, Scola no participó de la escritura del libro. El libro es obra del periodista Mauricio Codocea. Está bien escrito y su lectura es llevadera. Está plagado de testimonios algunos obtenidos exclusivamente para el libro y otros tantos recolectados de entrevistas previamente publicadas. Obviamente hay muchas cosas que yo ya conocía de Scola, pero hay muchas otras que no, simplemente porque Luifa (como se lo suele apodar) es de perfil muy bajo. Hay varios gestos que Luis ha tenido a lo largo de su carrera que me hacen pensar que lo vamos a extrañar mucho más allá de su rol de jugador y capitán de la selección Argentina.

Les dejo aquí tres videos de entrevistas de Luis que lo pintan de cuerpo entero.

La primera es una entrevista que le hace Juampi Sorín como parte del ciclo Capitanes en 2017.

La segunda es la que le hace el periodista Luis Novaresio en agosto de 2019.

Y la tercera, la más reciente, la que le hace Julio Leiva en el ciclo Caja Negra.

Y cierro con una frase que si bien no es de Luis, se la escuché decir a él en una de estas entrevistas:

El trabajo mata al talento cuando el talento no trabaja.

Evento «avanzado» de desarrollo ¿interesados?

La gran mayoría de las conferencias abiertas de las que tengo conocimiento suelen apuntar a una audiencia masiva y variada y aún cuando hay algunas sesiones avanzadas, es muy limitada la posibilidad de ir en profundidad. Típicamente hay un orador en una sesión tipo clase magistral y hacia el final de la sesión hay un espacio de preguntas y respuestas. En algunos casos hay sesiones tipo «taller» en las que se puede ir más en profundidad pero tampoco demasiado. Estos eventos están muy bien y son muy necesarios, pero los que tenemos ya varios años de experiencia en ocaciones nos gustaría tener opciones de eventos distintos, más profundos, menos masivos y con contenido más curado.

El año pasado tuve la oportunidad de participar del WOPR y a partir de esa experiencia estoy pensando en organizar un evento con una dinámica similar pero enfocado en desarrollo de software y concretamente para desarrolladores: no gerentes, no gente que programó hace años, no consultores, no arquitectos, sino que gente que está metiendo commits en su día a día. La idea seria algo así:

  1. Dos días en modalidad «inmersiva», o sea, el evento sería en alguna locación retirada de cara a pasar los 2 días «internados» ahí (onda el Agile Open Camp). Se me ocurre que podría ser en algún alojamiento rural o bien en algún apart en alguna locación turística en temporada baja. Onda que llegamos un miércoles por la noche, hacemos check-in y jueves temprano largamos. Jueves y viernes a full. Hacemos el cierre el viernes por la tarde noche y quien guste se puede quedar a pasar el fin de semana por su cuenta.
  2. Participación por invitación con cupos limitados, 20 participantes máximo.
  3. Cada participante tiene que postularse enviando un resumen del contenido que va a presentar.
  4. La organización selecciona los participantes y envía las invitaciones.
  5. Cada participante debe pagar pagar su participación esto es: alojamiento, traslado, comidas, etc. Para simplificar la gestión seguramente la organización armaría un paquete incluyendo todo.
  6. No hay agenda predefinida sino participantes. O sea, no sabes de entrada exactamente de qué se va a hablar pero sabes que estarás compartiendo 2 días con determinadas personas.
  7. Los temas que se tratarán durante el encuentro serán en parte definidos por la organización y en parte por los propios participantes.
  8. Todo participante tiene que estar preparado para presentar un contenido pero no es seguro que lo presente, dependerá del fluir del evento.

Me gustaría mucho participar de una evento así y por ello estoy dispuesto a organizarlo, la pregunta es: ¿habrá otros interesados? Si lees este post y te interesado participar, contactame.

Sobre los resultados inconclusos de los estudios sobre TDD

Practico TDD, enseño TDD e investigo sobre TDD. Hoy 2023 TDD es bastante conocido pero bastante menos practicado. Yo tengo mis propias sospechas pero recientemente me he encontrado con dos posibles explicaciones adicionales. En este sentido quiero referirme aquí al trabajo de Ghafari y colegas.

Comienzo explicando el contexto: si buscamos estudios sobre los beneficios de TDD vamos a encontrar evidencia no concluyente, o sea: encontraremos algunos estudios que a partir de experimentos aseveran ciertos beneficios de TDD al mismo tiempo que otros estudios hablan de limitaciones o incluso que la técnica no goza de ciertos beneficios. Ejemplo: algunos estudios indican que TDD mejora la calidad del código pero al mismo tiempo empeora la productividad. Otros estudios dicen que TDD no tiene impacto en la calidad e incluso algún otro habla de que tampoco impacta en la productividad.

A partir de esto, Ghafari y compañía, en su trabajo «Why Research on Test-Driven Development is Inconclusive?«, se propusieron estudiar la razón de estos resultados inconclusos. Para esto analizaron diversos estudios existentes sobre TDD y básicamente identificaron 5 factores:

  1. Definición de TDD: según indican, en los distintos estudios que analizaron se utilizan diferentes definiciones de TDD. Esto en lo personal me resultó muy raro, al menos en el sentido que los autores lo indican. Al margen de lo que indican los autores, lo que personalmente me resuena es que en mi propio trabajo de investigación he notado diferentes concepciones de TDD. Hay gente que entiende por TDD puntualmente lo descripto por Beck en su libro Test-Driven Development by Example, lo cual se centra en aplicar TDD a nivel «diseño de clases», muy asociado a prueba «chica» (onda unitaria), mientras que otros toman TDD como una idea más amplia, aplicable a distintos niveles de abstracción como son BDD/ATDD/SBE y más en línea con lo que el propio Beck menciona en su entrevista a Software Engineering Radio.
  2. Selección de los participantes: muchos de los estudios se hacen con estudiantes o con gente de industria que ha recibido una breve capacitación en TDD. Ambas situaciones son al menos discutibles para poder sacar métricas concluyentes. Si queremos llegar al fondo del asunto debemos realizar estudios con gente experimentada en el uso de TDD.
  3. Selección de la tarea: en general los experimentos utilizan ejercicios/tareas que distan mucho en complejidad de lo que uno se encuentra en «escenarios reales»
  4. Tipo de proyecto: la mayoría de los estudios se enfoca en «proyectos nuevos» (green field) cuando en los contextos reales es habitual tener que lidiar con proyectos existentes (brown field)
  5. Comparación: TDD es una práctica de uso en contextos ágiles, con lo cual al hacer estudios comparativos debería comparar el uso de TDD vs. (No-TDD en un contexto ágil), cosa que no siempre es así. Hay estudios en los que se compara el «uso de TDD» vs. «No-TDD en contextos waterfall», los resultados de este tipo de comparación puede deberse tanto al No uso TDD como también al uso de Waterfall. Es fundamental al comparar tener presente el contexto. También resulta relevante considerar distintos escenarios de No-TDD: Test-Last, Iterative Test-Last, No-Test-at-All pues la implicancias de la comparación pueden resultar muy distintas.

En términos generales me parecen bastante razonables estos 5 factores y obviamente los tendré presentes en mi propios trabajos. Para quienes quieran profundizar en esta cuestión les recomiendo leer el artículo completo, es bastante corto y de lectura llevadera.

off-topic: Argentina Campeón 2022

Hoy salgo de la temática habitual de este espacio para referirme a un hecho sin precedentes: el mundial de fútbol 2022. Al escribir estas líneas dudo si el hecho es el «mundial de fútbol» o «que Argentina fue campeón». En lo personal creo que es el mundial porque la locura, ilusión, «nivel de manija» que despertó el mundial en el pueblo argentino creo que va más allá de haber ganado la final o no. Obviamente cuando Argentina ganó la final la cuestión explotó, pero incluso antes de eso, lo que se vivió en Argentina no tuvo precedente para mí.

Yo no soy futbolero. Obviamente como todo argentino he practicado fútbol y me he puesto la casaca de algún equipo. Siempre en la posición de arquero, pero ya a los 10 años quedó claro que lo que mio no era el futbol sino el basket. También he ido a la cancha y he vivido un partido en la bombonera, pero siendo sincero casi todas las veces que he estado en un estadio de futbol ha sido para ver una banda de rock y no un partido de futbol. Así y todo, siempre miro los partidos de la selección.

En el 78, cuando Argentina ganó su primer campeonato mundial, yo aún no había nacido. En el 86, cuando Diego levantó la segunda copa para Argentina, yo aún era muy chico. Ya para el 90 tenia suficiente conciencia para sufrir colgado del travesaño en aquel partido de octavos de final contra Brasil. Luego los penales atajados por Goyco, el triunfo contra Italia y el sabor amargo de la primera final perdida contra Alemania.

Después vinieron algunas copas América y la ilusión del 94 con el Diego, el Bati, el Burrito y tantos más. Y otra tristeza infinita cuando «nos cortaron las piernas» y ese dolor de saber que ya no tendríamos al Diego en la selección.

Hubo otras ilusiones de la mano de otros cracks como Aimar, Crespo, Higuaín, Tevez, Riquelme y el propio Messi. Se ganaron campeonatos juveniles e incluso juegos olímpicos. Pero no fue hasta 2014 que la selección mayor pudo llegar a otra final y sin embargo la emoción no fue ni remotamente comparable a este 2022. En aquel 2014 Alemania resultó nuestro verdugo igual que en 90. Luego tuvimos dos finales de copa América (2015 y 2016) que también resultaron derrota.

El punto de inflexión que marcó el inicio del ciclo actual fue la eliminación temprana (digo temprana porque había expectativas de llegar más lejos) en octavos de final de Rusia 2018. Esa eliminación determinó la salida del técnico Sampaoli y la toma de la dirección por Scaloni. Se dice que el nombramiento de Scaloni fue inicialmente provisorio hasta encontrar un técnico definitivo, pero la selección Argentina era una papa caliente que nadie quería agarrar. Fue así que Scaloni, que había jugado en la selección pero que nunca había ejercido como «head coach» quedó confirmado en el cargo. De esta forma surgió «La Scaloneta».

El primer logro fue la Copa América 2021 el cual vino con varios condimentos: fue el primer título de Messi con la selección mayor, fue en Brasil y fue con victoria en la final contra Brasil en el Maracaná.

Luego la Scaloneta ganó «La Finalissima», una copa que enfrentó Argentina como campeón de América con Italia, el campeón de Europa.

Con dos títulos en bolsillo y un invicto de 36 partidos la Scaloneta llegó a Qatar. El torneo comenzó con un tropezón, derrota ante Arabia Saudita pero el tropezón no borró la ilusión (y de hecho yo creo que vino bien). Partido a partido el equipo fue mejorando en su desempeño y la emoción del pueblo fue en aumento. Cada partido implicaba una parálisis del país. Para cuando el equipo llegó a la semifinal la locura era total, el equipo estaba jugando muy bien y muchos ya estaban endeudados: algunos nivel económico para costearse el viaje a Qatar pero muchos más a nivel promesas. La semifinal contra Croacia fue un martes, y para muchos argentinos los días siguientes hasta la final del domingo fueron como vivir en el limbo. No se podía hablar de otra cosa. La selección estaba en todos lados, mirábamos los partidos anteriores una y otra vez. Los supersticiosos buscaban coincidencias por doquier y en los medios y redes sociales todo era Messi, Argentina y la Scaloneta.

Llegó el gran día, con mucha expectativa y mucho nervio. Al final del primer tiempo el equipo estaba ganando muy bien, con 2 goles de ventaja y con un juego muy sólido. El planteo de Argentina había dejado a Francia y sus figuras como una pálida sombra. Es por esto que el empaté de Francia y todo lo que vino después resultó un sufrimiento extremo. Pero finalmente ganamos la tercera, estallaron los festejos y terminó el año. Si, aún faltaban varios días, pero ya todo lo demás había perdido sentido, claro que los problemas del país seguían ahí y cada uno aún tenía obligaciones pero todo pasó a segundo plano. Los festejos el día de la victoria y los días subsiguientes cuando el equipo llegó a Argentina fueron algo nunca visto en el país. Comparto algunas fotos que dan testimonio de ello.

En fin, hora de disfrutar, festejar y cumplir las promesas: ¡somos campeones otra vez!

Exámenes orales y colectivos

Desde que estoy a cargo de MeMo2 en FIUBA e Ingeniería de Software en UNTREF, nunca tomé examen final sino que la aprobación de ambas materias siempre dependió de la calificación de múltiples tareas individuales (cuestionarios, ejercicios de programación, etc) y de trabajos prácticos grupales. Los alumnos en general se han mostrado muy conformes con este mecanismo de evaluación/aprobación.

Sin embargo, a lo largo de los años, he tenido algunas situaciones que me hicieron dudar de la conveniencia de este sistema. Fueron situaciones en las que de una u otra forma quedaba al descubierto el desconocimiento de algún alumno de algún tema importante. Esto se suma al clásico problema de participación/compromiso desparejo de los distintos alumnos en la realización de los trabajos grupales.

Es por esto que este cuatrimestre decidí comenzar a tomar examen final. En FIUBA tomamos final a todo el mundo, incluso a aquellos que completaron la cursada con excelente desempeño. En UNTREF solo tomamos final a aquellos alumnos cuyo rendimiento no fue tan bueno. El examen en UNTREF fue un oral bastante tradicional pues había un solo alumno en la fecha de diciembre. Pero en FIUBA, hubo unos 8 alumnos en cada fecha y la dinámica fue distinta.

En lo personal considero que las instancias de evaluación pueden ser también espacios de aprendizaje si utilizamos una dinámica que así lo permita. A mi parecer resulta difícil hacer que un examen escrito sea una instancia de aprendizaje pues no hay «ida y vuelta» cosa que si ocurre con un examen oral. En el oral típicamente el docente inicia con una pregunta que el alumno intenta contestar y a partir de ahí se puede establecer un diálogo de repregunta, aclaración, etc. Si adicionalmente hacemos que ese oral sea colectivo, la experiencia puede resultar mucho más enriquecedora. En las dos fecha de examen que tomé en diciembre utilicé dinámicas distintas pero siempre en modalidad «oral colectivo».

En ambos casos preparé una lista de preguntas y dividí a los alumnos en grupos de 4 o 6, de forma tal de evaluar un grupo a la vez mientras el resto esperaba fuera del aula. En ambos casos también consultaba a los alumnos si estaban conformes con la nota de cursada y firmarían con esa nota o si tenían intenciones de ir por más nota. Todos los alumnos decidieron «defender» la nota de cursada. Si alguno hubiera elegido ir por más nota, simplemente le hubiera pedido que contestara más preguntas.

En la primera fecha la dinámica fue la siguiente:

  1. Yo leía una pregunta en voz alta
  2. Los alumnos que querían contestar pedían la palabra levantando la mano
  3. Yo le dada la palabra un alumno
  4. El alumno contestaba
  5. Si la respuesta era incorrecta, yo daba la oportunidad de contestar a algún otro alumno
  6. Si la respuesta era correcta, yo permitía que algún otro alumno complementara
  7. De esta forma los alumnos sumaban puntos por cada respuesta/acotación correcta.
  8. Las participación incorrectas restaban puntos
  9. Dos o tres puntos positivos (dependiendo del desempeño del alumno durante la cursada) eran suficientes para la aprobación del exámen

En la segunda fecha la dinámica fue levemente distinta, en vez de leer yo una pregunta en voz alta, cada alumno tomaba un papelito con la pregunta a contestar. O sea, que en este caso no había chances de elegir que contestar.

De esta forma cada alumno, además del diálogo que se originaba a partir de su pregunta, tenía también la oportunidad de escuchar (y participar) de las preguntas/diálogos de sus compañeros.

Personalmente me gustó como salió esta primera tanda de finales con lo cual creo que es un mecanismo que mantendremos.

Cierre de cuatrimestre 2022-2 en MeMo2@fiuba

Bien. Muy bien. Mucho mejor de lo esperado. En la previa teníamos record de inscriptos y el desafió de un cambio importante en el equipo: la salida de EmilioG (que teniendo un cargo de ayudante hacía la veces de JTP) y varios colaboradores. Motivados por estas dos cuestiones y el feedback de los alumnos de cuatrimestres anteriores decidimos realizar algunos cambios en la materia (algo ya había adelanto yo en este otro post)

En resumidas cuentas los cambios más relevantes que implementamos fueron:

  • La primera parte de la materia fue principalmente presencial mientras que la segunda parte fue principalmente virtual. Esto permitió que los alumnos se conozcan cara a cara para formar los equipos de trabajo y luego con los equipos ya armados pasamos a modalidad virtual.
  • Bajamos prioridad a algunos temas para dar más profundidad a otros. En este sentido despriorizamos cuestiones como escalamiento de equipo y principios Lean (cuestiones que verán posiblemente en AdminProd y/o EvaPro) y arquitectura de software (hay una materia entera dedicada a ello). Al mismo tiempo pusimos más foco en el proceso de BDD/TDD/CI/CD y «programación colectiva» (pair-mob programming).
  • También agregamos un ejercicio para trabajar de a pares antes de la conformación de los equipos de proyecto
  • Empezamos a tomar examen final, hasta el momento el mecanismo de evaluación estaba basado exclusivamente en el desempeño de los alumnos en las tareas realizadas durante la cursada (incluyendo tareas individuales y grupales). Pero en los últimos años tuvimos algunos casos en los que en verdad dudamos que algunos alumnos realmente hubieran entendido ciertos conceptos. Para mitigar/minimizar estas situaciones (gente que apruebe la materia sin tener en claro algunos conceptos importantes) es que agregamos el examen final

En lo personal quedé muy conforme con la forma de fluir de la materia. Desde la coordinación de la materia todo resultó muy fluido, no fue necesario «correr» con ningún tema. Preparamos las clases y las consignas con suficiente antelación y no tuvimos la soga al cuello con ninguna corrección. Al mismo tiempo creo que encontramos un mix justo de presencialidad/virtualidad.

El feedback de los alumnos también fue muy positivo, tanto en las retrospectiva como en la encuesta final del curso. No hubo tantos reclamos respecto de la carga de trabajo de la materia, si bien fue un tema mencionado, fue mucho más discreto que en ocasiones previas. Con la encuesta de la materia se dieron algunas situaciones particulares:

  • La encuesta fue contestada por 23 de los 24 alumnos que completaron la materia (record)
  • La evaluación general de la materia (en promedio) dio: 9,1 lo cual iguala el máximo histórico de la materia pero con una particularidad adicional: un desvío mínimo, todas las evaluaciones fueron 8, 9 y 10, o sea que nadie calificó la materia con menos de 8.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas (algunas incluso con valores record): claridad de los docentes: 4,7/5; Conocimientos de los docentes: 4,9 /5; Dinámica de las clase: 4,7/5; Materiales de estudio: 4,4/5.
  • El NPS, que anteriormente nos había dado 38, ahora nos dio 61 (esta es una métrica que puede tomar valores en el rango -100 +100, con lo cual un 60 es muy bueno)

De la restrospectiva final identifiqué las siguientes acciones concretas para trabajar:

  • Revisar/editar los videos sobre infraestructura pues tienen contenidos que se sueperponen
  • Crear una base de conocimiento con los problemas recurrentes que se encuentran los alumnos al programar con Ruby/Padrino
  • Revisar el timelime de ejercicios/correcciones
  • Hacer una explicación más detallada de la configuración & funcionamiento del pipeline y la infra de los trabajos finales

Algunos otros números:

  • De los más de 30 inscriptos iniciales, solo 24 completaron la cursada
  • La nota promedio de aprobación de cursada fue 7,9
  • Tuvimos 38 tareas individuales, 1 tarea en parejas y 2 trabajos prácticos
  • En términos de dedicación extra clase, en promedio por alumno, fue de un total de 112 horas (53 de tareas individuales/en pareja, 12 horas de tp1 y 47 horas de tp2) repartidas en 15 semanas (que fue la duración de este cuatrimestre para nosotros). Esto nos da unas 7 horas de dedicación semanal extra clase por alumno a lo largo de todo el cuatrimestre.
  • Hasta el momento tuvimos 2 fechas de examen final en las cuales se presentaron 17 estudiantes de los cuales 15 fueron aprobados.

Sobre el curso de Prácticas Técnicas para Scrum Masters

La semana pasada completé la primera edición de este curso que pensamos junto @martinalaimo. Estoy muy contento con cómo salió considerando que fue la primera edición.

Fueron 4 encuentros online y sincrónicos a todo ritmo con un grupo de 20 participantes muy motivados. Si bien los encuentros tuvieron bastante interacción, me quedó gusto a poco con las interacción offline, me hubiera gustado ver más participación en los foros :-(.

Hablamos de facilitación de estimaciones, modelos de branching, integración continua, test automation y devops.

El feedback de los participantes fue muy positivo y todos coincidieron en que el curso debería haber tenido más encuentros para poder profundizar mas en algunas cuestiones, cosa con la que estoy completamente de acuerdo. Agradezco a todos los participantes por haberse sumado al curso y haber sido en cierto modo «conejillos de india» de este nuevo curso.

Ya tengo en mente varias mejoras para la siguiente edición incluyendo el hecho de extender la duración (posiblemente sean 5 o 6 encuentros) y agregar algunas demostraciones «ejecutables» de pipelines y pruebas automatizadas. Aún no hemos puesto fecha para la siguiente edición pero seguramente tengamos una fecha para el primer trimestre de 2023.

Finalmente quiero agradecer a Martin Alaimo por haberme alentado en esta iniciativa y al equipo de AlaimoLabs por el soporte y la logística del curso.

Sobre el WORP & QSconf

Empiezo por el final.

El viernes estuve participando de la Quality Sense Conference. Resulta que Federico Toledo (socio fundador de Abstracta) tiene una podcast llamado Quality Sense. Dado que a raíz del WORP habría en Montevideo varios referentes de temas de calidad, aprovechó para hacer esta conferencia y de esa forma ofrecer de forma abierta y gratuita una oportunidad de aprendizaje y networking para la comunidad.

Por restricciones personales de agenda no pude participar de toda la conferencia pero pude escuchar algunas charlas e incluso dar una charla yo mismo. En el canal de YouTube de Abstracta está disponible todo el stream de las charlas en castellano y en inglés.

Pero antes de la Quality Sense conf estuve participando del WOPR: Workshop On Performance and Reliability. Este workshop tiene un formato reducido y cerrado, o sea: el número de participantes puede variar levemente pero suele rondar las 25 personas y la participación es por postulación e invitación (ya escribí sobre esto en un post anterior). ¡Brutal! (dirían mis colegas Venezolanos). Fui en un modo muy «exploratorio» y completamente entregado a experimentar con un formato nuevo para mi. Y sinceramente todo estuvo muy por encima de mis expectativas, tanto formato como contenido.

A nivel de contenido me traje un montón de cuestiones para investigar y probar. Hay que destacar aquí que todo el contenido en el WORP (salvo algunas excepciones) es presentado en formato de experiencia, o sea: la gente no va contar una idea, ni a explicar conceptos, sino que los participantes van a contar una experiencia. Entonces todas las interacciones y el contenido compartido se desprenden de las experiencias compartidas por los participantes.

En cuanto al formato hay varias cuestiones interesantes:

  • En primer lugar el formato reducido habilita a explorar los temas con bastante profundidad al mismo tiempo que simplifica la logística de organización.
  • El hecho de que sea cerrado les da a los organizadores la oportunidad de seleccionar a los participantes y a partir de ello tener cierto control sobre el contenido pudiendo así asegurar diversidad y alineamiento en los temas.
  • La dinámica de interacción en el evento es en parte posible también por la cantidad reducida de participantes (aunque el facilitador comentó que utilizó la misma dinámica en reuniones con cientos de personas). La dinámica me gustó tanto que estoy considerando armar otro workshop con esta misma dinámica (en breve más novedades al respecto).

Luego de pasar mis notas sobre las experiencias presentadas escribiré otros post al respecto.

Continuará…

Pair Programming: prejuicios y beneficios

Sensación: pair-programming es un práctica muy popular en el sentido de que mucha gente (cree que) la conoce

Sensación: gran parte de los que dicen conocer la práctica, no la han puesto en práctica, o no la han practicado correctamente y hablan desde el desconocimiento y el prejuicio.

Dato: es una práctica muy poco usada (hay varios estudios que lo así lo indican, uno de ellos el trabajo sobre prácticas ágiles que hicimos en untref)

Lo curioso es que es una práctica que ha sido ampliamente estudiada hace ya bastante tiempo. Los estudios han dejando en claro los beneficios de esta técnica pero parece que las evidencias no han resultado suficientes para que la industria deje de lado sus prejuicios de «pérdida de productividad». Pero creo que también hay otro componente: a algunos programadores (no pocos) no les gusta hacer pair-programming pues prefieren hacer «solo-programming».

En fin, comparto algunos artículos sobre pair-programming que han resultado muy interesantes:

Si aún dudan sobre la efectividad y beneficios de Pair-Programming no duden en leer estos artículos.

Argenzuela: semana 8

Completamos la séptima semana/iteración de proyecto y creo que ya estamos acomodados como equipo. Venimos haciendo unos 6 o 7 ítems por iteración, lo cual equivale a unos 13 puntos. Estamos haciendo un buen slicing de ítems a punto tal que casi podríamos hablar de cantidad de ítems por iteración en lugar de puntos. El siguiente gráfico muestra la cantidad de puntos planificados (gris) vs. la cantidad de puntos entregados (verde). La primera iteración se ve como fuera de lugar porque se entregaron varios ítems que un miembro del equipo había estado trabajando unos días antes del inicio del proyecto.

Las piezas centrales de la arquitectura y el walking skeleton ya están construidos, parte de la solución ya está productiva y la próxima semana ejecutaremos las pruebas de performance.

Esta semana ya comencé gradualmente a desvincularme del equipo para en breve pasar a trabajar con otra célula del mismo producto.