Como aplicar princípios ágeis na sua startup: qualidade técnica

Como aplicar princípios ágeis na sua startup: qualidade técnica

Independente da metodologia escolhida, uma coisa é unânime em agile: as pessoas vêm antes da excelência técnica. Isso significa que o Desenvolvimento Ágil não se importa com qualidade? Não, não significa. É bem o contrário disso. A qualidade técnica deve andar junto com a satisfação do profissional.

É por isso que, antes de partir para as atividades de desenvolvimento, o time deve estar alinhado entre si, ter autonomia para decidir o que é importante para o projeto e fazer análises frequentes sobre si mesmos e sobre o trabalho que estão executando. Pessoas felizes trabalham melhor e chegam ao sucesso mais rapidamente.

Essas questões são levantadas pelo Manifesto Ágil. Pensando em facilitar sua vida na hora de entender e aplicar as premissas ágeis na sua startup, criei uma série de posts explicativos sobre os 12 princípios do Manifesto. Já falei sobre entrega de valor e comunicação.

Agora, encerro com os quatro princípios sobre qualidade técnica. Vem conferir e descobrir como eles se aplicam (ou podem ser aplicados) à sua startup!

A atenção contínua à excelência técnica e ao bom design aumenta a agilidade

Ter pleno controle ou noção de tudo que está acontecendo durante o desenvolvimento te ajuda a ter uma visão macro da situação. E, se você está ciente do que acontece, se você sabe por onde começou e para onde vai, consegue prever mudanças e se adequar a elas com mais agilidade. Medindo os resultados deliberadamente, você ganha em saber se, em algum momento, aquele detalhe que agora parece insignificante pode ou não virar uma bomba relógio.

Aplicamos esse princípio com frequência aqui na Aerochimps. Recentemente, aconteceu de mudarmos completamente o rumo de um projeto, despriorizar algumas funcionalidades menos urgentes para correr atrás do que era realmente essencial para o usuário. E só conseguimos fazer isso com certa agilidade porque o monitoramento foi e é contínuo. Percebemos a tempo que o retorno não seria compatível com o esforço e, por isso, era perda de tempo insistir.

Simplicidade — a arte de maximizar a quantidade de trabalho que não precisou ser feito — é essencial

Esse princípio é muito forte em startups e segue a linha do sistema de produção industrial toyotismo: produzir apenas o essencial. Ou seja, nada de estoques gigantes, de produzir sem pensar no amanhã — lembra do que acabamos de conversar ali em cima.

Enquanto o princípio anterior defende que é preciso estar atento a tudo, este outro acrescenta que é preciso pensar em curto e médio prazo também. Do que adiantaria produzir uma arquitetura super megalomaníaca se aquela funcionalidade só seria desenvolvida a longo prazo?

Existem várias formas de chegar a um objetivo, mas, no desenvolvimento ágil, a maneira ideal é aquela que se apresenta mais simples de ser feita, mais rápida de ser entregue e validada e que resolva o problema do usuário. Tudo isso sem perder o foco na qualidade e nos outros princípios.

A dica aqui é saber no que focar e não perder tempo com coisas menos importantes para o momento. O ganho dessa premissa aplicada é mais produtividade e tempo para trabalhar em outras coisas que você quer fazer, como desenvolver mais funcionalidades, por exemplo.

Isso ficou muito claro para mim quando o time de desenvolvimento da Chimps decidiu que um dos produtos que estávamos desenvolvendo precisava ser bilingue.

Com o objetivo estabelecido, passamos a produzir cada funcionalidade para ser disponibilizada em português e inglês. Depois de um tempo, percebemos que esse não era o melhor caminho e que estávamos perdendo tempo com algo que não era urgente e que poderia ser feito depois, quando entendêssemos melhor nosso usuário. E se nosso negócio se expandir primeiro pela América Latina? Nesse caso, a segunda língua deverá ser o espanhol e não o inglês.

As melhores arquiteturas, requisitos e projetos surgem de times auto-organizáveis

Muitas startups são reconhecidas por estabelecerem o ambiente ideal para o chamado “time auto-organizável”. Indo com muita liberdade, mas levando a responsabilidade junto, esse modelo de organização dá aos times autonomia para decidir o que fazer, como, quando e porquê fazer.

traditional VS agile team

Repescando um pouco dos outros dois princípios: se seu time sabe o que está acontecendo, se ele está preocupado em trabalhar só com o que for necessário e consegue projetar o resultado das suas ações lá pra frente, ele conseguirá tomar as decisões com mais facilidade e segurança do que uma pessoa alheia ao processo, que aparece apenas para dar ordens.

