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
Cronograma de estudo