Cultura e Métodos Ágeis: pilares para uma imersão avançada

Ágil: “por quê?”e “como?” - Apresentação

Olá! Boas-vindas ao curso de Métodos Ágeis: uma recapitulação. Este curso será ministrado pelo Roberto Pina, consultor e instrutor da Alura.

Este é o primeiro curso da formação Abordagens e práticas avançadas para times ágeis. O nosso objetivo é recapitular os fundamentos do Ágil para, então, seguirmos para contextos mais avançados.

O público-alvo do curso é composto por:

• Agilistas em geral, especialmente Scrum Masters;
• Pessoas interessadas em se aprofundar na temática da agilidade;
• Integrantes de áreas de governança;
• Consultores e consultoras em metodologias e transformação organizacional.

Para aproveitar melhor a formação, é recomendável que você seja iniciado(a) em Ágil e em seus fundamentos. Caso ainda não seja, você pode fazer a formação Gerente Ágil ou outros cursos introdutórios na plataforma.

O que será abordado no curso?

• Ágil: por que surgiu e como é utilizado;
• Scrum: papéis e artefatos;
• Scrum: eventos e cerimônias;
• Kanban e abordagens de fluxo;
• Análise crítica da cultura e dos métodos ágeis.

Benefícios da formação

• Aprofundamento sobre a temática do Ágil;
• Evolução pessoal e profissional, por meio do domínio de conceitos avançados do Ágil.

Durante a formação, exploraremos tópicos mais avançados, como o ágil escalado; a convergência do Lean com o Ágil, chamada de Lean Ágil; aspectos do agile coaching; tópicos avançados do Ágil; e soft skills relacionadas à liderança, como a resolução de conflitos.

Iniciaremos o curso abordando o propósito do Ágil. Ele surgiu para resolver algum problema específico? Qual seria? Perceberemos que esse problema começa com o conceito de complexidade, ou seja, com os produtos complexos. Vamos lá?

Ágil: “por quê?”e “como?” - Produtos complexos

Qualquer abordagem metodológica surge para tentar resolver um problema real. Para formularmos o problema que motivou o surgimento do Ágil, precisamos entender o conceito de produto complexo.

Para isso, usaremos o framework Cynefin.

Framework Cynefin

De maneira sucinta, esse framework é representado por um diagrama que contém quatro quadrantes, que descrevem produtos ou processos complexos, complicados, caóticos e simples. Cada quadrante tem uma linha de ação básica representada por três verbos no imperativo.

Simples

Um produto simples é aquele cuja relação de causa e efeito é óbvia. Neste caso, devemos perceber que o produto é simples, categorizá-lo e responder com um manejo conforme a categorização estabelecida.

Um exemplo de produto simples é o saca-rolhas. Ao observar alguém utilizando esse produto, conseguimos entender como ele funciona sem muita dificuldade. Por isso, podemos categorizá-lo como um produto simples.

Caótico

Em produtos caóticos, a relação entre causa e efeito é imprevisível. Diante desse cenário, devemos agir, perceber como a situação se modificou com a nossa ação e depois responder, ou seja, ajustar as nossas atitudes para tentar controlar o ambiente.

Um exemplo de uma situação caótica é um incêndio, pois não sabemos para onde o fogo irá. Começamos combatendo o incêndio, identificamos como ele reage e vamos nos adaptando ao que acontece no momento.

Complicado

Em um contexto complicado, a relação entre causa e efeito pode ser 100% compreendida, mas isso exige tempo e conhecimento especializado.

Nesse caso, devemos perceber, analisar e responder. O exemplo de um produto complicado é uma aeronave, composta por diversas partes. Estudar cada uma delas e entender o seu funcionamento em conjunto pode demorar anos, mas acontecerá em algum momento.

A relação de causa e efeito entre as partes tem uma explicação complicada, mas é possível entendê-la depois de muita dedicação. Outra característica dos produtos complicados é que, por mais difícil que seja entender o seu funcionamento, conseguimos fazer o seu escopo detalhado antes de construir o produto.

No nosso exemplo da aeronave, conseguimos desenhar um avião antes de ele ficar pronto, deixando tudo minuciosamente planejado para então construi-lo.

Complexo

O contexto ou produto complexo é aquele cuja relação entre causa e efeito só pode ser entendida parcialmente e após o produto estar pronto. Nesse caso, as palavras-chave são inspecione, perceba e responda.

Não conseguimos planejar o "implanejável". Devemos, então, perceber a realidade e responder de acordo. Um exemplo de um produto complexo é qualquer ser vivo ou situação em que o elemento humano seja preponderante.

Nesse caso, não conseguimos mapear tudo de antemão e seguir uma receita para que os problemas se resolvam.

O produto complexo precisa de feedback.

Ele demanda que ajustemos o caminho ao longo do percurso.

Desenvolvimento de produtos complexos

Dificuldade em definir requisitos detalhados de antemão

