Processo

Inserir Título
de Software
Aqui
Inserir Título Aqui
Lean e DevOps

Responsável pelo Conteúdo:

Prof. Me. Afonso Maria Luiz Rodrigues Pavão

Revisão Textual:
Prof.ª Me. Sandra Regina F. Moreira
 Lean e DevOps

Nesta unidade, trabalharemos os seguintes tópicos:

• Feature Driven Development - FDD;
• Dynamic Systems Development Method - DSDM;
• Crystal;
• Kanban;

Fonte: iStock/Getty Images

• Lean System Development - Lean;
• Development e Operations - DevOps.

Objetivos
• Conceituar e conhecer as metodologias atuais LEAN para desenvolvimento e entrega
de software.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o
último momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Lean e DevOps

Contextualização
Para começarmos nossos estudos, gostaria de propor que você que assistisse à
entrevista em vídeo intitulada “Filosofia Lean em 4 minutos”. Conforme Renato Willi,
produtor do vídeo: “Esta é uma breve apresentação sobre uma metodologia ágil de de-
senvolvimento de software, derivada do Modelo Toyota de Produção, chamada Lean
(“enxuto” em inglês) ”.

Você poderá acessá-la no link: https://youtu.be/FsKghWVmyQo

A partir do vídeo, convido você a refletir sobre os pontos de desperdício no desen-

volvimento de software, sobre onde estão os grandes ladrões de tempo e de dinheiro
quando desenvolvemos software e sobre a forma incessante com que a área de tecno-
logia de informação vem aprimorando (e trazendo) valor agregado ao negócio, além de
um simples desenvolvimento. Para, dessa forma ganhar relevância a ponto de, nos dia
atuais, ser inconcebível uma empresa - por menor que seja, sem tecnologia da informa-
ção, e em última instância, sem software.

6
Feature Driven Development - FDD
Trata-se de uma forma de desenvolver projetos de software de forma iterativa, ou
seja, seguindo os princípios ágeis de desenvolvimento e incrementando cada funciona-
lidade (ou parte) em produção cumulativamente, de modo a termos, ao final, o sistema
completamente operacional e atualizado.

O idealizador desse método foi Jeff de Lucca por volta de 1997, e dentro de
sua visão, o FDD foi criado para, entre outras coisas, dar visibilidade ao projeto de
software, principalmente quanto a situação atual, já que como o próprio nome diz, o
desenvolvimento é direcionado às funcionalidades. A medição também utiliza como item
de desempenho, a quantidade das funcionalidades feitas e ainda por fazer.

Algo importante que deve ser feito para que o FDD funcione efetivamente é a or-
ganização das entregas, ou seja, os “milestones”, demonstrando às partes interessadas
quando e qual funcionalidades eles irão receber ao longo do tempo.

Nesse caso, as iterações devem ser de curto prazo e corridas, de desenvolvimento em

torno de 2 a 3 semanas (são o ideal).

Muitas vezes os usuários e/ou clientes são impacientes, e, desta forma, mantê-los
abastecidos de novidades operacionais demonstra não apenas que o software está evo-
luindo, mas também, que está funcionando da forma que eles precisam e acrescentando
valor ao negócio, uma vez que eles enxergam a complementaridade funcional.

Os diagramas UML são muito usados para representar objetos de alto nível, como
diagramas de domínio e diagramas de classe.

O processo FDD leva em consideração a qualidade em todas as entregas das fun-

cionalidades, resultados sempre tangíveis, informações coletadas e utilizadas de forma
precisa, informações de status e progressos reais e significativos, e minimização de so-
brecarga e interrupções do pessoal de desenvolvimento.

Tudo isso é possível graças à abordagem FDD, que a partir de uma situação complexa
de domínio, a quebra em partes pequenas e mais simples. E cada uma delas é resolvida
num período de tempo curto, como já mencionado anteriormente (de 2 a 3 semanas
no máximo).

É interessante percebermos também que, ao quebrar o problema em partes menores,

