Sejam bem-vindos novamente, leitores! Após um período de ociosidade, o blog está de volta com mais uma sequência de artigos!
No dia 05 de novembro, tive a oportunidade (e a honra) de ser um dos participantes do evento Agile Brazil 2014, no qual, este ano, aconteceu na cidade de Florianópolis. Bom, para marcar o retorno das atividades do blog, não poderia deixar de elaborar um breve review deste evento, concorda? Continue lendo o artigo e descubra as ideias que foram transmitidas pelos agilistas!
Em primeiro lugar, gostaria de fazer um grande agradecimento à Softplan, em especial ao Julio Cesar Fausto, coordenador de desenvolvimento da equipe em que trabalho, pelo convite para participar do evento. Sem dúvidas, foi uma ótima experiência!
Joseph Yoder
O evento aconteceu no centro de eventos da ACM, nos dias 05, 06 e 07 de novembro. No primeiro dia, a abertura foi realizada pelo agilista americano Joseph Yoder, também fundador da The Refactory, Inc. “Joe” Yoder, como é conhecido no mundo ágil, destacou os vários motivos que geralmente levam os desenvolvedores a criarem código ruim, bem como apresentou técnicas para eliminá-lo.
Logo no início da apresentação, o que me chamou a atenção foi a analogia da janela quebrada (Broken window). Segundo Joe, não devemos, jamais, tolerar código defeituoso no software, ou “janelas quebradas”. Essa tolerância pode causar uma determinada influência ou conformidade entre a equipe, de modo que, ao “quebrar mais janelas”, ninguém tomará iniciativa. Aos poucos, a dívida técnica se tornará tão comum que será considerado natural. Como solução, Joe indicou várias técnicas, como Clean Code, Feature Envy e DRY, já abordadas aqui no blog.
Prosseguindo com a palestra, Joe disse algo que eu já observei há algum tempo, mas não encontrava um termo adequado para expressá-lo: a atividade de saneamento da código legado se resume basicamente em tradeoffs, ou “trocas”. Isso significa que, para pagar a dívida técnica de um código, algo terá que ser cedido, como se fosse uma negociação. Essas trocas são, na maioria das vezes, custo e tempo. Uma equipe ágil deve estar sempre ciente de que o saneamento da dívida técnica exigirá um aumento de custo ou redução das user stories em uma Sprint, portanto, essa “troca” deve ser definida de maneira minuciosa e estratégica.
Thiago Palma
Em seguida, decidi participar de uma palestra sobre refatoração e migração de código, apresentada por Thiago Palma. O palestrante, sobretudo, bateu na tecla da responsabilidade do desenvolvedor. A maioria dos softwares de grande porte, atualmente, possuem módulos antigos e pesados, passíveis de refatoração, porém, a perspectiva da equipe sempre é unânime: “Está assim há tanto tempo! Melhor não mexer, senão podemos quebrá-lo!”.
Segundo Thiago, essa é uma mentalidade de negação que deve ser transformada em iniciativa. Por exemplo, um membro da equipe pode começar com pequenas atitudes (ou small steps), como renomear uma variável ou um método e, gradativamente, dar passos cada vez maiores, ao mesmo tempo que influencia outros membros da equipe. A longo prazo, é provável que todos estejam no mesmo ritmo de responsabilidade, aplicando refatorações mais avançadas, como a criação de novas classes e a divisão de responsabilidades.
Após o almoço, me dirigi para a palestra sobre Automação, na qual foram apresentadas algumas ferramentas já populares, como o Jenkins (build contínuo), controles de versão e aplicativos para o gerenciamento do Kanban board (eu recomendo o Trello, embora não tenha sido mencionado na palestra).
Bruno Machado Soares
Logo após, acompanhei uma palestra bem interessante sobre Teoria das Restrições (Theory of Constraints) no mundo ágil, por Bruno Machado Soares. Me identifiquei com um das analogias apresentadas na palestra, que diz respeito ao equilíbrio entre “fazer” e “liberar”. O palestrante exemplificou que, em uma indústria, o setor de produção pode ser aperfeiçoado para produzir o dobro de produtos no mesmo tempo, porém, não fará nenhuma diferença se o setor de logística também não for otimizado.
De nada adianta aumentar a produção se as entregas continuarem as mesmas. E então, surgem as restrições. No desenvolvimento de software, é algo semelhante: não adianta, por exemplo, desenvolver uma quantidade maior de itens do Backlog se os testadores não irão conseguir testar e aprová-las. Restrições dessa natureza devem ser analisadas e solucionadas como parte de uma boa prática ágil, de forma que o sincronismo entre o que foi entregue esteja sempre em conformidade com o que foi estipulado.
Tissiane Nunes Costa
A quinta palestra foi relacionada à Engenharia de Valor, uma disciplina que, até então, eu não conhecia na prática. Tissiane Nunes Costa, da Ci&T, apresentou um framework que a empresa elaborou (baseado em planilhas e gráficos) para identificar itens de valor potencial para o Backlog, gerando resultados bastante objetivos. De acordo com os dados preenchidos da planilha (como os pesos e métricas), é possível cruzar o valor de negócio e o custo de cada user story. Por exemplo, uma determinada funcionalidade do Product Backlog pode apresentar um alto custo de desenvolvimento, enquanto representa um baixo valor de negócio. Neste caso, a equipe deve considerar fortemente a possibilidade de removê-la do Backlog.
Além disso, é necessário ponderar os itens de grande valor que já foram desenvolvidos. Isso implica que as empresas devem se concentrar no aprimoramento dessas funcionalidades ao invés de focar em novas implementações.
O mais interessante é que, conforme o valor que o software estiver agregando ao negócio, o investimento no projeto deve ser suspendido. Sim, isso mesmo! É algo que eu, particularmente, nunca havia considerado. Se o software já estiver em um estágio produtivo para o cliente, não compensa continuar alocando recursos humanos, tempo e dinheiro para implementar e disponibilizar itens de baixo valor que, na realidade, serão esporadicamente utilizados pelo cliente.
Rafaela Mantovani Fontana
Por fim, participei da palestra da Rafaela Mantovani Fontana, professora de Engenharia de Software na UFPR. Devo dizer que o assunto levantado também me deixou bem reflexivo! Rafaela apresentou as deficiências que podem ser encontradas em modelos de maturidade ágil (Mps.BR e CMMI), e idealizou uma nova forma de mensurar essa evolução: Progressive Outcomes Network. Neste modelo, ao invés de uma empresa atingir níveis de maturidade em escalas (como se fossem degraus de uma escada), o progresso é linear e independente de outras áreas, ou seja, e equipe de desenvolvimento, por exemplo, pode alcançar um nível avançado de amadurecimento mesmo que outras áreas ainda estejam fracamente “amadurecidas”.
De modo prático, como o próprio nome diz, é como um sistema de rede progressivo de aperfeiçoamento. Diferentes áreas atingem diferentes níveis de maturidade, por meio de critérios específicos e em prazos distintos. Ao meu ver, devido à categoria dessa ideia, a palestrante receberá um grande apoio da comunidade ágil.
Ah, antes que eu me esqueça, conheci a Cecilia Fernandes pessoalmente! Para quem não a conhece, ela é um dos membros da organização do evento Agile Brazil e instrutora da Caelum. Na época da faculdade, fiz uma entrevista com a Cecilia via e-mail como parte do survey que eu estava produzindo sobre Desenvolvimento Ágil, e recebi uma excelente contribuição. Uma parte dessa entrevista pode ser encontrada neste link.
Enfim, certamente, foi um ótimo dia de evento!
O Agile Brazil acontece em diferentes locais a cada ano. Se não me engano, em 2015 será realizado em Porto de Galinhas, Pernambuco. Se você mora por perto, participe!
Grande abraço!