Como aplicar princípios ágeis na sua startup: entrega de valor

Como aplicar princípios ágeis na sua startup: entrega de valor

Quando ouvimos falar em agilidade, logo associamos a palavra a algum processo ou prática. Isso não chega a ser um problema, principalmente para quem utiliza métodos ágeis há algum tempo. Mas, às vezes, vale a pena voltarmos duas casas para entender por que escolhemos essa forma de desenvolvimento e o que podemos fazer para melhorar nossos processos.
manifestoagil_valores
Para quem está começando agora, os valores do Manifesto Ágil são a porta de entrada que conduz até os Princípios Ágeis. Quando entendemos esses princípios e descobrimos a origem das metologias fica mais fácil aplicar os conceitos.

Para te ajudar a entender tudo isso de um jeito bem descomplicado, resolvi fazer uma série de posts explicando cada um dos 12 princípios ágeis. A ideia é abordar os conceitos, trazer algumas práticas e mostrar como eles se aplicam (ou podem ser aplicados) à sua startup.

Você vai perceber que a ordem não é a mesma do site oficial e que a tradução foi livremente adaptada por mim. Tudo pra ser mais prático e divertido para você: prometo!

Hoje, vou falar dos quatro princípios ágeis sobre entrega de valor. Vem comigo?

Nossa maior prioridade é satisfazer o cliente com entregas frequentes de software em funcionamento

Muitos times que trabalham com tecnologia ainda têm o hábito de desenvolver o produto quase que completamente para só depois colocá-lo no mundo. Além de não ser uma prática sustentável, esse tipo de desenvolvimento pode levar recursos, tempo e dinheiro direto para o lixo.

Quer saber se o seu produto atende às expectativas do cliente e do usuário antes de ser “tarde demais”? Entregue pequenas partes dele para que as pessoas testem. O conceito de desenvolvimento iterativo e incremental cai como uma luva nesse princípio. O segredo é garantir entregas regulares de produto funcionando.

Além do mais, quando você “começa antes de estar pronto”, tem a oportunidade de gerar um buzz entre o seu público e de fazer com que seu produto fique conhecido antes de chegar à sua forma completa.

O Conta Azul é um bom exemplo disso. O software começou bem pequeno, com poucas funcionalidades, apenas para resolver problemas de fluxo de caixa. Conforme foi crescendo, novas aplicações foram adicionadas, até ficar robusto como conhecemos hoje.

Atualmente, o Conta Azul é um dos sistemas de gestão para micro e pequenas empresas mais conhecidos. Quem acompanhou essa evolução aprendeu quase que naturalmente a utilizar as novas ferramentas implementadas ao longo do tempo. O software cresceu tanto que os novos usuários contam uma equipe disponível para explicar como funciona cada uma das funções.

Consegue perceber como a aceitação de mudanças é muito maior quando o público já conhece o produto? Além de ser muito mais interessante do que um produto que nunca tem novidades, essa evolução contínua facilita o conhecimento do usuário sobre o sistema. É mais fácil começar a usar um sistema que cresce com o tempo, do que entregar ao usuário um negócio cheio de funcionalidades que ele nem sabe por onde começar.

Por isso, não tenha medo de colocar o produto no ar, mesmo que ele não esteja pronto. Na verdade, pronto mesmo, ele nunca vai estar. Mas certifique-se de que o que vai para o ar funciona perfeitamente. E não se esqueça de fazer um bom planejamento de entregas para manter seu cliente satisfeito! O que nos leva ao princípio seguinte…

Entregue software funcionando com frequência, em intervalos de semanas ou meses, dando preferência para períodos mais curtos.

Nem todas as entregas precisam ser, necessariamente, para o público (essas podem ser a cada três ou quatro semanas, por exemplo).

Mas as entregas em períodos mais curtos são muitíssimo importantes para que o time veja o produto evoluindo e se sinta sempre motivado com os resultados. Quando demoramos para ver o resultado de um esforço, o desânimo é inevitável.

Para você ter uma noção de como é isso na prática, vou contar o que fazemos na Aerochimps. Aqui, a gente segue todas as etapas de entrega. Quando finalizamos uma tarefa, testamos o que foi feito em um servidor local.

Se estiver tudo certo, testamos a parte do software construída em um ambiente igual ao que será acessado pelo usuário após a implantação (deploy). Nessa etapa, a já conseguimos avaliar os resultados e perceber como está a evolução do produto.

Nossos sprints (ciclos de trabalho) são sempre baseados em entregas funcionais em homologação. Às vezes, precisamos de dois ou três sprints para que aconteça um deploy. Só depois de concluir e aprovar todas as etapas com o cliente é que disponibilizamos a atualização para o usuário.