além de diminuir a complexidade da aplicação, diminuímos também o risco - e temos
uma menor necessidade de comunicação, e também de paradas.

Perceba ainda que o tempo para achar erros e corrigir é bem menor, exatamente por
causa dessa redução de tempo entre a análise e o teste, já que as iterações, e consequen-
te integração da funcionalidade na aplicação operacional, é curta.

7
7
UNIDADE
Lean e DevOps

Initial Model
Modeling Storming

Build a Plan by Design by Build by

Develop an Features
Overall Model Feature Feature Feature
List

(more shape A list of features A development plan A design package Completed

than content) grouped into sets Class owners (add more content to client-valued
An object model and subject areas Feature set owners the object model) function
+ notes.

Figura 1 − O ciclo de vida do projeto FDD

Segundo Ambler (2005), o ciclo de vida FDD pode ser descrito conforme o excerto:
[...] existem cinco atividades principais em FDD que são realizadas de
forma iterativa. O primeiro é desenvolver um modelo geral, com obje-
tos de alto nível e notas. No início de um projeto, seu objetivo é iden-
tificar e entender os fundamentos do domínio, e ao longo do projeto,
irá modelar para refletir o que se está construindo. O segundo passo
é Build A Features List, agrupando-os em conjuntos relacionados e
áreas temáticas. Em seguida, planejamos por recurso, o resultado final
será um desenvolvimento, a identificação de proprietários de classe e a
identificação de proprietários de conjuntos de recursos. A maior parte
do esforço em um projeto de FDD, aproximadamente 75%, é com-
posto pelos passos 4 de 5 da figura acima: (Design By Feature e Build
By Feature). Essas duas atividades incluem tarefas como modelagem
detalhada, programação, teste e embalagem do sistema.

Requisitos Concepção e Planejamento

Desenvolver Construir Planejar
Mais forma que conteúdo um Modelo a Lista de por
Abrangente Features Feature

Plano de
Desenvolvimento

Modelo de Objetos Construção

Progresso
Detalhar Construir
Mais conteúdo na forma por por
Feature Feature
Produto

Pacotes de Trabalho

Figura 2 − Processo de gerenciamento de projetos com o FDD

8
 Podemos explicar o ciclo acima de forma simplificada, adotando as seguintes ações:
• Desenvolver um modelo geral com membros da equipe familiarizados com o domí-
nio comercial para construir um modelo geral do domínio, e, dessa forma, estabe-
lecer o escopo do produto de software.
• Criar uma lista de recursos (em FDD você desenvolve recursos e um recurso pode
ser, por exemplo, login de acesso ao sistema, ou cálculo de impostos sobre a NF de
serviços). Portanto, o time escreve uma lista de recursos e os agrupa em conjuntos,
e depois determina quais os conjuntos de recursos principais.
• Planejar por recurso, ou seja, a equipe estabelece um plano de desenvolvimento que
inclui a ordem em que os conjuntos de recursos serão realizados, que desenvolvedor
é responsável por qual recurso e os analistas responsáveis por cada classe.
• Design e desenvolvimento por recurso: design, construção e teste em sprints de
2 semanas.
• Os passos acima são repetidos até não existir mais recursos para desenvolver e integrar.

O FDD precisa de uma excelente articulação e um time experiente para poder ser
executado com maestria e proporcionar resultados esperados. Mas compensa cada
centavo, e é um dos processos de desenvolvimento de software mais utilizado porque é
flexível e focado nas pessoas e em suas responsabilidades.

Todavia, há a necessidade de pessoas sabendo quais serão seus papéis nesse processo.
Veja quais papeis existem num time de projeto FDD:
• Papéis-chave:
»» Gerente de Projeto (PM);
»» Arquiteto Chefe (CA);
»» Gerente de Desenvolvimento (DM);
»» Chefe dos Programadores;
»» Donos das Classes;
»» Especialistas no Domínio.
• Papéis de Suporte:
»» Gerente de lançamento;
»» Guru de Linguagem de Programação;
»» Engenheiro de Construção de Software;
»» Especialista em Ferramentas;
»» Administrador do Sistema.
• Papéis Adicionais:
»» 1. Testadores;
»» 2. Analistas de Subida em Produção;
»» 3. Escritores Técnicos.

