Categoría: opinion

Mejorando el flujo de trabajo a partir del burndown chart

Ayer completamos la tercera iteración del proyecto y la cosa empieza a fluir de lo lindo. Si bien veníamos cumpliendo con los compromisos asumidos el flujo de trabajo en las dos iteraciones anteriores había sido medio accidentado/abrupto como evidencia el burndown chart de la iteración 2.

Burndown chart iteración 2

En la retrospectiva de la iteración 2 tomamos conciencia de este flujo accidentado y decimos tomar medidas para mejorarlo. Principalmente intentamos tener ítems de backlog más pequeños, limitar el WIP y deployar de forma más frecuente. El resultado se puede apreciar en el siguiente gráfico.

Burndown chart iteración 3

 

A pesar de la mejora yo sigo teniendo un pequeña molestia pues no me gusta el cierre abrupto de la iteración. Este cierre es consecuencia de que terminamos a último momento el testing de la última porción de trabajo.

Ya que he compartido los gráficos quiero aprovechar también para compartir un breve análisis comparativo de los mismos:

  • Si bien ambas iteraciones tuvieron la misma duración calendario, la cantidad de días laborales en cada una, fue diferente (los días no laborales está representados por las franjas verticales de color gris más oscuro).
  • Debido al ítem anterior, el tamaño del compromiso asumido por el equipo también fue distinto: en la iteración 2 el compromiso fue de más de 50 puntos, mientras que en la iteración 3 fue de unos 40 puntos.

Preparing for IEEE Week Brazil

Preparing for IEEE Week Brazil

Next week I will be participating in the IEEE Week conference organised by the IEEE Students Chapter at University of Brasilia. In this context I will facilitate 2 activities.

On Monday 24 I will deliver a 4-hour workshop about «Modern Extreme Programming«.

On Tuesday 25 I will deliver the lecture: DevOps, myths and facts of a new paradigm.

Beyond these formal activities I expect to meet some local professors and practitioners to talk and share experiences about Software Engineering.

If you will be around and want to meet to share a talk (and a beer?) just contact me.

Ingeniería, el arte de hacer lo mejor posible con las restricciones existentes

Si no hubiera restricciones no sería ingeniería. De eso estoy seguro.

De lo que no estoy tan seguro es de que sea un arte. Tal vez sea una ciencia. No, ni lo uno ni lo otro. En fin, sea lo que sea, arte o ciencia ,o ambas, hay que hacer algo y hay que hacerlo atado a ciertas restricciones.

El siguiente punto es ¿hacer lo mejor posible? o ¿hacer lo mínimo posible? mmm, tal vez lo mínimo posible sea lo mejor posible. Creo que esto puede ser también polémico, pero al menos en la ingeniería de Software me parece bastante acertado.

Preparando Ingeniería de Software 2 @ FIUBA

Preparando Ingeniería de Software 2 @ FIUBA

Desde hace un tiempo estoy trabajando en preparar la materia Métodos y Modelos en la Ingeniería de Software 2 (95.21) perteneciente al nuevo plan de la Licenciatura en Análisis de Sistemas de la Facultad de Ingeniería de la UBA.

Formalmente el programa de la materia incluye una importante gama de temas que van desde procesos de adquisición hasta métodos de evaluación de arquitectura pasando por operaciones y sistemas de tiempo real.

La materia otorga 6 créditos y tiene una carga horaria de 6 horas semanales. Si bien aún no lo hemos hablamos explícitamente es muy posible que la materia se dicte en 2 clases semanales de 3 horas cada una.

Como primer paso tomamos el programa formal y lo desglosamos en capítulos/módulos que agrupan los principales temas.

En términos de enfoque pedagógico la idea es seguir con la misma estrategia que en la materia anterior (Métodos y Modelos en la Ingeniería de Software 1) el cual es muy similar al enfoque  que utilizo en UNTreF.

Continuará…

 

Libro AOC 2017: alfa 2 disponible

