O Lucas Húngaro me perguntou:
[Q]uais os benefícios que você está vendo no Scrum em relação à maneira que normalmente é usada pra desenvolver software? O impacto positivo na qualidade está sendo sensível?
Vocês usam também práticas do XP como integração contínua?
Eu estou longe de ser um especialista no assunto–quarta-feira agora termino o meu terceiro sprint–mas posso falar um pouco sobre a experiência que estamos tendo como equipe. Se eu falar besteira, a maioria da equipe tem blog e pode me corrigir (ou matar, dependendo da quantidade de besteira).
Apenas para esclarecimento, como já foi mencionado muitas vezes em material sobre o assunto, Scrum e XP são complementares no sentido de que um trata sobre o processo de desenvolvimento e o outro sobre o próprio desenvolvimento. Em outras palavras, um está mais na esfera gerencial enquanto o outro mais na esfera de produção.
O que eu vi no meu treinamento inicial e, obviamente, nesse três primeiros sprints me convenceu de duas coisas:
- O Scrum não é uma silver bullet
- O Scrum é apenas uma questão de bom senso
O primeiro fato é bem óbvio: se o Scrum fosse realmente uma silver bullet, sua adoção seria bem maior e os resultados seriam ganhos de produtividade tão imensos que estariam abalando a indústria nesse momento. O Scrum é muito bom, mas responde por somente uma das facetas de todo o processo de desenvolvimento.
Sobre o segundo fato, o Scrum é uma forma do velho acordo de cavalheiros, uma coisa que está cada vez mais distante de nosso realidade “moderna”. É uma proposta simples: o gerente diz o que precisa, os desenvolvedores dizem o que podem fazer–ambos sendo honestos entre si–e um acordo é feito sobre a produtividade dentro de um período. Nada mais e nada menos. Essencialmente, o Scrum é uma ferramenta que depende de uma comunicação honesta entre as duas partes envolvidas e que possui mecanismos para garantir que a comunicação continue honesta–ScrumMasters, taskboards, e burndown charts são só maneiras de garantir que a comunicação e o bom senso continuem sendo aplicados ao longo do sprint, o período convencionado para o desenvolvimento das características combinadas.
Nesse sentido, os benefícios, na minha opinião, são:
- Controle de expectativas
- Visibilidade de processo
- Comunicação facilitada
O impacto na produtividade e qualidade são medidos dentro desses três prismas e são bem interessantes. Obviamente, dentro do que o Scrum estabelece, há uma exigência de que todos comprem a idéia do mesmo. Uma equipe no processo caótico usual onde o gerente desconfia dos desenvolvedores, estabelece prazos irreais, e onde os desenvolvedores estão sempre dando estimativas incorretas por medo das conseqüências, não consegue, de forma alguma, usar o Scrum.
Quanto todos estão na mesma página–e 90% do Scrum é isso–a qualidade começa a aparecer porque o controle das expectativas é formalizado, o processo é transparente e todo mundo consegue acompanhar e resolver os problemas tão logo aparece, e a comunicação chega ao seu nível ideal.
Finalmente, em relação ao XP, estamos experimentando com o mesmo. No momento, estamos usando pair-programming e estamos bem satisfeitos com o incentivo que o mesmo está dando à equipe. A princípio, usar TDD e alocar duas pessoas em uma única tarefa parece contra-producente mas o efeito é realmente o contrário.
Estamos fazendo integração contínua e é fácil para todo mundo acompanhar o que está acontecendo. É claro que, como estamos relativamente no começo, há muita a evoluir. Mesmo assim, os resultados tem sido interessante.
Voltamos então à pergunta: compensa? Do que eu vi até agora, a resposta é sim. Quando se tem uma equipe e você precisa resolver os problemas Brookianos normais, Scrum é o que até agora me pareceu mais interessante. Provavelmente não se aplica em todas as situações, mas para o que estamos fazendo está funcionado muito bem.
Espero ter respondido à pergunta do Lucas. 
Não sei se respondeu a dele, mas as minhas (que ainda não havia perguntado a você hehe) respondeu.
Uma pena que nem todas empresas tenham isso em mente (seja os diretores, sejam os desenvolvedores).
Valeu pelos esclarecimentos.
Olá Ronaldo, o que é um(a) “silver bullet”?
http://en.wikipedia.org/wiki/No_Silver_Bullet
e aqui http://www.lips.utexas.edu/ee382c-15005/Readings/Readings1/05-Broo87.pdf
Opa, respondeu sim!
Há um tempo razoável venho estudando os métodos ágeis (principalmente XP) e costumo fazer esse tipo de pergunta para quem trabalha em equipes que os utilizam, pra verificar se a teoria funciona na prática.
Obrigado, Ronaldo!
Rafael, Lucas, não tem de quê.
Eventualmente, a intenção da equipe é publicar alguma coisa sobre Rails, Scrum, BDD e tudo o que estamos usando aqui para beneficiar outras equipes.
caras, desculpa minha ignorancia….
mas to na faculdade ainda…. a empresa na qual trabalho hj tem uns clientes grandes…..
começei a uma semana no final de um projeto….
me gerente me passou umas tarefas pra fazer…. sem quase documentação nenhuma e explicado tudo meia boca…… não sei como será daki pra frente…
em outras empresas também é assim ou é tudo detalhado certim??
flw