Bem-vindo à segunda parte do tema Desenvolvimento Ágil de Software com OutSystems. Neste artigo, você vai entender como a plataforma low-code OutSystems utiliza a metodologia Ágil como princípio de desenvolvimento de software.

Vamos lá?

Desenvolvimento Ágil de Software com OutSystems: entenda como funciona

A plataforma OutSystems utiliza o modelo Scrum, mas de uma forma mais específica (nos perdoem os puristas), com o objetivo de extrair a capacidade máxima das equipes de desenvolvimento.

Durante o projeto de desenvolvimento de um produto, nada melhor do que compreender  o caminho e segui-lo. E para isso, mostramos como a OutSystems aconselha o trabalho com o Scrum na parte de desenvolvimento do produto, considerando que o plano de projeto e entendimento dos objetivos do negócio já estejam alinhados com o time ágil.

Mas o que é Agile?

Em desenvolvimento de software, agile é uma abordagem de desenvolvimento mais adaptável e evolutiva, com entregas antecipadas e com melhorias contínuas. Essa abordagem é, sem sombra de dúvidas, a mais adequada para processos de desenvolvimento centrados no cliente e que precisa ser adaptada continuamente conforme o feedback do cliente.

Mas para tudo funcionar adequadamente devemos definir alguns detalhes importantes ao processo.

Qual o primeiro passo para iniciar o Desenvolvimento Ágil de Softwares?

O ideal é realizar um pequeno Workshop, com duração de uma ou duas semanas antes do Projeto Ágil, com o objetivo de projetar uma experiência digital incrível em torno de um conceito de negócio estratégico, envolvendo os responsáveis pelo negócio e o time de desenvolvimento.

Vejamos alguns pontos relevantes que são trabalhados durante o Workshop:

Ao final do Workshop é definido um documento de visão, que será seguido durante todo o processo de desenvolvimento. Mas ainda não é o momento de iniciar a primeira sprint. Para isso, todo time deve concordar com 2 critérios de aceite conhecidos como DoR e DoD.

DoR – Definition of Ready: é um acordo de trabalho entre o time de desenvolvimento e o Product Owner, aplicado a todas as Histórias de Usuário, com a intenção de que os itens do Backlog não entrem em uma Sprint com granularidade ruim, pouco ou nenhum detalhamento. Uma história deve ser bem definida para entrar na Sprint.

Exemplo de uma História de Usuário de Definição de Pronto (DOR)

• É escrito no máximo em 3 linhas.
• Os princípios de INVEST são metIs.
• É mapeada como uma etapa em um diagrama de processo de negócios.
• Contexto e valor de negócios são claramente priorizados (por exemplo, com base em MoSCoW).
• Esclareça as Histórias de Usuário para que todos (equipes de negócios, TI, Dev e QA) estejam alinhados sobre o que exatamente construir.
• Detalhes são capturados nos critérios de aceitação (funcionais e não funcionais).
• Wireframes/maquetes são desenhados ou revisados para as principais Histórias de Usuário validados por negócios.
• Casos/cenários de teste são capturados.
• Dados de teste abrangentes estão disponíveis.
• é estimado (em alto nível) e se encaixam em um sistema de iteração.

DoD – Definition of Done:  é um acordo genérico, definido pelos membros do time Scrum (Desenvolvedores e Product Owner), aplicável a todas as Histórias de Usuário, com o intuito de que todos os membros do time tenham um entendimento compartilhado do que significa “Done” para garantir a transparência. Ou seja, uma lista de verificação de atividades necessárias para que um incremento de software seja considerado como completo.

Agora com tudo planejado e um bom alinhamento do time, podemos realizar a reunião de Kick-off para dar início a primeira Sprint. Vamos ver como funciona estas iterações de forma ágil com Outsystems?

Modelo de uma Sprint para Desenvolvimento Ágil de Software

Durante a Sprint, temos 3 etapas que acontecem em paralelo, são elas:

Shape: Construção das Histórias, DoR e Sprint Planning.

Build: Desenvolvimento, testes unitários, demonstrações internas e DoD.

Accept: Testes de aceitação.

Shape

Durante a primeira etapa, a Outsystems nos guia para definirmos as prioridades das Histórias de usuários, com o objetivo de entregar o MVP o quanto antes, e para isso, existe uma lista que devemos observar para definir esta prioridade:

• Quão importante é isso para o objetivo final?
• Quantos usuários usarão esta história de usuário?
• Com que frequência a história do usuário será usada?
• Quão arriscada é essa história de usuário?

Respondidas estas questões de prioridade, podemos definir a importância de cada História de usuário. Estas User Stories devem ser construídas e estimadas para que sejam desenvolvidas em no máximo 2 ou 3 dias. Isso ocorre durante a primeira e segunda etapas do ciclo de vida das histórias de usuários (Write Backlog e Groom Backlog).