Libro AOC 2017: alfa 2 disponible

Acabamos de publicar el segundo release (alfa2). Esta nueva entrega contiene las siguientes novedades respecto de la anterior:

  • Actualizaciones a los primeros 4 capítulos publicados en la versión anterior
  • 5 nuevos capítulos de 5 nuevos autores: Vane Savino, Martín Salías, Ingrid Astiz, Ale Faguaga,  Hiroshi Hiromoto
  • Ilustraciones varias por Omar Fernández
  • Revisión editorial por Cora Fassina

Estimamos hacer un tercer release a mediados de abril  ya de categoría beta el cual incluiría el contenido final.

Como de costumbre el libro esta disponible en GitBook para descarga gratuita en diversos formatos.

Todo feedback es bienvenido.

Primer release (alfa) del libro del AOC 2017

Primer release (alfa) del libro del AOC 2017

Este primer release es una especie de alfa que cuenta con 4 capítulos:

  • F*** the Manifesto, por Juan Gabardini (@jgabardini)
  • El coach como impedimento, por Rox Muñoz (@jeri4queen)
  • Ve despacio que voy apurado, por Thomas Wallet (@WalletThomas)
  • Fragilidad, por NicoPaez (@inicopaez)

La idea de sacar este primer release tiene 2 objetivos principales:

  • Obtener feedback de la comunidad
  • Que los temas planteados en los distintos capítulos puedan servir como punto de partida para sesiones del AOC. Incluso tal vez con una sesión de escritura durante al AOC para sumar nuevos capítulos

Más allá de los 4 capítulos incluidos en esta primer versión, tenemos otros 7 capítulos en proceso de escritura. Algunos de ellos pintan muy picantes, comparto algunos títulos:

  • El agilismo ¿es una secta?
  • Hiperproductividad: un asesino silencioso
  • Retrospectivas != Mejora continua

Estimo que haremos un segundo release (que sería como una beta) en algún momento de Abril.

El release final será a comienzos de Mayo durante el AOC Chile.

Quienes gusten pueden acceder a este primer release aquí.

¡Agiles 2017 ya tiene fecha y sede!

¡Agiles 2017 ya tiene fecha y sede!

Hace un par de días el equipo organizador anunció que la conferencia tendrá lugar los días 12, 13 y 14 de Octubre, en la sede San Joaquín de la Universidad Técnica Federico Santa Maria (Santiago de Chile).

Personalmente estoy muy entusiasmado con esta edición de Agiles, en parte porque el año pasado no asistí, pero sobre todo porque parece que esté año la conferencia será distinta.

Históricamente la conferencia ha tenido un formato bastante tradicional con 2 días de sesiones surgidas de un Call-For-Papers y un día en formato Open Space. Pero parece que este año la mayor parte de la conferencia será en formato Open Space.

Para mantenerse informado de las noticias de la conferencia pueden seguir en Twitter la cuenta @agiles2017.

Cuando el mínimo producto viable es demasiado grande

El proyecto en el que estamos trabajando es una plataforma que nuestro cliente ofrece como servicio a sus propios clientes bajo un modelo tipo «suscripción».

Más específicamente estamos construyendo una nueva versión de esta plataforma, pues el cliente ya tiene versión que ha construido durante varios años. Más aún el cliente ya está recuperando su inversión. Las razones que lo llevan al contratar a un nuevo proveedor para hacer una nueva versión de su plataforma no vienen al caso en este artículo, pero es interesante destacar que la nueva versión no incluye nuevas funcionalidades (al menos en un principio) aunque se espera que resulte mucho más estable y escalable. Pero esta cuestiones técnicas no son precisamente lo que más me inquieta.

El tema que más me inquieta tiene que ver con la planificación. Construir un nuevo producto con toda la funcionalidad existente en el producto actual podría llevarnos más de un año. Demasiado tiempo, demasiado riesgo.

