Abordagem Lean Agile em Ação

Exemplo de Portal de Aluno

Uma faculdade comunitária deseja desenvolver um portal para alunos, oferecendo serviços online para os estudantes. Eles convidaram um representante de aluno, funcionários do departamento e membros do administrador do portal para formar uma equipe e participar do projeto de desenvolvimento do portal para alunos. Aqui estão as atas extraídas da primeira reunião.

Reunião de stakeholders

Agenda

• Sugerir funcionalidades para o portal de alunos
• Discutir a viabilidade da lista de funcionalidades propostas
• Priorizar funcionalidades a serem implementadas como principais, próximo lote, desejáveis…

Steve (Equipe de Desenvolvimento): Bem-vindos… Gostaríamos de tornar a reunião mais produtiva e frutífera. Quando sugerirmos funcionalidades que vocês desejam ter, podemos usar o seguinte formato como forma padrão de expressão: quem (você é), qual funcionalidade (você quer) e por que (você quer isso)… Essas funcionalidades serão registradas como histórias de usuário, como ferramenta de comunicação durante todo este projeto.

Em seguida, realizamos uma sessão de brainstorming para elaborar uma lista de histórias de usuário de diferentes stakeholders:

Representante de aluno: se inscrever em disciplinas, pagar taxa de matrícula, visualizar horário, editar horário, visualizar boletim, cancelar disciplinas…

Representante Acadêmico: adicionar informações da disciplina, editar informações da disciplina, excluir informações da disciplina…

Administrador do Portal: fazer backup das informações da disciplina, editar o status da conta do aluno

Agora, temos um conjunto de cartões que podem ser organizados em linhas e colunas

Priorizar Funcionalidades Propostas

Representante do Desenvolvedor: Temos uma lista de histórias de usuário priorizadas para serem implementadas na próxima iteração. Para isso, precisamos analisar cada história de usuário para entender melhor e obter mais informações. Vamos percorrer a primeira funcionalidade principal: a história de usuário ‘se inscrever em disciplina’

Obtivemos algumas informações adicionais, conforme segue, dos usuários finais para a reunião:

• Acadêmico: o aluno deve ser um aluno matriculado em tempo integral
• Administrador: o aluno deve fornecer credenciais de conta corretas para fazer login
• Acadêmico: a disciplina não está lotada
• Acadêmico: os pré-requisitos da disciplina devem ser atendidos
• Administrador: uma disciplina selecionada para ser adicionada ao horário não deve conflitar com o horário de outra disciplina
• Desenvolvedor: quais outras funcionalidades vocês gostariam que fossem agrupadas em uma lista junto com esta funcionalidade no sistema-alvo?
• Aluno: cancelar disciplinas, visualizar horário, editar horário.

Os 3Cs da História de Usuário

Boas histórias de usuário são muito mais do que apenas afirmações. Uma história de usuário padrão consiste em três partes, comumente conhecidas como os três C’s. O primeiro “C” de cada história de usuário deve seguir o formato padronizado de Como um [papel], eu quero [fazer algo], para que [benefícios], que é o conteúdo mínimo de uma história de usuário a ser colocada no cartão. As Conversas são o conteúdo do segundo “C” de uma história de usuário, que representam a discussão entre os usuários finais, o proprietário do projeto e a equipe de desenvolvimento. Nesses diálogos, são registradas as discussões verbais ou muitas outras informações úteis, como e-mails, wireframes ou quaisquer outros conteúdos relacionados ao projeto. O último “C” de uma história de usuário é a confirmação, que são os critérios de aceitação usados para confirmar que a história de usuário foi implementada corretamente e entregue com sucesso.

Deixe-me elaborar um pouco mais sobre como desenvolver a parte de confirmação de uma história de usuário. Aqui utilizamos o modelo mais conhecido chamado Gherkin, que adota a fórmula Dado-Quando-Então para orientar a escrita dos testes de aceitação para uma História de Usuário:

• (Dado.. e) algum contexto
• (Quando.. e) alguma ação é realizada
• (Então.. e) Realizar algumas ações

Ferramentas como o Cucumber e os frameworks de teste Jbehave incentivam o uso do modelo Dado/Então/Então para realizar testes automatizados, embora possa também ser usado puramente como um heurístico, independentemente de se utilizar uma ferramenta.

Vamos reunir todas as informações para a história de usuário “registrar curso” e colocá-las no formato 3Cs:

Agora, vamos colocar as informações no UeXceler, que inclui a conversão e a confirmação que desenvolvemos anteriormente.

Dividindo o Episódio em Histórias de Usuário

Se investigarmos mais detalhadamente a história de usuário “registrar curso”, podemos descobrir que é muito grande para ser incluída em um sprint. Podemos considerá-la como um Episódio (uma história de usuário maior), que pode ser dividida em um grupo de histórias de usuário menores e relacionadas. Podemos dividir um épico em tarefas, o que chamaria de divisão horizontal, ou alternativamente podemos dividir o épico em cenários e chamá-lo de divisão vertical.