O primeiro desafio para desenvolver um produto complexo é a dificuldade em definir requisitos detalhados de antemão. Esse detalhamento é possível no caso do produto complicado, por mais difícil que seja. Porém, é muito difícil (quase impossível!) ter o detalhamento dos requisitos antes de construir um produto complexo.

A visualização detalhada de todas as partes e a construção baseada em um passo a passo fixo não podem ser replicadas no caso de um produto complexo.

Tomemos como exemplo a produção de uma vacina, um produto complexo cuja fórmula não existe, mas terá que ser descoberta. Assim, o escopo do produto complexo será descoberto ao longo do percurso.

Dificuldade em estimar esforços, prazos e custos

Sendo assim, é difícil estimar os esforços necessários à construção do produto, seus prazos e custos, sendo comum extrapolarmos ambos.

Retomando o exemplo da vacina, esse produto pode demorar um tempo indeterminado para ficar pronto: de alguns poucos meses a anos. Do mesmo modo, pode ser que a vacina também não fique pronta.

Dificuldade em criar produtos manuteníveis e de qualidade

Também é difícil criar produtos complexos com uma estrutura limpa, organizada, sob total domínio e de fácil manutenção. Desenvolver produtos complexos de qualidade também é igualmente difícil.

Um exemplo de produto complexo é um software. Não conseguimos detalhar todos os seus requisitos de antemão. As pessoas usuárias só terão certeza sobre o que querem no software conforme o utilizarem.

Precisaríamos ter um nível de abstração gigantesco para olhar o projeto de um software no papel ou ler a sua documentação e ter a certeza de que todos os requisitos propostos adicionarão valor ao negócio.

Em vez disso, o software é composto por muitas partes e apenas a experiência direta com ele nos permite saber quais funcionalidades fazem sentido. Além disso, existem problemas crônicos de estimativas de prazo, custo e de qualidade, tal qual os demais produtos complexos.

No entanto, surgiram alternativas para contornar esses obstáculos. Na sequência, abordaremos a primeira tentativa de desenvolver softwares enquanto produtos complexos. Perceberemos que a primeira abordagem foi a de imitar a engenharia tradicional, com o método waterfall.

Abordaremos o que é o waterfall e se essa tentativa deu certo. Vamos lá?

Ágil: “por quê?”e “como?” - O Problema do ''waterfall''

Na indústria do software, os problemas para desenvolver os produtos complexos que mencionamos anteriormente caracterizaram o que o engenheiro de software Roger Pressman chamou de crise do software, um conjunto de problemas crônicos que persistiram por décadas.

Para enfrentar a crise do software, usou-se diversas técnicas e abordagens.

Abordagem estruturada

A primeira delas é a abordagem estruturada, que consistia em desenvolver um software em partes pequenas, ou seja, em fazer uma decomposição funcional. Assim, a ideia é que houvesse um controle mais fácil ao agregar várias partes simples.

O problema dessa abordagem é que a decomposição saía de controle. Fazia-se a decomposição a nível um, a nível dois e quando se chegava ao nível três, havia uma infinidade de partes e isso dificultava a composição do todo.

No entanto, essa foi uma tentativa importante que ajudou muitas pessoas Dev no início.

Orientação a objetos

O principal objetivo dessa abordagem era criar peças de software mais atomizadas e autônomas, cuja capacidade de reaproveitamento fosse melhor.

Um objeto é uma estrutura de software que contém dados, funções e métodos compactados em uma estrutura relativamente autônoma, que permite que ele funcione de modo relativamente independente.

Esse é um paradigma utilizado até hoje, mas não resolveu completamente a questão do reaproveitamento.

Engenharia de software

O raciocínio foi o seguinte: "Para os artefatos de engenharia como um galpão, uma usina ou uma ponte, construímos um plano detalhado, fazemos o artefato e ele funciona perfeitamente. Então, o que falta na indústria de software é a disciplina da engenharia!".

Acreditava-se que, utilizando os preceitos da engenharia na indústria de software, esta ganharia precisão e o gerenciamento seria melhor.

Projetização do desenvolvimento

Em seguida, pensou-se que o problema do software era a falta de planejamento e que isso seria resolvido com a abordagem de projetos ligada à engenharia tradicional. A intenção era desenvolver softwares de maneira mais previsível.

Assim, foram trazidas práticas de engenharia para o desenvolvimento de software, particularmente por meio do trabalho com projetos.

Mas como a engenharia tradicional funciona?

A engenharia tradicional e os projetos com origem na construção civil lidam com produtos complicados, mas repetíveis e previsíveis.

Pensemos na construção de um prédio: cada edifício é único, mas todos seguem uma mesma receita. É necessário compor uma laje, as colunas, a próxima laje e assim por diante, seguindo o desenho. Essa receita pode ser executada por pessoas com pouca especialização profissional, que seguem as orientações de alguém que atue como mestre de obras.

Isso porque o artefato de engenharia é repetível e previsível, permitindo a execução de um processo definido com base em um plano traçado de antemão. Essa dinâmica funciona tanto para a construção de um prédio quanto para a de um navio, por exemplo.

