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.