Divisão Horizontal

A abordagem tradicional para construir um grande recurso era decompor em trabalhos que precisavam ser realizados em camadas arquitetônicas. Por exemplo, modelo, visualização e controle (MVC) ou arquitetura cliente-servidor, para que possamos garantir a separação de preocupações na arquitetura do sistema, e posteriormente ajustá-la para uma arquitetura em n camadas, como GUI, lógica de controle, modelo de objetos, mapeamento objeto-relacional, camadas de banco de dados e assim por diante. Há muitas camadas na arquitetura em n camadas, e aqui estou apenas listando algumas delas:

• Permite que desenvolvamos alta especialização em uma das camadas arquitetônicas
• Outras aplicações poderão reutilizar a funcionalidade exposta pelas suas camadas.
• Você poderá distribuir suas camadas sobre múltiplas camadas físicas. Isso pode ter um impacto muito positivo em sua aplicação, melhorando o desempenho (às vezes), escalabilidade e tolerância a falhas.
• A manutenção da sua aplicação é mais fácil devido ao baixo acoplamento entre as camadas.
• Adicionar mais funcionalidades à sua aplicação torna-se mais fácil.
• As camadas tornam sua aplicação mais testável.

Há um grande número de implementações bem-sucedidas baseadas na arquitetura em n camadas, como o Ruby on Rails e arquiteturas baseadas em serviços web.

Histórias de Usuário e Divisão Horizontal

Apesar dos benefícios da arquitetura em n camadas para o nosso sistema, ela apresenta algumas desvantagens quando usada com a abordagem de histórias de usuário. Tendia a ter um ciclo de feedback muito lento, dependendo do tamanho do recurso, pois estamos esperando que todos terminem suas partes separadas para integrar e garantir que funcione. O termo “corte horizontal” refere-se ao uso dessa abordagem de camadas arquitetônicas como método principal de decomposição de grandes recursos.

Divisão Vertical

Para acelerar o ciclo de feedback, podemos pegar um épico e dividi-lo em vários cenários de usuário que cortam cada uma das camadas arquitetônicas. Podemos dividir quase qualquer recurso em fatias, de forma que levará no máximo alguns dias para construir, integrar e testar todas as peças. Cada fatia é composta por todo o trabalho necessário em uma camada arquitetônica, bem como qualquer teste e integração que precisem ser feitos para torná-lo pronto para lançamento.

Normalmente, a divisão horizontal divide recursos em histórias de usuário ou tarefas em nível de componente arquitetônico. Exemplo: interface de front-end, bancos de dados ou serviços de back-end. Já uma fatia vertical resulta em software funcional, demonstrável, que adiciona valor ao negócio. Assim, a divisão vertical melhora a capacidade da equipe de entregar um incremento de produto potencialmente entregável a cada sprint. Imagine cortar um bolo com camadas de creme, chocolate, frutas e bolo. Se você cortasse o bolo horizontalmente, seu amigo receberia apenas uma fatia de bolo, chocolate, creme ou fruta. Tenho certeza de que seus amigos prefeririam uma fatia com um pouco de todas as camadas. Obter apenas uma camada do bolo não lhes permite sentir o verdadeiro sabor de todo o bolo. Uma abordagem mais amigável para seus amigos é criar fatias verticais (o valor desejado).

Dividindo o Episódio Horizontalmente com Objetivo

Lembre-se de que a conversão para a história de usuário “registrar curso” que tivemos na reunião com os interessados, o recurso foi inicialmente proposto pelos alunos (papel principal) e apoiado por outros interessados. Ao aprofundarmos os detalhes da história de usuário, descobrimos que há bastante informação reservada por outros interessados que atuarão como papéis secundários na história de usuário.

Na realidade, alguns alunos podem não se importar ou até não querer as restrições definidas pelas pessoas com papéis secundários. Por exemplo, um aluno esquece a senha e a digita incorretamente três vezes, ele/ela pode não querer passar pelo processo de redefinição de senha, mas ainda tem a confiança para tentar várias vezes a mais, ou o aluno não quer ter um limite para livros da biblioteca, ou período de empréstimo, e assim por diante. Quem deseja estabelecer algumas regras de negócios, restrições para os recursos propostos como seu objetivo de usuário, são justamente aqueles que participam como papéis secundários na história de usuário. O recurso não deveria funcionar de forma alguma, se as regras de negócios e o segundo objetivo não forem impostos ao recurso proposto. Se dividirmos o épico horizontalmente de acordo com os objetivos dos atores secundários em um grupo de histórias de usuário, poderemos atender aos objetivos dos atores secundários, tornando a história de usuário testável e obtendo feedback diretamente da pessoa certa.

Vamos investigar as informações das seções de conversão e confirmação para ver como podemos dividir a história maior “registrar curso” em um grupo de histórias de usuário relacionadas.