Acontece que estes são produtos complicados, ou seja, conseguimos mapear e detalhar o seu escopo de antemão para só então começar a construi-los com base em uma receita.

No caso do software, a emulação da engenharia não resolveu o problema. Isso porque o software é um produto complexo, ou seja, seu processo de produção não é repetível nem previsível. Em vez disso, o software exige a adoção de um processo empírico, já que o escopo será descoberto ao longo da jornada.

O método de projeto da engenharia tradicional (o waterfall ou método cascata) não deu certo para software.

O que é o método waterfall?

O método waterfall se aplica a produtos complicados, mas não aos complexos. O waterfall usa a seguinte abordagem:

1. Definimos o escopo detalhado de todo o produto;
2. Criamos a documentação na forma de especificações funcionais e técnicas (em alguns casos, ambas compõem um único conjunto de documentos);
3. Construímos o produto de uma só vez ou fazemos grandes entregas;
4. Testamos tudo de uma vez ou em grandes partes;
5. Fazemos a implementação de uma única vez ou com grandes entregas espaçadas no tempo.

Tudo isso é acompanhado pela monitoração e pelo controle, ao melhor estilo de comando e controle: com um cronograma, um status report e um gerente de projetos que supervisiona o trabalho.

Com essa abordagem, acreditava-se que os softwares seriam entregues com mais previsibilidade e menos problemas de qualidade e de requisitos.

O problema do waterfall aplicado ao software

No entanto, essa abordagem para o desenvolvimento de software apresenta alguns problemas, como:

• Participação restrita de pessoas usuárias

Essa participação se concentra no início e no fim do projeto. Assim, estamos em diálogo com as pessoas usuárias durante a composição do escopo, mas a equipe "some" por um ou dois anos, entregando o software pronto ao fim desse período ou em grandes entregas realizadas de seis em seis meses, por exemplo.

Acontece que durante esse intervalo o negócio já pode te mudado, a pessoa usuária já pode ter tido novas ideias a respeito da solução ou ter mudado de ideia.

Ao realizarmos grandes entregas, é comum que as pessoas usuárias estranhem o resultado com exclamações como "Mas não foi isso que eu pedi!" ou "Você não entendeu!".

Essa participação restrita de pessoas usuárias gera definições de negócio ou produto pobres, pois não temos feedback. Elas são consultadas no início do processo, geralmente sendo solicitadas a assinar um maço de documentos e confiam no trabalho do pessoal de TI.

• Se o projeto for interrompido antes das etapas finais, nenhum produto operacional será entregue

Gastamos meses produzindo apenas documentação. Então, se o projeto for interrompido antes do seu fim, teremos apenas a documentação em papel. O software rodando só estará disponível nas fases finais do processo.

Com isso, só conseguimos um produto consistente, ou seja, o produto final ou grande parte dele pronta, após um longo período de trabalho. O software só começa a surgir após muitos meses de planejamento e discussão de requisitos.

• Documentação pesada e sempre com risco de ser ineficaz

No waterfall, geramos uma quantidade grande de documentação para tentar escapar da armadilha do descontrole. Porém, essa documentação pode se tornar um fim em si mesma e não um meio.

Por exemplo, desenha-se um diagrama sem saber exatamente o motivo, só porque o método sugere isso, com o intuito de ter um escopo perfeitamente definido que não gere estranheza na hora da entrega.

• As mudanças de requisitos não são bem-vindas

No waterfall, as mudanças que acontecem no produto pronto geram conflitos e atrasos. Por isso, o lema dessa abordagem é: "detalhe tudo o máximo que puder para evitar mudanças, pois elas são caras, complicadas e trazem impactos negativos".

Acontece que, no software, as mudanças são a regra e não a exceção, pois descobrimos os requisitos a partir das entregas, que devem ser pequenas, de preferência. O problema é que o waterfall prevê apenas entregas grandes, e não pequenas.

• Os requisitos não são totalmente visualizados e entendidos antes da execução do projeto

A pessoa usuária não consegue ver no papel como será a interface final do software. Então, a pessoa só sentirá se o software atende à sua necessidade quando o produto estiver pronto, mas aí já é tarde demais para fazer mudanças.

Esses são os grandes problemas do ciclo waterfall aplicado ao desenvolvimento de software. Para se contrapor a essa abordagem, surgiu a proposta do Ágil aplicado ao desenvolvimento de software. Com o método, veio também a cultura do Ágil, tema que abordaremos a seguir. Vamos em frente?

Sobre o curso Cultura e Métodos Ágeis: pilares para uma imersão avançada

O curso Cultura e Métodos Ágeis: pilares para uma imersão avançada possui 112 minutos de vídeos, em um total de 51 atividades. Gostou? Conheça nossos outros cursos de Métodos Ágeis em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Ágil: “por quê?”e “como?”
• Scrum – papéis e artefatos
• Scrum - eventos
• Kanban e abordagens de fluxo
• Análise crítica do Ágil