Engenharia de Software | Gerenciamento de Projetos de Software | Framework Scrum
Artefatos
O Scrum prevê alguns artefatos que nos permitem ter uma visão sobre o andamento do projeto e do Sprint. Esses artefatos são conhecidos como Backlog.
Backlog de Produto (Product Backlog)
É uma lista ordenada criada pelo time.
O formato da lista pode variar de acordo com cada time, pode ser formada por casos de uso, Funcionalidades (do FDD), porém os mais comuns são user stories, que veremos mais adiante quando tratarmos de Backlog e priorizações.
Durante a evolução do projeto podem ocorrer alterações nessa lista, como a inclusão de novos itens, mudanças na prioridade de desenvolvimento e entrega, alguns itens podem ser ajustados de acordo com importância para o negócio ou até mesmo eliminados. Mas o ÚNICO que pode inserir, alterar ou remover é o Dono do Produto (Product Owner).
Backlog do Sprint (Sprint Backlog)
É um conjunto de itens selecionados para serem implementados (e entregues como incremento ao produto) durante o Sprint.
O objetivo do Backlog do Sprint é tornar o trabalho visível e tangível para que o time atinja a meta do Sprint.
Dica!
Meta: A meta do Sprint são os itens (casos de uso, funcionalidades ou histórias do usuário) que precisam ser adicionadas ao produto (incremento gerado pelo Sprint) com sucesso. Geralmente na promoção dos itens do backlog de produto para o backlog do Sprint definimos itens a mais do que a meta, pois como as estimativas possuem certo grau de imprecisão, é possível que a meta seja atingida antes do término do Sprint, assim o time ainda tem itens para serem implementados.
Definição de Pronto: Essa definição precisa ser acordada e respeitada por todos do time, geralmente a definição de pronto significa dizer que o item já está codificado (de acordo com patterns definidas), testado (teste unitário, integração,…), documentado (manual atualizado), e implementável. Enquanto um item não atingiu todas as características determinadas na definição de pronto, ele é considerado WiP (Work In Progress – Trabalho em Progresso).
Os papéis e responsabilidades no Scrum
A organização dos recursos humanos envolvidos no projeto utilizando o framework Scrum é separada em três papéis:
Product Owner, Scrum Master e Desenvolvedores.
Vamos ver cada um deles a seguir.
Product Owner
O Product Owner ou dono do produto, basicamente o representante do cliente dentro do time Scrum, é responsável por entender o que o cliente precisa e transportar esse conhecimento para os desenvolvedores. Algumas de suas responsabilidades são:
- Participar do Daily Scrum;
- Responder dúvidas dos desenvolvedores sobre o que está sendo desenvolvido ou indicar que poderia respondê-las;
- Prover uma meta clara para cada Sprint;
- Obter feedback e expectativas dos clientes e extrair deles as necessidades;
- Manter o product backlog atualizado.
O Product Owner é uma pessoa e não um comitê. Pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner. Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões.
As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém tem permissão para falar com a Equipe de Desenvolvimento sobre diferentes configurações de prioridade, e o Time de Desenvolvimento não tem permissão para agir sobre o que outras pessoas disserem.
Responsabilidades do Product Owner
As responsabilidades do Product Owner são listadas para cada fase do projeto, mas não se limitam a elas.
Pre-Game
Antes do início do trabalho, fase conhecida como Pre-Game:
- Identificar as necessidades estratégicas do projeto (patrocinador, time, infraestrutura, áreas envolvidas etc.);
- Realizar Kick-Off;
- Descobrir a visão do produto e elaborar artefatos necessários;
- Descobrir os requisitos para o Product Backlog;
- Organizar e priorizar o Product Backlog.
Game
Durante o trabalho, fase conhecida como Game:
- Participar de todas as reuniões de planejamento e de revisão. Quando necessário visitar a reunião diária e participar da retrospectiva (geralmente, quando convidado pelo time);
- Estar disponível para o time (ou garantir que alguém designado por ele esteja);
- Elaborar plano de release (plano de versões, veremos mais adiante);
- Manter o Product Backlog;
- Atualizar o plano de release.
Post-Game
Após a conclusão das entregas do projeto, na finalização do projeto, fase conhecida como Post-Game:
- Promover e participar da retrospectiva do projeto;
- Tornar resultados visíveis para outros (e futuros) projetos Scrum na empresa.
É muito comum empresas que iniciam nos métodos ágeis definir Product Owner sem poder de decisão; com baixa disponibilidade; com interesse em apenas uma parte do projeto; ou com acúmulo de outras funções no time (ou desenvolvedor ou Scrum Master). Todas essas características enfraquecem e podem comprometer a adoção da agilidade e do projeto.
- P.O. sem poder de decisão;
- P.O. com baixa disponibilidade;
- O “metade” P.O.;
- P.O. distante;
- P.O. “proxy”;
- P.O. “da sua parte”.
Scrum Master
Segundo o Scrum Guide, o Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o time Scrum adira à teoria, práticas e regras do Scrum. O Scrum Master é um servo-líder para o time Scrum.
O Scrum Master ajuda aqueles que estão fora do time Scrum a entenderem quais as suas interações com o time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem essas interações para maximizar o valor criado pelo time Scrum.
Algumas de suas responsabilidades são:
- Educar o time e stakeholders sobre o processo;
- Assegurar que a equipe faça o Daily Scrum no horário certo e de modo produtivo;
- Resolver os impedimentos da melhor maneira possível;
- Manter o foco das reuniões;
- Indicar pontos de melhoria no processo e no ferramental.
Equipe de Desenvolvimento
Segundo o Scrum Guide, a Equipe de Desenvolvimento (Dev. Team) consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementar o produto “Pronto” ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam incrementos.
As Equipes de Desenvolvimento são estruturadas e autorizadas pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de Desenvolvimento como um todo.
Os times Scrum são auto-organizáveis e multifuncionais. Equipes auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe.
Sobre a Auto-Organização
A auto-organização é o processo onde uma estrutura ou padrão aparece em um sistema sem uma autoridade central ou elemento externo que define um planejamento.
Segundo a físico-química, a auto-organização é a característica de que sistemas abertos podem se organizar espontaneamente quando sujeitos a um dado gradiente. O termo auto, nesse caso, reflete o fato de que não há nenhuma instrução do ambiente sobre como a organização deve ocorrer ou como o sistema deve se adequar em resposta ao gradiente. Em outras palavras, o gradiente imposto é completamente neutro em termos de informações e a organização emerge de dentro do sistema. Processos de auto-organização são ubíquos na natureza: de células a órgãos e organismos, de indivíduos a organizações sociais, de casas a bairros, cidades etc.
Fonte: <http://cienciaecultura.bvs.br/scielo.php?pid=S0009-67252011000100010&script=sci_arttext>.
Para a química, a capacidade de auto-organização (self-assembly) consiste na formação (espontânea) de estruturas complexas a partir de componentes simples. Por exemplo, as espécies químicas denominadas anfifílicas – que incluem os detergentes e alguns líquidos – contêm uma parte hidrofílica (que “gosta” de água), e uma hidrofóbica (que não “gosta” de água). Por este motivo, estas espécies agregam-se na presença de água, formando, por exemplo, micelas ou bicamadas, isto é, se auto-organizam.
Fonte: <http://dererummundi.blogspot.com.br/2007/11/auto-organizao-de-sistemas-qumicos.html>.
É muito comum auto-organização ser chamada de anarquia, mas vamos a alguns esclarecimentos:
Anarquia vem do grego anarchia que significa “sem regras”. Encontramos outras variações sobre o significado da palavra como: “falta de ordem” ou “negação ou ausência de autoridades ou ordem estabelecida”. Esses significados são tratados como sinônimos para caos (sem ordem) ou complexidade (ordem, mas não imposta por uma autoridade).
Na mente da maioria das pessoas, anarquia é igual a caos. Esse equívoco é provavelmente a principal razão pela qual algumas pessoas especialistas não gostam de associar a auto-organização com anarquia. Veja, as galáxias se comportam de uma maneira anárquica, e ainda assim elas não são caóticas.
Nos países (não estamos falando dos governos), as suas relações de comércio são anarquias e também não são necessariamente são caóticas.
A auto-organização pode ser considerada uma variação complexa da anarquia. Tanto a química, a física e a biologia possuem suas próprias definições de auto-organização, mas nenhuma delas aborda a liderança, gerência ou autoridade. Assim, não faz muito sentido alterarmos os conceitos de auto-organização apenas para aplicar no contexto social.
Por exemplo, quando todas as netas e netos de minha mãe (crianças entre 2 e 7 anos) se reúnem na casa dela com seus muitos amiguinhos, correndo e gritando para todos os lados, nós adultos podemos acreditar que é um sistema anárquico quando na verdade eles estão auto-organizados. Isto ocorre porque a forma como eles se auto-organizam não necessariamente agrada (ou é aprovada) por nós (suas principais partes interessadas).
Este comportamento é observado em empresas/departamentos de software onde os desenvolvedores disputam em horário de trabalho campeonatos de videogame e ainda sim entregam seus trabalhos. Isso provoca um choque cultural na empresa que pode atingir até a diretoria executiva com essa nova forma de relacionamento.
É importante observar que a auto-organização não faz distinção entre bem e mal, virtudes ou vícios, atitude que agregam valores ou não.
Uma outra confusão muito comum é entre a auto-organização e as propriedades (técnicas) emergentes. Quando uma propriedade não pode ser rastreada a qualquer uma das partes individuais do sistema, essa propriedade é chamada de uma propriedade emergente. Por exemplo, sua personalidade é uma propriedade emergente do seu cérebro. Ela não pode ser atribuída a neurônios individuais.
As propriedades emergentes possuem as seguintes características:
Superveniência é a observação de que a propriedade deixará de existir se você tirar as peças individuais do sistema. Por exemplo, a sua personalidade desaparece se remover seus neurônios.
A propriedade não é um agregado, ou seja, essa propriedade não é simplesmente o resultado da soma das propriedades das partes individuais. Por exemplo, uma única molécula não tem fluidez. Então você não pode simplesmente somar a fluidez de um bilhão de moléculas individuais para determinar a fluidez da água.
Deve haver causalidade para baixo (downward causality), o que significa que a propriedade emergente deve influenciar o comportamento das peças individuais. Por exemplo, a cultura de um grupo de pessoas influencia o comportamento dos seus membros.
O comportamento emergente em times é o resultado da interação entre os seus membros. Assim, o time é responsável por sua própria cultura, processos, imagem perante a organização e muitas vezes até pelo seu “próprio nome”.
Responsabilidades
Como regra geral, podemos dividir os papéis e responsabilidades como:
MACRO P.O. (Negócio)
Assuntos relacionados ao macronegócio, priorização, definição do que será feito, orçamento ou qualquer outro assunto associado ao negócio é de responsabilidade do Product Owner (P.O.).
MICRO Dev. Team (Tecnologias)
Assuntos referentes à técnica de desenvolvimento, arquitetura, e assuntos mais técnicos são de responsabilidade do Time de Desenvolvimento (Dev. Team).
PROCESSOS (S.M)
E por fim, assuntos associados aos processos de trabalho são de responsabilidade do Scrum Master.
Estes personagens formam o TIME SCRUM e são, em conjunto, responsáveis pelo gerenciamento do projeto.
Eventos Scrum – Sprint
Segundo o Scrum Guide, o Sprint é um time-box de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado.
Sprints tem durações coerentes em todo o esforço de desenvolvimento. Um novo Sprint inicia imediatamente após a conclusão do Sprint anterior.
Os Sprints são compostos por:
- Planning meeting (Planejamento do Sprint)
- Daily Scrum (reuniões diárias)
- Revisão do Sprint (Review meeting)
- Retrospective meeting (retrospectiva do Sprint).
Eventos Scrum – Reunião de Planejamento – Planning meeting
A reunião de planejamento de Sprint é realizada no primeiro dia de cada Sprint. O Scrum Master, Product Owner e o time de desenvolvimento estão todos os presentes. Essa reunião não deve ocupar mais de 5% da duração do Sprint (por exemplo,em um Sprint de 2 semanas, não deve durar mais de 4 horas) e é dividida em duas partes e deve chegar a responder às seguintes perguntas:
- O que será entregue no Incremento resultante neste Sprint?
- Como faremos para entregar o Incremento neste Sprint?
Na primeira parte, o Product Owner apresenta o conjunto de características que ele gostaria de ver concluída no Sprint (“o quê”), os itens do topo do backlog do produto. O time avalia o esforço necessário para a conclusão de cada item e negocia o que é possível entregar no Sprint.
ATENÇÃO
A quantidade de itens selecionados para o Sprint é prerrogativa do Time de Desenvolvimento. Ele é o único capaz de avaliar o esforço para cada item já que será ele que irá desenvolvê-los. Em times com baixa maturidade é importante que o Scrum Master relembre da importância de não subestimar ou sobrecarregar o Sprint.
Após selecionar os itens que serão realizados no Sprint, o time define a meta do Sprint.
Na segunda parte da Reunião de Planejamento, o time define como irá transformar os itens do backlog do Sprint em incrementos do produto.
Nesta etapa o time determina as tarefas necessárias para implementar esses recursos (“o como”).
Estimativas de trabalho são revistas para ver se a equipe tem o tempo para concluir todas as características solicitadas no Sprint. Se assim for, a equipe se compromete com o Sprint. Se não, os recursos de menor prioridade voltam para o product backlog, até que a carga de trabalho para o Sprint seja de tamanho adequado para obter o compromisso da equipe.
Eventos Scrum – Scrum Diário – Daily Scrum
Geralmente cada membro do time responde às seguintes perguntas:
- O que fiz desde o último Daily Scrum?
- O que irei fazer até o próximo?
- Quais impedimentos estão me atrapalhando?
O objetivo dessa reunião é melhorar a comunicação na equipe e dar para todos uma visão mais clara do andamento do time no Sprint, além de facilitar a identificação e resolução de problemas e impedimentos.
Eventos Scrum – Reunião de Revisão do Sprint – Review meeting
No final do Sprint, o time convida os interessados (clientes) para uma reunião de revisão do Sprint, onde as tarefas que foram concluídas no Sprint são demostradas e o feedback é solicitado (apenas as que atendam a definição de pronto).
Essa reunião não deve ocupar mais de 2.5% do tamanho do Sprint (por exemplo, em um Sprint de 2 semanas não deve durar mais de 2 horas).
Essa reunião é importante para demostrar ao cliente as novidades que estarão disponíveis para o uso, quanto para que o time de desenvolvimento receba o feedback real dos usuários do sistema e entenda melhor suas necessidades.
Para saber mais sobre o framework Scrum acesse:
https://www.scrumalliance.org/
Caso o cliente tenha dúvidas, estas deverão ser respondidas e qualquer problema (ou possível problema) encontrado deve ser anotado.
Nesta reunião o Product Owner aprova ou rejeita os itens implementados. Caso rejeite, o item volta para o Backlog do Produto (e pode ou não entrar no próximo Sprint, dependerá da avaliação do Product Owner).
REFERENCIAS
SCRUM GUIDE. Disponível em: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf/
Acesso em: 20 jan. 2015
Engenharia de Software | Gerenciamento de Projetos de Software | Framework Scrum