Além disso, é o time que vai saber que tipo de arquitetura é muito grande ou escalável para o projeto. Afinal, são pessoas que estão próximas no dia a dia, vivenciando o projeto, trabalhando com o mesmo propósito. Porém, é necessário uma disciplina muito grande do time para, além de produzir, analisar o que está sendo feito.

Por que, em modelos mais tradicionais, gerentes são necessários? Oras, porque, muitas vezes, as pessoas que estão diretamente envolvidas com o projeto não conseguem olhar para o todo para saber a evolução do que está sendo feito. O agile vai na contramão desse padrão e lança o desafio de produzir com qualidade e fazer pausas estratégicas para análises de percurso e resultados.

Em intervalos regulares, o time reflete sobre como ser mais eficiente, ajustando seu comportamento em função das observações realizadas

Esse princípio é, basicamente, a defesa do Sprint Review, uma reunião que acontece ao final de cada Sprint para levantar os pontos positivos e negativos do ciclo. A partir dessa conversa, o time avalia o que deu certo, o que deu errado e propõe melhorias para o próximo ciclo de desenvolvimento. Fazer essa avaliação ao final de cada sprint contribui para que o projeto mantenha o ritmo sustentável e que cada ciclo seja melhor que o outro.

Na Chimps, temos Sprints de duas semanas e Sprint Reviews ao final de cada um deles. Mas a duração do sprint e a quantidade dos reviews varia de acordo com a necessidade do time. O único cuidado que deve ser tomado aqui é para que essas avaliações não se tornem mais frequentes do que o desenvolvimento em si. Analisar demais e produzir de menos é um problema. Só produzir e não analisar o que foi feito também.

Esse princípio vai muito além da produtividade. Fazer observação desse tipo ajuda a entender melhor as pessoas que compõem o projeto: elas estão felizes com o que estão fazendo? Querem fazer outras coisas? Gostam desse jeito ou querem sugerir para o time outra forma de trabalhar?

Outro ponto importante é o papel do Product Owner (P.O.) nesse processo. O P.O. não deve dar ordens, ele tem que chegar às conclusões junto com o time.

Tivemos uma experiência interessante na Aerochimps que se encaixa nesse princípio. Prestes a lançar um produto, reunimos todo o time e o P.O. no escritório, conectamos o computador na TV e simulamos as ações do usuário dentro do sistema, forçando erros para ver se o software estava preparado. Naquele momento, a gente observou o que havíamos feito e definimos juntos o que precisávamos melhorar e o que tinha que ser refeito.

Esse exemplo é sobre como encontrar erros no sistema, mas também é sobre como provocar reflexões. Porque, ao perceber que poderia ter feito algo diferente para evitar erros, você guarda o aprendizado para aplicar nas próximas experiências.

**

E você, como aplica esses princípios na sua startup? Tem alguma dúvida sobre algum deles? Sugestões? Críticas? Exemplos? Comentários? Compartilhe suas experiências e questionamentos nos comentários! :)

Next Post:
Previous Post:
  • http://www.regexti.com.br Reinaldo Torres

    Grande Idmar, olha eu ai denovo rs.

    Tenho uma pequena dúvida referente a um ponto do seu artigo. Eu consegui enxergar muita coisa por já ter trabalhado por alguns meses com agile, mas tenho algo que não visualizei com muita clareza.

    Vou dar um exemplo hipotético, somente para ilustrar a ideia da minha pergunta que farei a seguir: Imagina que você acordou com o cliente que em algum momento, você adicionará mais de um idioma na plataforma. Porém como não é necessário no início você não coloca essa funcionalidade e não dá a devida atenção e não faz um planejamento. Quando chega no momento de fazer essa implementação, você vê que terá que alterar o sistema inteiro, gerando um enorme re-trabalho, por não ter preparado a arquitetura da plataforma quando levantou essa necessidade, afinal, não era algo prioritário. Concorda que se houvesse um planejamento vc poderia deixar uma estrutura pre moldada para quando chegasse o momento certo, você ganharia tempo, reduzindo o custo de produção?

    A dúvida é, quando faz um planejamento de um projeto ágil, você tem que olhar o projeto em um todo, gastar as sprints iniciais para montar a arquitetura e depois trabalhar ? Ou você vai planejando e arquitetando de acordo com que vai produzindo?

    Grande abraço e parabéns pelo artigo!

    Reinaldo

    • Pablo Weslly

      Reposta da pergunta grande Idmar ?

  • Pingback: Os principais conceitos ágeis explicados - Bizstart()