Se collo a calquera de vós ao chou e lle pido que me recite as fases dun proxecto de software, seguro que me dirá algo semellante a “análise, deseño, implementación, mantemento e retiro”. De todas elas, a que menos atención recibe é a fase de retiro, así que, para non variar, non vou falar dela. A Folla de hoxe vai sobre o mantemento.
Moita xente pensa que, cando un proxecto chega á fase de mantemento, xa está todo o importante feito e só queda conservar o proxecto en marcha.
A miúdo, o equipo que fai a implementación é un equipo totalmente distinto do que fai o mantemento: o equipo de implementación chámase “desenvolvemento” e o equipo de mantemento chámase “sistemas”. Estes dous equipos só se comunican enviando programas compilados nunha dirección e emails extremadamente retranqueiros na outra dirección.
O equipo de desenvolvemento e o equipo de sistemas discuten amigablemente sobre a causa dun fallo en produción.
Cando un proxecto está organizado desa maneira, é moi difícil facer cambios nel despois de que pase a produción. O equipo de sistemas normalmente non ten programadores de seu, e se os ten, eles non contan cos medios necesarios para facer cambios no programa. O equipo de desenvolvemento é o que pode, pero agora está a traballar nun proxecto distinto e non ten tempo, ou os programadores que o fixeron marcharon da empresa, ou calquera outra escusa.
Moitas organizacións externalizan o desenvolvemento e o mantemento das aplicacións e caen nesa trampa. Se non sabiades por que moitas aplicacións das Administracións Públicas aparentan ser do ano 2005 e piden Internet Explorer 6 ou Netscape Navigator 4, velaí a resposta.
Isto non ocorre só co software de servidor: tamén pasa na industria do software para a venda. Moitos proxectos teñen un “equipo A” que desenvolve as novas versións dos programas e, cando o programa sae á venda, o equipo A muda para a próxima versión do programa, mentres que a versión actual pasa ás mans do “equipo B”, que ten como función arranxar erros e problemas de compatibilidade. Normalmente, o equipo B ten menos medios e experiencia que o equipo A, así que a calidade e a velocidade do seu traballo son inferiores.
Para evitar este problema, moitos expertos suxiren integrar os equipos que se adican ao desenvolvemento e ao mantemento. No exemplo do software que se pon á venda non habería equipos “A” e “B” separados, senón que sería un equipo único o que desenvolvera a nova versión mentres, tamén, manteñen a versión antiga. Esta solución ten tamén os seus propios problemas, especialmente coa prioritización e asignación de recursos a cada versión do proxecto, pero é interesante tela en mente.
No mundo do software de servidor, moitas organizacións tamén están a integrar os seus equipos. Nelas, o grupo de SRE ocupa o espazo que, noutras empresas, pertencería a “sistemas”, pero o seu papel é moito máis amplo. Os SRE son expertos en produción pero tamén son programadores competentes que colaboran co equipo de desenvolvemento para que a aplicación teña todo o necesario para monitorizala, para que escale, e todas esas cousas.
Outro termo que podedes procurar se estades interesados é DevOps. Neste sistema, os grupos de desenvolvemento e de produción están aínda máis integrados, e moitas veces son, directamente, o mesmo equipo. A risco de repetirme, “esta solución ten tamén os seus propios problemas, pero é interesante tela en mente”.
Dunha maneira ou doutra, espero que esta Folla vos anime a pensar máis na fase de mantemento dos vosos proxectos.
A ilustración desta Folla procede dun debuxo de Honoré Daumier.
1 comentario