Implementação de Software utilizando

Transcrição

1 Motivação: Dilemas da Construção de Software Implementação de Software utilizando Métodos Ágeis Ana Liddy Cenni de Castro Magalhães Palestra PUC-PR 10/06/2011 Fracassos são frequentes em projetos de software: Prazos e orçamentos não cumpridos Expectativas não satisfeitas Custo Retorno muito menor que o esperado Qualidade Impossível satisfazer ao mesmo tempo custo, prazo, escopo e qualidade Escopo A Busca por uma Solução Construir software = construir projetos de engenharia Receita para o sucesso: investir muito tempo e recursos em uma fase detalhada de planejamento e design garantir o sucesso da execução com gerenciamento e processos bem definidos Prazo Motivação: Dilemas da Construção de Software Motivação: Dilemas da Construção de Software Um Novo Problema... Por mais que as metodologias tenham definido processos e controles, os resultados estão longe dos esperados... Esta receita não funciona para o desenvolvimento de software: Um software é, pela sua própria natureza, intangível É impossível antever todas as suas funcionalidades As necessidades emergem durante todo o seu desenvolvimento, e vão amadurecendo até a sua implantação A utilização do software aprimora os seus recursos A mudança é, portanto, inevitável! A mudança, necessária, passa a ser amaldiçoada! A Dificuldade da Comunicação Quantos pontos a figura possui? Quantas pontas a figura possui? Qual a cor da figura? Falhas de Comunicação: Esquecimento Interpretação diferente Cenários destes Problemas Traduções Tempo de resposta longo Mensagens longas Linguagem ambígua 4

2 Agenda e Objetivos O Pensamento Ágil: A Quebra de Paradigma O Pensamento Ágil Entender a origem e os princípios ágeis Metodologias Ágeis para Desenvolvimento Conhecer as abordagens XP e Lean Programming Metodologias Ágeis para Gerenciamento Conhecer as abordagens APM e SCRUM Comparativo Abordagem Tradicional x Ágil Relacionar as diferenças entre as formas tradicional e ágil de desenvolvimento e gerenciamento de software Conclusão 5 Abordagem Tradicional: Custo Escopo Prazo Por que não... Qualidade Parte de um escopo fechado Define-se custo e prazo Manipula-se a qualidade Por que não Custo Qualidade Prazo Escopo Ter um prazo predefinido Ter um custo fixo, definido em função do prazo Manter os níveis de qualidade Manipular o escopo? Fazer o mais simples agora, e refinar depois? Mudar quando for necessário? Libertar-se do excesso de documentação? Usuários pagam por software, não por documentação A QUALIDADE é que faz a diferença... 6 O Pensamento Ágil: A Busca pela Agilidade... Metodologias Ágeis: Origem O que fazer? Construir o software de forma evolutiva e adaptativa Começar da forma mais simples possível: apenas com o planejamento e design necessários Resolver as necessidades mais claras e críticas: agregando valor ao produto e entregando algum resultado rapidamente Objetivo: ter um software em operação o mais rápido possível, para que ele tenha chance de evoluir! Investir ao máximo em simplicidade: desta forma, a mudança deixa de ser traumática e passa a ser natural Para colocar estas idéias em prática, é preciso mudar a forma de se negociar e desenvolver software! 7 Manifesto Ágil Estamos evidenciando maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: Indivíduos e interação MAIS QUE processos e ferramentas Software em funcionamento MAIS QUE documentação abrangente Colaboração com o cliente MAIS QUE negociação de contratos Responder a mudanças MAIS QUE seguir um plano Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. 8

3 Os 12 Princípios da Agilidade Os 12 Princípios da Agilidade Princípio 1: A mais alta prioridade é a satisfação do cliente, por meio da liberação mais rápida e contínua de software de valor Princípio 3: Libere software freqüentemente (em intervalos de 2 semanas até 2 meses), dando preferência para uma escala de tempo mais curta Princípio 2: Receba bem as mudanças de requisitos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente Fonte: SilverStream 9 Princípio 4: Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto Fonte: SilverStream 10 Os 12 Princípios da Agilidade Os 12 Princípios da Agilidade Princípio 5: Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para realizar o trabalho Princípio 7: Software funcionando é a principal medida de progresso de um projeto de software Princípio 6: O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face Fonte: SilverStream 11 Princípio 8: Processos ágeis promovem desenvolvimento sustentado assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica sempre Fonte: SilverStream 12

