|
|
| Linha 12: |
Linha 12: |
|
| |
|
| = Estudo dirigido = | | = Estudo dirigido = |
| * Metodologias tradicionais | | * Impactos da gerência de configuração em ambientes corporativos |
|
| |
|
| 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:
| | Para manter a operação do negócio em funcionamento, é necessário gerenciar informações e relacionamentos que incluem uma infinidade de registros de Itens de Configuração. Essa tarefa é complexa e requer o uso de uma ferramenta especializada. Afinal quanto tempo perderíamos em logar em cada um dos 15 servidores de um projeto, ou ambiente (produção, homologação e testes) e garantir que esses 15 servidores estejam com o mesmo estado? |
| - 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 | | * Infraestrutura como código |
| | | |
| 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.
| | Infraestrutura como código é, como o próprio nome já diz, a prática de tratar a infraestrutura de TI como se fosse código exatamente como um software. Isso permite que você adote práticas poderosas que incluem controle de versão, revisão por pares, testes automatizados, lançamento de releases por tags e entrega contínua, por exemplo. |
| 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.
| |
|
| |
|
|
| |
|
| | * Ferramentas de integração de código e gerência de configuração: Git, Jenkins, Puppet, Ansible |
|
| |
|
| EXTREME PROGRAMMING (XP)
| | Nessa parte do trabalho pensei em fazer um overview de como essas ferramentas fucionam e apresentar uma comparação com seus concorrentes mostrando as vantagens de utilizá-las. |
| 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)
| | * Importância de um ambiente de desenvolvimento para testes locais. Vagrant como ferramenta |
| 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%.
| |
|
| |
|
| | Como a infraestrutura como código preza testes automatizados, integração contínua para agilizar a entrega de software esse processo não pode ser quebrado toda vez que um desenvolvedor comete erros de sintaxe, ou não garante que um merge dê certo como acontece diariamente nas empresas de TI. Para evitar essas falhas humanas irei apresentar um ambiente de testes no qual o dev sobe um box em sua máquina local onde pode simular o ambiente estável de trabalho, e assim que os testes estiverem ok, o código subirá em todas as branches até chegar em produção na sua versão estável. |
|
| |
|
|
| |
|
| 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.
| |
|
| |
|
| | * Comparação de um ambiente legado com um ambiente integrado e versionado |
|
| |
|
| | Depois de fazermos a apresentação das ferramentas e processos que são utilizados na infraestrutura como código, poderíamos fazer um estudo de caso mostrando um ambiente legado no qual os analistas precisam conectar no servidor para fazer as devidas configurações/instalações, e em contrapartida, apresentar um ambiente totalmente gerenciado de forma que os desenvolvedores não precisam logar diretamente na maquina para fazer suas configurações. |
|
| |
|
| DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
| | Ou então, poderíamos mostrar o passo a passo de como transformar um projeto legado em um projeto com IaC (infra as code) de ponta a ponta. |
| 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).
| |
| | |
|
| |
|
| <br> | | <br> |
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
- Impactos da gerência de configuração em ambientes corporativos
Para manter a operação do negócio em funcionamento, é necessário gerenciar informações e relacionamentos que incluem uma infinidade de registros de Itens de Configuração. Essa tarefa é complexa e requer o uso de uma ferramenta especializada. Afinal quanto tempo perderíamos em logar em cada um dos 15 servidores de um projeto, ou ambiente (produção, homologação e testes) e garantir que esses 15 servidores estejam com o mesmo estado?
- Infraestrutura como código
Infraestrutura como código é, como o próprio nome já diz, a prática de tratar a infraestrutura de TI como se fosse código exatamente como um software. Isso permite que você adote práticas poderosas que incluem controle de versão, revisão por pares, testes automatizados, lançamento de releases por tags e entrega contínua, por exemplo.
- Ferramentas de integração de código e gerência de configuração: Git, Jenkins, Puppet, Ansible
Nessa parte do trabalho pensei em fazer um overview de como essas ferramentas fucionam e apresentar uma comparação com seus concorrentes mostrando as vantagens de utilizá-las.
- Importância de um ambiente de desenvolvimento para testes locais. Vagrant como ferramenta
Como a infraestrutura como código preza testes automatizados, integração contínua para agilizar a entrega de software esse processo não pode ser quebrado toda vez que um desenvolvedor comete erros de sintaxe, ou não garante que um merge dê certo como acontece diariamente nas empresas de TI. Para evitar essas falhas humanas irei apresentar um ambiente de testes no qual o dev sobe um box em sua máquina local onde pode simular o ambiente estável de trabalho, e assim que os testes estiverem ok, o código subirá em todas as branches até chegar em produção na sua versão estável.
- Comparação de um ambiente legado com um ambiente integrado e versionado
Depois de fazermos a apresentação das ferramentas e processos que são utilizados na infraestrutura como código, poderíamos fazer um estudo de caso mostrando um ambiente legado no qual os analistas precisam conectar no servidor para fazer as devidas configurações/instalações, e em contrapartida, apresentar um ambiente totalmente gerenciado de forma que os desenvolvedores não precisam logar diretamente na maquina para fazer suas configurações.
Ou então, poderíamos mostrar o passo a passo de como transformar um projeto legado em um projeto com IaC (infra as code) de ponta a ponta.
Cronograma de estudo