Metodologia Ágil alem do Scrum

Escopo

• Avaliar as metodologias atuais para o desenvolvimento de software e apresentar novas tendências, comparando com os modelos em franca operação no mundo.

Estudo dirigido

• Metodologias tradicionais

 Também conhecida como waterfall ou cascata, esse modelo dominou a maneira de desenvolvimento de software na década de 90. Entretanto, nessa metodologia é preciso tomar cuidado, pois todas suas fases devem ser muito bem definidas. Podemos definir essas fases como sendo:
  - Fase 1 Análise: Onde é feito o levantamento de requisitos. Seu principal objetivo é extrair do cliente especificações do sistema que serão entregues.
  - Fase 2 Design: Contemplada por um outro time de profissionais. Pegam os requisitos coletados na primeira fase e os convertem em diagramas, direcionando também,  as interfaces entre sistemas, hardware, custo necessário, calendário para entrega, etc.
  - Fase 3 Programação: Os diagramas finalizados, são passados para a equipe que o transformará em código fonte, software propriamente dito.
  - Fase 4 Testes: Nessa fase, testes exaustivos são aplicados no sistema, de forma que todas as funcionalidades possam ser testadas a fim de corrigir falhas que venham ocorrer.
  - Fase 5 Manutenção: Após os testes serem concluídos, o sistema entra em produção, cabendo ou não o fornecedor acompanhar esse sistema desenvolvendo melhorias e correção de bugs. Isso é feito dependendo do contrato.
  Se as fases iniciais do projeto não forem bem definidas, elas voltam sucessivamente até serem corrigidas, o que pode levar em seu pior caso, a volta na fase 1 gerando retrabalho para a equipe. É comum ocorrer volta as fases anteriores devido a documentação volumosa, falta de comunicação na equipe e pouca interação com o cliente.

