0

Scrum e XP e como eles podem auxiliar uma empresa

Willams Sousa
Willams Sousa

Parte I - O que é Scrum  e o que é Extreme Programming (aka XP)


Scrum


O Scrum é uma metodologia de desenvolvimento ágil e também "um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível" (Scrum Guide).


Como em qualquer metodologia, o Scrum segue alguns passos e conceitos.

Personagens: Product Owner, Scrum Master e Time de Desenvolvimento.


O Product Owner (aka PO) é o cara que negocia com o cliente, ele define prioridades e também lida com o backlog (outro conceito usado no Scrum). O Scrum Master (aka SM) é o cara que conhece a fundo as metodologias ágeis e tem como principal função manter o time de desenvolvimento unido e produtivo. Já o Time de desenvolvimento (aka Time Dev) é composto por pessoas aptas a desenvolverem o produto, no caso de um software são programadores, engenheiros e arquitetos de software. 


No Scrum o PO mantem um backlog que contém tudo que é necessário para um produto de acordo com as prioridades. A sprint é um tempo delimitado necessário para entregar valor para o cliente (e.g. um produto que pode ser usado, mesmo que parcial, de forma produtiva e concreta). O planning abre toda sprint onde o PO mostra o backlog para a equipe e onde é discutido o que será feito. Daily são reuniões diárias feitas pela equipe feitas geralmente pela manhã com duração de aproximadamente 15min com seus participantes em pé (foi constatado que reuniões onde os integrantes estão sentados tendem a serem menos produtivas!). Temos também o Sprint backlog que é uma parte do backlog separada para ser feita na próxima sprint de acordo com as prioridades. Ao final de cada sprint temos o Review, que consiste de uma reunião com todos envolvidos, incluindo o cliente, mostrando os resultados alcançados. E, por fim, temos a Retrospectiva onde apenas o time dev participa e são tratados assuntos da equipe que visa descobrir se todos estão satisfeitos e quais melhorias podem ser feitas.


Extreme Programming ou XP


O XP é uma metodologia baseada em princípios e valores fundamentados por um conjunto de práticas. O XP pode ser usado junto com o Scrum por ser focado mais em processos de engenharia e desenvolvimento de software. 

O conjunto de valores norteiam as pessoas envolvidas no desenvolvimento de softwares, eles são: comunicação, simplicidade, feedback, coragem e respeito. Já os princípios são: feedback rápido, presumir simplicidade, abraçar mudanças, trabalho de alta qualidade, pequenos passos, melhoria, diversidade, reflexão. 


Por fim, temos as práticas:


Planejamento: Reuniões feitas em períodos curtos (1 a 2 semanas) onde a equipe desenvolve um conjunto de funcionalidades criando as estórias que são escritas pelo cliente.


Stand Up Meeting: Reuniões feitas em pé como as Daily mencionadas no Scrum logo acima.

Programação em par: onde duas pessoas usam o mesmo computador, garantido que o software seja revisto sempre por pelo menos duas pessoas.


Testes constantes: onde é usado Test Driven Development também conhecido como TDD. Primeiro são criados os testes de unidade e só então uma implementação que passe nesses testes.


Refatoração: já conhecido dos programadores, é a melhoria constante do código organizando e aumentando sua clareza.


Código coletivo: o código não tem um dono específico, toda a equipe pode modificar qualquer parte do código permitido que todos na equipe conheça todo o código. 


Padronização do código: a equipe segue as mesmas regras parecendo que o código foi digitado pela mesma pessoa. (nomes de variáveis, espaçamentos, endentações, etc..).


Design simples: garantir que o código tenha apenas o que é necessário de acordo com o que o usuário está pedindo. Sabe-se que é comum o desenvolvedor incluir código que não é importante naquele momento, p.ex.


Metáfora: focado em melhorar a comunicação com o cliente traduzindo termos para a realidade do cliente.


Ritmo sustentável: garantir que todos estejam atentos e dispostos no trabalho garantindo a qualidade e o rendimento.

Semana de 40 horas: É trabalhar com qualidade buscando ter um ritmo de trabalho saudável, 40h por semana, 8h por dia, sem horas extras.


Integração contínua: sempre que algo for melhorado, não esperar para integrar no sistema. 

Releases curtos: a liberação de pequenas versões ajudam na aceitação do cliente que consegue testar parte do sistema.


Parte II - Como essas metodologias podem auxiliar uma empresa


Era comum que os produtos fossem desenvolvidos utilizando o modelo em cascata. Este modelo amenta desnecessariamente o tempo de entrega dos produtos porque sua estratégia consiste em dar mais foco na documentação que no desenvolvimento. Assim, pode ser que mesmo com 50% do produto já concluído o cliente ainda não tenha meios para testar o que já está pronto, pois isso muitas vezes significa que pouco ou nenhum código foi escrito ainda.


Com as metodologias Scrum e XP o foco principal é a entrega rápida de versões menores do sistema que satisfaz o cliente por já entregar algum valor em pouquíssimo tempo. Além disso, uma vez que o cliente consegue interagir com o produto logo em seus primeiros momentos, o cliente possui mais oportunidades para validar ou invalidar funcionalidades, dando a chance da equipe atuar rapidamente no sistema modificando e adaptando sem perdas desnecessárias de tempo e esforço (o que pode ser traduzido em: dinheiro, valor). 


Uma analogia para este processo pode ser feita com um cliente que deseja um produto que servirá como meio de transporte. No início pode ser acordado entre as partes que o cliente deseja um caminhão. No modelo em cascata o caminhão seria produzido do início ao fim e entregue ao cliente que, por motivos diversos, pode concluir que não era o que ele queria tornando as modificações e adaptações algo muito custoso tanto para o cliente, quanto para o desenvolvimento. Nos modelos de desenvolvimento citados acima, o cliente pode iniciar com a mesma ideia (um caminhão), mas nos primeiros momentos ele terá acesso a um patinete, poderá verificar a principal funcionalidade (transportar) e em um segundo momento receberá uma bicicleta, com as melhorias de um assento, então receberá uma moto que agora possui um motor, e, seguindo essa entrega contínua de valores, o cliente consegue atuar no processo de desenvolvimento e com as adaptações feitas ao longo do processo ele pode, em vez do caminhão, terminar com uma Ferrari! Tudo isso não terá impacto no desenvolvimento do produto, pois ele foi se adaptando de maneira natural e gradual, algo que seria impossível de ser feito caso o produto já seja um caminhão, impossibilitando a transformação deste em uma Ferrari.


Dessa forma, essas metodologias contribuem para o aumento da comunicação entre todas as partes envolvidas, desde o desenvolvedor no time de desenvolvimento até o cliente. Todos compartilham de maneira fluida e constante suas ideias transformando todo o processo em uma interatividade mais humana e dando foco mais nas pessoas que em documentações burocráticas.

0
8

Comentários (0)

Tento ser um sujeito legal e gosto de aprender linguagens de programação.

Brasil