1. O aluno deve ser um aluno registrado; caso contrário, ele/ela não terá a credencial fornecida pela notificação para novos alunos. Se ele/ela recebeu a notificação, mas a conta ainda não foi ativada, ele/ela precisará registrar a nova conta online (marcado como círculo vermelho 1)
2. Se aprofundarmos um pouco mais o processo de login, sabemos que, se um aluno fornecer as credenciais incorretamente três vezes, ele precisará entrar no processo de redefinição de senha (marcado como círculo vermelho 2 e 3)

Compartimento Geral de Histórias de Usuário

Vamos criar essas histórias de usuário no UeXceler:

A história de usuário de Login de Conta é criada no compartimento geral de histórias de usuário. Além das histórias de login, duas outras histórias relacionadas estão sendo criadas também no compartimento geral de histórias de usuário, que são a “redefinir senha” e “criar nova conta de aluno”, por motivos a seguir:

• Se as credenciais da conta forem inseridas incorretamente pelo aluno três vezes, isso acionará a história de usuário “redefinir senha”;
• e se um novo aluno ainda não se registrar para uma conta de aluno, ele/ela poderá acionar a história de usuário “criar nova conta de aluno” dentro da tela de login.

1. Como aluno, quero fazer login no portal do aluno, para que…
2. Como administrador do portal, quero verificar que a pessoa que faz login é um aluno registrado, para que…
3. Como coordenador do curso, quero verificar a adequação antes de permitir que o curso selecionado seja adicionado ao horário do aluno, para que…

Podemos considerar que essas três histórias de usuário foram divididas horizontalmente a partir do épico – “registrar curso”, mas essas histórias de usuário atenderão aos objetivos de alguns atores secundários com os quais você pode obter feedback e confirmar. Se as pré-condições não forem atendidas, a história de usuário principal não terá mais sentido algum.

Você pode ver que colocamos todas essas histórias de usuário no compartimento geral de histórias de usuário e a razão é que elas provavelmente compartilham a mesma pré-condição junto com outras funcionalidades relacionadas (histórias de usuário) na mesma página de invocação, como “visualizar horário”, “editar horário”, “cancelar cursos” e assim por diante.

Compartimentos de Casos de Uso

Há três marcadores em círculo vermelho restantes, marcados com 4, 5 e 6 na figura acima. Eles são os cenários alternativos do épico “registrar curso”. Se qualquer uma dessas três condições for falsificada, haverá um cenário alternativo para essa situação e pode ser representado como uma história de usuário dividida. Talvez possamos dividir horizontalmente ou verticalmente, mas será que a divisão vertical é sempre mais preferível? Nem sempre, depende realmente da situação. Não existe uma solução única que sirva para todos os casos no mundo; precisamos considerar qual abordagem é mais adequada para o seu caso. Deixe-me explicar um pouco mais.

Por exemplo, se você vai atribuir a história de usuário principal a um desenvolvedor e as três histórias de login, registro de nova conta e redefinição de senha a outro desenvolvedor. Você pode preferir que o responsável pela história de usuário principal desenvolva primeiro o cenário principal no sprint atual e desenvolva incrementalmente os cenários alternativos nos sprints subsequentes, pelo mesmo desenvolvedor (se o prazo permitir). Mas se o prazo for curto e, ao mesmo tempo, você sentir que é muito pesado para o mesmo desenvolvedor cuidar de todo o épico, então você pode dividi-lo horizontalmente em tarefas para atribuir a vários desenvolvedores em paralelo.

Divisão do Épico em Cenários

Se considerarmos os detalhes do cenário descrito na seção de confirmação do épico, podemos facilmente encontrar as fatias verticais para um grupo de histórias de usuário relacionadas.

1. Como coordenador do curso, quero verificar os pré-requisitos antes de permitir que o curso selecionado seja adicionado ao horário do aluno, para que…
2. Como coordenador do curso, quero verificar a disponibilidade do curso antes de permitir que o curso seja adicionado ao horário do aluno, para que…
3. Como coordenador do curso, quero verificar a disponibilidade do horário do aluno antes de permitir que o curso selecionado seja adicionado ao horário do aluno, para que…

Divisão do Épico em Tarefas

Se quisermos decompor o épico em tarefas menores para desenvolvimento paralelo no mesmo sprint, da seguinte forma:

1. Verificar o status da cota do curso
2. Verificar os pré-requisitos do curso
3. Verificar o horário

Agora, é sua escolha disponibilizar para dividir o épico em histórias de usuário no processo de desenvolvimento ágil. Você pode ver que a história de usuário “Registrar Curso” e suas histórias relacionadas estão colocadas em um compartimento de caso de uso (seu épico), também chamado de Registrar Curso, que é usado como um espaço reservado para acomodar todas as histórias principais e aquelas histórias derivadas da principal.