• Metodologias inovadoras

  Diante de desafios marcados pela alta tecnologia e competitividade, o mercado de TI deu uma resposta natural ao que diz respeito a metodologia de desenvolvimento de software. 
  A expressão “Metodologias Ágeis” tornou-se conhecida em 2001, quando especialistas em processos de desenvolvimento de software, estabeleceram princípios e características comuns destes métodos. Assim foi criada a “Aliança Ágil” e efetuou-se o estabelecimento do “Manifesto Ágil”.
  Algumas das principais características, além de agilidade, dos métodos ágeis são:
  - Processo incremental (quase uma oposição do tradicional modelo de cascata);
  - Colaboração do cliente;
  - Adaptabilidade (cada projeto está sujeito a passar por várias modificações);
  - Simplicidade;
  - Feedback constante;
  - Equipes pequenas (mas com alto nível técnico) multidisciplinares.

  SCRUM
  O Scrum é a metodologia mais utilizada atualmente quando se diz respeito a métodos ágeis. O foco é realizar entregas buscando desenvolver as principais funcionalidades do produto.
 -> Processo:
     - Product Backlog -> Escopo do projeto. Toda a equipe envolvida, juntamente com o cliente, fazem uma primeira reunião com a finalidade de definir funcionalidades do sistema.
     - Sprint Planning-> Nessa etapa não é tão necessário a presença do cliente pois será discutido as principais funcionalidades em seu nível de detalhamento, ou seja, como implementar essa funcionalidade e quebrá-la em tasks com níveis de complexidade. A partir de então é definido o que entrará nos Sprints.
     - Sprint -> Entrega das tasks definidas no passo anterior. Conjunto de requisitos e metas a serem implementados pelos desenvolvedores.
     - Daily Scrum -> Reunião diária na qual defini-se as tarefas do dia. Alinhamento da equipe com relação as suas atividades, repasse de dificuldades encontradas para que o Scrum Master possa solucionar.
 -> Time:
      - Product Owner -> Responsável por definir e priorizar o backlog do projeto. Em alguns casos o product owner é o próprio cliente.
      - Scrum Master -> Garante que o time faça o Scrum. Dentre suas funções está: motivação do time, manter o foco dos integrantes, responsável por remover quaisquer obstáculos que seja levantado pela equipe.
      - Team -> Quem de fato produz o resultado. São alto gerenciáveis e multidisciplinares.

  EXTREME PROGRAMMING (XP)
  Essa metodologia prega que o processo deve ser simples desde o momento de coleta de requisitos até a codificação e entrega do produto final.
  É preciso comunicação entre cliente, fornecedor e equipe para que não haja erros durante o projeto. Feedback rápido para o desenvolvedor evita perda de tempo caso o projeto não esteja andando conforme os requisitos apresentados.
     PRINCÍPIOS:
        ->The Customer is Always Available (O cliente sempre disponível): Para o feedback entre desenvolvedor e cliente fluir, é preciso manter constantes reuniões e 
              respostas rápidas do cliente independente o método (telefonemas, e-mail e etc).
        -> Metaphor (Uso de metáforas no projeto): Como a comunicação deve ser simples, é comum que a linguagem seja dada conforme entendimento do cliente ou 
               mesmo para a equipe. Ex: Entrou em produção o projeto Jornada do Vendedor. Sistema que foi desenvolvido para registrar as vendas realizadas no dia para os 
               vendedores de uma loja. 
        -> Planning Game (Planejando o jogo): Reuniões realizadas entre clientes e equipe responsável pelo projeto, para alinhamento de funcionalidades.
        -> Small Releases (Pequenas versões): Durante o andamento do software são liberadas versões contendo funcionalidades definidas anteriormente. Geralmente 
               se trata de uma funcionalidade.
        -> Acceptance Tests (Testes de Aceitação): Após cada release é realizado o teste de aceitação do cliente, onde ele testa e aceita ou não a aplicação.
        -> Test First Design (Primeiro os testes): Garante a redução de erros de programação e aumenta a fidelidade do código produzido ao padrão estabelecido para o 
                projeto.
        -> Continuous Integration (Integração Contínua): Como o código é dividido em módulos por funcionalidade, é preciso em algum momento a integração deles.
        -> Simple Design (Simplicidade de Projeto): A implementação do software deve ser escrito de forma simples e padronizada, facilitando a compreensão e possível 
               continuidade por qualquer um de seus membros.
        -> Refactoring (Refatoração - melhoria constante do código): A cada função inserida no código, essa pode passar por testes ou uma nova implementação.
        -> Pair Programming (Programação em dupla): O desenvolvimento de cada módulo é feito por duas pessoas em um mesmo computador. A metodologia alega ser 
               vantajoso pois diminui a probabilidade de erros de sintaxe/lógica, além de proporcionar a disseminação de conhecimento entre os membros da equipe.
        -> Move People Around (Rodízio de pessoas): Outra técnica que faz parte do processo é que no final de um período determinado, os pares peguem os módulos de 
              outra dupla e continue com a programação. Dessa forma todos estarão por dentro do que já foi realizado e garante padronização.
        -> Collective Code Ownership (Propriedade coletiva - O código é de todos da equipe): Como todos desenvolvem um pedacinho de cada funcionalidade, o código 
              passa a ser de da equipe toda.
        -> Coding Standards (Padronização do código): Para o rodízio de pessoas funcionar é preciso garantia de padrões no software.
        -> 40 Hour Week (Otimizando as jornadas de trabalho): Essa é a premissa de uma produtividade alta, sem horas extras e com garantia de pausas indeterminadas 
              desde que a meta esteja em dia entre as equipes.
  É preciso que se entenda bem o XP antes de aplicá-lo pois pontos críticos dessa metodologia como a programação em pares, rodízio de pessoas e testes unitários podem atrasar ou gerar custos extras ao projeto.

  FEATURE DRIVEN DEVELOPMENT (FDD)
  Essa metodologia é muito utilizada em conjunto com o Scrum.

