Páginas

quarta-feira, 31 de agosto de 2011

Implantando métodos ágeis em uma equipe gerenciada pelo BPC - parte 1


Estou dando inicio a uma série de post onde pretendo relatar como foi implantar métodos ágeis em uma equipe que utilizava o BPC na sua essência. Neste primeiro post vou falar de como foi implantar o SCRUM, destacando as dificuldades do processo de transição entre uma metodologia e outra.
A equipe de desenvolvimento era composta por 4 a 5 programadores e um gerente de projetos. O papel de analista era desempenhado pelo gerente e em outras situações pelos próprios programadores. Cada programador era responsável por um projeto, sendo assim, tínhamos sempre em desenvolvimento de 4 a 5 projetos, algumas vezes 1 programador ficava de responsável pelos BUGs, de todas as aplicações do setor de desenvolvimento, formando o cenário antes do SCRUM.
Devido a diversas questões de mercado, a empresa em questão unificou-se a outras grandes empresas formando uma grande rede nacional, e com isso surgiu a necessidade de um sistema que seria utilizado por toda a rede recém formada. Por causa da experiência da equipe de desenvolvimento no sistema que era necessário, a equipe foi designada a desenvolver o projeto em conjunto com a infra da sede, o nosso cliente também estava na unidade sede. Foi ai que começou os nossos problemas.
  • Primeiro, o usuário possuía um sistema que cobria todas as suas necessidades e não desejava a troca do mesmo, a troca de sistema estava sendo feita para reduzir custo pois os sistema terceiro tinha um custo altíssimo para a rede, sendo assim desde as primeiras reuniões ele tentava complicar ao máximo o desenvolvimento do novo sistema.
  • Segundo, as equipes da unidade sede trabalhavam utilizando metodologias tradicionais de desenvolvimento, e nós a BPC, em outras palavras, incompatibilidade total de trabalho.
  • Terceiro, o projeto era muito grande e devido as possibilidades que tínhamos de gerenciar o projeto (tradicionais ou BPC), era inviável desenvolver, pois se utilizássemos a tradicional não conseguiríamos entregar no prazo e se utilizássemos a BPC provavelmente entregaríamos no prazo porém não garantiríamos a qualidade.
Com o cenário descrito acima foi que surgiu a idéia de utilizar as metodologias ágeis, pois ao analisar o projeto identificamos que devido ao tamanho do projeto era praticamente impossível identificar todos os requisitos no inicio para fecharmos o escopo, e também verificamos que os requisitos poderiam ser entregues de acordo com a necessidade do cliente. Inicialmente a gerência relutou em aceitar o uso do Scrum, pois tanto a BPC quanto as Tradicionais fecham o escopo no inicio do projeto e como iríamos trabalhar com escopo flexível isso gerou uma grande desconfiança, se conseguiríamos entregar o projeto, mas por falta de opção eles tiveram que aceitar, uma vez que não conseguiriam entregar o projeto utilizando nenhuma das metodologias já utilizadas.
Após o convencimento dos gerentes veio a montagem e o treinamento do time. Esse momento foi bastante complexo, pois como foi citado anteriormente todos eram acostumados a trabalhar sozinhos em seus projetos, e a partir daquele momento deveríamos trabalhar em equipe como um time e não mais individualmente. Com isso, surgiram dificuldades como:
  • Trabalho em equipe. Este foi o maior problema por causa da vaidade de cada um. Não tínhamos a ideia de time, onde o pensamento de um complementa o do outro, no inicio o que imperava era o individualismo e cada um queria impor a sua ideia, isso gerava muito conflito entre os membros da equipe, ao longo do tempo foi passado ao time que ninguém era melhor ou pior, e que juntos o nosso conhecimento seria muito maior.
  • Velocidade x Qualidade. Quando terminávamos a reunião de planejamento, cada um pegava uma estória e fazíamos o mais rápido possível aquele requisito. Nos primeiros sprints, tivemos diversos problemas, pois nenhum requisito foi entregue 100%, sempre presamos a entrega e até aquele momento não nos preocupávamos muito com a qualidade e isso foi sentido fortemente na primeira entrega pois poucos requisitos foram entregues. Devido a essa primeira experiência começamos a garantir nossas entregas, era melhor entregar uma estória 100% do que 5 pela metade.
  • Porco e Galinha. Na histórinha conhecida do “Porco e da Galinha” quem se comprometi é sempre o “porco”, só que no inicio as “galinhas”(gerência) insistiam em se comprometer com o cliente com as entregas dos requisitos, e isso gerava um grande desconforto entre o time e a gerência, pois eles estavam traçando cronogramas sem consultar os “porcos”, com o tempo a confiança da gerência na equipe foi aumentado e esse problema foi resolvido, pois eles começaram a enxergar o comprometimento do time para com o projeto.
  • Cliente. O nosso cliente estava acostumado a trabalhar com escopo fechado, onde ele definia todas as funcionalidades do sistema no inicio e após uma serie de documentos assinados não se mexia mais no escopo do projeto. Sendo assim sempre que queria fazer uma solicitação ele enviava email para toda a gerência fazendo o maior “barulho”, pois ele achava que nós não faríamos o que ele estava solicitando. Aos poucos fomos explicando para ele a nossa maneira de trabalhar, pois ele também fazia parte do time e sem ele o projeto seria inviável. Quando entendeu que nós não éramos inimigos dele e sim parceiros nessa nova empreitada, o projeto fluiu naturalmente.
Depois de aproximadamente 2 meses do inicio do projeto a maioria das dificuldades acima já estavam controladas e sendo bem administradas, porém até hoje algumas vezes elas teimam em voltar, mas hoje administramos muito bem todas elas.
Abaixo vou listar as principais vantagens que tivemos com o uso do Scrum na gerência dos nossos projetos.
  • Comprometimento. O nosso time hoje é muito mais comprometido com o trabalho do que antes, pois hoje somos ouvidos nas decisões referentes aos cronogramas do projeto.
  • Qualidade. a quantidade de problemas que temos hoje em nossas entregas é muito pequena, uma vez que presamos muito a qualidade da entrega e não a quantidade.
  • Conhecimento. o conhecimento dos membros do time aumentou exponencialmente, pois ao dividirmos nossas experiências e conhecimento nivelamos por cima a equipe.
  • Respeito. as ideias e opiniões de todos são respeitadas hoje, pois sabemos que dentro do time nós nos completamos.

Tentei passar neste post um pouco da minha experiência na implantação das metodologias ágeis no desenvolvimento de softwares, o Scrum foi utilizado na gerência dos projetos com o auxilio do Extreming Programming (XP), a união dessas duas metodologias foi importantíssimo para o sucesso do projeto, pois o Scrum atacou a Gerência do Projeto e o XP a engenharia do sistema. Sobre o XP, falarei no próximo post.

Nenhum comentário:

Postar um comentário