Quando o assunto é metodologias de desenvolvimento ágil de software, o primeiro modelo que vem à cabeça é o SCRUM, uma vez que é mundialmente conhecido e muito praticado nas empresas ao redor do mundo. Entende-se por desenvolvimento ágil um conjuntos de métodos e práticas para desenvolver softwares. Alguns dos conceitos envolvidos são: Desenvolvimento iterativo/incremental, times auto-organizáveis e multifuncionais, entregar o que gera mais valor ao cliente, resposta rápida a mudanças, entre outras.
O SCRUM não é um framework para desenvolvimento de software apenas e, sim, para gerenciamento ágil de projetos de média e alta complexidade em ambientes mais desafiadores, que tem como foco as pessoas, mais do que os processos. O Scrum possui um conjunto de valores e princípios que busca entregar sempre o que gera mais valor ao cliente. Geralmente é utilizado em projetos onde não é possível ter um escopo fechado e é necessário responder rapidamente a mudanças.
A complexidade de um projeto é medido pelo conhecimento dos requisitos e das tecnologias envolvidas, pois se tiver um bom conhecimento dos requisitos e o domínio das tecnologias, pode-se utilizar uma das metodologias de processo definido, como por exemplo o cascata, incremental, evolucionário ou RAD. Quando tem-se pouco conhecimento dos requisitos e as ferramentas a serem utilizadas são muito complexas e não possui o domínio das mesmas, nesse cenário é recomendado a utilização do framework SCRUM.
O SCRUM preza por 3 valores essenciais, que são a transparência, a inspeção e a adaptação. A transparência é muito evidente e preza pela clareza de informações para toda equipe e um entendimento comum sobre a informação, principalmente em relação as considerações de "pronto". A inspeção busca a verificação constante do que está sendo feito e a importância de manter um progresso em relação a meta almejada. Logo, evitando entregas de baixa qualidade. A adaptação visa fazer os ajustes necessários ao processo ou mudanças do produto quando verifica-se que houve um desvio fora do aceitável.
Abaixo podemos ter uma pequena introdução do framework Scrum: seus papéis, cerimonias (eventos) e artefatos. Todos serão abordados com mais detalhes posteriormente.
O SCRUM é composto por 3 papéis fundamentais: Product Owner (Dono do Projeto), o Scrum Master e o Development Team (Equipe de Desenvolvimento).
O Product Owner é o representante do cliente no projeto, portanto deve ter um conhecimento do negócio e das necessidades de todos os interessados (stakeholders). Como elo entre o time Scrum e o cliente, deve estar sempre disponível para a equipe. O P.O. deve decidir quais os itens irão compor o Product Backlog e priorizá-los de forma que possa maximizar o valor do produto e garantir o ROI (Retorno sobre investimento).
O Scrum Master tem a responsabilidade de fazer com que toda a equipe respeite e siga os valores e as práticas do Scrum. Também deve assegurar o planejamento da Sprint para que a equipe não fique sobrecarregada. Como resultado, o time de desenvolvimento consegue realizar um planejamento de atividades mais real sobre o que a equipe pode realizar. Ele é responsável por remover os obstáculos que venham a ser levantadas pela equipe durante as reuniões diárias. Esse papel normalmente é exercido por um gerente de projeto ou por um líder técnico, mas poder ser ocupado por qualquer pessoa da equipe. Lembrando que o Scrum Master não é um Gerente da Equipe, é um líder facilitador e responsável pelo processo.
O Development Team, ou time de desenvolvimento, é responsável por transformar os requisitos do Product Backlog em software. É composta normalmente de 3 a 9 pessoas e entre elas não existe divisão de funções, como: programador, analista, etc. A equipe deve ser multifuncional, ou seja, todos os membros devem ter capacidade de realizar a tarefa que for preciso. Caso não a saiba, deve buscar aprender com os companheiros da equipe ou por outros meios. O time de desenvolvedores deve ser auto-gerenciável, pois o framework Scrum não contempla um gerente que diga o que cada um deve fazer. O time deve se organizar, decidir o que pode fazer e como deverá realizar as tarefas da Sprint. Essa ideia nasce com o objetivo de melhorar o trabalho em equipe, elevando o nível de comprometimento no desenvolvimento das atividades e do alcance da meta da Sprint.
O SCRUM gera 3 artefatos, que são o Backlog do Produto, o Backlog do Sprint e o Burn-down Chart.
http://imasters.com.br/wp-content/uploads/2013/01/scrumBoard1.jpg
O Backlog do Produto é composto pelos itens de tudo que deve compor o projeto a ser desenvolvido. Esses itens são organizados de acordo com suas prioridades, nas quais podem mudar durante o decorrer do projeto. Pode ser inserido um novo item ou também ser retirado algum item existente durante a execução do projeto. Essa resposta a mudança remete ao princípio de adaptação já vista anteriormente. O time de desenvolvimento deve estimar o esforço de todos os itens, a medida do necessário, para que possam identificar e acordar como dono do produto o que poderão desenvolver na Sprint.
O Backlog da Sprint é composto pelos itens que serão realizados durante a execução da Sprint e as tarefas designadas e estimadas para gerar o próximo incremento de software. Estes itens, assim como as tarefas da Sprint, são selecionados e definidos exclusivamente pelo time de desenvolvimento a partir do Backlog do Produto. Apesar de não ser uma ferramenta obrigatória do framework Scrum, é muito comum ser utilizado nas empresas um quadro Kanban para ajudar no dia-a-dia da Sprint.
O Burn-down Chart é um gráfico para medir a quantidade de trabalho restante ao longo da Sprint em relação ao planejado, embora também possa ser usado no planejamento de liberações (Releases) para exibir as entregas restantes do Product Backlog. É uma ferramenta visual poderosa para a equipe.
O SCRUM possui 5 eventos prescritos, todos com duração máxima predefinida (Time-Boxed), estes são: Sprint, Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.
A Sprint é o principal evento do Scrum que sustenta os demais eventos citados. Ela consiste em um ciclo de desenvolvimento que deve ter um período fixo (time-boxe) de 1 mês ou menos. Geralmente o período adotado no mercado é de Sprints de 30 ou 15 dias. Toda Sprint deve ter uma meta (Sprint Goal) a ser alcançada e deve entregar um incremento de software funcional.
O Sprint Planning é um evento com duração máxima de 8 horas (para Sprints de 30 dias ou proporcional para Sprints menores). Seu foco é no planejamento de todo trabalho que será realizado durante a execução da Sprint. Na Sprint Planning participa o Product Owner, o Scrum Master e o Development Team. O Product Owner deve descrever e explicar as funcionalidades prioritárias para todos da equipe. Em seguida a equipe de desenvolvimento estima a complexidade destes itens e "quebra" estas funcionalidades em tarefas. Como resultado, é gerado um artefato conhecido como Sprint Backlog. A reunião é dividida em duas partes e deve ser respondido as seguintes perguntas: 1. O que será feito nesta Sprint? 2. Como será feito?
O Daily Scrum é uma reunião que ocorre todos os dias da Sprint, exceto nos dias de Sprint Planning, Sprint Review e Sprint Retrospective. Ela deve ocorrer no mesmo horário e local designados, com a duração máxima de 15 minutos. É nesta reunião onde todos os membros da equipe de desenvolvimento responde a 3 perguntas: 1. O que fez desde a última reunião? 2. O que fará até a próxima reunião? Há algum impedimento em seu caminho? É importante saber que o Daily Scrum não é uma reunião para reportar-se a alguém, mas sim, uma reunião para o time de desenvolvimento pontuar problemas e impedimentos. O Daily Scrum permite acontecer a inspeção e adaptação da Sprint e os impedimentos levantados, devem ser tratados pelo Scrum Master o mais rápido possível.
O Sprint Review é uma reunião de revisão da Sprint com duração de 4 horas (ou proporcional para Sprints menores de 30 dias) feita no término de cada Sprint. Nesta reunião a equipe mostra os resultados que conseguiu atingir durante a Sprint e o Product Owner avalia e da seu feedback sobre o produto. Ou seja, o dono do produto deve verificar se foi atendido os requisitos especificados e, principalmente, se foi atingido a meta da Sprint. Não deve ser considerada como uma reunião de apresentação e itens que não atingiram a definição de "pronto" não devem ser apresentados.
O Sprint Retrospective é uma reunião que ocorre ao final de cada Sprint, após a Sprint Review. Tem duração de 3 horas (ou proporcional para Sprints menores de 30 dias). É uma reunião de melhoria contínua, onde é identificado o que pode ser melhorado no processo e as ações que serão tomadas para tal melhoria.
Time-box Scrum é o tempo de duração recomendado para cada evento do Scrum, de acordo com o tempo de duração da Sprint e com um Development Team de 3 a 9 pessoas. Observe abaixo uma tabela com o tempo de cada um desses eventos:
Pingback: O que é UML? - SmarTI