4 Os 12 Princípios da Agilidade Os 12 Princípios da Agilidade Princípio 9: A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a agilidade Princípio 11: As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadasorganizadas Princípio 10: Simplicidade a arte de maximizar a quantidade de trabalho a não ser realizado é essencial, devendo ser assumida em todos os aspectos do projeto 13 Fonte: SilverStream Princípio 12: Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento Fonte: SilverStream 14 Agenda e Objetivos A Abordagem Ágil para Desenvolvimento: XP Extreme Programming O Pensamento Ágil Entender a origem e os princípios ágeis Metodologias Ágeis para Desenvolvimento Conhecer as abordagens XP e Lean Programming Metodologias Ágeis para Gerenciamento Conhecer as abordagens APM e SCRUM Comparativo Abordagem Tradicional x Ágil Relacionar as diferenças entre as formas tradicional e ágil de desenvolvimento e gerenciamento de software Conclusão 15 Kent Beck, Eric Gamma Características: Metodologia leve (uma filosofia de desenvolvimento de software) É de domínio público, voltada para o desenvolvimento Emprega ao extremo boas práticas da engenharia de software Rever o código programação em pares faz revisão de código o tempo todo Testar o código testes automatizados e constantes, com integração contínua Envolver o cliente cliente presente e fazendo parte da equipe do projeto Descrita por meio de valores, princípios e práticas Possui uma comunidade que compartilha e aplica estas idéias - Critérios para julgar o que vemos, pensamos e fazemos - São abstratos, amplos e universais facilita prestar contas do valor ponte dá propósito à prática - Ações que seguem os princípios, sustentando os valores definidos - São úteis, se complementam e se amplificam

5 XP Extreme Programming: Valores Comunicação Fundamental para a compreensão do trabalho a ser feito e entrosamento da equipe Simplicidade É preferível fazer algo simples e gastar um pouco mais para alterar, se necessário, do que fazer algo complicado e não utilizar Sistemas simples são mais fáceis de serem testados Simplicidade Comunicação Respeito Realimentação Realimentação (feedback) É muito importante ter uma idéia clara sobre a situação atual do sistema Maior realimentação facilidade de comunicação, teste e aprendizado Coragem Algo que não funcione adequadamente deve ser descartado e refeito, de forma mais simples Respeito (entre a equipe e ao projeto incluído na 2ª Ed) Dá sustentação a todos os demais (mais básico de todos os valores) Saber ouvir, saber compreender e respeitar o ponto de vista do outro Coragem XP Extreme Programming: Princípios (1ª Ed) Objetivo: Proporcionar a pequenas / médias equipes um ambiente de desenvolvimento cooperativo, capaz de atingir altos níveis de produtividade e um elevado grau de confiança Medir honestamente Não gerar sobrecarga Comunicar de forma aberta e honesta Adaptar-se à cultura e condições locais Aceitar responsabilidades Realimentar rapidamente Fazer experimentos concretos Assumir a simplicidade Extreme Programming Aceitar a mudança Trabalhar a favor do instinto das pessoas Fazer mudanças incrementais Executar trabalho com qualidade Ensinar aprendendo Investir pouco no início Jogar para vencer XP Extreme Programming: Resumo Práticas (1ª Ed 2ª Ed) XP Extreme Programming: Papéis em Projetos Maior especialização de papéis: abordagem mais inclusiva Edição 1: cliente, programador, tester, coach, tracker Edição 2: destaca outros papéis típicos do desenvolvimento de software Diversidade de pessoas beneficia toda a equipe Cada papel deve compreender suas responsabilidades na equipe Cada um deve contribuir com tudo que pode para a equipe Papéis podem variar e uma mesma pessoa pode exercer vários papéis Interação deve seguir princípios de fluxo e benefício mútuos Programador Fonte: Cliente Acompanhador (tracker) Técnico (coach) Testador (tester) Executivos Recursos Humanos Gerentes de Produto Gerentes de Projeto Usuários Escritores Técnicos Arquitetos Projetistas de Interação Testadores (testers) Programadores

