IMHO, se vc espera conseguir CMMI/MPS.BR pra ter a certificação “Minha empresa é CMMI/MPS.BR nível X” eu diria que você pode adaptar desenvolvimento Ágil com o que essas certificações exigem.
Se você quer mais produtividade, vá pelo desenvolvimento Ágil.
Esses dias um “arquiteto de soluções” da microsoft me falou uma frase interessante… “Obter certificação CMMI é fácil, dobre o custo e triplique o prazo de seus projetos”
Se você for buscar por Lean, vai ver que o primeiro princípio é “Eliminate waste”, que não combina muito bem com o que CMMI/MPS.BR exigem…
Acho que é impressão sua. O cliente geralmente pede uma data de início e uma data de fim, quantas iterações tem no meio não é algo que ele geralmente se importe. Note que tieratividade != Escopo Aberto.
É o que eu quero, mas sabe como é. Vou escrever a proposta e ver o quê dá …
Estou vendo que o Scrum parece ser mais simples do quê imaginei, tem até o standup meeting diário que vi no XP. Vi tambem que ele pode ser combinado com o RUP. Acho que vou ficar com o scrum e “simplificar” a parte de desenvolvimento do ICONIX. Vamos ver, tem chão bagaraio …
E meu gerente quer tudo em 3 semanas (LOL).
Ainda bem que o enrolation tabajara não tem copyright
[quote=agodinhost]
Sashimi? Que comparação!!![/quote]
Sashimi (além de uma iguaria japonesa) é um princípio de processo de conceito bem simples: uma iteração é completa em si.
Pegue um pedaçod e filé de salmão e corte um pedaço. Você tem sashimi. Corte este pedaço em dois. Você tem 2 sashimis e não duas metades de sashimi.
Assim são as iterações e entregas em Scrum. O sistema é um filé de salmão e você aprte ele em pequenos sashimis, nunca entrega meio sashimi, sempre um sashimi, seja qual for o tamanho adotado.
Feature Driven Development certo Luiz?
Realmente nunca ouvi falar.
Você usa?
Achei muito material disponível em http://www.featuredrivendevelopment.com/ mas não achei menção a nenhum case nacional …
Tenho uma notícia boa e outra ruim. Primeiro a ruim: nunca ví processo prescritivo funcionar direito. Nem mesmo o RUP seguido ao pé da letra funciona. Todos os RUPs que funcionam são customizados. Essas receitinhas de bolo não existem.
Sei que para nossa área parece irresistível tentar controlar como a equipe vai se comportar. As pessoas tem medo quando um caso de uso fica ligeiramente diferente um do outro. Ficam incomodadas quando um diagrama está de um jeito e outro de outro. Esse “medo” é natural, mas o custo para você eliminar esse medo é alto demais!
Já trabalhei em muitos projetos e nesses projetos nenhum teve a dinâmica do processo igual. Os requisitos mudam, as pessoas mudam, a arquitetura muda, a geografia muda. Cada processo é diferente do outro. Para a gestão em geral, eles acham que com o processo as pessoas passam a ser descartáveis. Eles acham que com o processo eles não vão mais precisar reter talentos. É uma motivação errada para se ter um processo.
Vou falar uma coisa muito importante: a maioria das vezes que o gestor covarde diz que quer um processo se você pesquisar a fundo você vai ver que as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste e gerenciar o projeto. O processo de maneira alguma vai suplantar deficiências no skill das pessoas. Não é função do processo ensinar ninguém.
Um processo altamente prescritivo é motivado pelo medo, esse medo vai levar você a montar uma área SQA que vai te custar caro, o medo vai levar você ao vício do controle e você vai precisar de um PMO. O medo vai levar você ao lado negro da força.
Sendo um pouco mais prático SCRUM é uma metodologia que funciona muito bem com processos empíricos. O melhor exemplo de processo empírico que já ví é o post do Phillip acima. Resumindo em miúdos, todo processo de desenvolvimento de software deve ser baseado em INSPEÇÃO e ADAPTAÇÃO. O lado da engenharia pode ser um mix de práticas que você usa como uma caixa de ferramentas. Esse conceito é muito aceito atualmente. Tenho aplicado Casos de Uso, FDD e Domain Modeling para muitos projetos na parte de requisitos.
A notícia boa é que você está no lugar certo para fazer essas perguntas…
O negócio é abrir o olho e o blog do Vinicius é um excelente ponto de partida. Vejam as entrevistas de gente que implantou ISO, MPS.BR e CMMI e que hoje trabalha com SCRUM em http://blog.improveit.com.br/
Concordo com a maior parte do que vc disse, mas discordo quando vc afirma que “as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste”.
9 de cada 10 projetos afundam por incompetência GERENCIAL e não por incompetência técnica.
A incompetência técnica também é gerencial. Se as equipes não sabem desempenhar o trabalho é culpa do gestor.
Acho que coloquei minha frase de uma maneira errada. Você já trabalhou em alguns lugares onde tudo que dá errado as pessoas botam a culpa na falta de processos? Nesse cenário geralmente o problema é a falta de treinamento e não falta de processos.
