Vivemos uma era onde a tecnologia deixou de ser apenas entretenimento, para se tornar parte de nossas vidas. Aplicações como Waze, Uber, Bolt, Outlook, Gmail, WhatsApp, Spotify e Apple Pay se tornaram essenciais em nossas rotinas, mas para essas aplicações se tornarem tão efetivas a ponto de fazerem a diferença em nossas vidas foi necessário que tais empresas entendessem as “dores” da sociedade, para assim direcionarem tempo e recursos para que essas aplicações fossem desenvolvidas.


Foi necessário algo fundamental em todo este processo: comunicação. É exatamente nisso que nos focamos hoje, em como a comunicação influencia o ciclo de vida de um software e contribui para um desenvolvimento Agile.


Antes de mais, é importante entendermos o que é a comunicação no seu estado mais puro. A comunicação nada mais é do que o processo de troca de informações entre dois ou mais indivíduos. Para que uma comunicação seja feita com sucesso, o segredo está na forma como a outra parte recebe a informação, o que resulta da clareza com que é transmitida – quanto mais clara, simples e detalhada, mais fácil será de interpretar e assimilar.

 

 

 

Como aplicar a comunicação ao desenvolvimento de software?

Já entendemos o que é a comunicação, mas resta a dúvida: se esta é a base para o desenvolvimento Agile de software, então porque alguns produtos não fazem tanto sucesso como outros?


Claro que existem muito fatores para o sucesso, ou fracasso, de um produto, mas o facto é que os softwares que atingem o topo e se tornam referência, como os que citei no início, souberam aplicar (e muito bem) a comunicação ao longo do processo de desenvolvimento.


Esta forma de atuar vai muito além de reuniões diárias ou de uma cerimônia de refinamento – é necessário ouvir o que o cliente espera, ouvir a concorrência e assim colocar as ideias em prática.


Este processo parte do grau de interação entre cada membro da equipe e, principalmente, entre os personagens-chave, cuja responsabilidade é garantir que cada membro entende o que deve ser feito e como deve ser feito.


O segredo não está no que se escreve, mas sim na forma como a informação chega ao seu destinatário. Especialmente na área de desenvolvimento, por atuarmos muitas vezes de maneira remota, é fundamental garantir que o outro entende aquilo que deve ser feito, por isso deve ser privilegiada uma comunicação constante e detalhada.

 

 

Personagens-chave

Para que exista uma comunicação eficaz ao longo do desenvolvimento de software, são essenciais os seguintes intervenientes:

  • Product Owner (PO)
    É quem deve entender o que os clientes necessitam e porque necessitam de tal funcionalidade. A partir daí, deve coletar informações precisas e detalhadas – quanto mais informação, melhor.

  • Business Analyst (BA)
    Assim como o PO, também precisa entender o que os clientes esperam e é sua responsabilidade integrar a dimensão de negócios com a dimensão técnica de desenvolvimento. Parte do BA a criação de casos de uso, sendo que quanto maior for o entendimento e a clareza na escrita de cada caso e dos seus passos, maior será a assimilação por parte dos developers, o que irá garantir um desenvolvimento extremamente alinhado com as expectativas do cliente.

  • UX/UI Designer
    É o “mago” que começa a dar vida aos sonhos. Parte dele a criação de protótipos que garantam a marca e a identidade do produto, além de apresentar algo agradável, inovador e marcante na experiência do cliente. É nesse ponto que o cliente se encanta, seja pela simplicidade e inovação, seja pela facilidade de utilizar o software.

  • Especialista em Quality Assurance (QA) / Tester
    Executa um dos papéis mais importantes neste flow, que é o de garantir um produto com o mínimo de erros possível, através de testes que visam simular como o cliente pensa nos mais diversos cenários, seja de forma manual ou automatizada. O QA é aquele que, após uma longa e extensa bateria de testes, pode dar o veredito sobre se o produto está pronto, ou não, para chegar à mão do cliente.

 

Além destes personagens principais, não poderia deixar de citar também os Developers de Back-end e Front-end, os Arquitetos, os Site Reliability Engineers (SRE) e outros mais, que atuam nos bastidores e impõem, com base nas informações transmitidas pelos membros acima, seu background tecnológico para garantir aplicações leves e rápidas.


Veja que o processo de desenvolvimento de software vai muito além de ouvir o cliente e logo desenvolver – é necessário passar por alguns “filtros” que buscam explorar possibilidades para que o produto supere as expectativas dos clientes e, para isso, a comunicação precisa de ser a mais simples e clara possível.

 

 

Metodologia e processos Agile

