 |
| Photo by Eden Constantino on Unsplash |
Começo este texto em jeito de desabafo!
Andam para aí uma série de empresas / equipas / cenas, a afirmar que são ágeis, a implementar(?) metodologias ágeis e a perder tempo com cerimónias das quais não retiram sumo nenhum, mas como está na moda, são ágeis... e de ágeis só têm o nome.
"Ah e tal, isso do Scrum, Kanban e/ou outras não resulta"
Não?! Talvez não, mas só porque não são correctamente implementados, ou mesmo que o sejam, é preciso que as pessoas da organização mudem o chip para essa realidade.
Primeiro é necessário formar as pessoas e alterar a maneira de pensar (e de estar) destas, a seguir implementa-se (de preferência com a ajuda de alguém experiente) e depois sim, resulta.
Entre outras coisas, estimativas não são deadlines, sprints não são projectos waterfall de 3 semanas, as regras não podem mudar a meio (nem a todo o momento consoante o vento), pois metodologias ágeis não são sinónimo de desordem, confusão ou anarquia, o achometro de quem é superior hierárquico não é uma escala de medida científica, o modelo squads da Spotify resulta com eles, mas para lá chegarem passaram por implementação correcta da metodologia base, deixaram o processo ganhar raízes, mediram resultados e só depois foram alterando o que faz sentido para a sua realidade, e sobretudo: metodologias ágeis são (ou deveriam ser) baseadas em relações de confiança, abertura, partilha de informação, tudo sempre às claras, sem nada escondido debaixo do tapete, sem quintinhas, sem conceitos de que a minha quinta é melhor do que a tua. Mais: na minha opinião deve ser aberta à participação de todos.
Obviamente existem regras para isto funcionar, mas é (ou deveria ser) muito assim.
Nota: neste ponto terminou o desabafo e começa o texto a sério 😂
Colocando os maus exemplos de parte, felizmente já passei por equipas extremamente bem organizadas, com um ADN ágil e muito boas no desenvolvimento de software, com boas práticas, rapidez e qualidade na entrega, mas claro, temos sempre mais para aprender a todo o momento e existem sempre organizações e/ou equipas que estão um pouco mais à frente.
É aparentemente este o caso que vou descrever.
No meu computador pessoal, o sistema operativo é sempre e em exclusivo uma qualquer distribuição GNU/Linux, a minha preferida é o Debian com o ambiente de trabalho Gnome, mas recentemente apaixonei-me pela forma como a Canonical implementou o ambiente de trabalho Budgie num dos derivados oficiais do Ubuntu, andei um tempo a testar aquilo numa máquina virtual, mas depois aproveitei o lançamento da última LTS (Long Term Support) e instalei no computador.
Após a instalação e enquanto configurava o sistema operativo a meu gosto, detectei um erro, fui à Internet procurar o contacto para bug report, registei-me e mandei para lá a descrição do que estava a ocorrer, juntamente com um print screen e pronto.
Julgava eu que era só isto, mas fui agradavelmente surpreendido!
Quando dei por mim, estava inserido numa espécie de backlog de erros, fui sendo sempre avisado das actualizações do estado, qual o user que estava com o bug e a fazer o quê.
Após correcção forneceram-me instruções para testar, solicitando-me também que indicasse o passo a passo de todos os testes que fiz, os respectivos prints, resultados e no fim instruções para alterar o status do bug em conformidade.
Isto a mim diz-me muito, trabalho na área e o que estes senhores da Canonical demonstraram foi um profissionalismo ímpar, desenvolveram uma forma de dar acesso limitado mas mais do que suficiente para fazer o utilizador sentir-se como se fizesse parte da equipa, ganham ajuda externa, voluntária e gratuita para aumentar a qualidade do seu produto e todos ganham.
Passado uns dias soube-me mesmo bem quando o sistema operativo me alertou para a existência de actualizações e verifico que uma delas foi a que reportei (notem o sentido de pertença que o utilizador passa a ter com o produto) 😀
Comentários