Nos próximos parágrafos, dou sequência ao relato sobre minhas experiências práticas com métodos ágeis. Este artigo faz parte de uma série, iniciada em outubro de 2013 e garanto para vocês que vale a pena ler os artigos anteriores a este.
Quando fui contratado, em dezembro de 2012, fui alocado como webdesigner na equipe de desenvolvimento de sites, formada ainda por um desenvolvedor PHP e uma estruturadora. Uma de minhas funções nesta equipe era organizar o processo de trabalho e aumentar a produtividade da equipe. Soube, então, que esta equipe já havia realizado uma tentativa sem sucesso de usar o SCRUM para o processo de desenvolvimento de sites.
O principal motivo pelo fracasso dessa implantação foi o fato de o processo de desenvolvimento de sites ser muito dinâmico, o que obrigou uma adaptação drástica do SCRUM ao processo da empresa. Talvez, devido à falta de domínio do framework, a equipe não percebeu que também era necessário a mudança de comportamento cultural.
Se tivessem analisado melhor a situação e estudado melhor o framework, teriam percebido que o processo de produção da empresa se adaptaria melhor ao método Kanban ou à um mix dos dois métodos, Kanban e SCRUM.
Devido a essa experiência ruim da equipe, o primeiro desafio encontrado foi mostrar e provar que o problema não estava no método utilizado, mas na forma como o mesmo havia sido adaptado à realidade da empresa e nas pessoas, no comportamento e cultura que não haviam mudado.
Para resolver isto, o primeiro passo foi treinar a equipe, ensinando mais a fundo como o SCRUM e o Kanban trabalham, quais são seus focos principais, a diferença entre ambos (papéis, regras, artefatos, fluxos de trabalho, etc) e como podem ser utilizados em conjunto. Em seguida, foi realizada uma análise de como cada um dos métodos poderiam se adaptar, individualmente, aos processos atuais de desenvolvimento de sites.
Durante essa discussão e depois de muitas dúvidas respondidas, chegamos à conclusão de que era conveniente usar práticas dos dois métodos. E claro, era necessário uma grande mudança de postura dos membros da equipe de desenvolvimento e da diretoria.
Assim, iniciamos a implantação dessas mudanças. Utilizamos um novo projeto recém conquistado como projeto inicial. Inclusive, utilizei esse projeto como caso de uso para meu TCC da pós graduação que estava terminando na época.
Este projeto não obteve o sucesso que pretendíamos, mas em compensação, muitas melhorias de infraestrutura foram realizadas, como a aquisição de novo servidor de desenvolvimento local; a implantação de um sistema de help desk para organizar e melhorar a qualidade de atendimento aos clientes; a alteração do layout físico das salas, separando a recepção da sala de desenvolvimento e criando uma sala de reuniões para atender aos clientes; a implantação do repositório de versionamento de projetos; a reorganização do fluxo de trabalho do departamento comercial, entre outras. Todas as melhorias que trouxeram produtividade e um novo ânimo à equipe.
Logicamente, o fato de o primeiro projeto na nova metodologia de trabalho não ter obtido sucesso completo, trouxe desconfiança por parte dos membros da equipe. Devido a essa desconfiança e vários outros fatores, não demos a sequência necessária ao novo método nos projetos seguintes.
Já em agosto de 2013, parte da equipe de desenvolvimento de sites foi realocada para uma nova equipe de desenvolvimento de sistemas web, devido a um grande projeto de sistema. Na equipe de sites, ficou apenas um web designer que está usando, no momento, um Kanban pessoal para gerenciar suas tarefas. Como a ideia é montar uma nova equipe para o desenvolvimento de sites, em breve o método criado para ela voltará a ser utilizado com as devidas adaptações.
A nova equipe montada para o desenvolvimento de sistemas hoje é composta por mim e dois programadores. O método que vamos utilizar é o SCRUM e, no próximo artigo, contarei qual foi o primeiro desafio que enfrentei no gerenciamento dessa equipe.
Deixem seus comentários e até o próximo artigo.
