Enquanto o Extreming Programming(XP) tem como uma das suas práticas a programação em par, o Scrum utiliza a revisão de código. Quais das duas usar em seu projeto ? Qual é a melhor estratégia ?
Se você já tiver uma pequena noção sobre metodologias ágeis sabe que não existe uma resposta universal para as perguntas acima, a resposta certa é "depende". Obviamente se eu faço essas perguntas, dou essa resposta e então finalizo o post, tenho certeza de que perderei muitos leitores.
O objetivo deste texo é explicar algumas vantagens e desvantagens de cada uma dessas estratégias, quando e por que utilizá-las, além de mostrar a estratégia adotada com a equipe do projeto FPw Workflow (produto da LG Sistemas desenvolvido e mantido pela Fibonacci - Soluções Ágeis), no qual trabalhei por um ano e meio como Coach.
Programação em Par (XP)
A programação em par é, a principio, a estratégia mais cara, pois com ela é preciso manter dois desenvolvedores trabalhando na mesma estória. Porém, dessa forma, o código recebe revisão em tempo real, cada desenvolvedor monitora o código que o outro está escrevendo, o tempo todo, de forma a identificar erros comuns de programação de forma imediata, e então minimizar o custo de correção dos mesmos.
No final das contas a programação em par pode se tornar mais barata, já que irão "vazar" bem menos erros do que vazaria se uma pessoa estivesse programando sozinha, além disso o código fica mais legível já que será necessário a compreensão de duas pessoas e não de uma só.
Pergunta: Bem, se o a programação em par traz tantos benefícios por não utilizá-la sempre ?
Resposta: Quando as diferenças no níveis de conhecimento dos programadores de uma equipe possuir uma grande amplitude. Trocando em miúdos, se você coloca um programdor Senior para trabalhar em par com um programador estagiário sem nenhuma experiência, há uma grande chance de o Senior fazer todo o trabalho e o estagiário ficar olhando, pois não conseguirá acompanhar o desenvolvimento do outro, que por motivos de prazo e ansiedade, nem sempre terá a paciência para explicar tudo o que o outro não compreender.
Revisão de Código (Scrum)
O Scrum sugere que o código de uma dada feature seja revisado por outros desenvolvedores antes que possa ser considerado como concluído.
A princípio essa prática é mais barata pois só será necessário concentrar o trabalho de mais de um desenvolvedor em uma feature no momento da revisão de código, e esse momento é muito curto em relação a todo tempo necessário para a implementação da mesma.
Pergunta: Bem, se a revisão de código é barata, e no final o código será revisado por vários desenvolvedores, por que não utilizá-la sempre ?
Resposta: Durante o desenvolvimento de uma feature existem pontos críticos nos quais o trabalho em par se mostra muito mais eficiente do que trabalhar sozinho, de forma que trabalhar sozinho todo tempo pode atrasar o desenvolvimento além de impedir que a qualidade do código seja melhor, caso fosse escrito por mais de uma pessoa.
Na equipe de desenvolvimento do projeto FPw Workflow adotamos a seguinte estratégia para lidar tanto com as vantagens da programação em par quanto da revisão de código, e consequentemente minimizar as desvantagens das mesmas. A estratégia é exemplificada com a lista abaixo:
Espero ter contribuído!
Links:
http://www.lg.com.br/
http://fibonacci.inf.br/
http://improveit.com.br/xp/praticas/programacao_par
Se você já tiver uma pequena noção sobre metodologias ágeis sabe que não existe uma resposta universal para as perguntas acima, a resposta certa é "depende". Obviamente se eu faço essas perguntas, dou essa resposta e então finalizo o post, tenho certeza de que perderei muitos leitores.
O objetivo deste texo é explicar algumas vantagens e desvantagens de cada uma dessas estratégias, quando e por que utilizá-las, além de mostrar a estratégia adotada com a equipe do projeto FPw Workflow (produto da LG Sistemas desenvolvido e mantido pela Fibonacci - Soluções Ágeis), no qual trabalhei por um ano e meio como Coach.
Programação em Par (XP)
A programação em par é, a principio, a estratégia mais cara, pois com ela é preciso manter dois desenvolvedores trabalhando na mesma estória. Porém, dessa forma, o código recebe revisão em tempo real, cada desenvolvedor monitora o código que o outro está escrevendo, o tempo todo, de forma a identificar erros comuns de programação de forma imediata, e então minimizar o custo de correção dos mesmos.
No final das contas a programação em par pode se tornar mais barata, já que irão "vazar" bem menos erros do que vazaria se uma pessoa estivesse programando sozinha, além disso o código fica mais legível já que será necessário a compreensão de duas pessoas e não de uma só.
Pergunta: Bem, se o a programação em par traz tantos benefícios por não utilizá-la sempre ?
Resposta: Quando as diferenças no níveis de conhecimento dos programadores de uma equipe possuir uma grande amplitude. Trocando em miúdos, se você coloca um programdor Senior para trabalhar em par com um programador estagiário sem nenhuma experiência, há uma grande chance de o Senior fazer todo o trabalho e o estagiário ficar olhando, pois não conseguirá acompanhar o desenvolvimento do outro, que por motivos de prazo e ansiedade, nem sempre terá a paciência para explicar tudo o que o outro não compreender.
Revisão de Código (Scrum)
O Scrum sugere que o código de uma dada feature seja revisado por outros desenvolvedores antes que possa ser considerado como concluído.
A princípio essa prática é mais barata pois só será necessário concentrar o trabalho de mais de um desenvolvedor em uma feature no momento da revisão de código, e esse momento é muito curto em relação a todo tempo necessário para a implementação da mesma.
Pergunta: Bem, se a revisão de código é barata, e no final o código será revisado por vários desenvolvedores
Resposta: Durante o desenvolvimento de uma feature existem pontos críticos nos quais o trabalho em par se mostra muito mais eficiente do que trabalhar sozinho, de forma que trabalhar sozinho todo tempo pode atrasar o desenvolvimento além de impedir que a qualidade do código seja melhor, caso fosse escrito por mais de uma pessoa.
Caso Real: O melhor dos dois mundos no projeto FPw Workflow (LG Sistemas)
Na equipe de desenvolvimento do projeto FPw Workflow adotamos a seguinte estratégia para lidar tanto com as vantagens da programação em par quanto da revisão de código, e consequentemente minimizar as desvantagens das mesmas. A estratégia é exemplificada com a lista abaixo:
- No início de qualquer feature o desenvolvimento deve ser em par, com o responsável pela feature e o coach da equipe, até que solução já tenha um esboço inicial palpável(esse ponto varia de acordo com a experiência do desenvolvedor);
- O desenvolvedor deve reconhecer pontos, durante o desenvolvimento
, de maior impacto no código e na arquitetura do sistema, e então solicitar o coach para escolherem a melhor estratégia; - O restante do desenvolvimento o responsável realiza sozinho;
- Quando o responsável der a feature por concluída, o coach faz a revisão de código e se necessário deve solicitar a participação de outra pessoa da equipe com mais experiência.
Espero ter contribuído!
Links:
http://www.lg.com.br/
http://fibonacci.inf.br/
http://improveit.com.br/xp/praticas/programacao_par
.gif)
_1098.png)
_1100.png)
_512.png)
0 comentários:
Postar um comentário