Edição atual tal como às 18h25min de 24 de agosto de 2018

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

27/08 a 16/09: 01. Impactos da gerência de configuração em ambientes corporativos.
17/09 a 22/10: 02. Infraestrutura como código.
23/10 a 19/11: 03. Ferramentas de integração de código e gerência de configuração: Git, Jenkins, Puppet, Ansible.
20/11 a 20/12: 04. Importância de um ambiente de desenvolvimento para testes locais. Vagrant como ferramenta.
21/12/18 a 21/01/19: 05. Comparação de um ambiente legado com um ambiente integrado e versionado.
22/01/19 a 11/03/19: 06. Preparação e defesa do TCC

@@ Linha 2: / Linha 2: @@
 <br>
-* Avaliar as metodologias atuais para o desenvolvimento de software e apresentar novas tendências, comparando com os modelos em franca operação no mundo.
+* 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.
 <br>
 = 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.
+* 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?
-* 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.
+* Infraestrutura como código
-    EXTREME PROGRAMMING (XP)
+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.
-    Ainda será entregue
-    FEATURE DRIVEN DEVELOPMENT (FDD)
-    Ainda será entregue
+* Ferramentas de integração de código e gerência de configuração: Git, Jenkins, Puppet, Ansible
-    MICROSOFT SOLUTIONS FRAMEWORK (MSF)
+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.
-    Ainda será entregue
-    DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
-    Ainda será entregue
+* Importância de um ambiente de desenvolvimento para testes locais. Vagrant como ferramenta
-    LEAN
+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.
-    Ainda será entregue
-    OPENUP
-    Ainda será entregue
-   RUP
+* Comparação de um ambiente legado com um ambiente integrado e versionado
-   Ainda será entregue
+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.
 <br>
@@ Linha 76: / Linha 47: @@
 = Cronograma de estudo =
 <br>
+* 27/08 a 16/09: 01. Impactos da gerência de configuração em ambientes corporativos.
+* 17/09 a 22/10: 02. Infraestrutura como código.
+* 23/10 a 19/11: 03. Ferramentas de integração de código e gerência de configuração: Git, Jenkins, Puppet, Ansible.
+* 20/11 a 20/12: 04. Importância de um ambiente de desenvolvimento para testes locais. Vagrant como ferramenta.
+* 21/12/18 a 21/01/19: 05. Comparação de um ambiente legado com um ambiente integrado e versionado.
+* 22/01/19 a 11/03/19: 06. Preparação e defesa do TCC

Metodologia Ágil alem do Scrum: mudanças entre as edições

Edição atual tal como às 18h25min de 24 de agosto de 2018

Escopo

Estudo dirigido

Cronograma de estudo