Olá pessoal, esse meu último afastamento foi o maior de todos, alguns meses se passaram sem posts no blog. :/
Mas agora, estou "de-volta, de-novo, novamente, Again!!!", a redundancia é proposital, para enfatizar as ida
Pois bem, agora estou de volta com força total. Neste post vou atualizar vocês com algumas coisas que aconteceram nestes últimos tempos.
Agora imaginem somar a esta complexidade, um projeto legado que precisa ser mantido e evoluído, em paralelo com outro projeto que está sendo concebido. Consegum imaginar este cenário ? Um único líder e uma única equipe, para lidar com os dois projetos.
O projeto A que já está no mercado em dezenas de clientes, com uma certa demanda de manutenção e evolução, e o projeto B, que está sendo construído em paralelo e conta com um cliente interno. Além disso, o projeto A é em Delphi voltado para Win32 e o projeto B é em .NET voltado para WEB.
Bom, até um tempo atras eu imaginava que isso era possível, talvez por otimismo, talvez pela motivação do desafio, ou por qualquer outro motivo, eu acreditava que era possível no meu cenário(talvez em outros cenários seja mais viável), vi que estava equivocado e diante disso, compartilho com vocês algumas dificuldades que encontrei:
Para começar, quem conhece sabe que a adoção de métodos ágeis não é fácil. Eu acredito até que seja mais dificil do que um processo formal, ditado por regras e documentações extensivas.
Até mesmo em um ambiente digamos "propício" a uma metodologia ágil, com uma equipe experiente, motivada, uma liderança forte e bem definida, com um cliente participativo no projeto, mesmo neste ambiente, é complexo adotar metodos ágeis e suas técnicas e práticas.Agora imaginem somar a esta complexidade, um projeto legado que precisa ser mantido e evoluído, em paralelo com outro projeto que está sendo concebido. Consegum imaginar este cenário ? Um único líder e uma única equipe, para lidar com os dois projetos.
O projeto A que já está no mercado em dezenas de clientes, com uma certa demanda de manutenção e evolução, e o projeto B, que está sendo construído em paralelo e conta com um cliente interno. Além disso, o projeto A é em Delphi voltado para Win32 e o projeto B é em .NET voltado para WEB.
Bom, até um tempo atras eu imaginava que isso era possível, talvez por otimismo, talvez pela motivação do desafio, ou por qualquer outro motivo, eu acreditava que era possível no meu cenário(talvez em outros cenários seja mais viável), vi que estava equivocado e diante disso, compartilho com vocês algumas dificuldades que encontrei:
- Manutenção, ainda mais de projetos legados, são complicadas, muitas vezes imprevisíveis. Além disso, a correção de erros precisa ser priorizada, dessa forma os SLA's de manutenção acabam interferindo no desenvolvimento das stórias do sprint.
- A mudança de foco entre problema, tecnologia, cenário, plataforma do projeto A e do B, afetavam a produtividade e o crescimento da equipe. Ao invés de termos uma equipe com aquela tradicional curva de aumento de produtividade ao longo dos ciclos, tinhamos uma equipe com pouco ganho de produtividade, pois ela acabava não se dedicando inteiramente a um único projeto.
- A gestão de tarefas fica mais complicada, pois temos que misturar tarefas de dois projetos diferentes, com prioridades e complexidades diferentes, com processos e equipes de homologação diferentes.
- Algumas demandas de customização, prendiam membros da equipe por dias, atrapalhando a evolução do ciclo.
Motivado pelo desafio, buscamos customizações no processo e no ambiente, de forma a suportar este cenário. Eu admito que o resultado não foi ruim, mas estava distante do ideal. O Projeto A estava controlado com as customizações e correções sendo atendidas no prazo. Por outro lado o Projeto B estava se movimentando a 30km/h, mas o product owner precisava que este projeto se movimentasse a 100km/h.
Diante disso, em uma reunião com o Product Owner, foi decidido pelo caminho talvez mais óbvio: A divisão da equipe. Definimos um período de transição, e uma data de corte, quando a equipe do projeto B seria desligada do projeto A. Fiquei como ScrumMaster do projeto B, sem ter que me preocupar mais com o legado e as manutenções do projeto A. Ou seja, a partir de agora, eu e a equipe poderiamos ter Foco.
Escolhi os membros que melhor se enquadravam e fizemos a migração.
Desde então retomamos de forma mais consistente a adoção de Agile e o projeto está começando a ganhar mais volume e força.
Nos próximos posts comentarei mais sobre essa nossa nova experiência, falando sobre as práticas que estamos utilizando, os padrões que estamos seguindo, as dificuldades que estamos encontrando, enfim, sobre nossa experiência Agile.
Por hora é isso, desculpem-me pelo afastamento, e espero nos próximos dias, semanas, meses, anos, compartilhar muitas experiências de adoção de métodos ágeis com vocês.
Abraço.
Diante disso, em uma reunião com o Product Owner, foi decidido pelo caminho talvez mais óbvio: A divisão da equipe. Definimos um período de transição, e uma data de corte, quando a equipe do projeto B seria desligada do projeto A. Fiquei como ScrumMaster do projeto B, sem ter que me preocupar mais com o legado e as manutenções do projeto A. Ou seja, a partir de agora, eu e a equipe poderiamos ter Foco.
Escolhi os membros que melhor se enquadravam e fizemos a migração.
Desde então retomamos de forma mais consistente a adoção de Agile e o projeto está começando a ganhar mais volume e força.
Nos próximos posts comentarei mais sobre essa nossa nova experiência, falando sobre as práticas que estamos utilizando, os padrões que estamos seguindo, as dificuldades que estamos encontrando, enfim, sobre nossa experiência Agile.
Por hora é isso, desculpem-me pelo afastamento, e espero nos próximos dias, semanas, meses, anos, compartilhar muitas experiências de adoção de métodos ágeis com vocês.
Abraço.
Show, muito bom este artigo. Lhe desejo um novo re-re-começo com muita motivação pra que continue a nos trazer estas cconstrutivas informações.
ResponderExcluirRicardo aqui na empresa aonde trabalho temos problemas parecidos, temos vários sistemas(todos em Delphi - Win32) totalmente diferentes um dos outros em termos de finalidade para os nossos clientes e também são projetos legados. Temos um sistema que é o Carro Chefe da empresa e outros que são usados por poucos ou até um cliente, mas que necessariamente precisam de manutenção. E o rodízio da mão de obra dentre esses projetos faz com que a produtividade fique abaixo do esperado. Mas como INFELIZMENTE a documentação dos projetos aqui são poucas ou inexistentes e dizem que não temos TEMPO para isso, esse rodízio dos desenvolvedores nos sistemas acaba sendo meio que obrigatório, pois mesmo se um deles sair da equipe um outro desenvolvedor que já trabalhou no projeto poderá assumir o lugar. :S
ResponderExcluirOlá Wesley, desculpe pela demora no feedback, agora estou voltando a ficar mais ativo na atividade de blogueiro rsrs.
ResponderExcluirPois bem, este cenário é realmente muito complicado, ter que se dividir em vários projetos, em fases diferentes e as vezes em tecnologias diferentes, exige muito da equipe.
A adoção de Agile nestes ambientes se torna mais complexa do que o normal, sendo até inviável em alguns casos e sendo necessária muita customização na maioria das vezes.
Uma alternativa que considerei em meu ambiente, e acho que a tentativa é válida, é a seguinte: Se não for possível particionar a equipe, tentar particionar o dia dela, por exemplo, até 12:00 a equipe foca em um projeto depois disso foca no outro. É uma abordagem que pode dar certo, e exige bastante jogo de cintura do líder da equipe para gerenciar as requisições que fossem surgindo, negociar os prazos e garantir o foco da equipe nestes horários.
Talvez assim seja possível manter a rotatividade necessária e aumentar o foco, visto que os desenvolvedores só mudariam de foco uma vez no dia, ao invés de ficar naquele "vai-e-vem" de projetos e muitas das vezes sem nem saber o que o espera naquele dia.
É claro que esta abordagem não trará a mesma produtividade que se tivesse equipes distintas, cada uma focada em um projeto, mas acho que é uma tentativa válida.