Abrace as mudanças de requisitos do projeto, mesmo que ocorram tardiamente. Os processos ágeis apóiam a mudança como uma vantagem competitiva para o cliente

Conhece o termo “pivotar”? Derivado do inglês to pivot (“mudar” ou “girar”), indica uma mudança radical no rumo do negócio. Essa é uma das formas mais drásticas de explicar esse princípio e, por isso, a mais fácil de ser entendida.
Na prática, funciona assim: digamos que eu decidi desenvolver um aplicativo de relacionamento focado no público idoso. Investi uma boa grana para divulgar meu produto, mas ele não deu resultados. Em vez de jogar fora tudo o que foi feito, eu abraço as mudanças e adapto o que já existe para resolver outro problema. Com o material que tenho eu posso, por exemplo, direcionar o app para outro público ou adaptá-lo para outra funcionalidade.

Pivotar pode ser uma vantagem competitiva porque você sai de um nicho que não possui o problema que você quer resolver e parte para outro que precisa da sua solução.

Mas é claro que existem maneiras mais simples de aplicar esse conceito, que não envolvem mudanças tão bruscas na estrutura do negócio. Quando eu mudo o planejamento para implementar sugestões do usuário ou do cliente, por exemplo. Ou ainda quando eu recebo novos requisitos. Para esses casos, manter um product backlog (lista priorizada de necessidades) pode facilitar a troca de itens a serem desenvolvidos e dar visibilidade ao que será removido do projeto com a entrada de novos quesitos.

Software funcionando é a primeira medida do progresso

E, para finalizar a primeira parte da série, vamos falar sobre uma das questões mais polêmicas e controversas do Manifesto Ágil. Polêmica porque toca num ponto sensível que é a documentação.

O Manifesto Ágil não é contra a documentação. O que torna essa questão delicada é que, ao contrário dos métodos tradicionais, as metologias ágeis não defendem a documentação como provas de que o projeto vai bem.

Só o produto em desenvolvimento é capaz, ele mesmo, de medir o redimento do time e a qualidade do que é entregue. Até porque o cliente faz parte do time e acompanha o processo.

Alguma documentação até pode ajudar a avaliar os resultados do time e contribuir para organização interna, mas não adianta de nada quando não condiz com os prazos de entrega.

Começamos a usar na Aerochimps uma ferramenta de gerenciamento de projetos chamada Taiga. Esse software gera um gráfico interessante que ajuda a enxergar o progresso do produto.

Gráfico de Burndown

Gráfico de Burndown

O cenário ideal para este gráfico seria a parte verde estar o mais próxima possível da linha cinza. Quando isso acontece, significa que o time está num ritmo de produção estável. Se está muito acima, revela que não conseguimos entregar o que foi planejado no tempo estipulado. E, muito abaixo, mostra que a capacidade de produção do time pode estar subestimada.

Se o time está muito rápido, é sinal que precisa pegar mais tarefas para entrar linha. Se está muito lento, mostra que é preciso pegar menos tarefa ou quebrar as tarefas que existem em pedaços menores para voltar para os eixos.

Eu indico essa ferramenta para times que estão começando a trabalhar juntos e ainda não se conhecem muito bem. Essa “documentação” se torna uma ótima forma de entender como anda o ritmo de produção dos times.

E você, segue quais desses princípios? Sente dificuldade em algum? Compartilhe suas experiências de aplicação e os desafios que você enfrenta ao adotar essas ideias! :)

Next Post:
Previous Post:
  • Reinaldo Torres

    Olá Idmar .

    Excelente post sobre desenvolvimento ágil e suas vantagens. Atualmente estou abrindo uma empresa na área de TI e pretendo trabalhar utilizando essa metodologia.
    Estou com algumas idéias sobre transparência e entregas frequentes com software funcionando etc. Tive o privilégio de trabalhar em uma empresa onde tive contato com essa metologia e achei muito funcional e sinceramente não gostaria mais de trabalhar de forma diferente.

    A grande dúvida seria. É interessante o cliente ter acesso somente ao produto final, ou seria interessante também o cliente ter acesso aos nossos registros de desenvolvimento do software (imagina a analogia de um restaurante onde um cliente consegue ver seus cozinheiros trabalhando e fazendo a comida através de um vidro). Acha que vale a pena ter esse tipo de transparência ? Ou somente as interações na semana apresentação.

    Meus parabéns pelo post

    Reinaldo Torres

  • Pingback: Como aplicar princípios ágeis na sua startup: comunicação - Bizstart()

  • Pingback: Como aplicar princípios ágeis na sua startup: comunicação | Startup SC()

  • Pingback: Como aplicar princípios ágeis na sua startup: qualidade técnica - Bizstart()