Inside the Manifesto

No post anterior falamos sobre o manifesto e princípios da cultura ágil. Vamos relembrar o manifesto:

Indivíduos e interação entre eles 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

“ah entendi, o negócio é só conversar, sem documentar e sem usar ferramentas, contrato é supérfluo e não precisa de planejamento. Gostei!”

Interpretações de texto ao pé da letra já renderam muitas guerras. É preciso adaptar o entendimento a realidade de cada pessoa e empresa.

Vamos lá:

Indivíduos e interação entre eles mais que processos e ferramentas

Toda empresa possui seus processos e ferramentas que os apoiam. Por exemplo, no início de um projeto de desenvolvimento, é feita a captação e análise de requisitos do projeto. Em seguida eles são documentados nos padrões que a empresa utiliza, gerando normalmente extensa documentação e diagramas.

Como este trabalho faz parte do processo e agrega valor ao projeto (e se não agrega precisa ser revisto), ele continuará sendo feito. O que é proposto é que as pessoas envolvidas na escrita e análise dos requisitos e as pessoas que fazem parte do time de desenvolvimento se reúnam e conversem sobre os requisitos, garantindo que todos os envolvidos tenham o mesmo entendimento de cada ponto. Isso aumenta a produtividade e gera menos retrabalho ao longo do projeto.

Software em funcionamento mais que documentação abrangente

Pegando o gancho do exemplo anterior, as documentações previstas no processo da empresa continuaram sendo feitas e se possível devem ser otimizadas. Mas de nada adianta centenas de páginas de documentação se o produto não agrega o valor esperado para o cliente, se é instável e complicado demais. Este ponto se apoia no princípio “Software funcional é a medida primária de progresso”. É o software funcionando como se deve que vai agregar valor ao cliente.

Colaboração com o cliente mais que negociação de contratos

Muitos entendem esta frase como “fazer o que o cliente quiser”. Não é por aí.

Trata-se de ser mais flexível no tratamento com o cliente sempre que possível. Obviamente que o contrato sempre vai permear a relação já que juridicamente é o que vale. Mas se é possível atender melhor uma necessidade e isso não vai causar prejuízo à empresa, porque não fazer?

Por exemplo, o contrato com o cliente estipula que o prazo de entrega é de dois dias úteis para corrigir um problema em ambiente de produção. Mas você sabe que determinado problema é mais crítico para um cliente e direciona outros esforços para resolver o quanto antes. Isso é colaborar com o cliente independente do contrato.

Um outro exemplo: é feita uma análise de requisitos para customizar uma nova funcionalidade. No meio do caminho o cliente solicita mudanças na interface com o usuário. Essas mudanças serão visuais, não demandando mais horas que o previsto. Ao invés de primeiro atualizar toda a documentação para depois fazer a alteração, só inverta a ordem. O cliente certamente ficará mais feliz com a postura mais flexível.

Responder a mudanças mais que seguir um plano

Ao contrário do que muitos pensam ao ler este item, é necessário muito, mas muito planejamento para se trabalhar com métodos ágeis.

O responsável pelo backlog, o Product Owner, deve planejar no mínimo duas iterações (sprints) a frente da iteração em curso. Isto para que os itens estejam transparentes para todos os interessados e que possam ser trabalhados de forma a estarem prontos para entrar na iteração planejada. Sem ter o planejamento prévio do que será feito a frente, não se pode aceitar uma mudança, pois não será possível avaliar o impacto nos itens já priorizados pelo próprio cliente.

Então, primeiro ponto: para que se possa responder a mudanças, é necessário muito planejamento.

Segundo ponto: solicitada uma mudança, deve ser feita uma avaliação em conjunto com o cliente para que ele possa priorizar o que mais vai trazer valor ao negócio. Feita essa priorização, avalia-se o impacto nos itens já planejados e decide a ação a ser tomada.

É claro que, se o projeto em curso for negociado em horas fechadas e a mudança aumenta o esforço, será necessária uma reavaliação dos custos. Não se aceita uma mudança que vai impactar nas horas só porque o cliente pediu, toda uma avaliação deve ser feita e para que ela seja rápida e certeira, é necessário muito planejamento prévio.

Contudo, se uma mudança solicitada pelo cliente não trouxer novos custos, como mudar a ordem de alguns itens por exemplo, isso deve ser encarado de forma natural por uma equipe ágil. Mudanças de rota são necessárias para que o projeto alcance o melhor retorno possível ao cliente. Lembrando o primeiro princípio, a satisfação do cliente é uma prioridade.

E afinal, a única certeza que se tem sobre desenvolvimento de software é que os requisitos vão mudar.

No próximo post começaremos a falar sobre SCRUM, da teoria à prática.

Até o próximo.

Assine nossa newsletter e não perca novas atualizações. Aqui

#agile #scrum #manifesto