oferecerem propostas mais simples de compreensao e apuracao de resultado, comecaram a chamar a atencao positivamente da industria de software. Face a isso, iniciou-se um movimento liderado pelas universidades no Brasil (hoje sou consultor de metodologias ageis da USP) que objetiva esclarecer os metodos e gerar conteudos praticos que facilitem a implantacao de tais propostas metodologicas. Certificadas de que estes metodos funcionam, as empresas de software comecaram a estudar uma proposta de metodologia classificada como agil, que propoe novos metodos em substituicao aos metodos praticados tradicionalmente. Este criterio de escolha, que em minha opiniao esta suficientemente maduro, buscou primeiramente resolver as questoes acerca da organizacao, distribuicao e controle das atividades de um projeto de software. Eis a explicacao da escolha da metodologia SCRUM pelo mercado de empresas desenvolvedoras de software.SCRUM, muito simples de usarA metodologia SCRUM esta entrando na moda aqui no Brasil, apos ja haver conquistados inumeras empresas da industria de software na America do Norte.Particularmente, eu considero o SCRUM uma proposta extremamente pratica e honesta. Defino por pratica neste contexto a facilidade de compreensao e aplicacao em nosso ambiente de desenvolvimento de software. Defino por honesta a fidelidade entre a proposta do metodo e o resultado que podemos obter apos aplica-lo. SCRUM, nome utilizado inicialmente pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka, descrevia um tipo de processo de desenvolvimento de produto utilizado no Japao.Tambem o nome SCRUM foi escolhido pela similaridade entre o jogo de Rugby e o tipo de desenvolvimento de produto comentado. Ambos sao adaptativos, rapidos e promovem a auto-organizacao.Para explicar SCRUM, utilizarei uma estrategia que foi usada pelo Ken Schwaber em seu livro chamado Agile Project Development with SCRUM. Na minha leitura, este e o melhor livro disponivel lancado ate a presente data. Iniciando um projeto, ha uma formalizacao de todas as coisas que se pretende fazer ou que se precisa construir no projeto. Cada item desta lista representa um requisito funcional, ou requisito nao funcional, ou questao de tecnologia / infra-estrutura. Esta lista e denominada Product Backlog.Podemos traduzir Product Backlog como uma lista de todos os requisitos de um produto priorizados, ou, em outras palavras, e qualquer coisa que represente um trabalho que precisa ser feito para o produto. Os itens com maior prioridade nesta lista sao os requisitos mais desejados pelo produto. No projeto real, o Product Backlog nunca e finalizado. Existe uma natural evolucao e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem ate serem eliminados. Apesar de se permitir que areas usuarias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog. O Product Owner possui a responsabilidade de definir a ordem que os requisitos serao produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos. Esta equipe recebe o nome de SCRUM Teams. A preparacao dos trabalhos e denominada SPRINT Planning.SPRINT Planning e composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condicoes e exigencias do negocio, as caracteristicas da tecnologia a ser usada e o comprometimento em entregar