Hai xa bastante tempo que quero facer unha refactorización no traballo. Varios compañeiros están de acordo comigo e eu sei perfectamente o que quero facer. O problema é que a refactorización resulta en modificar varios miles de liñas e, obviamente, non lle podo enviar iso a ninguén para que o revise. Polo tanto, pasei unhas poucas semanas a crear unha serie de cambios pequenos que van resultar, finalmente, na refactorización que eu quería facer no principio.
O que máis sorprende a moita xente é que eu poida investir tempo nunha refactorización. Moitos equipos de desenvolvemento de software van de sprint a sprint sen parar nin a respirar, adicando todo o seu tempo a resolver “historias de usuario” e cun xefe de proxecto que só sabe contar puntos e ten como frases favoritas “é que vós sempre queredes estar refactorizando”, “hai que saber a diferencia entre o urxente e o importante” e “xa me vés outra vez con esa leria da débeda técnica”.
“O segredo da miña produtividade é que eu fixo a mirada no meu obxectivo e non me deixo distraer polo que apareza no camiño”.
Este ritmo non é sostible a longo prazo: é coma se nunha tenda quixeran adicar todo o tempo a vender mercadoría, desde que abre na mañá ata que cerra no serán, pero non quixeran reservar nada de tempo para limpar e organizar a tenda e encargar máis xénero para vender no día seguinte. Despois de tres días, esa tenda había estar toda emporcallada e cos andeis baleiros.
Na planificación dos proxectos é imprescindible incluír tempo para imprevistos e para facer mantemento, e iso é igual de certo se facemos desenvolvemento en fervenza como se usamos unha metodoloxía Agile. Os motivos son moi simples: por exemplo, é inevitable introducir erros de programación e, cando impiden que o programa funcione, hai que corrixilos e iso leva tempo.
Aínda na ausencia de erros, moitas veces o código escrito non é axeitado e é preciso cambialo ou incluso volvelo deseñar. Isto, unha vez máis, leva tempo. O proxecto hase atrasar se non ten tempo asignado para facer estes cambios, porque van consumir parte do tempo que queriamos adicar a todas as outras cousas que hai que facer no proxecto.
Outro motivo para programar algún tempo extra no proxecto é a formación e o adestramento. Non falo de cursos e seminarios, senón de cousas tan simples como facer prototipos ou ler documentación. Cando un piloto de rally participa nunha carreira, esa non é a primeira vez que pasa por este circuíto: xa pasou por el outras veces, tomando notas e estudando as curvas, para poder ir o máis rápido posible no día da carreira.
En cambio, moitas veces parece que se espera que os programadores sexan capaces de escribir un programa complexo no primeiro intento. Na práctica, moitas veces a primeira versión non serve e hai que facer unha nova, outra vez causando atrasos. Mellor sería asignar algún tempo para facer un prototipo antes da implementación real.
Moitas veces é difícil xustificar este tempo extra, especialmente en consultorías que cobran por horas ou en equipos que empregan metodoloxías Agile que poñen énfase nos sprints e en entregar historias de usuario e facer tantos puntos por sprint. Porén, facer o esforzo paga a pena porque dá igual se ese tempo está programado ou non: no final, hase consumir. A diferenza é o resultado que ides ter seis meses máis tarde: un proxecto de seis meses entregado a tempo ou un de catro meses entregado con dous meses de atraso. Os dous durarán o mesmo tempo, pero só un deles vai manter altas a reputación e a moral do equipo. Cal pensades que é?
A ilustración desta Folla é un gravado de José Guadalupe Posada.
1 comentario