Time Scrum: Dono do Produto, Scrum Master e Equipe de Desenvolvimento

Times Scrum são auto-organizáveis e multifuncionais. Times auto-organizáveis têm autonomia para escolher a melhor maneira de completarem seu trabalho, ao invés de se submeterem à direção de pessoas fora do time. Times multifuncionais reúnem todo o expertise necessário para completar o trabalho sem depender de pessoas de fora.

O modelo de time no Scrum tem características importantes, como flexibilidade e criatividade, além de serem bastante produtivos. Os times Scrum realizam entregas incrementais de produto “Pronto”, ou seja, entregam versões de forma que sempre haja um produto funcional disponível.

O Time Scrum é composto pelo Product Owner, Scrum Master e o Development Team .

Vejamos seus papéis a seguir.

Product Owner ou Dono do Projeto

Product Owner ou Dono do Projeto é a única pessoa responsável por gerenciar o Backlog do Produto. Embora ele possa delegar tarefas para o Time de Desenvolvimento, o Backlog do Produto continua sendo de sua responsabilidade. Caso alguém deseje alterar as prioridades do Backlog, primeiro deve conversar e convencer o Product Owner. De acordo com Schwaber e Sutherland (2016, p. 6), 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 o Time 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. Ele sempre vai atualizar, priorizar e se preocupar em refinar o Product Backlog.

Scrum Master

O ScrumMaster tem a responsabilidade de remover os possíveis impedimentos que a equipe ou time possam ter e protege o Time de envolvimentos externos prejudiciais. Ele busca garantir o uso adequado do Scrum de forma que o Time adote as práticas e regras. Ele tem preocupação com a cultura organizacional, pois ela pode afetar o sucesso do projeto. O Scrum Master ajuda os que não pertencem ao Time Scrum a compreenderem quais são e como são as suas interações com o Time. Em seu papel de “servidor-líder”, o Scrum Master trabalha junto com o Product Owner, junto com o Time de Desenvolvimento e para a organização. 

O time Scrum.

Por OksanaAlex / shutterstock.com

 

Valores do Scrum

 

Quando os valores de comprometimento, coragem, foco, transparência e respeito são assumidos e vividos pelo Time Scrum, os pilares do Scrum de transparência, inspeção e adaptação tornam-se vivos e constroem a confiança para todos. Os membros do Time Scrum aprendem e exploram estes valores à medida que trabalham com os eventos, papéis e artefatos do Scrum.

O sucesso no uso do Scrum depende das pessoas se tornarem mais proficientes na vivência destes cinco valores. As pessoas se comprometem pessoalmente em alcançar estes objetivos do Time Scrum. O Time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis. Todos focam no trabalho da Sprint e nos objetivos do Time Scrum. O Time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a execução dos trabalhos. Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes (SCHWABER; SUTHERLAND, 2016, p. 5).

A figura apresenta o ciclo de vida do Scrum. Nela pode-se observar a interação entre os diversos elementos que compõem o framework e que estudaremos neste capítulo, quais sejam:

• Time Scrum (Product Owner, Scrum Master, Equipe de Desenvolvimento);
• Eventos Scrum (Sprint, Reunião de Planejamento da Sprint, Reunião Diária, Reunião de Revisão da Sprint, Reunião de Retrospectiva da Sprint);
• Artefatos Scrum (Product Backlog, Sprint Backlog).

Ciclo de vida Scrum.

Fonte: ned.unifenas.br .

Modelagem ágil com Scrum

Segundo seus criadores, Ken Schwaber e Jeff Sutherland, o Scrum é um framework ágil para a conclusão de projetos complexos. É um framework que permite que pessoas possam tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Mas o framework Scrum, muitas vezes, é visto como enganosamente simples. A partir deste conceito, caro aluno, vamos nos aprofundar no estudo deste método ágil de desenvolvimento de software. 

Visão geral do Scrum

O Scrum não é um processo padrão que descreve o que fazer em cada situação. Sua verdadeira eficiência é comprovada em trabalhos complexos, em que não há certeza do que irá ocorrer.

De acordo com Schwaber e Sutherland (2016, p. 3), o Scrum é:

• leve;
• simples de entender;
• extremamente difícil de dominar.

O Scrum é baseado em teorias empíricas de controle de processo, ou empirismo, cujas bases se fundamentam no fato de que o conhecimento é adquirido pela experiência e que as tomadas de decisão são baseadas no que é conhecido.

Ainda de acordo com os autores, o Scrum possui três pilares de controle de processo empírico, que sustentam sua implementação, e são assim definidas por eles:

• Adaptação : caso algum aspecto seja identificado como desvio, podendo levar o produto a algo inaceitável, o processo deve ser ajustado, e isso deve ser feito o mais rapidamente possível;
• Inspeção : os usuários devem inspecionar frequentemente os artefatos Scrum e verificar possíveis variações que comprometam seu progresso, mas este trabalho é mais adequadamente realizado se for deixado a cargo de inspetores especializados neste tipo de verificação;
• Transparência : todos os aspectos significativos dos processos devem estar visíveis aos responsáveis pelos resultados. Esta transparência requer o uso de um padrão comum para que todos possam ter a mesma compreensão do que está sendo visto.

O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. O frameworkScrum é composto por membros do time Scrum associados a papéis, eventos, artefatos e regras. Cada um destes componentes serve a um objetivo específico e é essencial para o uso e sucesso do Scrum. As regras do Scrum integram os eventos, papéis e artefatos, administrando as relações e interações entre eles.

Scrum

Scrum é o nome de uma jogada derivada de um esporte chamado rúgbi. Este nome foi adotado para um modelo ágil de processos desenvolvido por Jeff Sutherland, Ken Schwaber e sua equipe na década de 1990. Seu objetivo inicial era atender as empresas de desenvolvimento de software; no entanto, com o tempo, passou a ter seus conceitos aplicados a gerenciamento de projetos.

Scrum é mais um framework do que uma metodologia. Significa, para os envolvidos, uma mudança de conceitos. O envolvimento é obrigatório, e a participação do time é essencial para o sucesso de sua aplicação. 

Scrum no rúgbi

 

Fonte: rugbycamps.ie

Reflexões sobre os modelos ágeis

“Nenhum homem é uma ilha”. Adotar modelos ágeis não é apenas adotar um desafio para realizar uma tarefa difícil em um curto espaço de tempo, mas significa aprender a trabalhar em equipe. Significa respeitar as regras, pessoas e decisões. Existem leis que, assim como princípios, regem a criação em modelos ágeis, e todas devem ser seguidas.

Não existe e nem nunca vai existir uma regra única para ser usada neste conceito, pois cada situação, cada negócio, cada estratégia vai exigir ações e procedimentos distintos.

Imagine um time de futebol em que cada jogador decide jogar como bem entende, desconsiderando as orientações do treinador. O jogador pode saber jogar melhor em uma posição, mas a tática montada pode colocá-lo em outra posição. O que o jogador deve fazer em uma situação dessas? Seguir seus instintos ou obedecer às ordens? Se estivermos falando de um time que pratica modelos ágeis, estamos falando de obedecer às ordens ou participar da estratégia que visa o benefício coletivo e não individual.

Cada orientação sobre a documentação, reuniões, obediência a prazos etc. irá determinar o sucesso do planejamento e do negócio.

O sucesso do grupo depende de cada indivíduo aceitar e respeitar seu papel no planejamento. Aceitar significa visar o bem do grupo e não o bem de cada membro individual do grupo.

Há um ditado popular que diz que a união faz a força. E nas equipes de modelos ágeis nunca se viu tanto na prática a realidade disto.

Importância da equipe em projetos ágeis.

Por 3dmask / shutterstock.com.

 

DSDM - Método de Desenvolvimento de Sistemas Dinâmicos

O DSDM ( Dynamic Systems Development Method ou Metodologia de Desenvolvimento de Sistemas Dinâmicos) é uma metodologia de desenvolvimento de software originalmente baseada em RAD ( Rapid Application Development ou Desenvolvimento Rápido de Aplicação) . O DSDM é uma metodologia de desenvolvimento iterativo e incremental que enfatiza o envolvimento constante do usuário (WIKIDOT.com, 2011).

Além de envolver o cliente, o DSDM tem como propósito a entrega do software sem estourar o tempo e dentro do custo estimado. Para isso, a DSDM realiza a entrega de protótipos gerados em tempos ágeis, suas equipes de desenvolvimento são autônomas, realiza grande quantidade de testes durante todo o desenvolvimento e define prioridades nos requisitos. 

XP - Programação Extrema

O XP ( Extreme Programming ) é um dos processos ágeis mais populares e possui evidências de ser bem-sucedido em empresas de todos os tamanhos e indústrias do mundo inteiro. É visto como bem-sucedido porque salienta a satisfação do cliente. Em vez de entregar tudo o que o cliente poderia desejar em alguma data distante no futuro, este processo fornece o software em pequenos pacotes. 

Programação extrema

 

Por Bakhtiar Zein / shutterstock.com 

O XP capacita os desenvolvedores a responder às mudanças que refletem as necessidades dos clientes, mesmo no final do ciclo de vida. Este processo enfatiza o trabalho em equipe. Os gerentes, clientes e desenvolvedores são todos parceiros iguais em uma equipe colaborativa.

Além disso, implementa um ambiente simples, mas eficaz, permitindo que as equipes tornem-se altamente produtivas. A equipe se auto-organiza em torno do problema para resolvê-lo o mais eficientemente possível.