9
9
UNIDADE
Lean e DevOps

Dynamic Systems Development

Method - DSDM
É um método que faz uso, principalmente, da participação contínua do usuário em
um processo de desenvolvimento iterativo baseado em protótipo, que é sensível às
alterações de requisitos de negócios, ainda que, suficientemente definido para permitir a
utilização de uma sistemática de gestão de qualidade formal.

Clifton e Dunlap (2003) enfatizam que “[...] enquanto nas metodologias de desenvol-
vimento tradicionais, a funcionalidade é fixa e o tempo e os recursos são variáveis, no
DSDM, o tempo é fixo e a funcionalidade é variável”. Podemos ver a compressão dessa
dimensão em foco na figura 3.

Functionality Time Resources

Fixed
DSDM

Traditional
Variable
Time Resources Functionality
Figura 3 − Tempo como dimensão fixa num projeto DSDM

Conforme Norfolk, a DSDM está assentada em alguns princípios e algumas boas

práticas são abaixo recomendadas:
Não há envolvimento do usuário ativo (idealmente ambos usuários
e desenvolvedores compartilham um local de trabalho), para que as
decisões possam ser feitas no local. Isto faz o compromisso do usuário
um fator crítico de sucesso.

A equipe deve ser habilitada e “empoderada” a tomar decisões sem

esperar pela aprovação de nível mais alto.

Novamente, o compromisso da gerência sênior é crítico nesse quesito.

Os requisitos de negócios têm precedência (construir o produto certo

antes de construi-lo sem erros).

A equipe se concentra na entrega do produto, ao invés da realização

de atividades prescritas.

O desenvolvimento é iterativo, conduzido por feedback do usuário.

Todas as alterações são reversíveis.

Há gestão de recompensas por conclusão de entrega, ao invés de

simplesmente completar tarefas.

10
 Os testes são realizados em todo o ciclo de vida, e não apenas antes da
entrega (quando geralmente é tarde demais para corrigir alguma coisa).

As estimativas devem ser justas no tempo, e especificar sempre os

resultados de negócios esperados.

Elas devem ser baseadas na funcionalidade para os negócios (pontos

de função), e não em linhas de código.

A avaliação dos riscos deve incidir sobre as funções de negócios sendo

entregues, e não sobre o processo de construção.

Embora não seja requerida uma especificação formal, o escopo de alto

nível e objetivos devem ser congelados ou postos numa linha de base
consensual antes de começar.

Deve haver uma relação flexível e ajustada entre vendedores e com-

pradores, porque DSDM não entrega uma especificação formal como
base para compra como processos tradicionais de desenvolvimento de
software fazem, entregando contratos com responsabilidades e demais
obrigações. É claro que há relações contratuais, mas há foco no que é
estritamente necessário.

