Agiles 2019: un espacio para los autores latinoamericanos

Agiles 2019: un espacio para los autores latinoamericanos

Tanto en la conferencia Agile, organizada anualmente por la Agile Alliance, como también en la XP, suele haber un espacio de “librería” donde se venden libros de los oradores de la conferencia y también clásicos de agile.

Me gustaría ver algo así en Agiles2019 pero con una vuelta de rosca.

Dado que en la comunidad Agile de Latam hay varios autores de libros de sobre agile y afines, planificaría una sesión (estableciendo de antemano día, horario y sala) para que cada autor presente su libro en 5 minutos (tipo lightning talk). Luego de la sesión cada autor podría vender o regalar sus libros.

Para que esto ocurra es necesario que la organización haga dos 2 cosas:

  1. Difundir la idea ANTES de la conferencia para que cada autor pueda preparar su lightning talk y también para que pueda organizarse para llevar libros en formato físico o para subirlos a algún medio digital.
  2. Reservar el espacio en cuestión (tanto físico como a nivel agenda)

Me parece que en términos de costo/beneficio esta iniciativa sería muy positiva:

  • El costo para los organizadores es mínimo (yo mismo me ofrecería a hacerlo si me dieran acceso a la lista de participantes).
  • Me parece que también es bueno para que los autores puedan difundir su obra
  • Creo que es un aporte de valor para los asistentes, ya que los libros en castellano sobre agile no tienen gran difusión y escuchar sobre un libro de la voz del propio autor creo que siempre suma.
  • Finalmente, si esta sesión se hiciera el primer día de la conferencia podría funcionar como disparador de otras sesiones en torno a alguno de los libros presentados.

Como realmente quisiera ver esto materializado, ya le escribí al grupo organizador de Agiles 2019 para ver si puedo conseguir su apoyo para llevar esto adelante.

Clase de postgrado sobre TDD con nuevo enfoque

La semana pasada estuve dando una clase de Test-Driven Development en el postgrado de Ingeniería de Software de la Universidad Católica Argentina. Dado que se trataba de un postgrado con gente ya experimentada en desarrollo de software, decidí probar un enfoque distinto al que suelo usar en mis clases de grado cuando enseño TDD.

Comencé presentando el tema desde una perspectiva de alto nivel repasando el proceso completo desarrollo desde la concepción del proyecto. Presenté primero la idea de TDD a nivel de funcionalidad de usuario (Especificación con Ejemplos / Behaviour-Driven Development) utilizando primero Fitnesse y luego Cucumber. Con esto generé un primer “click” en la audiencia y luego de un rato de charla/debate presenté TDD a nivel clases usando JUnit.

A lo largo de la clase también hice un breve repaso histórico del surgimiento de TDD y XP. En línea con esto recomiendo esta entrevista a Kent Beck en Software Engineering Radio, imperdible.

Me gusto mucho esta forma de presentar el tema por lo cual es muy posible que vuelva a utilizarla.

Nuevo taller de gestión de proyectos

Nuevo taller de gestión de proyectos

Ayer estrené un nuevo taller: Gestión de proyectos. Esta no es una temática habitual en mis talleres pero sí en mis materias. En general los talleres que dicto en el sector privado están más asociados a temas técnicos, pero resulta que estoy trabajando en un cliente en el que estoy haciendo un poco de gestión y a partir de eso surgió la oportunidad de dar este taller. Básicamente tomé algunos materiales que uso habitualmente en mi materia y los reordené para este taller.

El taller duró casi 4 horas, participaron unas 8 personas y fue muy bien recibido por los participantes (evaluación 4,7 / 5). En cierto modo me sentí sorprendido pues si bien los materiales ya los venía usando en mi materia, fue la primera vez que los usaba fuera del contexto de la materia y salió todo mejor de lo esperado.

La primera parte del taller estuvo centrada en cuestiones generales de gestión de proyectos y la segunda parte en cuestiones de seguimiento de iteración. El temario resumido fue:

  • Proyectos y fases
  • Alcance, Costo y Calendario
  • Modelos de contratación
  • Criterios de éxito
  • La gestión tradicional vs la gestión con foco en la entrega de valor
  • La gestión en los enfoques ágiles
  • Diseño del board de proyecto
  • Smells en la planificación
  • Smells en daily
  • Smells en las retrospectivas
  • Herramientas de seguimiento: Burndown y Velocity charts
  • Métricas y acción

