Vindo do mundo waterfall, o tema de hoje foi um dos que tive mais dificuldade em absorver, quando comecei a conhecer o Mindset Ágil. Em verdade, empresas estão acostumadas a formar pessoas presas a processos e documentos, que, muitas vezes, não fazem sentido algum. Assim, passamos para o Princípio Ágil de hoje, que diz:
O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
Não estamos mais preocupados com longos documentos (que ninguém lê). Estamos preocupados com software em funcionamento, feito por profissionais motivados em obter a satisfação do cliente. Desta forma, nada mais justo que dar mais importância às conversas cara a cara, certo?
Do ponto de vista do software em funcionamento, tirar uma dúvida pontual em uma conversa é mais rápido do que marcar uma reunião para discutir o problema, esperar a formalização ou até mesmo a nova versão da documentação.
Para atendermos a velocidade do mercado, é necessário trabalhar com agilidade. Isso não significa que virou bagunça e que nada precisa ser documentado e a área de negócios pode mudar de opinião a toda hora! Não temos nada contra documentação!
Pelo contrário, documentar é muito útil, para o time, para a área de negócio e para quem deverá tomar conta do software no futuro, depois que ele for para a produção.
Eu gosto muito do modelo wiki para registrar regras de negócio. O registro tem que ser simples e direto. Tem que dizer a que veio, pra que serve, sem rodeios.
Mas, antes disso, durante o desenvolvimento, temos uma iteração de duas semanas, onde temos que entregar valor ao produto ao seu final. Logo, não podemos esperar que uma documentação seja atualizada para que possamos prosseguir.
Neste tema, o quanto mais próximo estiver a área de negócio, melhor, mais assertiva e pontual será a conversação. Se o time tem acesso aos conhecedores do negócio, deixe-os interagir. Desta colaboração surgirá um software mais aderente com as necessidades do negócio.
Por definição, uma user story tem o seguinte formato:
Eu, como [ator], desejo [funcionalidade] para [valor agregado].
A forma como a implementação será feita é de responsabilidade do time; a história conta o que deve ser feito, por que e para quem isso é importante. O caminho que separa estes dois pontos é composto por regras de negócio.
Já vi user stories que escondiam, em um campo de observação, uma especificação técnico-funcional. Mais uma vez: não tente colocar o mindset waterfall no modelo ágil! Ninguém lê uma documentação extensa, sejamos razoáveis.
Quando você tem algo muito grande pra ler e seguir como um roteiro, é bem provável que você leia apenas uma vez e, durante a implementação, é provável que você coloque o que acha que leu, misturado com a sua interpretação pessoal, mais as suas experiências passadas.
Não tem como fugir disso! Quantos testes já voltaram por que existiam coisas especificadas (mesmo pequenos detalhes) e não foram implementados? E sempre você ouvirá “ah, eu esqueci…” ou “ah, eu tinha entendido que…”
Mas isso é normal! É humano! É muito chato desenvolver com um roteiro!
O trabalho de desenvolvimento tem que ser mais dinâmico, por isso, uma user story é curta: para que elas seja o início de uma conversa, de uma colaboração.
Lógico, é preciso muita maturidade! No mindset ágil, vamos esquecer o “jeitinho brasileiro”, que sempre acha uma forma de conseguir o que quer. aqui, não cabe querer levar vantagem! Temos que ser transparentes. Se eu esqueci de falar algum detalhe importante, diga! Não tem que colocar as coisas por debaixo dos panos! A palavra de ordem é confiança!
Não existe espaço para, por desconfiança, esperar uma formalização ou atualização de documentos para prosseguir o trabalho.
Lembrem-se: todos compõem um time e todos devem caminhar na mesma direção: a direção da entrega de valor ao produto, ao final da iteração.
Então, que tal pegar dois cafés e ir até a mesa do responsável pela regra de negócio? É mais divertido! É mais humano!
Esse foi mais um artigo da série sobre os Princípios Ágeis! Aprenda mais sobre oMindset Ágil, participando do Agile Trends, um evento sobre agilidade e gestão, altamente inovador e interativo. Inscreva-se aqui! E continue ligado no Agile Momentum para os outros artigos da série!
[…] Mas isso não significa que ele precisa tomar pra si o papel que é do Product Owner! Certa vez, escrevi que “uma user story é um convite para uma conversa” entre o time e o Product Owner. O […]
CurtirCurtir
[…] Mas isso não significa que ele precisa tomar para si o papel que é do Product Owner! Certa vez, escrevi que “uma user story é um convite para uma conversa” entre o time e o Product Owner. O Scrum […]
CurtirCurtir
[…] Mas isso não significa que ele precisa tomar para si o papel que é do Product Owner! Certa vez, escrevi que “uma user story é um convite para uma conversa” entre o time e o Product Owner. O Scrum […]
CurtirCurtir
[…] Mas isso não significa que ele precisa tomar pra si o papel que é do Product Owner! Certa vez, escrevi que “uma user story é um convite para uma conversa” entre o time e o Product Owner. O Scrum […]
CurtirCurtir