Escopo
- Impactos da gerência de configuração em ambientes corporativos.
- Infraestrutura como código.
- Ferramentas de integração de código e gerência de configuração: Git, Jenkins, Puppet, Ansible.
- Importância de um ambiente de desenvolvimento para testes locais. Vagrant como ferramenta.
- Comparação de um ambiente legado com um ambiente integrado e versionado.
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)
Esta metodologia foi desenvolvida por especialistas da área de Computação, no qual juntaram e aperfeiçoaram suas melhores técnicas. Assim, a DSDM surgiu como uma extensão do RAD (Rapid Application Development), focada em projetos de Sistemas de Informação caracterizados por prazos e orçamentos apertados
PRINCÍPIOS:
O DSDM consiste em 3 fases:
- Pré-Projeto: Nessa fase é definido o orçamento e firmado contrato.
- O Ciclo de Vida do Projeto: É realizado um estudo a respeito das regras de negócio do cliente, para que os requisitos sejam construídos. Depois de construídos
são convertidos em um Modelo Funcional. A prototipagem é uma das técnicas chave dessa metodologia. A partir daí, começa a implementação de fato do
sistema, desde os testes iniciais até a homologação do produto final.
- Pós-Projeto: Essa fase assegura um sistema de atuação eficiente, isto é, implementado, testado e validado pelo cliente, e em constante manutenção e
melhoria de funcionalidades.
LEAN
Mary e Tom Poppendieck (adeptos do Lean voltado a TI, defensores do agile e autores do livro: "Lean Software Development - An Agile Toolkit", fazem o seguinte comentário: "Acelerar a produção do desenvolvimento de Software é geralmente uma questão de melhorar o processo ao invés de adicionar pessoas. Pare de fazer coisas que o cliente não valoriza! Vista os óculos do cliente! "
Tentando resumir em uma frase, Lean é um princípio ágil cujo foco é cortar a "gordura" do processo de software, focando na eliminação de desperdícios.
PRINCÍPIOS:
- Eliminar Desperdícios: tirar o foco tudo aquilo que não agrega valor ao cliente. Como exemplo temos, extensas documentações, burocracia, funcionalidades extras
que não serão utilizadas, trabalhos parcialmente prontos, passos extras, etc.
- Qualidade embutida: A qualidade do produto não deve ser verificada somente no final e sim, desde o início. Quando antes um problema é verificado, mais barato
fica, além de evitar problemas bem maiores com o andar o projeto. Foco na prevenção de falhas em todo o sistema.
- Criar conhecimentos: Equipes pequenas, feedback contínuo, treinamentos e mentoring, code reviews, etc.
- Adiar decisões / compromissos: Uma estratégia chave para adiar decisões/comprometimentos no desenvolvimento de um sistema complexo e com muitas
incertezas é usar práticas que permitam abraçar as mudanças tardiamente. Ou seja, antes de tomar decisões precipitadas devemos baseá-las em fatos.
- Respeitar as pessoas: Para que as pessoas possam assumir responsabilidades, se sentir motivados e atuar como uma equipe eles precisam de confiança e de
respeito.
- Otimizar o todo: Otimizar todo o processo com métricas de tempo para cada atividade, lucros e perdas, tempo de ciclo.
OPENUP
O Open Unified Process (OpenUP) ou Processo Unificado Aberto se baseia em um ciclo iterativo e incremental, entretanto, o foco é criar um modelo ágil e enxuto, o que torna um diferencial da metodologia é que ela possui além da iteração normal, um micro incremento, este micro incremento é uma pequena unidade de trabalho de uma pessoa da equipe e o conjunto são executadas em uma iteração.
O OpenUP está estruturado em 3 camadas distintas:
1ª Camada - Ciclo de Vida de Projeto -> É subdividido em fases:
Iniciação - Coleta dos requisitos do sistema de acordo com as regras de negócio e necessidades do cliente.
Elaboração - Processo de desenvolvimento da análise arquitetural.
Construção - Implementação e testes do sistema.
Transição - Lançamento da versão beta para que o cliente receba treinamentos quanto a usabilidade da solução proposta.
2ª Camada - Ciclo de Vida de Iteração -> Executável testado exaustivamente entregue ao cliente.
3ª Camada - Ciclo de Vida de Micro Incremento -> O conceito de um Micro Incremento auxilia aos indivíduos da equipe de desenvolvimento a partilhar suas
atividades em pequenas unidades, onde cada unidade se encerra com a entrega de um artefato de valor para a equipe. Micro Incrementos provêm um feedback
muito rápido em relação à qualidade do Produto de Trabalho gerado, feedback esse que pode direcionar as decisões tomadas ao término de cada iteração.
RUP
O Rational Unified Process (RUP), é considerado por alguns como metodologia ágil mas para outros não. Os princípios desse framework foram alterados em 2007 para suportar um desenvolvimento ágil e ser orientado a negócios.
PRINCÍPIOS:
- Adaptar o processo (identificar qual processo será necessário ao projeto) ;
- Balancear as prioridades dos investidores (compreender e priorizar os requisitos conforme as necessidades de negócios);
- Colaborar através de equipes (comunicação e ambientes de colaboração);
- Demonstrar valor iterativamente (feedback inicial e contínuo, adaptar os planos, gerenciar alterações);
- Elevar o nível de abstração (reduzir a complexidade e a quantidade de documentação por meio de reutilização de recursos existentes);
- Focalizar continuamente na qualidade (testes, integração contínua, automação de testes incrementais).
Cronograma de estudo