miércoles, septiembre 24, 2014

Metodologías de desarrollo ¿Ser o no ser?, he ahí la cuestión

Este mes comencé una "nueva aventura/desafío laboral" en otra empresa. Viniendo de una modalidad de trabajo bastante salvaje, llegar a una empresa donde el uso de metodologías de desarrollo es intenso ha sido un cambio no menor. La experiencia ha sido bastante diferente a lo acostumbrado.

En mis trabajos anteriores si bien nos preocupábamos de una u otra manera de llevar un control de versiones, y llevar algún registro de actividades, todo el desarrollo se realizó de manera "salvaje". Salvaje en el sentido que más que el control sobre las actividades a realizar, lo que importa, y casi lo único que importa, es cumplir con las entregas finales de código (y no es que con metodologías más estrictas esto sea menos importante). Dicho en fácil, estuve desarrollando "a lo brutito" mucho mucho tiempo. El objetivo era cumplir si o si.

Metodologías

En esta empresa, muy ligado al alto nivel de los profesionales del equipo con el que debo trabajar, así como también la envergadura del proyecto en curso, la planificación y las metodologías son vitales:
  • Se realiza una planificación para la semana. Un conjunto de tareas que debiera estar resuelto en un plazo dado. La fecha tope normalmente no debiera exceder  de una semana de trabajo (5 días).
  • Cada mañana se realiza una "breve" (a veces no tan breve) reunión, a priori no más de 3 minutos por persona. Todos de pie debemos contar que hicimos en la jornada anterior, y cuál es nuestra planificación para el día de hoy. Se deben levantar las alertas necesarias  sobre aquello que pueda dificultar el desarrollo.
  • Cada viernes, idealmente en la mañana, se realiza una sesión de demo en la que se presenta al equipo algún resultado visible de las actividades realizadas en la semana.
  • Las actividades se ordenan en un tablero Kanban en el cual cada tarea se va moviendo de columna conforme al estado de la misma. Las columnas son:
    • Por hacer
    • En desarrollo
    • Detenido
    • Resuelto
    • Cerrado
  • Cada bloque de código tiene que contar con su correspondiente set de prueba. El Test Driven Development (TDD) amerita un artículo aparte (próximamente en este mismo canal).
Uno de los focos principales es la autogestión del equipo, por lo que cada integrante hace sus propias estimaciones de tiempo.
Y el nivel de control sobre el equipo de desarrollo es claro, siempre sabes que están haciendo todos.

Lo positivo

  • El equipo tiene una visión general de todo lo que está pasando. Se lo involucra en las actividades de la empresa, lo que SIEMPRE es bueno.
  • Se logra un nivel de orden para las actividades de cada integrante del equipo.
  • Se puede dimensionar el costo en tiempo para el desarrollo de un proyecto.
  • Se van afinando, progresivamente, los procesos de desarrollo.

Lo no tan bueno (desde la humilde perspectiva del autor)

Mi gran reparo respecto a la aplicación de estas metodologías apunta hacia el tiempo.
Hacer una reunión diaria, de pie, en un equipo de más de 5 personas puede tomar por lo bajo 30 minutos. Similarmente hacer una sesión de sesiones de demo, podría extenderse al orden de una hora.

En relación al registro de actividades y atenerse a las directrices que se definan incluso para los comentarios al subir código a un repositorio de versiones tampoco es  una tarea directa.

Y sobre los sets de pruebas, estos deben considerarse como un desarrollo anexo, que se suma al tiempo normal de desarrollo. Suele suceder que la detección y corrección de errores (bugs) puede resultar muy rápida, sin embargo la construcción de los set de pruebas muchas veces puede demorar bastante, y muchas veces no tienes como dimensionarlo de manera adecuada.

Tengo cierta claridad sobre la duración de los períodos reales de productividad diaria, habitualmente no más de 5 o 6 horas en una jornada de 8 horas, sin embargo contar con un hora menos para resolver mis tareas planificadas (y me refiero exclusivamente a mi experiencia) pesa.
En un trabajo anterior mi jefe decidió involucrarme en reuniones con cliente, a veces 2 horas al día. Paralelamente yo tenía asignadas ciertas actividades de desarrollo, con fechas de entrega planificadas. Esos días por fuerza tuve que recuperar las horas que literalmente perdí por estar metido en reuniones.