Notas sobre los trabajos finales de carrera en informática/computación

Notas sobre los trabajos finales de carrera en informática/computación

Durante este cuatrimestre he recibido varias consultas sobre trabajo finales de carrera tanto en FIUBA como en UNTREF.

En UNTreF los alumnos deben hacer un Trabajo final Integrador mientras en FIUBA los alumnos pueden optar por Trabajo Profesional o una Tesis. En este artículo quiero centrarme en el Trabajo Profesional de FIUBA que es equivalente al Trabajo Final Integrador de UNTreF. En otro post trataré el tema de la tesis.

Antes que nada aclaro: lo que escribo aquí no es información oficial de ninguna carrera. Esto es un resumen Es información que yo he recopilado a partir de charlas informales con otro

Algunas cuestiones generales sobre este TFI/TP son:

  • Puede hacerse en forma individual o grupal.
  • Se espera que insuma un esfuerzo aproximado de unas 200 horas por estudiante.
  • Es necesario un profesor que dirija el trabajo.
  • El estudiante debe presentar una propuesta formal con el aval de su director.
  • No existe una lista de temas para el trabajo, en ocasiones los profesores/directores tienen algunas propuestas.
  • Se espera que el trabajo integre los contenidos y habilidades adquiridas durante la carrera.
  • El trabajo no es un trabajo práctico de una materia, es un trabajo final de carrera con lo cual las complejidad y alcance deberían ser mayores a los de un trabajo práctico de una materia.
  • Típicamente el trabajo consiste en algún tipo de desarrollo. No es mandatorio que el desarrollo sea alto totalmente nuevo, la novedad o desafío puede estar en la forma de resolución, en las tecnologías utilizadas o algunas otra cuestión de índole ingenieril.
  • Una fuente interesante de ideas que suelo recomendar es el Technology Radar que publica periódicamente la gente de Thoughtworks

Espero estas líneas resulten de utilidad.

Preparando sesiones para Agiles 2019 (invitación)

Preparando sesiones para Agiles 2019 (invitación)

Estamos a prácticamente 3 meses de la conferencia pero no aún no se sabe mucho aunque, dado que es en formato Open Space, tal vez tampoco haya mucho que decir. Será en el Salón Metropolitano de Rosario del 19 al 21 de Septiembre, se esperan unas 1000 personas, será en formato Open Space y ….. listo. Hay algo más de información en el sitio, pero es más bien metadata. Yo ya compré mi entrada en el primer early bird, la misma incluye una remera pero no el almuerzo.

Personalmente no me terminan de convencer las conferencias en formato 100% Open Space. Y mucho menos en la comunidad Agiles Latam, principalmente porque he visto varias sesiones con un exceso de improvisación y muy bajo nivel/calidad.

A grandes rasgos la propuesta es:

  • Lanzar la convocatoria de participantes de esta iniciativa (este post)
  • Hacer una primera sesión online para explicar conocer la iniciativa, confirmar los participantes y definir los sesiones/temas a preparar. A partir de esto empezamos a preparar las sesiones.
  • Hacer una o dos sesiones online de seguimiento y coordinación para asegurarnos de llegar Agiles con las sesiones pulidas y sincronizadas.
  • El punto de partida e hilo conductor de las sesiones será el libro Accelerate, o sea: las sesiones tratarán algún tema del libro
  • Durante la conferencia realizaremos las sesiones planificadas y generaremos el/los entregables.

¿Te gusta el plan? ¿Queres sumarte?:

Sobre Scrum Masters & Project Management

Sobre Scrum Masters & Project Management

Continuando con la cuestión de planteada previamente (el sospechoso rol del Scrum Master…) sobre las responsabilidades extra que suelen recaer en aquellas personas que ocupan el rol de Scrum Master en las empresas de desarrollo de Software, hoy quiero referirme puntualmente al Project Management.

Antes que nada hago algunas aclaraciones sobre Management según Agile:

  1. El manifiesto ágil dice explícitamente que el equipo es auto-organizado, lo cual implica que la estrategia de management es distinta a la tradicional (muchas veces taylorista) y que varias tareas de management recaerán en el propio equipo. No está completamente claro cuales de las tareas de management toma el equipo y cuales caen fuera, eso habilita a que cada equipo/organización lo maneje de forma distinta.
  2. Más allá de que el equipo sea auto-organizado es razonable que el equipo tenga que interfacear/reportar/coordinar en algún punto con la organización a la cual pertenece. Una cuestión clave aquí es como de implementa esa interface respetando la auto-organización del equipo.