Ciclo de vida das histórias de usuários

Isso mesmo, a Outsystems nos ensina este conceito de forma bem simples, para compreendermos como uma história evolui (a história passa por uma “esteira”) dentro de uma Sprint, podemos ver um resumo deste conceito na imagem abaixo, lembrando que o primeiro item é o Write Backlog.

Após estas 2 etapas, chega o momento daquela reunião semanal, a famosa Planning, nesta reunião, o conteúdo para o próximo Sprint é acordado, com base na capacidade da equipe de desenvolvimento disponível e nas Histórias de Usuário prontas.

Build

Chegamos no momento de desenvolver e testar o produto (Develop & Test), é importante lembrar que a equipe de desenvolvimento deve estar alinhada com a Arquitetura definida no documento de visão e atenta aos requisitos da história usuário.

Mas não é apenas com a “mão na massa” que o time deve se preocupar. É importante realizar reuniões diárias (Daily Scrum), para obter o status do progresso diário do projeto e certificar que a equipe ainda está alinhada. Durante a Daily, também é alinhado com a equipe:

• O que a equipe fez.
• O que a equipe está fazendo.
• O que a equipe vai fazer a seguir.

Junto com o time de desenvolvimento, a equipe de testes também entra em ação para testar o que foi entregue na Sprint anterior (dentro dos conceitos de DoD).

O analista de negócio é uma figura muito importante neste momento, para que sejam esclarecidas as dúvidas que possam aparecer durante a construção, e para identificar a necessidade de criar novos Backlogs e Histórias, o que é um ponto forte da metodologia ágil, a agilidade de reagir a mudanças.

React to Feedback

Nesta quinta etapa do ciclo de vida da história de usuário, o Product Owner executa uma demonstração interna, junto com o Analista de negócio e Tester, para identificar se é preciso alterar alguma entrega e reagir o quanto antes, para adaptação e estabilização da história.

Accept

Chegando na sexta etapa (Demo) é realizado a Sprint Review/Retrospective, para validar as entregas da equipe e verificar se os critérios estabelecidos no planejamento foram executados.

É importante que sejam envolvidos alguns usuários chave, para que o feedback seja próximo do que se espera do produto.

O objetivo principal é validar com o que foi definido:

• Fornecer o máximo de feedback possível
• Testar em um ambiente de controle de qualidade, obter suporte do Product Owner e da equipe de desenvolvimento.
• Testar a cada iteração reduza os riscos de adoção
• Testar em um cronograma diário e recorrente nos primeiros 2 ou 3 dias de iteração (pelo menos)
• Testadores e analista de negócios
• Analista de negócios seleciona os usuários-chave
• Fazem os testes de aceitação
• Marcam histórias de usuário válidas
• Em um movimento de progresso
• Mitigando o risco

Retrospective

A reunião de retrospectiva na iteração é organizada pelo product owner que:

• Deve ser agendada durante a última iteração para ocorrer no início da próxima iteração;
• Deve durar uma hora, no máximo;
• Deve contar com a presença de todas as pessoas envolvidas na última iteração,
• O product owner coordenará a sessão, que deve começar com um lembrete do objetivo de uma retrospectiva (basicamente aprender com as iterações passadas para melhorar no futuro);
• Depois, cada um dos participantes deve oferecer suas contribuições sobre a última iteração e citar pelo menos três ações que deram certo, três ações que deram errado e três sugestões de melhorias;
• O product owner (PO) tem que garantir que esse feedback seja registrado e mantido em algum lugar visível e acessível a todos. Por exemplo, ele pode ser escrito em post-its colados na pared. Isso facilitará a vida do PO, a fim de obter um acordo da equipe sobre as melhorias para iniciar o processo;
• O product owner deve fazer uma revisão de duas melhorias que saíram da última retrospectiva para que todos entendam o que aconteceu antes e aprendam com isso;
• A equipe começará a analisar todas as contribuições feitas e votar nas mais importantes;
• Ao final, as duas entradas mais votadas das melhorias serão colocadas em prática nesta iteração, e na próxima iteração outra retrospectiva irá analisar, e outras melhorias virão (e assim por diante, em um movimento cíclico e contínuo);

Com todas as Histórias de Usuários finalizadas dentro do conceito DoD durante as Sprints e os testes finais em QA/UAT, já pode ser agendado o Go Live do produto.

Para planejar e aprender mais sobre o Scrum com OutSystems sugerimos os links abaixo:

https://www.outsystems.com/learn/courses/137/project-initiation/?LearningPathId=19

https://www.outsystems.com/learn/courses/135/project-iterations/

Aqui encerramos este artigo com a mensagem que acredito que deve ser sempre lembrada.

De nada adianta agilidade e rapidez sem qualidade!

 As retrospectivas existem para se avaliar e validar os processos, mas lembre-se que o objetivo é a melhoria e o amadurecimento da equipe.