¿Ser o no ser? (o ¿cuándo usar metodologías?)

La respuesta debiera ser siempre. Debiera ser...
Desde mi aún inexperto punto de vista, como en muchos otros casos, la respuesta será un gran depende. Las ventajas son bastante claras sobre no usar metodologías. Sin embargo, su uso estará definido desde la misma filosofía de la empresa hasta el tipo de proyectos que se está desarrollando.

  • Tratar de imponer el uso de metodologías en una empresa que ha sobrevivido en estado salvaje puede tener un costo más alto que el beneficio en el corto y mediano plazo tras incorporarlas. Hay empresas que simplemente no valoran hacer las cosas bien, basta con hacerlas (tristemente las hay...).
  • En proyectos "pequeños" desarrollados por ejercitos de un solo hombre es discutible (y sólo discutible) si vale la pena incluir el desgaste natural asociado a incorporar metodologías.

Personalmente creo que la decisión pasa por la apreciación que tenga cada lider de desarrollo respecto al recurso tiempo, y de que manera puede hacer mejor gestión de este.
Pero sí, hay mucha ganancia en usar metodologías, sólo hay que encontrar la combinación correcta, en la medida que civilice un poco los procesos de desarrollo

domingo, septiembre 21, 2014

¿Qué tan frágil es tu organización?

Hace aproximadamente un mes atrás conversaba con mi ahora ex-jefe sobre que tan frágil es una organización. Básicamente porque mi rol en la empresa tenía cada vez más responsabilidades, y en caso de irme reemplazarme no sería tan sencillo. Hoy estoy trabajando en otra empresa, y créanme que la últimas semanas en mi antiguo trabajo fueron intensas.

Un artículo atrás hablaba del costo de la especialización, y la importancia de poder desempeñarse como un profesional versátil (busquen por fullstack developer para más referencias al respecto).
Si bien es cierto un fullstack developer resulta muy valioso para la organización, es también un riesgo, tan grande como su valor como profesional, puesto que inevitablemente habrá muchas tareas que le serán confiadas. Muchas veces, por no decir la mayoría, este tipo de profesional será el único quien se puede hacer cargo de muchas de las ya mencionadas tareas, o bien será el único que las puede resolver de manera rápida y eficiente.

Cuando se dió esta conversación con mi antiguo jefe, me señaló que si yo me iba, le sería muy difícil encontrar a alguien que pudiera cubrir mi posición. Similarmente si se iba otro compañero que se ha involucrado más en actividades de gestión que de desarrollo, la empresa se tambalea.
Paradojalmente unas semanas después recibí una oferta de aquellas que no esperas que se repitan, y la acepté. Es complejo ver como la empresa en la que has trabajado tiene que empezar a considerar el plan B para todas las actividades en las que estabas involucrado.

¿Ustedes tiene un plan B en caso de?

¿Qué tan frágil es tu organización?

Habitualmente se dice que una organización es tan fuerte como su eslabón más débil, pero ¿qué tan frágil es?
La fragilidad de una organización, empresa, e incluso emprendimientos ligados al desarrollo viene dada por cuántos son los soportes que sostienen las actividades clave/sensibles/de vital importancia, y cuanto es el riesgo que se debe asumir si alguno de estos pilares ya no está en el equipo.

Por ejemplo: Un emprendimiento cuyo norte es entregar un producto de software no debiera depender de una sola persona para hacerse cargo del desarrollo (o de la parte TI si quieren ampliar el concepto). Si esta persona decidiera no seguir, si no hay como reemplazar sus experticias, es probable que tengan que replantear el emprendimiento en si.

Si miramos a las empresas como el juego de la Yenga, la fragilidad podría verse como  cuantos palitos puedes sacar antes que la torre de derrumbe. Mejor aún, dependerá además de que tan abajo o arriba estén los palitos que sacas (obviando el hecho que una torre no representa precisamente una pirámide organizacional).

Y claramente hay muchísimos otros factores que influyen.