Nesta nossa lição, vamos aprofundar os conhecimentos acerca dos principais métodos da literatura que seguem os princípios e valores ágeis. Vamos estudar tanto o principal método ágil para se desenvolver software (eXtremme Programming) quanto os dois principais métodos para se gerenciar projetos de software seguindo os princípios ágeis (SCRUM e KanBan). Os métodos ágeis são muito utilizados em empresas do tipo startups e hoje em dia têm sido mais aplicados do que os métodos tradicionais nas organizações tradicionais.

Nós discutimos em lições anteriores os processos prescritivos e os princípios das metodologias ágeis, e agora é o momento de sabermos aplicar esses conceitos. O momento agora é o COMO fazer e não mais o “O QUE” fazer.

Você seguir os princípios e valores ágeis significa que o projeto terá uma ênfase muito maior nas pessoas envolvidas no projeto do que na documentação ou no uso de processos muito bem definidos. O foco estará na entrega das funcionalidades no menor tempo possível e com a maior qualidade, relação essa que não é tão simples de se conseguir. Assim, o profissional que está à frente de um projeto de software deve compreender bem COMO ele deverá conduzir as ações da sua equipe para que riscos sejam minimizados e a qualidade seja garantida.

Nesse momento entram os métodos, com especial destaque para o método de desenvolvimento de software ágil chamado eXtremme Programming (XP). Contudo, apenas saber o método de desenvolvimento de software ágil não é suficiente para conduzir um projeto seguindo os princípios ágeis, também vamos precisar de um método de gestão de projetos ágeis, nesse momento surgem o SCRUM e o KanBan.

É muito importante que você entenda a diferença entre KanBan, SCRUM e XP. Já vi muitos profissionais com anos de experiência confundir esses métodos e dizer que são a mesma coisa ou que servem para os mesmos propósitos. KanBan e SCRUM são usados para a GERÊNCIA DE PROJETOS sob os princípios ágeis e o XP serve como MÉTODO (como fazer) para o desenvolvimento de um software sob os princípios ágeis. Vamos, então, entender tudo isso por meio de uma situação simulada. Vamos lá!

Imagine que você é o gerente de um projeto que tem como escopo a criação de um aplicativo móvel para vendas e compras de produtos pelos profissionais dos departamentos de Vendas e de Compras de uma organização do ramo de sapatos. Você já fez as análises que discutimos em lições anteriores e decidiu que o melhor método para o desenvolvimento desse aplicativo móvel é por meio de metodologias ágeis.

A princípio o aplicativo móvel terá por volta de 10 funcionalidades, sendo cinco para Vendas e cinco para Compras. Há na equipe dois programadores experientes e você como gerente de projetos. Num primeiro momento você organizou o projeto seguindo os princípios do KanBan (discutiremos os detalhes mais a frente). Assim, você coloca um quadro branco na sala da equipe e divide esse quadro em três colunas. A primeira coluna tem o título “Para fazer”, a segunda coluna o título “Fazendo” e a terceira coluna o título “Feito”. Esse quadro indicará para a equipe o andamento do projeto e todos poderão observar o que tem para fazer, o que está sendo feito e o que já foi finalizado.

Para o desenvolvimento do software, você decidiu utilizar o método XP, porque aprendeu no seu curso técnico. A dupla de desenvolvedores tem dúvidas sobre como desenvolver o software seguindo o método XP e você explica alguns detalhes, como por exemplo: ambos os programadores deverão trabalhar juntos e isso não significa que um faz uma parte e o outro faz outra parte, mas significa que ambos trabalharão nas mesmas funcionalidades ao mesmo tempo. Essa prática do XP é importante, porque “duas cabeças pensam melhor do que uma” e também minimiza o risco de algum integrante deixar o projeto e não ser possível dar continuidade de onde parou, uma vez que na metodologia ágil a documentação é bem menor do que no método prescritivo.

Você também orienta os desenvolvedores de que eles não deverão ter longas jornadas de trabalho, que superem as 40 horas semanais. Além disso, você convida o principal stakeholder para fazer parte da equipe, já que essa é uma prática adotada pelo método XP.

Com tudo devidamente organizado e planejado, o desenvolvimento é iniciado por meio das histórias dos usuários que têm maior peso. Ou seja, os requisitos que foram definidos como os mais importantes pelo próprio usuário e equipe de desenvolvedores.

No caso acima, nós percebemos várias práticas que ainda não havíamos estudado em outros métodos de desenvolvimento ou de gestão de projetos. Isso ocorreu porque estamos seguindo os valores e princípios da metodologia ágil. Na sequência, vamos compreender tudo isso com maior detalhamento.

Nesta nossa seção de conceitualização, vamos discutir as características do eXtremme Programming (XP), SCRUM e KanBan.

eXtremme Programming

 O XP (eXtreme Programming - Programação Extrema) sugere o uso de equipes com poucas pessoas (ex. até 10 pessoas), valoriza a comunicação oral, a qualidade dos códigos desenvolvidos e os testes como uma forma de garantir o sucesso do trabalho desenvolvido. O XP também prioriza a confiança na equipe e nas habilidades técnicas de cada envolvido (BECK; ANDRES, 2004).

