Metodologia de Trabalho

Voltar

Cerimônias

• Abaixo o Modelo de Trabalho atual com as cerimonias Agile:

Estória

Uma Estória é uma descrição resumida que representa a decomposição de uma Funcionalidade do Sistema e é realizada dentro de uma Sprint. Para sua construção utiliza-se um modelo mais humano que busca manter a necessidade de negócio na perspectiva do usuário. Em geral as Estórias seguem a seguinte estrutura. “Eu como, <Papel do usuário> gostaria que <descrição da necessidade> de tal forma que <descrição do objetivo>.

A respeito da Estória é importante o conhecimento de três características relevantes para o planejamento e execução que são a “Definition of Ready”, “Definition of Done” e "Critério de Aceite", que podem ser descritos como:

Definition of Ready: Descritivo das necessidades que devem ser atendidas para que a Estória seja classificada como pronta para ser executada pelo time de desenvolvimento. Apenas Estórias classificadas como prontas, serão consideras para formação do Sprint Backlog.

Definition of Done (Definição de “Pronto”): Descritivo das necessidades que devem ser atendidas para que a Estória seja considerada como aceita. Esta definição é dada durante o Release Planning e será a base de comparação para aceite durante a Sprint Review. O Definition of Done é genérico para todas as Estórias, e pode incluir, mas não está restrita a critérios como: "Código completo"; "Testes unitários escritos e rodando"; "Testes de integração escritos e rodando"; "Documentação de usuário e treinamento completos", sendo estes apenas exemplos.

Critério de Aceite: Descritivo das funcionalidades que precisam ser atendidas para que, juntamente com o Definition of Done, a Estória possa ser aceita pelo Product Owner. Diferentemente do Definition of Done, os critérios de aceite são específicos para cada Estória.

Para definição de uma Estória, recomenda-se a observação de alguns atributos, entre eles: • As Estórias de usuários devem ser independentes uma das outras • As Estórias devem ser negociáveis • As Estórias devem ter relevância para o usuário • As Estórias devem ser passíveis de estimativa • As Estórias devem ser dimensionadas para entrega dentro de uma Sprint • As Estórias devem ser testáveis.

Product Backlog e Sprint Backlog

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

Interação (Sprint)

O Sprint é um período fixo (time-box) de duas semanas a serem executadas em sequência, visando à entrega de um incremento de produto baseado nas Estórias de usuário registradas e priorizadas no Sprint Backlog. A execução de uma Sprint é composta por:

• Um período de 10 dias úteis de duração consecutivos (2 semanas). Tais horas serão executadas apenas em dias úteis, na qual o time de desenvolvimento realizará a execução das tarefas determinadas;

• Destes 10 dias úteis: 4hrs serão dedicadod a uma sessão de planejamento (Sprint Planning) e 4hrs serão dedicados a uma sessão de revisão da Sprint (Sprint review), e uma sessão de retrospectiva de Sprint (Sprint Retrospective);

• Considera-se a Sprint encerrada assim que o período time-box se encerra;

• O cancelamento do Sprint pode ocorrer quando o Product Owner concluir que as Estórias presentes na Sprint não fazem mais sentido de existir. Neste caso, assim que a Sprint corrente for cancelada, será iniciada um nova Sprint, que excepcionalmente, terá duração igual aos dias restantes da Sprint Cancelada. Desta forma, garantimos o cumprimento do time-box definido.

Planejamento da Interação (Sprint)

• A Sprint Planning é conduzida para que o Product Owner apresente ao time o objetivo da Sprint e as Estórias identificadas e priorizadas para trabalho. A Sprint Planning é realizada no primeiro dia da Sprint.

o A Sprint Planning é o último nível de planejamento dentro da abordagem proposta.

o Como resultado do trabalho da Sprint Planning, teremos a confirmação das Estórias a serem executadas, tarefas e o esforço para execução. Neste momento devem ser trabalhadas a priorização e gestão do backlog da Sprint, que deverá ser feita em conjunto com o PO da Fundação Ary Frauzino, sendo fundamental sua participação nesta atividade. Durante a Sprint Planning, os seguintes cenários podem ocorrer:

• O Time conclui que uma ou mais Estórias de usuários incluídas na Sprint foram subestimadas e que a Sprint não comporta a sua execução. Neste caso, o escopo da Sprint é redefinido, movendo uma ou mais Estórias para o Backlog do Release, passível de execução na próxima Sprint, ou para o Product Backlog, passível de execução em Releases seguintes.

• O Time detecta capacidade ociosa na Sprint. Novas Estórias que não estão originalmente previstas para execução na Sprint serão inclusas até consumir a capacidade ociosa.

• O Time conclui que uma Estória originalmente prevista não faz mais sentido de existir. Neste caso, o backlog da Sprint é redefinido, através da remoção da Estória. Uma vez que a remoção acarrete em capacidade ociosa, nova Estória poderá ser incluída conforme descrito acima.

Review/Demo

• A sessão de revisão da Sprint (Sprint Review), é conduzida para a revisão das Estórias executadas e atendimento a definição de "pronto” estabelecido no detalhamento da Estória, sendo executada no último dia da Sprint.

Retrospectiva

• A sessão de retrospectiva (Sprint Retrospective), é conduzida para que o time avalie a forma em que o trabalho foi realizado e lições aprendidas.

Daily Meeting

A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas: O que você fez ontem? O que você fará hoje? Há algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.

Refinamento ("Grooming")

• Durante a execução das Sprints, enquanto o time de execução realiza a construção das Estórias, o Scrum Master e o Product Owner da Fundação Ary Frauzino farão o detalhamento e priorização do Backlog para a próxima Sprint. Neste caso recomenda-se selecionar um ou mais membros do time de desenvolvimento para antecipar questões técnicas da estória.