Feeds:
Posts
Comentários

Archive for maio \29\+00:00 2011

Construir um produto de software é diferente de qualquer outro tipo de produto. A abstração é muito grande. E todo projeto de software sofre dos mesmos problemas: Escopo e cronograma extrapolado, usuários insatisfeitos e implementação de funcionalidades desnecessárias. E qual o primeiro e talvez único que culpamos nesta história toda? O usuário, que muda de ideia o tempo todo e não consegue manter o escopo original, causando todo atraso.

Bom, se nenhum projeto é igual ao outro (escopo, usuários, requisitos, forma de desenvolver), mas todos sofrem dos mesmos problemas, será que o problema está mesmo no usuário ou em nossa forma de desenvolver software? “Se você acha que o problema está fora, esse pensamento é o problema!”. Vamos refletir.

Adepta a métodos ágeis há muito tempo (o muito tempo são 4 anos, desde do final da faculdade), onde naquela época me apaixonei por Extremme Programming (XP) e Scrum na teoria (não trabalhava com desenvolvimento ainda), sempre busquei ler muitas experiências relatadas na internet da aplicação destas práticas ágeis, em blogs, palestras, artigos, etc. Encontrei recentemente uma palestra que relatou exatamente o que enxerguei no Scrum. Uma maneira óbvia de desenvolver software, que poucas pessoas enxergam e têm a coragem de aplicar (porque “ninguém” gosta de mudança). Mas mesmo pensando desta maneira “ágil”, cometemos de vez em quando os mesmos erros: Culpamos os usuários dos atrasos e mudanças, ou, fazemos “cara feia” para as mudanças, como se fosse proibido acontecer.

Vamos nos colocar como usuários em outras situações. Quando você vai comprar uma roupa, você simplesmente explica o estilo, cor, tamanho, detalhes, espera a vendedora achar algo que se encaixe nesses “requisitos”, leva a roupa embalada e ao tirar da sacola para usar, tem uma surpresa!? Não, nós compramos roupa vendo, provando, e às vezes até levando pra casa pra combinar com outras peças do guarda-roupa, não é mesmo?

Vamos pensar em outra situação, a de aproveitar a oportunidade. Sua loja preferida de calçados  (ou de sua esposa)  entra em uma mega liquidação com descontos de até 70%. Ela compra vários como se fosse a última oportunidade! Se ela soubesse que essa promoção é mensal ou semanal, não compraria menos? Rs… Sim! É o que acontece: Fechamento do escopo no início do projeto vs Priorização de estórias à cada Sprint.

Esta palestra e alguns exemplos que foram dados me fizeram pensar nisso: “É verdade. A hora do planejamento do escopo é a única oportunidade que o usuário tem de pedir o que ele precisa. E exigimos que ele nos conte tudo, com detalhes, sem conhecer de software, sem conseguir imaginar o resultado final, sem “provar” nada! Tudo para evitar atrasos”.

Você sabia que 7 entre 10 projetos de software atrasam 200%? E que 80% das funcionalidades do software não são utilizadas?

Bom e aí, é hora de começar a pensar no óbvio: Se o usuário tivesse mais oportunidades para solicitar novos requisitos e a possibilidade de ir provado de pouquinho o software, este cenário não poderia ser diferente?

O Scrum propõe exatamente isto: Resposta rápida às necessidades de negócio, menor impacto das mudanças no projeto, entregas frequentes de software funcionando, priorização dos requisitos a cada “timebox” (entrega), etc.

Vale a pena ouvir a palestra.

Num próximo post explico o Scrum e como essas ideias podem ser aplicadas.

Read Full Post »

Você usa mesmo Scrum?

Ao escrever o post me deparei com uma dificuldade. Como tratar de Scrum? Metodologia, Método, Modelo ou Framework?!

Gostaria muito de me aprofundar nesta questão e levantar debates, encontrar definições, mas procurando discussões e definições na internet, encontrei muito debate sem fim. Como não quero nem tenho propriedade para bater o martelo em relação a este assunto, vamos deixar o debate para quem possui mais argumentos. Para mim, método ou framework não mudam meu conceito de Scrum. O importante é entender Scrum, estudar Scrum. O que o defini vamos deixar para depois.

Então, vou chamar de simplesmente “O [coloquem o que quiser aqui] SCRUM”.

Bom, o Scrum não nos ensina uma receita exata de como fazer as coisas (receitas vocês vão encontrar em panelasnovas.wordpress.com, rsrsrs). O que devemos fazer é adaptar suas práticas à cultura da empresa. Muitos não entendem isso e interpretam Scrum de maneira errada. Outros aplicam mais ou menos, as coisas não vão bem e então, “o Scrum não funciona”. Será que usamos mesmo Scrum?

Encontrei uma entrevista com o Jeff Sutherland (um dos inventores do Scrum), dizendo que aplica um teste às equipes (Nokia Test) para verificar se estão mesmo usando Scrum. Para acompanhar a entrevista, clique aqui. O teste se resume basicamente nas premissas abaixo:

As iterações devem ter um tempo menor do que quatro semanas.
-O software deve estar testado e funcionando ao fim de cada iteração.
-A iteração deve começar antes que toda a especificação esteja pronta.

A segunda parte foca no Scrum propriamente dito. As perguntas são:

– Existe um Product Owner definido?
– Existe um Product Backlog priorizado por valor de negócio?
– O Product Backlog tem estimativas criadas pela equipe?
– A equipe gera gráficos de burndown e sabe a sua velocidade?
– Não existem gerentes atrapalhando e interrompendo o trabalho da equipe?

E você, usa Scrum? O que você aplica no dia-a-dia do seu trabalho?

Read Full Post »