De acordo com Teles (2014), XP pode melhorar um projeto de software com base em cinco aspectos essenciais:

• Comunicação;
• Simplicidade;
• Comentários;
• Respeito;
• Coragem.

Os programadores mantêm o design simples, limpo e procuram obter feedback , testando o software. Eles entregam o sistema para os clientes o mais cedo possível e implementam mudanças, respondendo rapidamente às alterações nos requisitos e nas tecnologias. Cada pequeno sucesso aprofunda o respeito para as contribuições únicas de cada membro da equipe e de todos.

O aspecto mais relevante do XP são as suas regras simples. Ele é muito parecido com um quebra-cabeça, em que há muitos pedaços pequenos. Individualmente as peças não fazem sentido, mas, quando combinadas, formam uma imagem completa. As regras podem parecer estranhas e talvez até ingênuas no início, mas são baseadas em sólidos valores e princípios.

 

OpenUP - Processo Unificado Aberto

O OpenUP está em conformidade com os princípios do Manifesto do Desenvolvimento de Software Ágil, pois possui uma abordagem iterativa e incremental e é um processo que não está associado a nenhuma ferramenta específica.

De acordo com Santos (2009), o OpenUP é um processo que é considerado mínimo, completo e extensível, que valoriza a colaboração entre a equipe e os benefícios aos interessados ao invés da formalidade e entregáveis desnecessários. 

Características do OpenUP

 

Fonte: www.slideshare.net .

O OpenUP apresenta a mesma distribuição de fases já conhecidas no RUP, em que o critério de saída de cada fase é no mínimo atender as seguintes respostas:

• Iniciação: Todos os stakeholders concordam com o escopo e objetivos do projeto?
• Elaboração: Todos concordam com a arquitetura proposta e o valor entregue ao cliente considerando os riscos levantados?
• Construção: Existe uma aplicação que está quase pronta, bem próxima a ser finalizada?
• Transição: A aplicação está finalizada e o cliente satisfeito?

O ciclo de vida do projeto possui foco nas necessidades dos stakeholders e interação com o time.

Além da divisão por fases, o OpenUP divide o projeto em iterações planejadas que podem variar de alguns dias a algumas semanas. A média recomendada é de quatro semanas, podendo ser reduzida ou aumentada em até aproximadamente seis semanas. Ao final de cada iteração deve ser gerado um incremento ao produto (chamado de build executável ou demo).

Ao final de cada iteração geralmente é realizada uma retrospectiva e avaliação em que são discutidas as lições aprendidas do projeto. Vale mencionar que o principal objetivo da retrospectiva é aprender com erros e acertos e não apontar culpados.

Outro conceito importante é o de microincremento, que é a execução de um pequeno passo que precisa ser mensurável para alcançar os objetivos de uma iteração. Este pode representar o resultado de alguns dias ou horas de trabalho, de uma pessoa ou um grupo determinado.

 

AD - Dados Agile

De acordo com Ambler (2013), o objetivo do método AD ( Agile Data ) é definir estratégias que os profissionais de TI podem aplicar em uma grande variedade de situações para trabalhar em conjunto, de forma eficaz, sobre os dados de sistemas. Isso não quer dizer que o AD engloba todos os conceitos ou metodologias.

O AD pode ser considerado como um conjunto de filosofias que permite que os profissionais de TI trabalhem em conjunto, de forma eficaz, quando se tratam dos aspectos de dados de softwares, em que os desenvolvedores:

• Trabalham em estreita colaboração com as partes interessadas do projeto;
• Devem reconhecer que os sistemas legados e bancos de dados colocam restrições sobre eles;
• Devem seguir as normas da organização e diretrizes e estarem dispostos a fornecer um feedback de sua evolução;
• Irão trabalhar em estreita colaboração com os arquitetos da empresa, pessoas que devem se tornar membros ativos de uma equipe de projeto.

EssUP - Processo Unificado Essencial

O EssUP ( Essential Unified Process ) foi criado por Ivar Jacobson como uma melhoria do RUP ( Rational Unified Process ). O método utiliza práticas como casos de uso, desenvolvimento interativo, ADD ( Architecture Driven Development ), que foram incorporadas do RUP, CMMI e desenvolvimento ágil.

De acordo com Jacobson (2017), EssUP incorpora práticas que contêm um pequeno número de cartas que proveem uma forma estruturada e útil de guiar o desenvolvimento. Estas práticas foram projetadas de forma que possam ser adotadas de forma individual ou em qualquer combinação, o que torna o processo fácil de ser adotado e adaptado à organização. São cinco práticas básicas, endereçadas ao trabalho técnico de desenvolvimento, e três práticas de trabalho, que promovem o trabalho efetivo da equipe e de melhoria do processo.