(NORFOLK, disponível em: <https://goo.gl/R9es6H>. Acesso em 31/01/2018)

Feasibility
Agree Study Implement
Plan
Business Study
Create Identify Review Train
Functional Functional Functional Business Implementation Users
Prototype Model Prototype Aspects
User
Review
Review Approval &
Functional
Design Guidelines
Prototype
Prototype

Identify Create
Design
Design Design
& Build
Prototype Prototype

Agree
Plan

Figura 4 − Ciclo de vida de um projeto DSDM

Fonte: wiki.expertiza.ncsu.edu

A figura acima pode ser melhor compreendida quando colocamos atividades numa
linha de tempo, na qual o primeiro item a ser feito é um estudo de viabilidade, ou
seja, se o projeto vai vingar, por isso é importante realizar um estudo do negócio, pois
os aspectos comerciais podem gerar desafios de software que precisam ser avaliados
quanto aos riscos oferecidos ao próprio projeto.

A fase de modelo funcional é onde fazemos a prototipagem de funcionalidades, e como

estas devem se comportar. São levados em consideração aspectos como experiência do
usuário, desempenho, solução, dentre outros.

11
11
UNIDADE
Lean e DevOps

Após a melhoria ou ajuste desses protótipos, vamos resolver os aspectos de desenho,

e também codificar para gerarmos o produto - sempre lembrando que isso deve ser feito
através das iterações.

Por fim, a funcionalidade - após o teste e correções - se houver, é implantada e

integrada, e passa a ser mantida, levando em consideração que quando há manutenção,
ela é feita seguindo-se esse mesmo ciclo explicado.

Crystal
Sob encomenda da IBM, para se desenvolver uma metodologia ágil e funcional
orientada a objetos, foi criado por Cockburn.

O nome do método também foi criado por Cockburn com base no cristal, que visto de
cima, possui um elemento central que mostra os valores que são seguidos na aplicação do
método, e as faces são elementos específicos como ferramentas e técnicas, dentre outros.

Seus focos são:

• Pessoas, comunidade, interação, habilidades, talentos e comunicações.
• Cada equipe tem um conjunto diferente de talentos e habilidades.
• Usar processos adaptados a esses talentos e habilidades.

Cockburn determina 7 propriedades essenciais para o sucesso de um projeto usan-

do Crystal:
• Entrega frequente.
• Melhoria reflexiva, ou seja, pensar no que acelera o processo ou o atrasa - e de
que formas podemos melhorar isso.
• Comunicação osmótica - nesse caso, entendemos como sendo algo como escuta
ativa a partir de um entendimento de uma questão pela pessoa que possui conhe-
cimento significativo para responder e te dar caminhos. Recomenda-se fazer isto
constantemente, e você pode até determinar como: por exemplo, uma vez a cada
15 dias.
• Segurança pessoal - isso é bastante desafiador, porque queremos dizer com isso que
você precisa ter segurança em discordar de seu superior ou de alguma de suas ideias -
e apresentar motivos e propostas de solução, de forma não beligerante, por exemplo.
• Foco no que se está fazendo, e também reconhecendo as prioridades – e sem-
pre mantendo o foco nelas.
• Acesso fácil a usuários experientes. Se puder fazer isso, grande parte dos pro-
blemas e riscos podem ser conhecidos e contornados de maneira satisfatória e num
custo adequado. Além disso, o tempo de resposta para um problema muitas vezes
não passa de mais de uns poucos minutos em vez de semanas.

12
 • Ambiente técnico com gerenciamento de configuração, testes automatizados e
que permita integração de funcionalidades ou partes de software desenvolvido de
maneira frequente e estável.

Cockburn entende que o desenvolvimento de software baseado em Crystal é um

tipo de jogo cooperativo, e a comunicação cara a cara desempenha papel fundamental
nisso, conforme mostra o gráfico de efetividade no link abaixo.

Riqueza do canal de comunicação versus a efetividade da comunicação: https://goo.gl/HvvNL2

Crystal é adaptativo para cada tipo de porte de projeto. Dessa forma, Cockburn,
elaborou cores para o Crystal, em que cada uma representa o tamanho de um time de
projeto que pode possuir até 6 pessoas para o Crystal Clear, até 20 para o Crystal
Yellow, até 80 para o Crystal Orange e acima de 80 até 200 para o Crystal Red, e
assim por diante.

Figura 5 − Família Crystal baseada na relação de indivíduos empregados

em projetos que envolvam níveis de criticidade
Fonte: pep.ifsp.edu.br

Por fim, para evoluir utilizando a metodologia Crystal, devemos utilizar diversas
estratégias e técnicas como:
• Técnica exploratória 360 graus. Nesse caso, entende-se analisar sob todos os
ângulos e aspectos a viabilidade do projeto.
• Ganho rápido, ou se preferir, pegue alguma entrega com alto valor agregado e a
ponha para funcionar logo de cara no projeto.
• Esqueleto que anda. Aqui estamos falando em conseguir implementar uma funcio-
nalidade de ponta a ponta, validando a arquitetura da solução proposta e encan-
tando o cliente - porque ele verá algo tangível e funcional. E, se houver problemas,
você já descobre logo de início, e consegue dar atenção. Ao passo que se isso for
descoberto no final do projeto, pode-se constituir em um elemento gerador de des-
gaste, retrabalho e não entrega – que, na pior das hipóteses, tenderá a naufragar o
projeto como um todo.
• Re-arquitetura incremental. Nesse aspecto entendemos como é importante
a estratégia do “esqueleto que anda”, porque com um esqueleto arquitetural já

13
13
UNIDADE
Lean e DevOps

desenvolvido, ele pode evoluir, ser modificado, causando um menor impacto e

mantendo-se sempre atualizado.
• Visibilidade de informação. Isto é importante porque a estratégia de se manter
todos informados e com dados transparentes sobre o projeto diminui a ansiedade
das partes interessadas, bem como permite que todos saibam exatamente o que
está acontecendo, tanto para o bem quanto para o mal.
• Obter e manter um repositório de conhecimento ou mesmo informações levanta-
das de projetos anteriores como lições aprendidas para uso no início do projeto é
bastante importante e relevante. Além disso, a cada entrega aprendemos mais e sa-
bemos onde erramos, de tal forma que podemos chamar a equipe e termos um tempo
de reflexão sobre os eventos. Isso nos ajuda a estarmos melhor preparados para a pró-
xima iteração - e supostamente evitaria erros recorrentes, já que houve aprendizagem.
• O Crystal tem um foco de reuniões diárias para identificar problemas e não
ser reativo.
• Utilizar técnicas como programação aos pares usada em XP é também bastante útil.

Por fim, há possibilidade de percebermos alguns pontos fortes referentes a adoção

do método Crystal.

Entre eles, podemos destacar que o envolvimento dos usuários, especialistas nos ne-
gócios, praticamente deveria blindar a falhas de entregas. O controle da gestão transpa-
rente gera controle mais efetivo e evita suposições. Também o fato das entregas serem
contínuas dentro de horizontes de tempos conhecidos de todos diminui o estresse da
comunicação incompleta e interpretações errôneas do que ocorre.

Kanban
Quando falamos em Kanban, a primeira coisa que nos vem em mente é o famoso
processo empregado nas linhas de produção na Toyota, onde ele foi criado, e também
pelos mais diversos exemplos e metáforas empregados para seu entendimento, como
por exemplo, a sinalização nas mesas dos rodízios de churrasco no Brasil.

O Kanban é um método adotado no desenvolvimento de software para realizar o

gerenciamento visual de produtos, focado na entrega contínua - porém sem atropelar,
estressar e soterrar a equipe de desenvolvimento.

O Kanban foi projetado para gerar eficácia. Portanto, fazer, e fazer certo da primeira vez,
e, desta forma, resolver o problema. Ou seja, precisamos de gente sênior para ser eficaz
em desenvolvimento, orientando e elevando os trainees, juniores e plenos até a excelência.

Como o Kanban é visual, há 3 princípios importantes para utilizar:

• Todos os itens de trabalho, ou seja, as atividades a serem feitas, devem ser vistas
de forma direta, incluindo em qual etapa de produção estão ou não. Portanto, de
forma direta: “veja o que você e os outros estão fazendo neste instante”.

14
 • Como o método Kanban é “uma represa”, devemos nos basear no volume de vazão;
ou, se preferir, em seu fluxo. Se você passar trabalho demais, vai comprometer o
time de desenvolvimento e “afogá-los”; assim, devemos limitar o quanto de trabalho
eles poderão assumir ao mesmo tempo.
• Mas o Kanban também é seletivo, e se temos um longo backlog, obviamente de-
vemos puxar os itens de prioridade mais alta de desenvolvimento assim que o time
terminar uma tarefa.

O Kanban se vale de um quadro de visualização, ou seja, transparência do que se está

fazendo e mensagens em tempo real da capacidade em realizar aquele trabalho. Desta
forma, cada desenvolvedor tem seu job exposto num quadro disposto numa matriz linha
x coluna, onde cada coluna representa em que estágio ou fase se encontra aquele cartão.

E o que é interessante é que o time fica focado no que pegou para fazer, e somente
naquilo. Somente quando terminam vão para o próximo job. O trabalho a ser feito é
priorizado pelo proprietário do produto, e, dessa forma, ele deve manter os itens mais
importantes no topo da lista “buffer”.

Outro item interessante é que quando um cartão de trabalho passa por todas as co-
lunas do quadro visual, dizemos que ele completou um ciclo. A ideia lógica aqui é que
um cartão demore o menor ciclo possível, numa melhoria contínua. Como disse ante-
riormente, o foco é a eficácia, ou seja, andar rápido e fazer certo sempre. Isto também
significa que a responsabilidade por dar certo é do time todo, inclusive nos testes, que
são feitos também pelos desenvolvedores, e não apenas pelos testadores.

A quantidade de colunas num quadro Kanban deve conter minimamente:

• Trabalho a fazer;
• Trabalho em progresso;
• Revisão de código;
• Terminado.

Caso queira, pode-se acrescentar outras colunas como, por exemplo, uma coluna
TESTE. Mas lembre-se de que quanto mais colunas, mais troca de contexto o cartão
- e consequentemente, a atividade vai sofrer, afetando o tempo e uma das funções do
Kanban, que é um ciclo correto e curto.

Exemplo de quadro Kanban: https://goo.gl/ek3UZX

O Kanban pode ser utilizado no desenvolvimento de software em um quadro com 7

colunas, por exemplo:
• Retrospectiva do produto;
• Requisitos;
• Desenho;
• Desenvolvimento;

15
15
UNIDADE
Lean e DevOps

• Testes;
• Desdobramentos e Correções;
• Feito.

Por fim, devemos deixar claro que Kanban não é uma ferramenta do Scrum, nem
vice-versa. O Kanban é uma forma de liberar software o mais rápido possível, e de ma-
neira correta.

Quadro 1 − Quadro comparativo entre Kanban e SCRUM

Kanban Scrum
Papéis pré-definidos do mestre Scrum, proprietário do
Sem papéis prescritos
produto e membro da equipe
Entrega Contínua Sprints de caixa
O trabalho é??? puxado??? através do sistema (fluxo de O trabalho é??? puxado??? através do sistema em lotes (o
peça única) backlog de sprint)
As mudanças podem ser feitas a qualquer momento Nenhuma alteração permitida no meio do sprint
Tempo de ciclo Velocidade
Mais apropriado em ambientes operacionais com alto grau Mais apropriado em situações onde o trabalho pode ser
de variabilidade em prioridade priorizado em lotes que podem ser deixados sozinhos

Lean System Development - Lean

O Lean também foi um processo de melhoria de produção adaptado em seus princípios
para o desenvolvimento de sistemas de informação. É baseado em alguns princípios:
• Eliminar desperdícios: diz respeito a fazer documentação que vá adicionar valor ao
projeto e dar satisfação ao cliente. E isso ocorre aprendendo a ver onde há fontes
de desperdício.
• Incrementar feedback: evitar que as situações-problema fiquem presas somente à
cabeça do analista ou desenvolvedor. Ele deve deixar exposto e conversar aberta-
mente sobre a situação.
• Atrasar é se comprometer: não se deve postergar nada, mas tomar decisões o mais
tarde possível, pois isto permite analisar todas as possibilidades no horizonte de
tempo, tomando decisões mais acertadas.
• Entregar com rapidez: fazer bem, fazer certo e entregar valor ao cliente. Se você
atrasar a tomada de decisão para tomar decisões melhores, você pode entregar
melhor e mais rápido quando chegar a hora.
• Empoderar a equipe: dar oportunidade aos membros da equipe para adicionar valor
à solução, utilizando-se de todo o potencial deles. Motivar é a palavra. Dar oportu-
nidade de liderança em certas situações e deixar a especialidade de cada membro
ter um melhor proveito na hora certa.
• Construir integridade: trata-se aqui da percepção da aplicação bem construída, bem testa-
da, funcional e estável. Metodologias como o TDD podem ajudar a atingir esse princípio.

16
 • Visão do todo: nesse item devemos ter cuidado em ficarmos otimizando coisas
pequenas que não gerem impacto no todo sistêmico, pois normalmente se gasta
um esforço em tempo e dinheiro enorme às custas do dinheiro do projeto - e
quando precisar de um dos dois, verá que não os possui.

Development e Operations - DevOps

É uma metodologia de desenvolvimento de software que pretende integrar funções
de desenvolvimento de software e operações de software num mesmo ciclo. Para isso
ocorrer é mandatório um alto nível de maturidade e coordenação envolvendo todas as
áreas envolvidas, desde negócios, passando por engenharia, desenvolvimento, testes e
qualidade, dentre outros.

Trata-se de um processo integrado que requer também alto grau de automação para
garantir a entrega constante, ou seja, automação de infraestrutura e entrega contínua.

Figura 6 − Ciclo de desenvolvimento e operação DEVOPS

Conforme o excerto do artigo de Mueller (2010), podemos definir que DevOps segue
os princípios ágeis de desenvolvimento em todas as suas etapas.
Valores do DevOps: creio que os valores fundamentais do DevOps
são efetivamente capturados no Manifesto ágil - com talvez uma leve
emenda para se concentrar no serviço geral ou software totalmente
entregue ao cliente em vez de simplesmente “software de trabalho”.
Algumas definições anteriores do DevOps, como “People Over
Process, Over Tools”, de Alex Honor, faz eco às declarações básicas
do Agile Manifesto e solicita a colaboração direta de dev + ops (nesse
caso, literalmente, apoio de desenvolvimento e operações).

Princípios DevOps: Não há consenso, mas no nível conceitual é principal-

mente o alargamento dos princípios ágeis para incluir sistemas e opera-
ções em vez de interromper suas preocupações no check-out de código.

17
17
UNIDADE
Lean e DevOps

Métodos DevOps: Alguns dos métodos como Scrum com operações,

Kanban com operações etc. (embora geralmente com mais foco na
integração de operações com dev, QA e produtos nas equipes).

Práticas DevOps: Técnicas específicas utilizadas como parte da imple-

mentação dos conceitos e processos acima. Integração contínua e im-
plantação contínua. Para tanto, utilizar a virtualização e a computação
em nuvem como prática comum para acelerar a mudança no mundo
da infraestrutura moderna.

DevOps Tools: Houve uma explosão de ferramentas em lançamento

(jenkins, travis, teamcity), gerenciamento de configurações (fantoche,
chef, ansible, cfengine), orquestração (zookeeper, noah, mesos), moni-
toramento, virtualização e contêineres (AWS, OpenStack, vagabund,
docker) e muito mais.

Figura 7 − Ciclo de desenvolvimento e operação DEVOPS

Fonte: i.warosu.org

18
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
Feature Driven Development (FDD) and Agile Modeling
Desenvolvimento desenvolvido por características (FDD) e modelagem ágil.
https://goo.gl/V2Ep4b
What is DevOps?
Ciclo de desenvolvimento e operação DEVOPS com sugestão de ferramental para cada
item do processo.
https://goo.gl/y6hECM
Ciclo de vida de um projeto DSDM
https://goo.gl/kEivQ4
Lean Thinking: Mentalidade Enxuta para Desenvolvimento Ágil de Software
Exemplo de quadro Kanban.
https://goo.gl/oDfNDL
Feature Driven Development (FDD) and Agile Modeling
O ciclo de vida do projeto FDD.
https://goo.gl/V2Ep4b
What is Kanban? Kanban Software Tools
Quadro comparativo entre Kanban x SCRUM.
https://goo.gl/8vSAIg
Alistair Cockburn
Riqueza do canal de comunicação versus a efetividade da comunicação.
https://goo.gl/RMlCS

Vídeos
Kanban no Desenvolvimento Ágil de Software by Dilbert
https://youtu.be/LJOiFRsp0Z8
DevOps Tools | Automation using DevOps Tools | DevOps Training | DevOps Tutorial | Edureka
https://youtu.be/3eiYRPeNKMs
What is Git | What is GitHub | Git Tutorial | GitHub Tutorial | Devops Tutorial | Edureka
https://youtu.be/xuB1Id2Wxak
What is Docker\Docker Tutorial for Beginners\Docker Container\DevOps Tools\Edureka
https://youtu.be/lcQfQRDAMpQ
What is Jenkins\Jenkins Tutorial for Beginners\Jenkins Continuous Integration Tutorial\Edureka
https://youtu.be/p7-U1_E_j3w
What is Puppet\Puppet Tutorial for Beginners\Puppet Configuration Management Tutorial\Edureka
https://youtu.be/PL_J5Gj3GAQ
Ansible Playbook Tutorial\Ansible Tutorial For Beginners\DevOps Tools\Edureka
https://youtu.be/dCQpaTTTv98

19
19
UNIDADE
Lean e DevOps

Leitura
O que é DSDM
https://goo.gl/XPCKNG
Proposta de utilização de FDD e APF para melhoria do processo de software
https://goo.gl/zcCF4W
Comparação entre os Processos dos Métodos Ágeis: Xp, Scrum, Fdd e Asd em Relação ao
Desenvolvimento Iterativo Incremental
https://goo.gl/if5KVZ
Entrega contínua – como entregar software de forma rápida e confiável
https://goo.gl/cJkqEX
What Is DevOps?
https://goo.gl/8ehILD
Understanding DSDM - PC Network Advisor
https://goo.gl/R9es6H
DevOps and user experience at Concur
Ciclo de desenvolvimento e operação DEVOPS.
https://goo.gl/HhMc1l
Metodologias Crystal e Metodologia DSDM(Dynamic Systems Development Method)
Família Crystal baseada na relação de indivíduos empregados em projetos que envolvam
níveis de criticidade.
https://goo.gl/aP2Nn3
Proposta de Utilização de FDD e APF para Melhoria do Processo de Software
Processo de gerenciamento de projetos com o FDD.
https://goo.gl/zcCF4W
O que é DSDM
Tempo como dimensão fixa num projeto DSDM.
https://goo.gl/XPCKNG

20
Referências
FOGGETTI Cristiano, ORG. Gestão ágil de projetos. São Paulo, Pearson, 2015. (e-book)

PAGE-JONES, Meilir. Fundamentos do desenho orientado a objetos com UML. São

Paulo, Makron Books, 2001. (e-book)

PFLEEGER, S. L. Engenharia de software - teoria e prática. 2.ed. São Paulo: Pearson/

Prentice Hall, 2004. (e-book)

PRESSMAN, R. S. Engenharia de software. 7.ed. Rio de Janeiro: McGraw-Hill do

Brasil, 2011. (e-book)

SCHACH, S. R. Engenharia de software: os paradigmas clássico & orientado a objetos.

7. ed. São Paulo: Bookman, 2009.

SHORE, James; WARDEN, Shane. A arte do desenvolvimento ágil. Rio de Janeiro:

Alta Books 2008.

SOMMERVILLE, I. Engenharia de software. 8.ed. São Paulo: Pearson, 2001. (e-book)

WAZLAWICK, Raul Sidnei. Análise e design orientados a objetos para sistemas de

informação: modelagem com UML, OCL e IFML. 3.ed. Rio de Janeiro: Campus, 2015.

21
21