6 XP Extreme Programming: Ciclo de Vida Típico Fonte: Copyright 2001 J. Donovan Wells A Abordagem Ágil para Desenvolvimento: Lean Programming Abordagem Lean Derivada do Sistema Toyota de Produção Busca da forma ótima de produzir pela eliminação de desperdício e automação inteligente visando melhorar o valor global para o cliente Eliminar estoque, defeitos, trabalho que não agrega valor, sobrecarga Parar a linha de produção quando um defeito é identificado Abordagem Just in Time: nada deve ser produzido, transportado ou comprado antes da hora exata Obter as coisas certas, no lugar certo, no hora certa e na quantidade certa Atingir o fluxo perfeito de trabalho Minimizar desperdício Ser flexível e apto à mudança Testada e experimentada em vários contextos nas duas últimas décadas Figura: Wikipedia Mary e Tom Poppendieck Lean Programming Lean Programming Práticas básicas da abordagem Lean para software 1: Eliminar desperdício Gerar só artefatos que agreguem valor ao produto final, de forma eficiente 2: Minimizar estoque Minimizar documentação e artefatos intermediários (maior abstração) 3: Maximizar o fluxo Reduzir o ciclo de desenvolvimento usar abordagem iterativa e incremental 4: Produzir sob demanda Especificar requisitos o mais tarde possível, estar aberto à mudança 5: Dar autonomia aos trabalhadores Deixar a equipe tomar decisões e se auto-organizar, dar visibilidade 6: Atender aos requisitos do cliente Desenvolver o mais crítico primeiro, obter feedback a cada iteração Práticas básicas da mentalidade Lean para software (cont.) 7: Fazer certo da primeira vez Desenvolver dirigido por testes, aplicar refactoring quando evoluir 8: Abolir otimização local Não gerenciar escopo além do necessário ele será auto gerenciado em um domínio claro, com ciclos iterativos de prazo fixo e com foco no uso pretendido 9: Ser parceiro na cadeia cliente fornecedor Fornecer o melhor software possível (> valor agregado, > custo-benefício) 10: Criar a cultura de melhoria contínua Excelência = habilidade para adaptar a ambientes de grande mudança Desenvolvimento iterativo, refactoring, aprendizado contínuo Resultado: maior qualidade e menor tempo e custo da produção de software

7 Agenda e Objetivos A Abordagem Ágil para o Gerenciamento: APM: Agile Project Management O Pensamento Ágil Entender a origem e os princípios ágeis Metodologias Ágeis para Desenvolvimento Conhecer as abordagens XP e Lean Programming Metodologias Ágeis para Gerenciamento Conhecer as abordagens APM e SCRUM Comparativo Abordagem Tradicional x Ágil Relacionar as diferenças entre as formas tradicional e ágil de desenvolvimento e gerenciamento de software Conclusão 25 Princípios: Baseado em Sistemas Adaptativos Complexos Revoadas, cardumes, enxames Comportamento coletivo: ordem, auto-organização, inteligência coletiva, adaptação a ambientes dinâmicos, habilidade em lidar com a mudança Organizações: sistemas adaptáveis, com seres inteligentes Confiança na habilidade coletiva para resolver problemas Imprevisibilidade limita planejar: enfatizar a adaptabilidade Papel do Gerente de Projeto: líder adaptável Promove o trabalho colaborativo em equipe, defende o projeto e remove obstáculos para sua progressão Jim Highsmith et al. APM: Agile Project Management A Abordagem Ágil para o Gerenciamento: SCRUM Possui 6 práticas simples P1: Visão Direcionada Estabeleça uma visão direcionadora para o projeto e reforce-a continuamente, por meio de palavras e ações P2: Trabalho e Colaboração em Equipe Facilite a colaboração e o trabalho em equipe reforçando relacionamentos P3: Regras Simples Estabeleça e apóie um conjunto de práticas-chave P4: Informação Aberta Forneça acesso aberto à informação P5: Toque leve Aplique somente o controle suficiente para manter a ordem emergente P6: Vigilância Ágil Aplique um contínuo monitoramento, aprendizado e adaptação ao ambiente Metodologia (framework) cujo nome deriva de uma estratégia usada no rugby Possui como espinha dorsal um Sprint Período (em geral de 30 dias) durante o qual a equipe de desenvolvimento irá correr atrás de seu objetivo (Sprint Goal), implementando uma lista de requisitos predefinidos (Sprint Backlog) Sempre apresenta um executável no final da Sprint Idéia: iterações curtas e focadas melhoram a visibilidade para acompanhar o desenvolvimento Mais voltado para o gerenciamento de projetos com equipes pequenas e requisitos instáveis ou desconhecidos 24 h Pregame Postgame Game Product Backlog Sprint Backlog 30 dias Sprint Incremento de trabalho do sw

