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

This message was edited 2 times. Last update was at 30/07/2010 16:50:43

fala galera. Faz um tempo que não posto aqui mas retornei por uma simples duvida.

Existe certificações para empresas que utilizam o SCRUM ou qualquer outra metodologia agil?
Uma empesa que utiliza destas metodologias, elas geralmente abandonam totalmente os processos formais da engenharia de software?

Eu comecei a estudar metodologias ageis recentemente. Sou aquela pessoa que nasceu e cresceu em ambiente baseado em processos, auditorias e evidencias. Achei interessante a forma que trabalha as metodologias ageis, mais precisamente o Scram. mas fiquei na duvida:
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 Scram? onde vai ser colocado tudo isso?

Vamos supor, num ciclo de vida de um projeto baseado no RUP...

Iniciação, planejamento, requisitos, analise e projeto, contrução, integração teste e homologação

não haveria estas fases certo?

Grato pela atenção.

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?

Att.,

Debugger Membro desde: 27/07/2010 13:50:07 Mensagens: 67 Offline

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/

Debugger Membro desde: 27/07/2010 13:50:07 Mensagens: 67 Offline

Mais alguém de Araraquara?

samuel.grigolato wrote:Mais alguém de Araraquara?

Mundo pequeno hehehe

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

alex lopes.

hahaha

Debugger Membro desde: 27/07/2010 13:50:07 Mensagens: 67 Offline

É o Mansidãaao cara! hehehehe..

JotaJota wrote:Existe certificações para empresas que utilizam o SCRUM ou qualquer outra metodologia agil?

Pra que uma empresa precisaria disso?

JotaJota wrote:Uma empesa que utiliza destas metodologias, elas geralmente abandonam totalmente os processos formais da engenharia de software?

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

JotaJota wrote: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?

Uma explicação mais detalhada disso ficaria meio grande... vou resumir de maneira "grosseira" dizendo que muitas dessas coisas acontece a cada Sprint, como "solicitação de mudanças", riscos... etc.

JotaJota wrote:Iniciação, planejamento, requisitos, analise e projeto, contrução, integração teste e homologação

Mesma coisa da resposta anterior.

JotaJota wrote: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?

Ele não tem que saber tamanho de nada, quem da tamanhos/complexidades/tempos para as coisas é a equipe de desenvolvedores.
UM sprint pode ter entre 2 e 4 semanas, um projeto é composto de VÁRIOS sprints.

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.

GUJ Expert Membro desde: 22/01/2007 22:00:53 Mensagens: 4181 Offline

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

Notícias, artigos e o maior fórum brasileiro sobre Java