Cinco frases que todo agilista deve ter na ponta da língua
Em quase seis meses trabalhando no gb.tech pude perceber como a cultura ágil é presente na vida de todos os colaboradores. Isto posto, alguns conceitos ágeis parecem tão atípicos que devem ser sempre reforçados.
Não se pode mensurar trabalho criativo em horas
O mundo tecnológico é inerentemente mensurável. Este é o principal motivo pelo qual pessoas da área de exatas têm muita dificuldade em compreender a estimativa de esforço em story points, uma medida agnóstica, sem grandeza definida.
Quando pensamos em um contexto operacional, o trabalho é facilmente calculável. Podemos medir a produção de um produto em determinadas unidades/hora, a construção de um prédio em pavimentos/dia, e assim por diante. No caso de um contexto criativo, onde é necessário um perfil analítico, medir e tentar padronizar este trabalho com o intuito de aferir desempenho e definir metas torna-se impossível.
Vamos a um exemplo prático: na Diretoria de Dados do Grupo Boticário utilizamos o BigQuery da plataforma Google Cloud como nosso Data Lakehouse. Em um projeto realizado em meados de 2021, um engenheiro optou por utilizar o Data Fusion— um serviço gerenciado da plataforma Google que administra pipelines de dados utilizando clusters temporários) — para realizar a ingestão de 12 tabelas provenientes de um SGBD(sistema gerenciador de banco de dados).
Quase um ano depois, o SGBD de origem foi reestruturado para melhor atender necessidades de integração do negócio. Em vista desta mudança, foi necessário realizar um projeto de sustentação para consumir os dados das tabelas que foram criadas após a sua reestruturação. Coincidentemente foram criadas 12 novas tabelas, o mesmo número de tabelas do consumo inicial.
Outro engenheiro de dados do time assinalou a tarefa para si. Mesmo conhecendo o trabalho que já havia sido feito anteriormente e tendo acesso ao código já desenvolvido, o engenheiro optou por realizar uma análise de tempo e custo sobre o código. Ele constatou que seria mais eficaz (e financeiramente mais viável) realizar a ingestão através de Cloud Functions — um ambiente FaaS da plataforma do Google para a execução de código através de funções como serviço — e assim o fez.
Se tentássemos medir ou padronizar o esforço realizado por ambos os engenheiros, qual seria o correto? Ambos tiveram o mesmo esforço pois consumiram o mesmo número de tabelas? O primeiro engenheiro teve mais esforço pois não sabia o que iria encontrar incialmente? Ou o segundo engenheiro teve mais esforço pela sua pesquisa e recriação do código?
A resposta correta é: nenhum deles. Note que estamos falando do mesmo número de tabelas, o mesmo sistema de destino, o mesmo time, a mesma empresa, os mesmos dados, a mesma origem de dados (e, se me permitem acrescentar, até a mesma versão do SGBD de origem). Não há distinção na entrada e na saída dos dados. Há diferença apenas no trabalho analítico e criativo de cada um, que levou cada engenheiro a realizar a entrega com formas de execução totalmente diferentes.
Você ainda pode não estar convencido e argumentar: "eu posso medir quantas horas cada um levou para terminar o user story, afinal, quem levou menos tempo foi mais eficaz". Mas será que realmente quem levou menos tempo foi mais eficaz? Como se mensura o tempo de pesquisa que levou o segundo engenheiro a testar os dois métodos e optar por reescrever o código? Como se mensura o tempo de pesquisa do primeiro engenheiro, que não conhecia a fonte de dados inicial? Se você definisse um padrão de x horas para que a ingestão fosse realizada, o desenvolvedor iria se dar o trabalho de realizar a pesquisa, ou iria apenas copiar e colar o código antigo para entregar a tarefa dentro do tempo estimado? Definir um tempo para o trabalho criativo é acabar com a criatividade do trabalho.
Todo o contexto acima nos faz voltar ao ponto central desta paragrafação: story points são uma representação agnóstica de grandeza que retrata a estimativa de capacidade de um time e apenas daquele time, pois foi o time — e somente o time — quem definiu a estimativa de esforço de cada user story com base no seu conhecimento, na sua capacidade analítica e na sua criatividade. É provável que ao longo do tempo e com mais conhecimento, o mesmo user story seja executado utilizando um esforço menor, aumentando a capacidade da equipe.
Vou repetir para você não esquecer: não se pode mensurar o trabalho criativo em horas.
O Product Owner é dono de um backlog, não de um time
O cargo de Product Owner (PO) traz a palavra "dono" na tradução literal do seu nome. Por uma série de fatores históricos da nossa sociedade é comum que os novos proprietários, ao assumirem este cargo, esqueçam que sua única propriedade é o backlog priorizado de um produto.
O time ágil deve ser auto gerenciável, sem uma liderança formal. O próprio time é responsável por dizer ao PO qual a capacidade de uma sprint futura, utilizando dados de velocidade das sprints passadas e levando em conta os planejamentos de férias, days off de membros do time, feriados e recessos. Comumente o Scrum Master pode ajudar o time nesta programação, mas é importante salientar que ele não deve fazer o papel de porta-voz da equipe, pois todo o time deve possuir voz ativa nas decisões.
Um anti-padrão relativamente comum é acreditar que, por ser dono do backlog priorizado, o PO pode assinalar tarefas e user stories para membros da equipe. Este é mais um comportamento de gestão funcional herdado de modelos de gestão de projetos obsoletos, que deve ser evitado a todo custo. Em um time auto gerenciável, o próprio time deve decidir quem vai executar uma determinada tarefa.
Preferencialmente, a primeira pessoa com capacidade disponível irá se assinalar para executar o user story do topo do backlog. Se não há espaço para o time se auto gerenciar, uma pessoa que não é especialista em determinado user story nunca terá capacidade para aprender novas habilidades, realizar shadowing e pedir ajuda para outros membros do time. Todos estarão sempre ocupados com execução de tarefas e não terão espaço para ensinar e aprender com os outros integrantes da equipe. A entrega que um time se compromete a realizar em uma sprint diz respeito ao time como um todo, não à cada pessoa da equipe.
Ao visualizar um board o PO deve se ater apenas ao que lhe diz respeito: a coluna intitulada "backlog priorizado". Outras atividades, como assinalar user stories, definir capacidade, estimar esforço, conduzir stand-ups, cobrar indivíduos pela entrega, não são atribuições do PO.
Uma história de usuário deve ser propositalmente insuficiente para sua compreensão
Esta é mais uma frase que inicialmente não parece trivial, especialmente em times disfuncionais onde há a centralização do "poder" do user story no Product Owner.
Na mesma linha do pensamento acima, quando um PO acredita ser o dono das histórias de usuário é comum que elas sejam escritas com um alto nível de detalhamento, onde há descrição, inclusive, da forma como o time de desenvolvimento deve executar o user story. Aproveito este momento para citar outra frase, um bônus no mesmo contexto: ao escrever uma história de usuário, não descreva funcionalidade, descreva a necessidade.
O user story deve ter detalhamento suficiente sobre o porquê de sua entrega e os parâmetros que serão utilizados para definir se aquela entrega foi atingida. Como ela vai ser executada funcionalmente deve ser uma decisão do engenheiro ou do desenvolvedor, através dos mecanismos criativos e analíticos que ele achar cabível.
A insuficiência na compreensão de um user story tem um objetivo ainda maior: gerar conversa. O Product Owner não é uma blindagem entre os clientes e os desenvolvedores — o time deve ter a capacidade e habilidade de se comunicar com os clientes e discutir as necessidades funcionais das entregas, fomentando assim o processo criativo de tomada de decisão na hora da sua execução. O time de desenvolvimento precisa aprender a linguagem de negócio, caso contrário a equipe nunca vai entender o propósito da entrega para o negócio.
Mudanças de escopo são bem-vindas
O pior projeto que pode ser entregue ao final de um ano é o projeto que foi especificado há um ano atrás. Mudanças de escopo fazem parte do dia a dia de um Product Owner e devem ser bem recebidas. Um projeto que foi especificado há muito tempo e não possui mudanças, normalmente significa uma de duas coisas:
- O negócio não tem interesse no projeto, portanto você irá gastar esforço e capacidade do time e não entregará valor;
- Na entrega final, seu projeto estará defasado em relação ao mercado.
O escopo do projeto é o alvo de entrega de valor para o cliente — alvo no qual o PO deve estar sempre de olho — várias sprints à frente do que está sendo executado atualmente pelo time de desenvolvimento. Uma mudança de escopo não significa que o produto terá que ser refeito, que exigirá mais capacidade ou que levará mais tempo para ser executado.
Aceitar a mudança de escopo significa recalcular a rota para ser mais assertivo no seu destino. Lembre-se: em um projeto, a única certeza é a mudança.
Num processo criativo saudável, não se sabe de quem foi a ideia
Engana-se quem pensa que metodologias de inovação como o Design Thinking são aplicadas somente na criação de novos produtos. Sua fase de ideação, por exemplo, pode ser utilizada para trazer novas ideias e dar maior liberdade ao time de desenvolvimento. Os dois pontos centrais de um bom brainstorming estão pautados na liberdade e na colaboratividade. Quanto mais pessoas pensam juntas e melhoram as ideias umas das outras, mais a ideia passa a ser da equipe como um todo, deixando de ser "a ideia do Fulano".
Em grandes empresas estas etapas podem parecer difíceis de ser executadas pelo engessamento de processos, especialmente aqueles associados à segurança da informação, mas não desanime. O brainstorming pode ser utilizado como forma de filtrar e sugerir melhorias de ideias e processos já pré-concebidos dentro do time.
Algumas frases deste artigo são de autoria de Rodrigo de Toledo, co-fundador e trainer da K21 — as frases foram reescritas sem perder seu propósito original.
