O MANIFESTO ÁGIL foi desenvolvido por 17 profissionais no início de 2001, anarquistas organizacionais, como foram chamados por Jim Highsmith, signatário do manifesto e principal desenvolvedor do Método Ágil.
Anteriormente ao Manifesto Ágil o termo conhecido era "Peso Leve" (Lightweights), posteriormente mudou para Ágil tirando a falsa impressão de apenas uma contraposição às metodologias tradicionais de gerenciamento de projetos, que eram conhecidas como "Peso-pesado" (Heavyweights), com ciclos preditivos de desenvolvimento do produto, onde todo o escopo era detalhado e planejado do início ao fim, gerando extensa documentação e esforço inicial.
👁🗨Atente-se que: o conceito Ágil deve ser ligado a busca pela mínima documentação e processo mínimo necessário, pela valorização das pessoas, pela comunicação fluída entre stakeholders, pela participação efetiva do cliente no ambiente do projeto e pela entrega frequente de valor.
OS VALORES
Com abordagem bem simples, os dezessete determinaram para o desenvolvimento de software de maneira ágil os seguintes valores fundamentais:
"Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda".
Não significa que os itens da direita não devam ser praticados, são importantes também, um mais outro menos à depender das caraterísticas do projeto.
A filosofia ágil valoriza os itens da esquerda, pois são fundamentais para garantir o bom andamento do projeto, entregas constantes, trazem maior percepção de qualidade e que entregam mais valor para o cliente.
É fundamental que esses valores sejam internalizados por todos os profissionais que atuam com agilidade. Nesse sentido, vale a pena detalhá-los um pouco mais:
1) Indivíduos e interações mais que processos e ferramentas
Existem softwares fantásticos de comunicação que facilitam imensamente a comunicação entre os intervenientes do projeto, mas o Manifesto Ágil defende que nada substitui uma discussão cara-a-cara. Solucionar problemas ou definir ações para resolvê-los na maioria dos casos é mais eficiente em reunião presencial objetiva do que troca de uma infinidade de e-mails ou mensagens inbox que são respondidas sem muita análise ou até priorizadas aquém da urgência merecida.
Outro ponto importante sobre interações entre os stakeholders do projeto que devemos salientar é que quanto mais os profissionais se relacionam, conversam entre si para valor no final de cada Sprint mais se sentem confiantes que estão no caminho certo e passam a confiar mais nos outros, criando ambiente ideal solucionar problemas, seus próprios conflitos e, principalmente, para o desenvolvimento do trabalho em equipe.
2) Software em funcionamento mais que documentação abrangente
O Scrum não orienta que deixem de elaborar documentação projeto, mas enfatiza que o produto funcionando exatamente como o cliente ensejou é mais importante que infinitas páginas de instruções de como o produto funciona ou um plano extenso de como o projeto será gerenciado. Essa abordagem fica mais evidente na Reunião de Revisão da Sprint.
3) Colaboração com o cliente mais que negociação de contratos
Significa trazer o cliente para acompanhar o desenvolvimento do produto, conhecer o planejamento, o que está em andamento e mostrá-lo de forma transparente o que ainda falta concluir. Traga-o para o seu lado (do lado negro da força ou dos jedis, depende de qual é seu clã), permitindo-o que colabore com o Time de Desenvolvimento, deixando-o a vontade para opinar.
👁🗨 Vale a pena destacar que permitir o cliente participar do processo de desenvolvimento não significa acatar seu julgamento quanto ao objetivo da Sprint, impor mudanças sem devida análise ou deixar que atrapalhe nas reuniões.
4) Responder a mudanças mais que seguir um plano.
De forma moderada todas as sugestões de mudanças, seja por parte do cliente seja pelo Time Scrum, devem ser sempre bem aceitas e tratadas imediatamente. Todas as mudanças devem ser analisadas se são pertinentes ou não, se aprovadas devem ser decompostas, priorizadas e planejadas para entrarem em futuras Sprints.
Quer saber mais sobre Scrum? Sugiro iniciar o Scrum Path+ Program - Curso de Scrum, através do botão abaixo:
コメント