8 SCRUM: Principais Papéis SCRUM: Fluxo de Atividades Os papéis nos SCRUM são responsabilidades no processo e não posições na organização - Lidera a equipe de desenvolvimento - Resolve possíveis impedimentos - Assegura que a equipe possui as condições necessárias para alcançar os objetivos do Sprint - Realiza reuniões diárias com a equipe para acompanhar atividades Product Owner - Ponto focal com a visão do cliente - Responsável pelo Product Backlog - Reúne mudanças e prioriza funcionalidades - Realiza o aceite do produto ao final do sprint - Gerencia a rentabilidade do projeto (ROI) Scrum Master Scrum Team - Time = equipe de desenvolvimento - É auto organizável e responsável pelos resultados - Interage com o Product Owner para determinar o objetivo do Sprint, priorizar as funcionalidades e definir tarefas detalhadas Fonte: SCRUM: Principais Atividades SCRUM: Principais Atividades Estimation Meeting Preparação para o Sprint Planning Criação / revisão do Product Backlog Projeto macro da arquitetura e definição de pacotes Relização de estimativa formal Estima somente o tamanho e não o tempo para execução Serve de entrada para o planejamento de versões (releases) Sprint Planning Meetings (1,2) Reuniões para rever, fazer considerações e organizar o Sprint 1) define Selected Product Backlog a partir do Product Backlog (foco: Release) 2) define o Sprint Backlog a partir do Selected Product Backlog (foco: Sprint) Define o objetivo do próximo Sprint (Sprint Goal) A Execução de um Sprint A equipe constrói as funcionalidades definidas no Sprint Backlog, visando atingir o objetivo (Sprint Goal) Ocorre em 30 dias e possui escopo fixo neste período A equipe se auto-organiza para executar o trabalho Trabalha alinhada com os padrões e regras para sua execução O progresso das atividades é acompanhado Daily Scrum Meetings Reunião diária de 15 minutos (em pé) Mesmo local e hora, todos os dias Cada participante responde O que foi realizado desde a reunião anterior? O que será realizado até a próxima reunião? Existe algum obstáculo / impedimento para prosseguir? Questões são apenas identificadas para posterior tratamento Benefícios: integra a equipe, compartilha conhecimentos, identifica e trata problemas com rapidez, acompanha progresso e minimiza riscos

9 SCRUM: Principais Atividades SCRUM: Principais Atividades Acompanhamento das atividades Gráfico Burndown Atualizado diariamente durante o Daily Scrum Geração de novas funcionalidades Trabalho considerado pronto quando: Código está limpo e aderente a padrões Foi refatorado, rodou teste unitário Foi feito check-in e foi integrado ao produto Done! Término anormal de um Sprint Sprints podem ser cancelados antes dos 30 dias se: a equipe perceber que não irá atingir o objetivo (sprint goal) O objetivo passar a ser irrelevante devido a circunstâncias externas Próximos passos Conduzir nova Sprint Planning Meeting na qual a razão do término anormal será revisto Sprint Retrospective Meeting Reunião para discutir e opinar sobre o Sprint A idéia central é identificar formas da equipe ser mais produtiva e melhor em Sprints futuros Relacionado a 3 perguntas: What went well o que deu certo / foi bom What could have been better questões / problemas detectados What could have been improved melhorias a implementar SCRUM: Ferramentas Agenda e Objetivos Agile Radiator : quadro de acompanhamento O Pensamento Ágil Entender a origem e os princípios ágeis Metodologias Ágeis para Desenvolvimento Conhecer as abordagens XP e Lean Programming Metodologias Ágeis para Gerenciamento Conhecer as abordagens APM e SCRUM Comparativo Abordagem Tradicional x Ágil Relacionar as diferenças entre as formas tradicional e ágil de desenvolvimento e gerenciamento de software Conclusão 36