PROCESSO: - Desenvolver um Modelo Abrangente: O FDD entende que uma das formas mais performáticas na entrega de software, é que a soma das partes é maior que o

               todo. Essa fase se inicia com o detalhamento do negócio em questão, para melhor entendimento dos requisitos e funcionalidades do sistema que será 
               implementado.

- Lista de Funcionalidades: Após a fase anterior, é preciso colocar em hierarquia as funcionalidades para serem implementadas. - Detalhamento de funcionalidades: É muito importante nessa fase que o desenho do projeto esteja de acordo com as necessidades do cliente, sendo assim, é

               preferível o contato constante com ele, como em todas metodologias ágeis. Há documentação nessa fase.

- Desenvolvimento: Diferentemente do XP, aqui o desenvolvedor é responsável pelo módulo ou funcionalidade a ele atribuído. O desenvolvimento é incremental, e

               indica-se a utilização de testes do início ao fim do processo, além da utilização de integração continua.
   Segundo a metodologia, o percentual de tempo gasto em cada etapa é:
      -> Levantamento do domínio da aplicação = 1%;
      -> Projeto = 40%;
      -> Inspeção do projeto = 3%;
      -> Desenvolvimento = 45%;
      -> Inspeção do código = 10%;
      -> Integração = 1%.

   MICROSOFT SOLUTIONS FRAMEWORK (MSF)
   	O MSF é a metodologia que a Microsoft aplica em seu desenvolvimento de software, mesmo que ela não considere o MSF como metodologia e sim uma disciplina. 

Visando as metodologias que já existiam no mercado, a Microsoft decidiu criar seu próprio framework ágil de acordo com as boas práticas de desenvolvimento de software utilizando sua vasta experiência nessa industria. PRINCÍPIOS: - Foco no negócio: Entender porque o projeto existe da perspectiva do negócio.

           - Comunicação: MSF aconselha a comunicação aberta em toda a equipe, clientes e outros componentes do time.
           - Visão de projeto compartilhado: O processo de compartilhamento de visão de projeto é especificado no início do projeto. Na criação desta visão o time se 
                   comunica no intuito de identificar e resolver conflitos e resolver visões enganosas. Isto permite definir a direção do projeto.
          - Esclarecer as responsabilidades compartilhadas: Todo o time compartilha várias responsabilidades para ensinar o próprio time e seu relacionamento aos 
                   respectivos stakeholders.
          - Mais poderes aos membros do time: Baseado em time de pares MSF dá poderes aos membros do time por ter que atingir as metas e entregas, aceitando o fato 
                  de terem as responsabilidades compartilhadas por tomar decisões, direções quando necessário.
          - Agilidade: As iterações do ciclo de vida do modelo de processo habilitam ajustes de cursos para a entrega do projeto em cada milestone.
          - Investimento em qualidade: MSF tem por premissa que todo o time é responsável por balancear os custos, e funcionalidades para preservar a solução em 
                 qualidade e assegurar a qualidade. Membros do time precisam construir qualidade em todas as fases até o sucesso da solução, e por sua vez a organização 
                 deve investir em seu time em educação, treinamento, e experiência.
         - Aprender com todas as experiências: Nos últimos 20 anos houve um crescimento colossal no que diz respeito à taxa de sucesso de projetos. Dados que a maior 
                 causa de falha são praticamente os mesmos, as organizações de TI não aprendem com as suas falhas de projeto. O MSF engloba o conceito de contínuo 
                 crescimento baseado em aprendizado individual e de time.

O MSF não possui um processo estático, permitindo dessa maneira que a equipe adeque o processo de acordo com suas necessidades. Além de não haver detalhes especificados sobre como a metodologia funciona.

   DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
   Ainda será entregue

   LEAN
   Ainda será entregue

   OPENUP
   Ainda será entregue

  RUP
  Ainda será entregue