Atualmente é raro encontrar alguém que não reconheça os benefícios dos métodos ágeis de gestão desenvolvimento de software. Métodos ágeis têm sido utilizados por uma quantidade cada vez maior de empresas, pessoas e áreas. Além disso, eles têm sido adotados nos mais diversos tipos de projetos de desenvolvimento de software.
Apesar da existência de tal diversidade, geralmente as práticas ágeis são adotadas na íntegra, sem levar em conta particularidades relacionadas ao tipo do projeto e suas entregas. Age-se “by the book”, usando conceitos e ferramentas que não foram criadas para resolver os problemas que estão sendo enfrentados. É nesse momento que discussões e questionamentos internos e externos a uma equipe surgem, podendo colocar em xeque não só a gestão mas o trabalho da equipe.
Comecei a praticar métodos ágeis (Extreme Programming) entre 2002 e 2003, pouco antes de trabalhar como revisor do livro “Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade“. Desde então, tive a oportunidade não só de vivenciar diferentes situações, mas também pude estudar muitos casos como parte da minha pesquisa no Mestrado e no Doutorado na UFRJ.
Listei abaixo, alguns pontos curiosos ou que julguei serem relevantes ao longo dessa trajetória de praticante e estudioso de métodos ágeis, seja como Arquiteto de Integrações ou como gestor de equipes de desenvolvimento.
O que você entrega?
O SAFe utiliza o termo Potentially Shippable Increment (PSI). O Incremental Funding Method utiliza Minimum Marketable Feature (MMF). O LeSS utiliza o termo Potentially Shippable Product Increment. Outros usam Minimum Viable Product (MVP), User Stories, Features, etc. Seja qual for o nome, uma característica comum é que em todos eles o resultado do trabalho será entregue ao usuário final, seja com o objetivo de gerar retorno financeiro – como é o caso das MMFs – ou com o objetivo de melhor direcionar a visão do produto aprendendo o que realmente o usuário final necessita – como é o caso do MVP.
Em se tratando de entregas de uma equipe de Arquitetura/Integração, só deveríamos chamar de PSI, MMF, MVP etc, se o que estiver sendo desenvolvido for uma API com fins de comercialização. O mesmo se aplicaria no caso do setor público, para projetos de e-gov em que as entregas estejam relacionadas a Open Government Data. Isso por que, nesses casos, uma API pode ser considerada realmente como um produto, no sentido de algo que pode ser oferecido ao mercado para satisfazer um desejo ou uma necessidade.
Trata-se de um cenário bem diferente de integrações, APIs ou serviços (SOA) desenvolvidos com fins de integrar aplicações corporativas, por exemplo. Para esses casos, por exemplo, o Incremental Funding Method utiliza o termo Architectural Elements (AE). Tratam-se de entregas que, apesar de não serem capazes de gerar nenhum retorno financeiro, elas são pré-requisitos para que as que geram retorno financeiro (MMFs) possam ser desenvolvidas. Isso faz todo sentido se considerarmos que integrações, APIs e serviços tornam possível a execução de partes de um processo de negócio de forma mais eficiente.
Histórias de (qual) usuário?
Geralmente assisto apresentações, em congressos de desenvolvimento de software, sobre escrita de histórias. Por diversas vez ao final da apresentação perguntei: “E se o que está sendo desenvolvido é uma API ou um serviço (SOA), ou seja, não é algo que está em uma tela de uma aplicação, de um app ou de um site? Que ‘usuário’ eu coloco no nome da história ao escrever “Eu como <usuário>…“? Invariavelmente a resposta que ouço é para utilizar o nome do sistema que irá consumir a API ou o serviço.
Em um primeiro momento isso pode parecer satisfatório, mas depois de um tempo praticando essa recomendação, acabei percebendo que ela se tornou, digamos, chata. Por exemplo, em um dos projetos que trabalhei estávamos implementando mais de 70 integrações com um determinado sistema de gestão. Imagine você olhar o seu quadro diariamente e vê-lo tomado de histórias “Eu como sistema NomeDoSistemaDeGestão…“. Dependendo do nome sistema, se você usa Post-it, só essa parte do nome da história ocupará a metade do espaço do papel. Se você usa um sistema como o Rally ou Jira Agile, o mesmo acontecerá com os cartões ou issues. A consequência foi que simplesmente deixarmos de escrever essa parte no nome da história, passando a escrever apenas a parte do “o que fazer” e do “por que fazer/qual benefício“.
Uma evolução dessa abordagem seria identificar junto ao sistema de gestão qual o papel dos usuários que estão utilizando a funcionalidade acionou a requisição à API ou serviço. Então, seria utilizado nas histórias de integração esse papel, ao invés do nome da aplicação.
A história foi entregue ou está impedida?
Existem casos em que a API ou serviço é desenvolvida em paralelo ao desenvolvimento de consumidores e provedores. Por mais estranho que isso possa parecer, é possível. Trata-se da abordagem Contract First.
Nessa abordagem todas as partes envolvidas na integração acordam qual será a interface do serviço e iniciam seus desenvolvimentos usando Mocks. Quando todos estiverem prontos, faz-se um teste integrado.
Logicamente que essa abordagem pode levar a retrabalho em todas as equipes de desenvolvimento. Por isso, é importante acompanhar ao longo do projeto se ela está valendo a pena ou não.
Atenção especial deve ser dada à definição do Critério de Pronto das histórias. Isso por que se o critério exigir a comunicação com o(s) provedor(es), pode ser que sua história já entre no Sprint impedida, por ser dependente da entrega desses provedores e/ou da realização de um teste integrado.
Quem é o Product Owner?
Não é incomum ver equipes de desenvolvimento de arquitetura/integrações atenderem a vários projetos em paralelo. Nesse cenário em que a equipe presta “serviços compartilhados” dentro de uma organização, pode ficar difícil definir apenas um único Product Owner. Afinal de contas, como ter apenas 1 pessoa definindo requisitos, critérios de aceite e apoiando os cenários de teste de diferentes serviços de vários projetos ao mesmo tempo? Simplesmente esse é um cenário de gestão que não parece ser escalável.
Em cenários complexos como esse, uma opção é considerar os Arquitetos de TI, Arquitetos de Soluções ou Arquitetos de Integração, como sendo os Product Owners. Eles teriam a responsabilidade não apenas de escrever as histórias mas também validar as entregas feitas pelas equipes de integração. Essa abordagem tenho utilizado com sucesso há 100 (cem) Sprints (de 2 semanas cada)!
Que documentação deverá ser gerada (se é que alguma)?
Essa questão é bastante recorrente entre os praticantes iniciantes de métodos ágeis. Quando tal pergunta é feita, geralmente a resposta é “O método não diz que você não deve gerar nenhuma documentação” ou “Gere apenas a documentação necessária, que vai ser realmente utilizada“. Tudo muito genérico e superficial, o que não responde a pergunta.
No caso do desenvolvimento de APIs e serviços, existem pelo menos 3 “artefatos” que acredito serem essenciais:
- Um diagrama mostrando uma visão de alto nível sobre as partes envolvidas na integração (Ex: localização dos consumidores, middleware, provedores etc). Esse diagrama pode mostrar também algumas informações sobre a infraestrutura;
- Um mapeamento de dados para especificar como os dados enviados pelo consumidor serão tratados pela API ou serviço e enviados ao provedores (e vice-versa). Tanto esse mapeamento quanto o diagrama apoiarão o desenvolvimento da API ou serviço;
- Um guia de como a API ou serviço deverá ser utilizado. Isso inclui parâmetros de entrada e saída, informações no cabeçalho e corpo das requisições e respostas, códigos de status (HTTP) e respectivas mensagens. Uma dica para esse caso seria utilizar o Swagger.
Sobre esse último ponto, vale a pena ficar atento à iniciativa de unificação da Open API Initiavive – OAI.
Usar métodos ágeis em equipes que prestam serviços compartilhados e que não controem um produto (no sentido de algo que pode ser oferecido ao mercado para satisfazer um desejo ou uma necessidade) sem dúvida é um desafio diferente de utilizá-los quando todos estão voltados a um único e mesmo objetivo.
Seja qual for o método ágil que você utiliza ou como você chama as coisas que estão a sua volta, o importante é não perder a essência ágil representada pelo Manifesto Ágil. Seja qual for seu tipo de projeto ou entrega, o importante é não deixar de seguir os 12 princípios do Manifesto.
Para refletir mais sobre o assunto, recomendo a leitura do post “Do We Really Need Another Method?” de Ron Jeffries, um dos pais do Manifesto Ágil.
TaaS - Thoughts as a Service 