En estos días precisamente estamos trabajando con la gente de negocio para intentar identificar un estrategia que nos permita liberar al menos una parte del producto y de esa forma comenzar a tener un retorno de la inversión y mitigar los riesgos.

Continuara…

 

Categorias de prácticas DevOps

Por estos días me encuentro leyendo el libro de DevOps del SEI que me compré el mes pasado. Llevo leído aproximadamente un tercio de libro y por el momento viene bien, o sea, la mayoría de las cosas ya las conocía, algunas pocas no y otras pocas no estoy seguro de compartirlas. Entre las cosas que no conocía hay una en particular que me resultó muy interesante: la categorización de las prácticas DevOps. El libro propone agrupar las prácticas en 5 categorías:

  1. Hacer al grupo de Operaciones un ciudadano de primera clase (first-class citizen).
  2. Hacer al grupo de Desarrollo responsable del manejo de los incidentes en producción
  3. Establecer un proceso formal de deployment
  4. Usar Continuous Deployment
  5. Manejar la infraestructura como código

En teoría todas las prácticas DevOps podrían caer en alguna de estas 5 categorías. A mi parecer las 3 primeras categorías son más de índole «cultural» o de proceso, mientras que las 2 últimas son más de índole técnica. En este sentido el poder hacer la distinción puede ayudar a la hora de armar un plan de adopción de DevOps.

El desafío de las pequeñas empresas de IT versus las grandes multinacionales

El año pasado tuve la oportunidad de trabajar por un período muy breve con un joven y talentoso ingeniero de @Fiuba. En aquel momento él trabaja para una empresa de desarrollo de software de tamaño mediano (en términos de Argentina serian unos 100 empleados). Recientemente supe que fue contratado por una empresa multinacional y eso me recordó un pasaje de mi propia carrera profesional. Al mismo tiempo me puse a pensar ¿como pueden hacer las pequeñas empresas para retener a sus talentos ante las ofertas de las grandes empresas?

En primer lugar sospecho que la cuestión no pasa por dinero/beneficios, porque creo que incluso cuando las pequeñas empresas pudieran competir (o incluso superar) las ofertas económicas de las grandes empresas, creo que hay otra serie de cuestiones mucho más influyentes. Tomo mi propio caso, cuando decidí trabajar para un gigante multinacional no lo hice por dinero sino para ganar experiencia y hacer carrera. El trabajar en una empresa grande de primer nivel mundial ofrece una serie de oportunidades/desafíos que para algunos (yo incluido) resultan sumamente atractivos.

Hace un par de días vengo pensando sobre este tema y se me ocurrieron dos estrategias posibles para competir con las grandes empresas:

  • Ser parte: conozco un par de casos de empresas pequeñas (menos de 50 empleados) que a partir de una estructura casi horizontal cuentan con mecanismos para hacer participes a su gente del rumbo de la empresa. Un caso de esto es @10Pines.  Otro caso similar pero un poco distinto es Tecso, que tiene la particularidad de ser bastante más grande (creo que son más de 200 empleados). Creo que el «ser parte» en este sentido puede resultar muy incentivo muy importante y muy difícil de lograr en las grandes empresas (aclaración: tener acciones de la empresa no necesariamente te «hace parte»)
  • Plan de carrera: este punto es justamente una de las falencias de muchas empresas chicas, no tienen planes de carrera, cosa que si suelen tener las grandes empresas. A pesar de esto creo que si las empresas chicas invirtieran en armar planes de carrera, podrían ofrecer a sus empleados alternativas incluso más interesantes que las ofrecidos por las grandes empresas. Un situación común en las grandes empresas es que a partir de cierto punto para crecer hay que ocupar una posición de gestión, o sea los planes de carrera para perfiles técnicos suelen ser muy limitados. Una empresa pequeña que me consta supo tener en algún momento un plan de carrera claramente definido y muy atractivo para gente de perfil técnico fue @Southworks.

¿Alguna otra idea o comentarios para sumar?