10 Abordagens Ágeis: Visão Crítica Abordagem Tradicional x Ágil: Comparativo Geral Principais virtudes Equipes integradas e colaborativas Divisão de responsabilidades e papéis bem definidos Forma de trabalho ágil e flexível Possibilita inúmeras mudanças no decorrer do projeto Foco em produtividade e resultado de valor Minimiza riscos e maximiza qualidade Principais críticas Dificuldade de manutenção pela falta de documentação Efetividade da programação em pares: custo x benefício Dificuldade de se ter o cliente presente e envolvido Dificuldade de estabelecer contrato com escopo variável Requer colaboração e confiança entre equipe e cliente Sucesso dependente da competência das pessoas Restrições de escala (tamanho da equipe, local físico) Necessidade de combinar abordagens (ex: XP e Scrum) Abordagem Tradicional Preditivo: detalhar o que ainda não é bem conhecido Rígido: seguir especificação predefinida, a qualquer custo Burocrático: controlar sempre, para alcançar objetivo planejado Orientado a processos: segui-los possibilita garantir a qualidade Documentação gera confiança Sucesso = entregar o planejado Gerência = comando-e-controle voltado para trabalho em massa, ênfase: papel do gerente, com planejamento e disciplina fortes Abordagem Ágil Adaptativo: conhecer problema e resolver crítico primeiro Flexível: adaptar-se a requisitos atuais, que podem mudar Simplista: fazer algo simples de imediato e alterar se necessário Orientado a pessoas: motivadas comprometidas e produtivas Comunicação gera confiança Sucesso = entregar o desejado Gerência = liderança/orientação trabalhadores do conhecimento, ênfase: criatividade,flexibilidade atenção às pessoas 38 Abordagem Tradicional x Ágil: Comparativo Geral Abordagem Tradicional x Ágil: Principais Mudanças Abordagem Tradicional Abordagem Ágil Desenvolvedor hábil (variedade) Cliente pouco envolvido Requisitos conhecidos, estáveis Retrabalho/reestruturação caro Planejamento direciona os resultados (incentiva controlar) Conjunto de processos, com metodologia definida Premia a garantia da qualidade Foco: grandes projetos ou os com restrições de confiabilidade, planej. estratégico / priorização (exigem mais formalismo) Objetivo: controlar, em busca de alcançar o objetivo planejado (tempo, orçamento, escopo) Desenvolvedor ágil (colaborador) Cliente comprometido (autonomia) Requisitos emergentes, mutáveis Retrabalho/reestruturação barata Resultados direcionam o planejamento (incentiva mudar) Conjunto de valores, com atitudes e princípios definidos Premia o valor rápido obtido Foco: projetos de natureza exploratória e inovadores, com equipes pequenas/médias (exigem maior adaptação) Objetivo: simplificar processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos 39 Custo da mudança Entrega de valor Tempo Tempo Intensidade e stress Transparência Envolvimento do cliente Ágil Tradicional Tempo Tempo Ref: Henrik Kniberg

11 Abordagem Tradicional x Ágil: Similaridades Agenda e Objetivos As abordagens possuem pontos positivos e negativos Partem de pressupostos diferentes! Podem coexistir e conviver bem em um mesmo ambiente as boas práticas são compatíveis e podem funcionar bem, mesmo sem contemplar integralmente um modelo ou norma Importante: considerar, criteriosamente, o ambiente e uso correto O ciclo de vida ágil é semelhante aos outros Definir o que o cliente quer e iniciar o projeto Planejar o projeto, calculando esforço Executar o plano, construindo a solução Monitorar resultados e entregar ao cliente Ciclos mais rápidos, executados várias vezes Necessário buscar o ponto de equilíbrio, avaliando riscos Planejamento aperfeiçoa a agilidade Agilidade dá eficiência ao planejamento O Pensamento Ágil Entender a origem e os princípios ágeis Metodologias Ágeis para Desenvolvimento Conhecer as abordagens XP e Lean Programming Metodologias Ágeis para Gerenciamento Conhecer as abordagens APM e SCRUM Comparativo Abordagem Tradicional x Ágil Relacionar as diferenças entre as formas tradicional e ágil de desenvolvimento e gerenciamento de software Conclusão 42 Abordagem Tradicional x Ágil Conclusão Abordagem Tradicional x Ágil Conclusão Manifesto Ágil: par de alternativas se reforçam processos e ferramentas podem melhor capacitar os indivíduos e interações documentação ajuda as pessoas a entenderem um software complexo negociação de contrato pode ser parte integrante da colaboração do cliente seguir um plano pode ser o melhor modo para responder a mudança, quando esta for previsível pessoas ativamente envolvidas e suas proposições de valor são fundamentais! 43 O Equilíbrio de Interesses Dude s Law Dude = David Hussmans ( guru da agilidade) Recebeu o Prêmio Gordon Pask por suas contribuições Valor = Porquê / Como Considerando o Porquê constante (você sabe o que esperar)... Se aumenta o Como ( pesa o processo), o Valor é reduzido Se reduz o Como (simplifica o processo), o Valor aumenta À medida que o Como tende ao mínimo necessário, o Valor tende a aumentar significativamente

12 Conclusão Geral atender aos requisitos com menor custo dentro do prazo PRODUZIR MELHOR SOFTWARE com mais qualidade?? Dúvidas?? O QUE FAZER COMO FAZER Obrigado! Normas e modelos existentes Métodos Processos Ferramentas Apontam um caminho: Não uma linha de trem, mas um plano de vôo! 45 analiddy@gmail.com