Prefácio da segunda edição - Dos pequis aos bahs e tchês, passando pelas Cataratas do Iguaçu, por Carolina Borim

Posted on: sex, 05/10/2019 - 10:35 By: Aline Brod

Há muito tempo, quando ainda frequentava o colégio, aprendi que algumas convenções deveriam ser seguidas para a escrita de textos. Por não me considerar uma pessoa, digamos, convencional, peço licença ao meu amigo Cesar para deixar com que este texto siga seu próprio caminho, sem levar totalmente em conta tais convenções.

Vivi parte da minha vida em Goiânia, de onde sempre acompanhei o trabalho do Cesar Brod. Porém, nos conhecemos pessoalmente em uma das edições, não me lembro exatamente qual, da Conferência Latino-Americana de Software Livre, Latinoware, que acontece anualmente em Foz do Iguaçu.

Em um dos anos subsequentes, no mesmo evento, tive a oportunidade de me deparar com a primeira edição de seu livro de Scrum. Naquela altura, trabalhava, ainda em Goiânia, em uma empresa de desenvolvimento de software que vivia a tentativa do que eu hoje, carinhosamente, chamo de transformação ágil. Comprei o livro e deixava-o, de forma proposital, sobre a minha mesa. Várias pessoas que por ali passavam, paravam e o olhavam, folheavam e comentavam sobre o quão interessante o livro era. Estávamos sedentos por conhecimento sobre aquela metodologia que começávamos a implantar.

Tive a oportunidade de estar na equipe piloto, ou seja, a primeira da empresa na qual aconteceria a implantação do Scrum. Na época, fizemos inúmeros treinamentos e eu, particularmente, buscava aprofundar meu conhecimento na metodologia.

A leitura do Scrum – Guia prático para projetos ágeis era bem interessante, pois, permita-me fazer alguns trocadilhos, o Cesar trazia, de forma rica e ao mesmo tempo simples, a visão prática de diferentes conceitos teóricos e lineares que se adaptam e dinamizam o dia a dia de uma equipe de desenvolvimento. E, para as pessoas que conhecem o Cesar, ler o livro é como ouvi-lo contar pessoalmente o aprendizado e as experiências de sua trajetória profissional.

A adoção da metodologia não foi rápida e exigiu uma alteração completa de comportamento e pensamento. A organização viveu, durante 20 anos, imersa em um processo de desenvolvimento completamente Waterfall e o gerenciamento dos projetos era distante e inacessível, por parte das equipes. Porém, dia após dia, conseguimos ver a evolução do time.

Começamos a conhecer a nossa velocidade real. Nos reuníamos constantemente com nosso Product Owner para priorizar as funcionalidades em vez de simplesmente desenvolvê-las à nossa mera vontade. Principalmente: conseguíamos visualizar melhor o esforço necessário para terminar o desenvolvimento de uma funcionalidade. Literalmente entramos em uma fase de: “Stop starting, start ending” (pare de começar e comece a terminar) e não ficávamos mais eternamente presos em uma história.

Apesar de não gostar muito da palavra “cerimônia”, como um time e sempre juntos, seguíamos todas as que eram propostas pela metodologia. Repriorizávamos nosso backlog do produto, definíamos um backlog da Sprint, jogávamos as cartas, fazíamos Sprints quinzenais, reuníamo-nos diariamente em frente ao nosso quadro de tarefas, começamos a trabalhar em pares e, literalmente, nos tornamos um time autogerenciável e auto-organizado.

Tínhamos uma pessoa no papel de Scrummaster, o que foi algo bem interessante, pois era um alicerce, um líder-servidor. Não precisávamos mais de alguém para nos apontar tarefas a serem feitas. Como time, nos reuníamos e decidíamos quais histórias seriam desenvolvidas e em qual ordem, levando em consideração também as facilidades que cada um tinha para a rotação dos pares. O Scrummaster nos ajudava a balancear essas facilidades, a entender melhor o contexto no qual a estória estava inserida e, principalmente, desbloqueava as nossas dificuldades.

Foi, como citado anteriormente, uma mudança total na mentalidade da equipe. Começamos a valorizar mais a interação entre o time. A sensação é que, naquele momento, finalmente vestíamos a mesma camisa. Valorizamos mais as pequenas partes do produto funcionando, substituindo toda aquela documentação gigantesca que ninguém lia. O software era, de fato, a documentação viva do nosso trabalho.

Tínhamos a colaboração entre todas as partes interessadas no projeto. A mudança da mentalidade do time fomentou interesse de mudança em todos os stakeholders. Trabalhávamos juntos e respondíamos rapidamente às mudanças – conseguíamos avaliar de forma efetiva se estávamos entregando valor e realizávamos as alterações necessárias de forma dinâmica. Nos adaptamos e nos tornamos adaptáveis.

Claro que as coisas nem sempre foram fáceis. Era complexo levar ideias disruptivas para um ambiente solidificado em metodologias tradicionais. O “sempre fizemos nosso negócio assim” era um fator difícil de ser vencido. Pessoas que estavam na empresa há muito tempo viam a multidisciplinaridade como uma ameaça. Já outros acreditavam que o Scrum faria milagres e seria a bala de prata para todos os problemas da empresa.

Eram nesses momentos que tínhamos o suporte indireto de pessoas como o Cesar, que em livros ou em blog posts compartilhavam suas experiências, as quais, acredite ou não, eram muito parecidas com as que vivíamos. E conseguimos sucesso. Tivemos um produto de qualidade entregue. O time saiu com a sensação de dever cumprido. Já os clientes ficaram felizes e com um produto que, de fato, atendia às suas necessidades. Sucesso!

Em resumo: devemos aproveitar este livro como a ferramenta de compartilhamento do conhecimento que ele é. Ele apresenta a experiência do Cesar, trabalhando com diferentes equipes, ao longo de sua trajetória por vários projetos. É uma inspiração. É simples, prático e literalmente nos guia, mostrando caminhos, para que eles sejam escolhidos de acordo com a situação que encaramos no dia a dia ágil. E sem mais delongas, tomo emprestadas as palavras de Leonard Nimoy, que dizia: “O verdadeiro milagre é este: quanto mais compartilhamos, mais temos. Vida longa e próspera!”.

Comentar

CAPTCHA Nosso portal usa esse mecanismo para evitar spam.