Vamos observar agora a relação entre o XP e os quatro valores da metodologia ágil. Você lembra deles? (I) Indivíduos e interações acima de processos e ferramentas; (II) Software em funcionamento acima de documentação abrangente; (III) Colaboração com o cliente acima de negociação de contratos; (IV) Responder a mudanças acima de seguir um plano.

Assim como o manifesto ágil, o eXtreme Programming apresenta quatro princípios que direcionam o método, sendo eles:

No XP, os requisitos funcionais do sistema são documentados por meio de User Stories (histórias de usuários). O próprio stakeholder descreve os requisitos em um texto narrativo. Nesse caso, você pode ouvir a descrição do stakeholder e fazer você mesmo a descrição textual. O texto deve ser simples, objetivo e ter um nome curto para identificar cada história do usuário. Cada uma dessas histórias deve receber um peso relativo à sua importância ou, até mesmo, o risco e o esforço a ser despendido no seu desenvolvimento.

No XP, são feitos Testes de Unidade antes do desenvolvimento do código pelos programadores. O teste de aceitação no XP se baseia na seguinte pergunta: “o que precisa ser codificado para se ter certeza de que uma user story está OK?“.

A refatoração (refactoring) no XP se fundamenta na melhoria contínua do código-fonte do projeto. O código deve ser continuamente melhorado para que ele seja o mais simples possível de ser compreendido por um outro programador.

O código-fonte no XP é compartilhado, ou seja, todo o código no XP é de autoria do grupo. A ideia central é que todos da equipe conheçam o código que está sendo desenvolvido. Essa prática é importante para evitar que a saída de membros da equipe comprometa o projeto.

O XP se baseia na integração contínua das funcionalidades que forem sendo entregues. Por se basear na entrega de histórias dos usuários, o XP faz pequenas entregas de tempos em tempos, assim, é necessário que essas entregas sejam continuamente integradas para que o sistema comece a “tomar corpo”.

O XP defende a jornada máxima de trabalho de 40 horas e não incentiva que os desenvolvedores passem dias e noites programando. Na ótica dos princípios do XP, programadores cansados produzem muito menos e códigos de má qualidade.

A programação em pares é um dos grandes diferenciais do XP. Nessa técnica, dois programadores ficam lado a lado, um codifica enquanto o outro analisa a lógica desenvolvida, pensa em formas de simplificá-la, além de elaborar possíveis testes que serão feitos.

No XP, é sugerido que o cliente/stakeholder esteja presente junto com a equipe de desenvolvimento. Isso pode facilitar a validação dos requisitos, pois caso uma dúvida surja, o stakeholder estará ao lado da equipe para que essa dúvida seja sanada o mais breve possível. Se esse envolvimento do cliente não for possível, é sugerido que haja uma forma de comunicação direta e rápida.

Na sequência, vamos observar essas práticas na forma gráfica e como elas se relacionam (ver Figura 1).

O processo inicia pela etapa de Planejamento, onde as histórias dos usuários são realizadas, bem como os valores dessas histórias são definidos. Também na etapa de Planejamento são definidos os testes e os critérios de aceitação desses testes.

