Olá pessoal, o post de hoje fala sobre os principais valores que podemos notar numa metodologia de desenvolvimento ágil, como o Scrum.
Feedback
O primeiro valor é o feedback, pois a compreensão dos usuários é uma das atividades mais difíceis e importantes dos desenvolvedores, afinal, ela é responsável por todos os esforços que vem a seguir.
O problema é que nem sempre o PO tem como prever corretamente as funcionalidades de que necessita, por isso é fundamental uma forte interação com os desenvolvedores ao longo do projeto. Por esta razão o Scrum é organizado em Sprints curtas de desenvolvimento (tempo médio de duas semanas).
Comunicação
A clareza na comunicação é essencial para que qualquer projeto de software dê certo. Um equívoco no processo de comunicação acarreta no desentendimento ou compreensão incorreta em algum aspecto do projeto.
Quando uma ideia é transmitida entre pessoas, estando as duas (ou mais) presentes no mesmo ambiente, o interlocutor dispõe de uma gama de artifícios da comunicação, como gestos, entonação, postura, expressões de corpo e faciais, tom de voz. O mesmo discurso, quando feito em uma conversa por telefone, perde todos os elementos visuais, o que pode causar um ruído nessa comunicação e um entendimento incorreto. Por este motivo, o Scrum defende o envolvimento de todos os participantes do projeto e, inclusive, a comunicação direta entre o PO e os membros da equipe de desenvolvimento.
Coragem
Segundo Beck e Fowler, existem alguns “medos” que exercem influência diretamente negativa sobre um processo de desenvolvimento de software. Por exemplo, os clientes temem:
- Não obter o que pediram;
- Pedir errado;
- Pagar muito por pouco;
- Não saber o que está acontecendo.
Já os desenvolvedores, temem:
- Não receber definições claras sobre o que deve ser feito;
- Ser solicitados a fazer mais do que sabem fazer;
- Não ter tempo suficiente para fazer um bom trabalho, sacrificando a qualidade.
As equipes Scrum devem reconhecer esses pontos e ter coragem para enfrentá-los da melhor forma possível. Um pensamento errado é “ficar na torcida” para que determinado problema nunca ocorra, pois os problemas ocorrerão. E pior, geralmente ocorre exatamente aquele que tanto tememos. O correto, por parte da equipe, é saber que problemas irão ocorrer e ter a confiança necessária para adotar soluções que possam reduzir ou eliminar as consequências dos problemas.
As práticas do Scrum, como a reunião diária, programação em par, releases curtos, testes, integração contínua e outros compõem uma espécie de rede de suporte e apoio, para que a equipe tenha a confiança e os artifícios necessários para a realização de um trabalho de qualidade.
Gostaram dos principais valores de uma metodologia de Desenvolvimento Ágil? Até o próximo post!
O que tem matado os desenvolvedores é a pressa dos clientes, querem tudo pra ontem. O P.O. não está acostumado a receber aos poucos, e mesmo que receba aos poucos o software, vai querer sempre boas doses de software. Não quer apenas uma 'tela', mesmo que essa tela exija integração entre outros sistemas externos, necessitem de uma análise mais profunda.
Então um ambiente que era pra rodar o perfeito MVC, é sacrificado, já que herança e polimorfismo é deixado de lado por levar mais tempo pra executar do que criar um simples laço de repitação direto no HTML, por exemplo.
Muito do scrum vai ser sacrificado se as pessoas envolvidas não tiverem pulso. E dizer: 'não é possível entregar tudo isso, muitas horas são consumidas em análise do que se vai programar, já que em grande maioria a documentação é nula'
Olá Bargão,
eu acredito que a situação descrita por você acontece com frequência no mercado. O papel do Scrum é fornecer exatamente o apoio que precisamos para convencer ao P.O. da importância de um trabalho bem feito.
Isso entra no valor da coragem. É importante a firmeza para afirmar o trabalho que será feito e, com Sprints de curta duração (duas semanas, por exemplo) o P.O. já terá um pequeno retorno do trabalho que está sendo desenvolvido. É muito mais gratificante para o P.O. ter essa oportunidade de acompanhar e vendo o produto sendo criado aos poucos, do que um desenvolvimento “às escuras”, onde após meses o P.O. vê (ou não) o que criado.
Obrigado pelo comentário. Continue acessando o nosso blog e participando!