Muito bem, já vimos quem são os personagens e agora precisamos entender como “conectá-los”. Para isso, precisamos abordar uma metodologia extremamente eficiente e bem conhecida no mundo do desenvolvimento de software: o Manifesto Agile. Trata-se de um documento que, ao longo dos anos, se tornou a bíblia do desenvolvimento Agile e que é sustentado por quatro valores essenciais:

 

  • Indivíduos e interações acima de processos e ferramentas
    Manter a comunicação ao longo do processo de desenvolvimento de software é extremamente importante para diminuir possíveis problemas e aproximar as pessoas. Ferramentas e processos são importantes, mas devem ser usados de forma pragmática.

  • Software funcionando é melhor que documentação abrangente
    Um software em pleno funcionamento é bem mais importante do que seguir à risca o que está no planeamento, até porque um software funcionando e sem erros é o melhor indicativo de que foi realizado um excelente trabalho. Os clientes pagam pelo resultado e não pelo bem elaborado plano que pode nunca vir a sair do papel.

  • Colaboração com o cliente acima da negociação de contratos
    O cliente deve jogar no nosso time e sempre como titular. O propósito desta relação é a colaboração, pois assim como uma equipa joga em prol de um objetivo comum, também nós devemos fazer com que nossas decisões estejam inteiramente alinhadas com os objetivos do cliente.

  • Responder a mudanças ao invés de seguir um plano
    Utilizar os feedbacks recebidos durante o processo, junto com a análise do cenário, são pontos essenciais para darmos respostas rápidas sobre o rumo das operações envolvidas. Porém, isto não nos isenta de termos um plano, que deve estar pronto para toda e qualquer mudança.

 

Dentro da metodologia Agile, temos diversos frameworks que nos auxiliam neste processo de desenvolvimento mais fluido. De entre eles destacam-se: 

 

Scrum

Com um nome derivado dos conceitos de equipe de rugby, o Scrum é uma abordagem que auxilia na estruturação da equipa, definindo papéis e comportamentos através de seus três artefatos: o backlog do produto, o backlog do sprint e o incremento do produto. Brevemente explicando:

  • Backlog do produto
    É a lista dinâmica de funções, requisitos, ajustes e correções que atua como um preview para backlog do sprint.

  • Backlog do sprint
    Antes de mais, sprint é o termo utilizado para definir o ciclo de desenvolvimento do produto, que geralmente é de 30 dias, sempre com o objetivo de entregar algo que agregue valor ao cliente. Assim, o backlog do sprint é a lista de entregáveis – casos de uso e correções de bugs – selecionada pela equipe para serem entregues no decorrer do sprint.

  • Incremento do produto
    Muitas vezes identificado como “Done” (ou “Concluído”), o incremento é o que foi finalizado e está pronto para a próxima release do produto.

 

Para que todo este processo funcione, é necessário que alguns ritos – conhecidos como “cerimônias” – sejam realizados, de forma que todas as “engrenagens” estejam alinhadas e em perfeito funcionamento. De entre as cerimônias temos: Planning, Daily, Review e Retrospective:

  • Planning
    É a reunião em que todos os personagens citados anteriormente se reúnem para definir os itens a serem trabalhados ao longo do sprint, baseando-se nas prioridades de cada item.

  • Daily
    São encontros de 15 minutos que acontecem todos os dias da sprint corrente. A ideia é discutir o progresso, impedimentos ou qualquer outro ponto que possa afetar a entrega.

  • Review
    É uma reunião onde todos os membros apresentam o que foi realizado no último ciclo e, com base no veredito do PO, é oficializado o que entrará na lista do próximo review.

  • Retrospective
    É o momento em que o time se reúne para analisar os pontos positivos e negativos que ocorreram no último ciclo de desenvolvimento e, a partir daí, seguir com melhorias.

Kanban

Metodologia que também faz parte do universo Agile e tem como objetivo monitorizar e controlar o processo de desenvolvimento. Com esta abordagem podemos acompanhar o status de cada tarefa e garantir a eficiência na entrega, visto que cada personagem pode atuar na mesma tarefa em momentos diferentes


Uma excelente ferramenta para o Kanban e amplamente utilizada é o Jira, que facilita todo este processo e ainda garante outros benefícios como o suporte a testes automatizados, controle de CI/CD (Continuous Integration/Continuous Delivery), entre outros.


O fluxo de trabalho Kanban funciona da seguinte forma:

  • Com a definição de stages (fases) para determinada task (tarefa), e após a criação dos requisitos por parte do BA e dos mockups criados pelo UX, a tarefa sai do backlog e passa para o estado por “Em desenvolvimento”, onde atuam os developers back e front-end;
  • Segue depois para o estado “Em Testes”, onde os QA realizam a bateria de testes;
  • Por fim, chega a “Finished”, onde após a review o PO pode mover para “Done” tudo que estiver conforme esperado e pronto para ser implementado.

 

Apesar de este processo parecer um tanto moroso, vimos que ele é bem detalhado e que faz com que todos os membros do time interajam. Isto facilita o entendimento do que está sendo feito, além de permitir saber o status dos entregáveis e garantir que a cada novo sprint o time esteja mais forte e preparado, baseando-se nos feedbacks da retrospetiva.

 

 

Conclusão

Ao longo deste artigo vimos como uma comunicação bem clara e precisa pode influenciar o bom e rápido desenvolvimento de um software. Vale lembrar que a interação precisa de ser constante ao longo de toda a construção de um software (como prega a metodologia Agile), sendo que quanto mais fácil for de interpretar, melhor será o resultado e a entrega.
Partilha este artigo