Más allá de de estas cuestiones conceptuales lo que suelo encontrarme muy frecuentemente en empresas de desarrollo de software es que una misma persona concentra el rol de Scrum Master y también varias tareas de management. En particular hay 2 escenarios muy comunes: 1) Scrum Masters haciendo Project Management y 2) Project Managers haciendo de Scrum Masters.

1) Sobre Project Managers haciendo de Scrum Masters

Esta es gente viene de una experiencia de Project Management y que ahora que “el mundo es Agile” se metió en Scrum y adoptó el rol de Scrum Master. Como ya tiene una experiencia en management no le resulta difícil tomar las tareas de management que le pide la organización. El gran desafío aquí es que esta persona pueda dejar de lado algunas practicas de management porque está trabajando con un equipo auto-organizado. Situaciones típicas en este escenario son:

  • La Daily Standup convertida en un reporte de estado
  • Ver al Scrum Master asignando tareas
  • Tracking y reporte en término de horas
  • Micro-management
  • Percepción del Scrum Master como Jefe del equipo

2) Sobre Scrum Master haciendo Management

En este escenario tenemos gente que se formó/entrenó como Scrum Master y que adicionalmente se encuentra con que debe cubrir tareas de management para las cuales no tiene formación. En este escenario estoy hablando de personas que llegan a ser Scrum Master luego de haberse desempañado como Developer, Tester o algún otro rol pero no Project Managers. En estos casos, si el equipo no tiene la experiencia suficiente para auto-organizarse vemos sufrir al proyecto: no hay métricas, el equipo no tiene una velocidad de delivery predecible ni estable, el cliente ve mucho post-its que en lugar de ayudar a la gestión generan una sensación de desorden y extrema informalidad, la gestión de riesgos es bastante endeble (si es que se hace), y el equipo no tiene la habilidad/capacidad de manejar imprevistos de ningún tipo, etc.

Como ya mencioné no me convence la estrategia de concentrar las tareas de management y Scrum Master en una misma persona, pero si alguna organización piensa hacerlo, espero que al menos tomen la precaución de asegurarse que esa persona que ocupe el doble rol tenga la apropiada formación tanto para las tareas de Scrum Master como también para las tareas de Project Management.

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

Una situación que veo recurrentemente en las empresas de desarrollo software para terceros es que conforman sus equipos poniendo una persona en el rol de Scrum Master y asignandole también algunas otras tareas. Esto genera que en términos generales que la persona en el rol de Scrum Master termine concentrando 3 grupos de tareas:

  • a) tareas de facilitación propias del Scrum Master que podemos resumir como ayudar a que el equipo siga la propuesta de proceso de Scrum, removiendo potenciales impedimentos, etc
  • b) tareas típicas de la gestión del proyecto desde la perspectiva de la software factory como ser: seguimiento del presupuesto, planificación del equipo a mediano/largo plazo, seguimiento de la facturación, gestión de riesgos, etc. Aclaro aquí una cuestión importante: la gestión de presupuesto y del plan son responsabilidades del Producto Owner cuando vemos el proyecto desde la perspectiva de la organización que es dueña del producto, pero estas cuestiones también están presentes desde la perspectiva del proyecto de la software factory.
  • c) tareas de gestión internas requeridas por la organización(software factory) respecto de los miembros del equipo como ser evaluaciones de desempeño, coordinación de licencias, etc.

Lo que me resulta sospecho es la concentración de estos tres grupos de tareas en un misma persona porque me parece que puede haber cierto conflicto. Un caso puntual a modo de ejemplo: se supone que el Scrum Master debería generar un contexto de seguridad para que el equipo y sus miembros puedan hablar en confianza sobre sus dificultades, equivocaciones, etc, pero al mismo tiempo esa persona Scrum Master tiene que evaluar el desempeño de los miembros del equipo ¿cuan seguro puede sentirse un miembro de equipo para hablar de sus equivocaciones cuando ese Scrum Master es también la persona que evalúa su desempeño?

Lo que yo recomendaría en estos escenarios es tener dos personas distintas: una con el rol de Scrum Master (que estaría presente en el día a día del proyecto ) y otra con el rol de gestor de proyecto (con una presencia mucho más esporádica).