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).

Manejo de parámetros de deployment en Jenkins

Al implementar un pipeline de deployment suele surgir la necesidad de usar algunos parámetros como ser credenciales para conexión a un server, alguna API Key para interactuar con un cloud provider, etc.

Hay varias formas de manejar esto cuando trabajamos con Jenkins. Hoy quiero compartir una forma que me parece elegante y simple a la vez.

La propuesta es utilizar el soporte de Credenciales que ofrece Jenkins. Para esto vamos a Credentials > Global > Add Credentials.

En la pantalla de agregado de Credenciales elegimos el tipo de credencial que queremos agregar. En este ejemplo voy a elegir una credencial del tipo Secret Text pues quiero guardar un simple API token.

Con esto ya hemos almacenado nuestra credencial en Jenkins. El campo ID es el que utilizaremos a posteriori para referenciar esta credencial.

La forma de usar esta credencial varia dependiendo del tipo de credencial (en este caso es Secret Text) y del “lugar” desde donde querramos accederla por ejemplo si es un FreeStyle job o un Pipeline job.

Para usar esta credencial desde un pipeline job se puede usar el siguiente snippet.

Para usar este credencial desde un FreeStyle job, primero bindeamos la credencial a una variable y luego utilizamos directamente la variable.

Un detalle no menor de esta estrategia es que cuando se ejecuta el job el valor de la credencial es enmascarado.