A segunda etapa é o Projeto, onde é realizado um projeto bastante simples por meio de um cartão que é chamado de CRC (Class-Responsability-Collaborator – Classe-Responsabilidade-Colaborador – veja um exemplo aqui http://agilemodeling.com/artifacts/crcModel.htm). Esse cartão, basicamente, define o nome da Classe, os atributos (dados) que essa classe terá e quem está envolvido com essa classe. Podemos fazer uma relação do cartão CRC com o Diagrama de Classe da UML e parte do Diagrama de Caso de Uso por meio dos atores que usam uma funcionalidade do sistema. O colaborador do CRC seria semelhante a um ator do Diagrama de Caso de Uso.

A terceira etapa é a Codificação e neste momento três práticas são importantes: a primeira é a programação em pares. A segunda é o teste unitário que busca encontrar erros ou defeitos no código e a terceira é a refabricação em que se busca melhorar a qualidade do código.

A quarta etapa é o Teste onde é realizado o teste de aceitação de acordo com os critérios definidos na etapa de Planejamento. Esses testes são realizados pelo stakeholder com o objetivo de garantir que aquele incremento está validado. Com o incremento validado, é recalculado o andamento do projeto considerando que uma entrega foi feita. Caso o teste não passe pela aceitação do stakeholder, o processo é reiniciado.

SCRUM

O SCRUM é uma metodologia de gerência de projetos que segue os valores e princípios ágeis. O método foi idealizado por Ken Schwaber e Jeff Sutherland (SCHWABER, 2004; SCHWABER; SUTHERLAND, 2017).

No SCRUM, o desenvolvimento do software é organizado por meio de pequenas etapas que recebem o nome de iterações. Cada iteração segue as etapas de definição dos requisitos daquela iteração, projeto, programação e testes. Para compreendermos como o SCRUM funciona, vamos usar uma representação gráfica do método, conforme Figura 2.

De acordo com a figura, podemos observar vários elementos que compõem o método SCRUM. O “Product Backlog” se refere à lista de requisitos funcionais com maior valor para o produto software. A avaliação de qual requisito tem mais valor é realizada pela equipe em conjunto com os clientes (stakeholder). Perceba que aqui há uma grande semelhança com o XP em relação às histórias dos usuários e o valor dado aos requisitos funcionais. Esse procedimento é importante porque permite à equipe definir o que é prioritário dentre os requisitos especificados.

Na sequência, temos a etapa chamada de “Sprint Backlog” que é uma lista de requisitos funcionais que irão para o Sprint. É semelhante a uma lista de tarefas previamente definidas pela equipe para ser executada, ou seja, codificada. A figura ainda destaca que a Sprint deve durar no máximo 30 dias (30 days). Nos princípios ágeis, as entregas devem ser em intervalos curtos, no caso, no máximo 30 dias. O Scrum ainda sugere que a equipe do projeto se reúna diariamente. Contudo, essas reuniões devem ter um tempo de duração curto, entre 10 a 30 minutos, e que seja realizada informalmente. Os participantes podem estar em pé mesmo, num ambiente informal e sem a necessidade de práticas formais de reunião como atas ou um ambiente controlado de acesso. O objetivo é discutir o desenvolvimento do projeto, dificuldades que estão ocorrendo, finalizações e andamento. Três questões devem ser respondidas por cada participante do grupo:

Por fim, o SCRUM sugere uma reunião de revisão do Sprint, também informal, mas com a presença do stakeholder para validar o Sprint. Caso o Sprint seja validado, parte-se para um novo planejamento e o ciclo se inicia. Contudo, podem ocorrer mudanças e estas farão parte do escopo de um novo Product Backlog. Realiza-se novas avaliações quanto ao valor da funcionalidade para a sua ida ao Sprint. Todo o processo é reiniciado.

O último elemento da figura é o “Working incremente of the software – incrementos do software” e se refere as entregas já realizadas após os Sprints.

Nós podemos perceber que o SCRUM tem muitas semelhanças com o XP, mas é válido destacar que o SCRUM é usado para a Gerência do Projeto e o XP é um método de desenvolvimento do software. Logo, sugiro que eles sejam usados em conjunto. O SCRUM para a gerência de projetos que seguem princípios ágeis e o XP para o desenvolvimento do software.

KanBan

Um outro método de gerência de projetos que é bastante utilizado no desenvolvimento de softwares e que se destaca pela sua simplicidade é o KanBan. O KanBan sugere a divisão de um projeto em três colunas. Na primeira coluna, são listadas as atividades do projeto “A fazer”, na segunda coluna as atividades que estão em execução – “Fazendo” e a terceira coluna as atividades finalizadas – “Feito”. Veja um exemplo no Quadro 1:

Nós podemos usar o KanBan em conjunto com outros métodos de gestão de projetos (ex. SCRUM) ou mesmo com metodologias de Desenvolvimento de Software, como, por exemplo, pegar as cinco etapas do desenvolvimento clássico de um software (ex. Levantamento de Requisitos, Análise, Codificação, Teste e Manutenção) e para cada uma das etapas colocar os três grupos do KanBan (A fazer, Fazendo e Feito). Assim, você pode acompanhar, visualmente, o projeto.

Nós vimos nesta lição que os valores e princípios ágeis estudados na lição anterior agora são aplicados tanto em métodos para a gerência de projetos quanto para o desenvolvimento de um software.

Para que possamos aplicar praticamente esses métodos, imagine que você vai iniciar um projeto de desenvolvimento de software e o projeto vai seguir a metodologia ágil. Você já conhece o SCRUM e decide utilizá-lo como método de gerência do projeto. Você se reúne com os stakeholders para definir o Product Backlog e estabelecer as prioridades das tarefas. Você aproveita para utilizar os princípios do XP, sugerindo que os usuários escrevam as histórias das funcionalidades que eles desejam. Nesse momento, você está usando recursos do SCRUM e do XP em conjunto, o que é uma boa prática. Após os stakeholders escreverem as suas histórias, elas são lidas e discutidas com relação ao seu valor para o projeto. Após os valores das histórias (na ótica do XP) e dos backlogs (no SCRUM), você parte para definir quais requisitos farão parte da primeira Sprint do projeto. Definidos o Sprint Backlog, ou seja, os requisitos que vão para o Sprint, você percebe que pode organizar a execução dessa Sprint por meio do KanBan para facilitar o progresso pela equipe. Assim, você pega as etapas do XP (Planejamento, Projeto, Codificação e Teste) e coloca essas quatro etapas dentro das colunas “A fazer”, “Fazendo” e “Feito” do KanBan.

Assim, você consegue organizar todo o seu projeto e as etapas de desenvolvimento do software por meio de três métodos ágeis: SCRUM, XP e KanBan.

Bacana, hein!

Clique aqui, teste seus conhecimentos sobre esta lição e confirme sua participação nesta disciplina!