Engenharia de Software Capítulo 2 - Processos

Engenharia de Software Capítulo 2 - Processos

1. Processos

   • Desenvolvimento de Software
     • É o conjunto de passos, etapas e tarefas que se usa para construir um software
     • Manifesto Ágil
       • Defendiam que software é diferente de produtos tradicionais de Engenharia.
         • Requisitos de um software mudam com frequência
         • Clientes frequentemente não têm uma ideia precisa do que querem
         • Mundo muda!
         • Documentos detalhados, pesados e extensos
       • Snowbird, Utah (EUA), 2001
       • Reunião com 17 profissionais da industria
       • Passaram a valorizar
         • Indivíduos e interações, mais do que processos e ferramentas
         • Software em funcionamento, mais do que documentação abrangente
         • Colaboração com o cliente, mais do que negociação de contratos
         • Resposta a mudanças, mais do que seguir um plano.
       • Processos Ágeis
         • Ciclos curtos e iterativos de desenvolvimento
         • Sistema vai sendo construído de forma incremental
         • Desenvolvimento usando um Processo Ágil.
         • Menor ênfase em documentação
         • Menor ênfase em planos detalhados
         • Inexistência de uma fase dedicada a design
         • Desenvolvimento em times pequenos
         • Ênfase em novas práticas de desenvolvimento (pelo menos, para o início dos anos 2000)
           • Programação em pares
           • Testes automatizados
           • Integração contínua
         • Envolvimento constante do cliente
       • Métodos Ágeis
         • São métodos que definem práticas, atividades, eventos e técnicas compatíveis com princípios ágeis de desenvolvimento de software.
         • Extreme Programming
           • É um método leve recomendado para desenvolver software com requisitos vagos ou sujeitos a mudanças
           • Valores
             • Comunicação
             • Simplicidade
             • Feedback
               • "Planeje-se para jogar fora partes de seu sistema, pois você fará isso." - Frederick Brooks
             • Coragem
             • Respeito
             • Qualidade de vida
             • Também são valores universais para o convívio humano
           • Princípios
             • Humanidade
               • Software é uma atividade intensiva no uso de capital humano.
               • Peopleware
                 • Tom DeMarco, Livro: Peopleware: Productive Projects and Teams (3rd Edition)
                 • A ideia é que a gestão de pessoas (com suas expectativas, crescimento, motivação, transparência e responsabilidade) é fundamental para o sucesso de projetos de software.
             • Economicidade
               • Software é uma atividade cara, que demanda a alocação de recursos financeiros consideráveis
               • Software tem que gerar resultados econômicos
             • Benefícios Mútuos
               • Decisões tomadas em um projeto de software têm que beneficiar múltiplos stakeholders.
             • Melhorias Contínuas
               • O sistema vai sendo continuamente aprimorado, a cada iteração, com o feedback dos clientes e de todos os membros do time.
             • Falhas Acontecem
               • Bugs
               • Funcionalidades que não se mostraram interessantes para os usuários finais
               • Desempenho, usabilidade, privacidade, disponibilidade, etc
             • Baby Steps
               • É melhor um progresso seguro, testado e validado, mesmo que pequeno, do que grandes implementações com riscos de serem descartadas pelos usuários.
             • Responsabilidade Pessoal
           • Proposto Kent Beck, Livro: Extreme programming explained: embrace change (1999)
           • Práticas
             • Práticas sobre o Processo de Desenvolvimento
               • Representante dos clientes
                 • User stories
                   • São documentos simples, que focam nas funcionalidades do sistema, sempre na visão de seus usuários
                   • Story points,
                     • quanto tempo será necessário para implementar as histórias escritas
                     • Planning Poker
                       • Técnica usada para estimar o tamanho de histórias
                     • Velocidade
                       • É o número de story points que ele consegue implementar em uma iteração
                 • Decide sobre a ordem de implementação das histórias
               • Iterações
                 • São conjuntos de tarefas resultantes da decomposição de histórias, com duração total de algumas semanas.
               • Releases
                 • Conjunto de iterações, com duração total de alguns meses.
               • Planejamento de releases (planning game)
                 • Aloca histórias a iterações e releases
               • Planejamento da iteração
                 • Decompõe as histórias de uma iteração em tarefas, que devem ser atividades de programação que possam ser alocadas para um dos desenvolvedores do time.
               • Folgas (slacks)
                 • São tarefas que podem ser adiadas, caso necessário
                 • Objetivos
                   • Criar um buffer de segurança em uma iteração
                   • Permitir que os desenvolvedores respirem um pouco
             • Práticas de Programação
               • Design Incremental
                 • O time deve reservar tempo para definir o design do sistema em desenvolvimento
                 • Atividade contínua e incremental
                 • Refactoring deve ser continuamente aplicado
                 • Times experientes tem boa aproximação do design na primeira iteração
               • Programação em Pares
                 • Toda tarefa de codificação (novas histórias, teste, correção de um bug) deve ser realizada por dois desenvolvedores trabalhando juntos, compartilhando o mesmo teclado e monitor.
                 • Líder (ou driver)
                   • Fica com o teclado e o mouse.
                 • Navegador
                   • Revisor e questionador o trabalho do líder
                 • Conhecimento sobre o código não fica atrelado a só um desenvolvedor
                 • Revisão de código
                   • Um código tem que ser revisado por outro desenvolvedor de maneia assíncrona
                 • Propriedade Coletiva do Código
                   • Qualquer par de desenvolvedores trabalhando junto pode modificar qualquer parte do código, não precisa pedir autorização
               • Testes Automatizados
                 • Propõe a implementação de programas (testes) para executar pequenas unidades de um sistema, como métodos, e verificar se as saídas produzidas são aquelas esperadas.
               • Desenvolvimento Dirigido por Testes (TDD)
                 • implementa-se o teste de um método e, só então, o seu código.
                 • Testes escritos devem ser a primeira implementação
                 • Desenvolvedor deve se colocar no papel de cliente, pensando na sua interface e usabilidade
               • Build Automatizado
                 • Build
                   • Geração de uma versão de um sistema que seja executável e que possa ser colocada em produção
                 • São usadas ferramentas para automatizar
                   • Sistema Make
                   • Maven
                   • Gradle
                   • MSBuild
                 • XP defende que o processo de build seja automatizado, sem nenhuma intervenção dos desenvolvedores
               • Integração Contínua
                 • Software são desenvolvidos com o apoio de sistemas de controle de versões, que armazenam o código fonte do sistema e de arquivos relacionados, como arquivos de configuração, documentação, etc.
                 • Version Control System (VCS)
                   • 1º baixar (pull) o código fonte
                   • 2º Integração: subir o código modificado (push)
                   • Conflitos de Integração
                     • Devem ser resolvidos manualmente
                     • Integration hell
                 • Desenvolvedores devem integrar seu código sempre, se possível todos os dias.
                 • Serviço de integração contínua
                   • Esse serviço faz o build do código e executa os testes
             • Práticas de Gerenciamento de Projetos
               • Ambiente de Trabalho
                 • Time pequeno
                 • Todos os desenvolvedores trabalhem em uma mesma sala
                 • Espaço de trabalho seja informativo (permitir que o time possa visualizar o trabalho que está sendo realizado)
                 • jornadas de trabalho sustentáveis
               • Contratos com Escopo Aberto
                 • Escopo fechado
                   • Empresa contratante define os requisitos do sistema, um preço e um prazo de entrega
                   • requisitos mudam
                   • Clientes não sabem o que querem
                 • Escopo é aberto
                   • Pagamento ocorre por hora trabalhada
                   • Cliente define as histórias e faz a validação delas ao final de cada iteração.
                   • Colaboração com o cliente, mais do que negociação de contratos
               • Métricas de Processo
                 • número de bugs em produção
                 • Intervalo de tempo entre o início do desenvolvimento e o momento em que o projeto começar a gerar resultados financeiros
         • Scrum
           • É um método ágil, iterativo e incremental para gerenciamento de projetos
           • Jeffrey Sutherland e Ken Schwaber, artigo "SCRUM Development Process", 1995
           • Papéis
             • Product Owner
               • Deve possuir a visão do produto que será construído
               • Escrever as histórias dos usuários
               • Deve estar sempre disponível para tirar dúvidas do time.
             • Scrum Master
               • Trata-se do especialista em Scrum do time, sendo responsável por garantir que as regras do método estão sendo seguidas.
               • Facilitador dos trabalhos e removedor de impedimentos.
             • Times Cross-funcionais (multidisciplinares)
               • Vão incluir todos os especialistas necessários para desenvolver o produto, de forma a não depender de membros externos.
               • Estimar o tamanho das histórias definidas pelo Dono do Produto, usando story points
           • Artefatos e Eventos
             • Backlog do Produto (artefato)
               • É uma lista de histórias, ordenada por prioridades
               • É dinâmico e deve ser continuamente atualizado, de forma a refletir mudanças nos requisitos e na visão do produto.
             • Sprint (evento)
               • É o nome dado por Scrum para uma iteração
               • O desenvolvimento é dividido em sprints, de até um mês.
               • O resultado de um sprint é chamado de um produto potencialmente pronto para entrar em produção (potentially shippable product)
             • Planejamento do Sprint (evento)
               • É uma reunião na qual todo o time se reúne para decidir as histórias que serão implementadas no sprint que vai se iniciar.
               • 1ª Parte:
                 • Product Owner propõe histórias para o sprint e o restante do time decide se tem velocidade para implementá-las
               • 2ª Parte:
                 • Quebram as histórias em tarefas e estimam a duração delas
                   • Os times Scrum são auto-organizáveis
               • Atenção: Em um time scrum, todos têm o mesmo nível hierárquico
             • Backlog do Sprint (artefato)
               • É o artefato gerado ao final do Planejamento do Sprint.
               • É uma lista com as tarefas do sprint, inclui a duração das mesmas
               • É dinâmico
                 • Tarefas podem se mostrar desnecessárias e outras podem surgir
                 • Pode-se alterar a estimativa de horas previstas para uma tarefa
               • Objetivo do sprint (sprint goal)
                 • Não pode ser alterado
                 • É a lista de histórias que o dono do produto selecionou para o sprint e que o time de desenvolvimento se comprometeu a implementar na duração do mesmo.
             • Quadro Scrum (Scrum Board)
               • É um quadro com tarefas a fazer, em andamento e finalizadas
               • Pode ser fixado nas paredes do ambiente de trabalho
             • Gráfico de Burndown
               • A cada dia do sprint, esse gráfico mostra quantas horas são necessárias para se implementar as tarefas que ainda não estão concluídas.
               • A curva o gráfico deve ser delinante, atingindo valor zero caso a sprint seja bem sucedida
             • Reuniões Diárias
               • Cerca de 15 minutos
               • Participar todos os membros do time.
               • Reuniões em pé (standup meetings, ou ainda daily scrum)
               • Os membros devem responer as perguntas:
                 • o que ele fez no dia anterior;
                 • o que ele pretende fazer no dia corrente;
                 • se está enfrentando algum problema/impedimento, na sua tarefa
               • Têm como objetivo melhorar a comunicação entre os membros do time, fazendo com que eles compartilhem e socializem o andamento do projeto.
             • Revisão do Sprint (Sprint Review)
               • É uma reunião para mostrar os resultados de um sprint
               • Devem participar todos os membros do time, outros stakeholders, convidados pelo Product Owner
               • O time demonstra, ao vivo, o produto para os clientes
               • Podem ou não ser aprovadas, caso não seja, volta para o Backlog do Produto
             • Retrospectiva
               • É a última atividade de um sprint.
               • Reflete sobre o sprint que está terminando
               • E identificar pontos de melhorias no processo, nas pessoas, nos relacionamentos e nas ferramentas usadas.
               • Depois da retrospectiva, o ciclo se repete, com um novo sprint.
             • Time-box
               • Duração bem efinida
               • O objetivo é criar um fluxo contínuo de trabalho, bem como fomentar o compromisso da equipe com o sucesso do sprint e evitar a perda de foco.
             • Critérios para conclusão de histórias
               • Qualidade externa:
                 • Testes de aceitação (caixa preta ou funcionais)
                 • Testes não-funcionais (desempenho, usabilidade)
               • Qualidade interna:
                 • Testes de unidade;
                 • Revisão de código.
         • Kanban
           • Origem na década de 50 no Japão
             • Usado no processo de produção just-in-time em fábricas da toyota
             • Palavra japonesa kanban significa "cartão visual" ou "cartão de sinalização"
           • Usado pela primeira vez na Microsoft, em 2004, por David Anderson
           • Quadro Kanban (Kanban Board)
             • Primeira coluna
               • backlog do produto
               • Usuários escrevem as histórias, que vão para o Backlog.
             • As demais colunas são passos que devem ser seguidos para transformar uma história do usuário em uma funcionalidade executável
             • Histórias são processadas passo a passo, da esquerda para a direita
             • Cada coluna é dividida em duas sub-colunas: em execução e concluídas
             • Pode ser assim montado em uma das paredes do ambiente de trabalho do time.
           • Sistema pull.
           • Limites WIP (Work in Progress)
             • Métodos de gerenciamento de projetos têm como objetivo garantir um ritmo sustentável de trabalho.
             • Deve-se evitar:
               • O time ficar ocioso
               • O time ficar sobrecarregado de trabalho
             • Trata-se do limite máximo de cartões presentes em cada passo
             • É evitar que os times Kanban fiquem sobrecarregados de trabalho
             • Calculando WIP
               • 1º Estimar quanto tempo em média uma tarefa (lead time (LT))
               • 2º Estimar o número de tarefas produzidas por dia no passo com maior lead time (throughput (TP))
               • WIP(passo) = TP * LT(passo).
                 • margem de erro de 50%
               • Lei de Little
                 • O número de itens em um sistema de filas é igual à taxa de chegada desses itens multiplicado pelo tempo que cada item fica no sistema
                 • WIP = TP * LT
           • Ao contrário de Scrum, Kanban não define uma lista fixa de papéis
         • Quando não Usar Métodos Ágeis?
           • Condições do mercado são estáveis e previsíveis;
           • Requisitos claros no início do projeto até o fim
           • Clientes não estão disponíveis para colaboração frequente;
           • Mudanças no final do projeto são caras ou impossíveis;
           • Impacto de mudanças provisórias pode ser catastrófico.
           • Clientes não conseguem testar partes do produto, antes de completo;
           • Sistema semelhante já foi feito antes;
         • Outros Métodos Iterativos
           • Modelo em Espiral
             • Nesse modelo, um sistema é desenvolvido na forma de uma espiral de iterações.
             • Cada espiral tem 4 etapas:
               • Definição de objetivos e restrições
                 • Custos, cronogramas, etc.
               • Avaliação de alternativas e análise de riscos
               • Desenvolvimento e testes
                 • Deve-se gerar um protótipo que possa ser demonstrado aos usuários do sistema.
               • Planejamento da próxima iteração ou então tomar a decisão de parar,
             • Barry Boehm, em 1986
           • Surgiram na Transição Waterfall (~1970) / Ágil (~2000) que foi gradativa
           • Rational Unified Process (RUP)
             • Surgiu no final da década de 90, Proposto pela Rational, que depois comprada pela IBM
             • É baseado na linguagem de modelagem UML
             • É associado a ferramentas de apoio ao projeto e análise de software, ferramentas CASE (Computer-Aided Software Engineering)
             • O projeto e análise deveriam ser baseados em diagramas UML, onde seriam desenhados usando-se ferramentas computacionais
             • Inception
               • Inclui análise de viabilidade, definição de orçamentos, análise de riscos e definição de escopo do sistema
               • Ao final o business case do sistema deve estar bem claro
             • Elaboração
               • Incluiu especificação de requisitos (via UML), definição da arquitetura do sistema, bem como de um plano para o seu desenvolvimento
               • Ao final todos os riscos identificados na fase anterior devem estar controlados e mitigados.
             • Construção
               • Na qual se realiza o projeto de mais baixo nível, implementação e testes do sistema
               • Ao final deve ser disponibilizado um sistema funcional, a documentação e manuais, para os usuários validarem
             • Transição
               • Ocorre a disponibilização do sistema para produção, incluindo a definição de todas as rotinas de implantação
     • Produtos
       • Resultados de uma das atividades do processo;
     • Papéis
       • Refletem as responsabilidades das pessoas envolvidas no processo;
     • Pré e Pós-Condições
       • Declarações verdadeiras antes e depois de uma atividade do processo ou da produ ção de um produto.
   • Exemplo: produção de um carro
   • Engenharia tradicional
     • Planejamento detalhado
     • Waterfall
       • Não funcionou com software
     • Conjunto de atividades inter-relacionadas que transformam uma ou mais entradas (inputs) em saídas (outputs) enquanto consome recursos para realizar a transformação.

Imagens e arquivos do mapa