asai – administração da informática – prof. malomar alex seminotti

ASAI – Administração da Informática – Prof. Malomar Alex Seminotti


Atender necessidades do cliente Prazo x Custo aceitáveis Crise do Software – desenvolvimento caótico Relatório de 1969◦ 50 a 80% dos projetos não concluídos◦ 90% dos concluídos com orçamento 150 a 400%

superior ao previsto


Chaos Report (Standish Group)

Fonte: Teles (2004)


Utilização das Funcionalidades

Fonte: Teles (2004)


Crise continua atualmente Pressman: “...crise é uma contradição de

termos. [...] O que temos é uma calamidade crônica.”


Clássicas ou em cascata Origem na década de 70 Engenharia do Software Criada por Royce, que argumentava “ser um risco e um convite para falhas”


Baseadas na engenharia Idéias originárias do pensamento industrial e

técnicas de construção Ampla quantidade de documentação Burocráticas


Custo das mudanças aumenta com o tempo

Fonte: Beck (2000)


Leves Equilíbrio entre muito e nenhum processo Décadas de evolução das metodologias Criadas com o manifesto ágil◦Reunião com 17 especialistas em 2001◦Métodos próprios de desenvolvimento◦Princípios comuns aos métodos de cada um◦Base filosófica para desenvolvimento ágil


Manifesto Ágil

“Estamos descobrindo maneiras melhores de desenvolver software,

fazendo-o nós mesmos e ajudando outros a fazê-lo.

Através deste trabalho, passamos a valorizar:

Indivíduos e interações MAIS QUE processos e ferramentas; Software funcionando MAIS QUE documentação completa e detalhada; Colaboração com o cliente MAIS QUE negociação de contratos; Adaptação a mudanças MAIS QUE seguir o plano inicial.

Ou seja, mesmo havendo valor nos itens à direita,

valorizamos mais os itens à esquerda”


Características comuns◦Foco na comunicação◦Desenvolvimento interativo◦Testes◦Qualidade do código

Objetivos◦Minimizar os riscos do desenvolvimento (mini-ciclos)◦Satisfazer o cliente com entregas periódicas◦Preparar a equipe para requisitos “mutantes”◦ Incentivar a troca de informações


Custo se mantém “constante” após determinado tempo

Fonte: Beck (2000)


Destina-se a equipes pequenas e médias Ambientes onde requisitos mudam com

frequência Criada por Kent Beck, em 1996, no projeto C3 da

Chrysler Cliente deve receber o máximo de valor de cada

dia de trabalho da equipe de desenvolvimento Baseada em valores e práticas


Comunicação◦Deve ser feita face-a-face ou como for mais viável◦Entre os membros da equipe e entre a equipe e o cliente◦Prevenir mal entendidos◦Sanar dúvidas imediatamente◦Evitar que estas influenciem negativamente as decisões

do projeto


Feedback◦Retorno que o cliente fornece à equipe◦ Feita com base no uso que o cliente faz do software◦Evita trabalho com funcionalidades supérfluas

Simplicidade◦Adotar solução simples para alcançar o objetivo◦Sem adivinhar as necessidades futuras


Coragem◦Acreditar nas práticas e valores XP◦Evoluir o software com segurança e agilidade◦Simplificar os códigos complexos


Cliente Presente◦Cliente deve participar do desenvolvimento◦ Feedback para direcionar a equipe ao que lhe agrega

mais valor

Jogo do Planejamento◦XP é dividido em ciclos: iterações e releases◦Cliente prioriza as funcionalidades em cartões (estórias)◦Estimativa do tempo de desenvolvimento◦Definição das estórias que farão parte da iteração


Reunião Diária◦ Feita em pé com duração máxima de 15 minutos◦ Troca de conhecimento: O que fiz ontem? O que farei

hoje? Tenho impedimentos?

Programação em Pares◦ Técnica controversa◦ Implementação feita em duplas◦Código mais simples e eficaz: um codifica e o outro

revisa o código ◦Menor número de erros


Desenvolvimento Guiado por Testes◦ Testes guiam o desenvolvimento◦Desenvolver testes antes de codificar◦Validação do sistema e qualidade maior

Refatoração◦Simplificar o código sem alterar funcionamento◦ Facilitar entendimento e manutenção◦ Testes evitam que à refatoração interrompa o

funcionamento do software


Propriedade Coletiva◦Responsável “simbólico” pelos módulos◦Qualquer membro da equipe pode alterar o código sem

pedir autorização

Padrões de Codificação◦Equipe deve possuir um padrão a ser usado por todos◦Sistema homogêneo◦Manutenção do código facilitada


Design Simples◦ Implementar o suficiente para suprir a necessidade

(simplicidade)◦Apoiada por testes e refatorações

Metáfora◦ Facilitar a comunicação com o cliente◦ Transmitir idéias complexas de forma simplificada


Ritmo Sustentável◦ Trabalhar 8 horas por dia – evitar horas-extras◦Desenvolver software é um trabalho criativo◦Mente descansada para o dia seguinte◦Produção de código com qualidade e sem erros

Integração Contínua◦ Integração do código ao repositório várias vezes ao dia◦Não quebrar harmonia das partes prontas


Releases Curtos◦Entrega de um conjunto reduzido de funcionalidades◦Gerar fluxo contínuo de valor para o cliente◦Cliente não precisa esperar o software ser totalmente

concluído para começar a usá-lo (feedback)


Fonte: adaptado de XProgramming.com


Aberto e público Todos os membros da equipe trabalhar próximos Escutar as perguntas dos colegas Escutar uma conversa “acidentalmente” que

possa contribuir Mesas que permitam programação em par Quadro branco: comunicação e troca de idéias


Mural ou kanban: estórias não iniciadas, em andamento e finalizadas

Visualização do andamento da iteração

Fonte: adaptado de Kniberg (2009)


Empresa premia o funcionário individualmente Contratos de escopo fechado (prazo e escopo

rígido) Clientes exigem extensa documentação Ambiente de trabalho que não facilite colaboração Equipes grandes e espalhadas geograficamente Falta de apoio da direção para uso da XP


Baseado na XP Enfoque no gerenciamento de projeto Criado na década de 90 Por Jeff Sutherland e Ken Schwaber


Product Owner: patrocinador do projeto Scrum Master: líder técnico Scrum Team: equipe de desenvolvimento


Sprint: período de tempo de 2 a 4 semanas Dividido em:

– Planejamento – Revisão– Execução – Retrospectiva


Reunião de Planejamento (Sprint Planning Meeting)

Reunião Diária (Scrum Daily Meeting) Reunião de Revisão (Sprint Review Meeting) Reunião de Retrospectiva (Sprint Retrospective) Product Backlog


Sprint Backlog◦Dividido em tarefas◦Acompanhamento feito com gráficos Burn-Up ou Burn-

Down Chart


asai – administração da informática – prof. malomar alex seminotti

Documents