Metodologia de Trabalho

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 Feature 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.

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

Planejamento e priorização do backlog (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 pode-se selecionar um ou mais membros do time de desenvolvimento para antecipar questões técnicas da estória