Scrum - existe certificação para empresas que utilizam o Scrum? / e outras dúvidas

E aíi Jota!

Então cara, a idéia por traz do Scrum é mudar a forma como o desenvolvimento é encarado, de forma a trazer o cliente mais perto (e com mais frequência) para o ciclo de desenvolvimento, evitando assim que quando seu software entre em produção ele já esteja obsoleto, ou seja, não atinja em sua plenitude os objetivos do cliente.

Metodologias ágeis não cobrem essas outras áreas que você citou, mas nada impede do processo organizacional abranger processos de reutilização e padronização de configuração de software, por exemplo.

Quanto as solicitações de mudanças, esse é o principal fundamento do cliente, que faz novas solicitações a cada Sprint (no caso do Scrum) e essas solicitações incluem as mudanças em funcionalidades já existentes.

Finalizando, não é que um projeto tem só 2 a 4 semanas, cada Sprint (parecido com uma iteração) tem uma janela de tempo fixo, o projeto em si não necessita nem de um final planejado (como geralmente é o caso em aplicações internas, onde os Sprints permanecem mesmo sem nada o que fazer, sem nenhuma alocação).

E ai Jota, blz rapaz!?

Existem certificações sim! => http://www.scrumalliance.org/courses | http://www.leadingagile.com/2009/05/why-leanssc-why-lean-certification.html

E de uma olhada no site do improveit, do Vinicius Teles, apesar dele ser pró XP, fala um pouco de Scrum também:

http://improveit.com.br/scrum

E claro…http://blog.fragmental.com.br/2008/05/27/a-completa-irrelevancia-do-certified-scrum-master/

Mais alguém de Araraquara? 8)

Mundo pequeno hehehe

Grande Samuel… tudo bem mestre?
A.L tbm é de Araraquara?

alex lopes.

hahaha

É o Mansidãaao cara! hehehehe…

Pra que uma empresa precisaria disso?

Scrum é sobre a gestão do projeto, não sobre engenharia de desenvolvimento… isso vc faz da maneira que achar melhor.

JotaJota:

E a area de Gestão de configuração
E a area de reuso?
e a area de solicitação de mudanças
e a area de riscos, métricas?

Com Scrum? onde vai ser colocado tudo isso?

Mesma coisa da resposta anterior.

JotaJota:

Como que o Product Owner iria ser capaz de entender que uma coisa que ele quer tem uma medida maior que a outra?
e se for um projeto super completo, que integra varias filiais ou varias unidades
2 a 4 semanas é relativamente pouco, não?

Se ajudar em algo: http://laguiar.wordpress.com/2008/06/30/introducao-scrum/

[]s

Scrum leva em conta times auto-organizaveis, boa parte das areas citadas estão pulverizadas na figura do PO, Scrum Master e Time.

O Software é desenvolvido iterativamente. Entre um Sprint e Outro ocorrem 2 reuniões de Planning com o Product Owner presente. Para mim ‘solicitação de mudanças’ acontece nesse momento, por exemplo (ate o Sprint atual pode ser cancelado para antecipar este evento). Um sistema grande pode ser desenvolvido por um ou mais times Scrum com um ou mais POs que se sincronizam de acordo com as necessidades. Com iterações curtas vc logo tem software funcionando, pronto para ser usado. Software sendo usado gera feedback do usuario. Feedback mais cedo gera outras histórias, por isso que geralmente se trabalha com escopo aberto. Inclusive dá pra descobrir se o software vai ser um fracasso e encerrar o projeto antes e diminuir o prejuizo.

Agora, isto serve para desenvolvimento de alguns tipos de produtos. Se vc quer lidar com algo já em produção que receba atualizações e bugfixes vc pode pensar em Kamban. Dessa forma vc não tem sprints mas trabalha com SLAs de X periodo de tempo por tarefas que são trabalhadas de forma continua.

Alguns projetos devem ser tão complexos, cheio de gente dando pitaco ou cheios de áreas que talvez não seja possivel usar Scrum num primeiro momento. Talvez seja interessante fazer um piloto com um projeto menor ou com uma parte dele. Na verdade ja seria muito bom trabalhar com interações curtas e uma reunião de retrospectiva do ciclo ao final, com o time.

Sou totalmente a favor do Scrum. acho muito eficiente.

O X da questão é que seu time tem que ser bom. Se tiver pessoas de pouca experiência e conhecimento do negócio/ferramenta, seus prazos vão sempre estourar.

Acaba sendo que se quiser realmente levar o scrum a sério, será necessário gastar mais. Quanto melhor a equipe tecnicamente falando, menor a chance do seu Sprint atrasar.

Como responsável pelo SCRUM eu emiti seu certificado de acordo com seu interesse.

http://bit.ly/cDao23