mitos do desenvolvimento de software
DESCRIPTION
Apresentação do Rodrigo Yoshima na palestra do JustJavaTRANSCRIPT
Mitos do Desenvolvimento de Software
(e soluções ágeis)
Rodrigo Yoshima
Agenda
• Como era nos anos 90?• Mitos do Gerenciamento• Mitos dos Requisitos• Mitos do Design e do Código
Conheça o Tonhão!
Perfil do Sponsor 90’
O que ele queria:
• Uma solução rápida e barata• Feedback rápido• Ver coisas concretas• Implantar o mais rápido possível• Ganhar dinheiro com o software• Estar presente
Uma ligação que mudou tudo...
Y2K
Depois da virado do Milênio
Os projetos não voltaram mais para as empresas! Ficaram nas consultorias!
• Contratos ganharam muita importância• O usuário ficou distante• O report do andamento do projeto ficou abstrato• Os projetos ficaram maiores e mais custosos• RUP Cascata, CMM, PMBOK
O que estamos procurando?Definição de Sucesso de umProjeto de Software
• O software resolve o problema (qualidade externa)
• O software é fácil de manter e evoluir (qualidade interna)
• Menor custo e prazo possível (qualidade do projeto)
Mitos do GerenciamentoA base do gerenciamento de projetos de software é o processo iterativo incremental!
Mitos do Gerenciamento: Escopo
Escopo em software não são requisitos detalhados! Escopo são os problemas que o software pretende resolver!
As empresas tem problemas!!!
Duas empresas oferecem seus serviços:
Bravos Guerreiros S/A
• Experiência• Humildade• Foco em resultados• Escopo Aberto
DXA Ltda.
• Certificações• Planos detalhados• Foco no contrato• Escopo Fechado
Bravos Guerreiros S/A
Contrato de Escopo Aberto (Risco-Benefício)
• Cegar o dragão na semana 1• Tirar sua habilidade de voar na semana 2• Fazê-lo parar de cuspir fogo na semana 3• Impedi-lo de destruir casas na semana 4• Cortar suas pernas na semana 5
• O pagamento é semanal
DXA Ltda.
Contrato Escopo Fechado (por Entregáveis)
• Estudo exaustivo do dragão• Atirar 200 flechas• Lançar 30 pedras com a Catapulta• 400 golpes de espada• 250 golpes com o machado
• O pagamento é por ação tomada
Trazendo isso para software...
• Num primeiro planejamento rápido elabore uma “pilha de requisitos” que inicialmente é suficiente para solucionar o problema.
• Não é necessário detalhar os requisitos neste momento pois essa pilha pode mudar
• Priorize os requisitos (os mais importantes primeiro)
Desenvolvimento Iterativo
• Defina o tamanho das iterações– Todas elas terão o mesmo tamanho
– Qual a maturidade da equipe?
– Qual a disponibilidade do cliente?
1 2 3 4
...2 semanas
5
Desenvolvimento Iterativo• Desenvolva uma parte da pilha na iteração 1:
– Plano: O que podemos entregar?– Execute o trabalho focado só nesses requisitos – Entregue com qualidade– Demonstre o resultado para os interessados
1 2 3 4
...2 semanas
5
Desenvolvimento Iterativo• O ciclo recomeça!!!!
– Avalie as “avarias” no dragão (ele pode morrer antes!)
– Atualize a lista de requisitos (novos ou priorização)
– Faça o planejamento da iteração 2
1 2 3 4
...2 semanas
5
Desenvolvimento Iterativo
SIM, pode ser que nosso planejamento da iteração não se CUMPRA!!!!
1 2 3 4
...2 semanas
5
? ? ?
Por que não gerenciar tarefas?
“Você não consegue controlar aquilo que você não consegue mensurar.”
Tom Demarco, 1983
Mito do Gerenciamento
Em software, a soma das tarefas não é garantia de sorriso na cara do cliente.
O Gerenciamento de Projetos deve responder quais resultados você está obtendo e não o que você
está fazendo!
Como é a sua equipe?
Requisitos
Análise
Desenvolvimento
Teste
Por que não aplicamos Taylorismo?
Especialização e rigorosamente “dividir e conquistar” serviu para produzir mais carros de maneira mais barata. Na minha experiência esses princípios não fazem sentido como estratégia para desenvolvimento de software. Nem para o negócio e nem para o lado humano eles fazem sentido.Kent Beck, 2004
Mito: Divisão e Especialização
Promova a Colaboração!!!!
Mito: Divisão e Especialização
Papéis do SCRUM
Product Owner
Equipe
ScrumMaster
Erros em Requisitos!
• Ficar muito tempo sem reduzir a incerteza(sem entregar software funcionando)
• Requisitos mudam! (não adianta especificar todos no início)• Papel e Diagramas aceitam qualquer coisa• Software funcionando é o melhor artefato
para levantar requisitos
Faça junto com o Cliente!!!
Mitos da Análise e do Design
• O que é Análise para você?• O que eu quero com o meu Design?
Análise e Design focam principalmente a qualidade interna do software.
Como modelamos atualmente?
• Uso do modelo é homeopático• Modelamos em Grupo!• Focamos a comunicação dentro da Equipe• Poucos modelos viram artefatos• Buscamos um bom código e não um bom modelo• Rascunhos também servem• Modelagem = minutos / Codificação = horas
Usamos UML? Sim!
Usamos UML? Sim!
Sempre UML? Não!!!
Seu código sempre deve ser bonito. O modelo visual não!
O que é um modelo afinal?
“O modelo é uma simplificação de uma coisa complexa.” Grady
Booch, 1999
Mitos da codificação
• O que é programar para você?• Analista é melhor que Programador?
A codificação é a atividade que deve ser valorizada no desenvolvimento de
software, afinal, o código é o elemento mais próximo do que queremos de fato:
solucionar problemas de negócio.
Como programamos atualmente?• Nosso código é formal• Nosso código documenta praticamente 95% do projeto:
– Comentários em código– Orientação a Objetos: Alta Coesão / Baixo Acoplamento– Design Patterns (Padrões)– Domain-Driven Design– TDD / BDD : Testes, Testes e Mais Testes Automatizados– Fazer mais com menos código (frameworks e abstrações fortes)
Isso garante a manutenção do projeto!!!!
• Programamos em Grupo• Arquitetura Aberta• Design Emergente
O Código é o seu Design!
Programar é uma atividade de design – um bom processo reconhece isso, e não teme
iniciar a codificação quando isso fizer sentido. Jack W. Reeves, 1992
O Mito “Nerd”
Desenvolver software é uma atividade social e imersa na área
de negócios do cliente.
Quem quer simplesmente receber especificações e se isolar
não terá espaço no mercado!
Mito da Melhoria do Processo
