Mitos do Desenvolvimento de Software

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

Obrigado!!!Mail: rodrigoy@aspercom.com.br

Blog: http://blog.aspercom.com.br