Hace un tiempo me contactó un cliente para pedirme que le de una mano acompañando a uno de sus equipos en un proyecto que estaban por empezar. Me adelanto algo de información por mail y agendamos una call. La información del mail ya me levanto algunos warnings: un proyecto de 3 meses con 12 personas en el equipo de desarrollo (demasiada gente apilada en para tan poco tiempo).
La idea del cliente era que yo colaborara haciendo coaching del equipo pues tenían la intención de realizar varios ajustes en la forma de llevar a cabo el proyecto incorporando prácticas ágiles. Ya en la call el cliente comentó que las fechas estaban fijas y que el alcance también estaba bastante fijo. A esta situación se sumaron dos factores importantes: el equipo de desarrollo estaría distribuido y el proyecto era de vital importancia porque era el primero con un nuevo cliente y el éxito de este proyecto definiría la realización o no de siguientes proyectos.
Si bien el proyecto parecía desafiante decidí no aceptarlo porque me pareció que no se daban las condiciones para hacer coaching (al menos como a mi me gusta hacerlo). Cuando acompaño a un equipo (no me gusta el término coaching, me gusta más hablar de acompañamiento) trabajo en la mejora del equipo y eso implica un proceso de aprendizaje que requiere tiempo para experimentar y posibilidad de equivocarse. Pero este proyecto que me proponía el cliente no contaba con un contexto favorable para experimentación y aprendizaje, había una presión muy fuerte para el éxito del proyecto y un conjunto de restricciones que limitaban mucho el margen de acción ante imprevistos y equivocaciones.
Recientemente en un charla con un estudiante surgió el tema de la «documentación oficial de Agile». Con esto el alumno apuntaba a algo así como PMBoK o el SWEBoK pero de Agile. Esa consulta me motivo a escribir estas líneas.
En primer lugar lo que tenemos es el manifiesto ágil que dice y de forma bastante genérica (pero lo que dice es importante). Por otro lado tenemos libros sobre métodos y prácticas específicas escritos por sus propios autores (obviamente también hay libros escritos por terceros, pero el hecho de que estén escritos por los autores podría llegar a darle un peso diferente). Un ejemplos de esto son los libros de Beck sobre XP y TDD. En el caso de Scrum tenemos la Guía Oficial de Scrum escrita por Schwaber y Sutherland y avalada por varias «organizaciones de Scrum».
Pero más allá de métodos en particular, existe la Agile Practice Guide, un libro de unas 180 páginas publicado hace un par de años. El mismo surgió de un esfuerzo conjunto del Project Management Institute y la Agile Alliance. Esta guía es de acceso gratuito para los suscriptores de la Agile Alliance (y estimo que también para los del PMI) pero también puede comprarse en Amazon.
Debo admitir que antes de leerla tenía cierto prejuicio sobre su utilidad y el nivel de «humo». A pesar de eso, la leí y me sorprendí. Personalmente no me aportó mucho pero creo que puede ser un punto de partida intersante para gente que recién se acerca a agile. Más aún, en un punto creo que podría ser una lectura obligatoria. Me pareció muy sano que el primer capítulo es muy explícito sobre las limitaciones de agile en el sentido de que:
no es una bala de plata
no aplica a todos los contextos/proyectos
requiere de ciertas pre-condiciones
Por otro lado también debo decir que tiene un foco en temas de gestión. Apenas menciona a la pasada algunas prácticas técnicas y sin entrar en detalle en ninguna de ellas.
Algunos puntos interesantes que incluye esta guía y que me parece vale la pena destacar son:
Trata el tema métricas
Dedica una sección importante al modelo de equipo haciendo incapié en Servant Leadership y hablando incluso del rol de Project Manager
En el marco del Plan 2020 la Facultad de Ingeniería de la UBA está haciendo nuevos planes de estudio para todas las carreras entre las cuales están la Ingeniería en Informática y la Licenciatura en Análisis de Sistemas. El plan de la licenciatura es bastante nuevo (2015) pero el de la ingeniería no. Salvo algunas modificaciones menores el plan actual de la Ingeniería en Informática es el mismo plan con el que estudié yo a fines de los 90′.
Hace un par de semanas asistí una presentación que realizó la comisión curricular que está trabajando en el nuevo plan de Ingeniería en Informática.
En términos generales me gustó la forma que va tomando en nuevo plan. Comparto algunas observaciones al respecto.
Al comienzo de la presentación mencionaron algo así como que «los egresados de nuestra carrera están muy bien vistos en el mercado por su formación». Comparto parcialmente: creo que efectivamente hay una muy buena percepción/desempeño de nuestros egresados, pero no estoy tan seguro que sea por la formación académica. Creo que esto es en gran parte por cuestiones «accidentales», creo que nuestros egresados son en primer lugar gente perseverante, que está acostumbrada a lidiar con dificultades (materias con horarios que se superponen, docentes «dificultadores», paros, recursos limitados y demás cuestiones extra académicas). Creo que esa capacidad de luchar y superar la adversidad contextual es lo que representa un diferencial en el egresado de fiuba. En cierto modo esto es lamentable, yo quisiera que nos destacaremos por la formación académica, pero me parece que actualmente no es así (vengo con esta idea desde hace ya varios años).
También se mencionaron los distintos factores que tuvieron presentes para la conformación del nuevo plan. Me resulto llamativo que no hayan mencionado el tema de las deserciones. Yo tengo la sensación de que el ratio ingresantes/egresados es muy malo y creo que también que hay una cantidad no menor que abandona cuando le falta solo la tesis/TP.
Respecto del esquema de materias me gustó y aunque parece que la parte de Ingeniería de Software (que es mi área) ha sido reducida, no me parece mal porque creo que ciertos temas de la ingeniería de software deben versen en forma transversal (por el ejemplo el tema testing y ciertos aspectos de planificación/organización).
Sentí cierta decepción al ver que la carga de materias de ciencia básica es todavía muy alta. Se eliminó Quimica 1, pero se agregó Matemática Discreta (que me parece bien) y se mantiene Análisis Matemático 3 (yo que la hubiera dejado como electiva). También se mantienen Fisica 1 y 2 (espero que al menos eliminen los contenidos repetidos entre Física del CBC y Física 1).
Entre las novedades que me resultaron más relevantes están:
La inclusión de Teoría de Algoritmos y Arquitectura de Software como materias obligatorias
La inclusión de contenidos de seguridad en forma transversal en varias materias
Una nueva materia llamada Infraestructura con foco en virtualización, cloud, etc.
Por otro lado tuve algunas charlas informales con miembros de la curricular que trabaja en el plan 2020 de la licenciatura y según me comentaron, el nuevo plan no tendrá modificaciones muy relevantes ya que el plan actual es bastante nuevo.
Con estos nuevos planes parece decantar que la Licenciatura en Análisis de Sistemas ofrecerá una sólida formación en cuestiones de Ingeniería de Software mientras que la Ingeniería en Informática formará gente con perfil más técnico. De todas formas hay que destacar que cada alumno tiene la posibilidad de armar su propio perfil a partir de la materias electiva que elija.
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:
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.
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.
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.
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
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
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.
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:
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.
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.
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).
Blog de NicoPaez 