Claro que não adianta você saber exatamente o que vai fazer na versão mínima de seu produto web se você não tiver um ótimo time de desenvolvedores de software e designers de interface do usuário. Só que ter pessoas bem qualificadas por si só não resolve. É preciso que essas pessoas trabalhem usando as melhores práticas de engenharia de software. Vou comentar um pouco sobre algumas dessas práticas aqui, apesar de esse não ser o foco principal deste blog.

Desenvolvimento iterativo de software

A primeira boa prática que quero comentar aqui é o desenvolvimento iterativo de software. Essa forma de desenvolvimento se contrapõe ao modelo de desenvolvimento de software conhecido como waterfall. No desenvolvimento waterfall as fases de desenvolvimento de software são claramente definidas e, uma vez terminada uma fase e iniciada a outra, não se pode voltar atrás. Por exemplo, se você quer desenvolver um produto web, no desenvolvimento waterfall você precisa especificar absolutamente todas as funcionalidade que você vai querer nesse software, pois o desenvolvimento de software é visto como um projeto com começo, meio e fim que acontece em sequência: definição de requisitos, detalhamento e especificação do software, codificação, teste e produção. Já no desenvolvimento iterativo de software, esse mesmo ciclo é reduzido ao seu menor tamanho possível e repetido várias vezes usando o feedback do ciclo anterior para melhorar o próximo ciclo.

Jeff Patton, reconhecido consultor de desenvolvimento de software, fez uma comparação entre waterfall e desenvolvimento iterativo de software fazendo uma analogia com o processo de pintar um quadro. Qual dos dois processos abaixo parece ser mais natural?

Waterfall

Desenvolvimento iterativo

Esse processo de desenvolvimento iterativo de software acabou sendo uma das bases do Manifesto para Desenvolvimento Ágil de Software, escrito há mais de 10 anos, que acabou se tornando uma revolução na forma de se fazer software:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Esse manifesto melhorou em muito a forma como software é desenvolvido, garantindo maior envolvimento da pessoa que define como vai ser o software durante o desenvolvimento desse software.

A partir desse manifesto alguns processos de desenvolvimento de software foram criados de forma a permitir esse envolvimento. Uma das recomendações que veio como consequência do manifesto é os times que desenvolvem software devem se reunir periodicamente para definir o que fazer e para acompanhar o andamento do projeto. Nessas reuniões participam não só os desenvolvedores de software como também as pessoas que definem “o que” e “como” será o produto web. O “o que” é definido pela função de gestão de produto e o “como” é definido pela função de experiência do usuário, funções descritas no post Quem deve criar uma startup de um produto web?. Essas reuniões frequentes são fundamentais para garantir a velocidade de entrega do produto mínimo.

TDD

Outra boa prática muito importante é o TDD (Test Driven Development ou Desenvolvimento Baseado em Testes). Por meio dessa prática se garante não só a qualidade do software que está sendo desenvolvido, uma vez que todas as suas funções têm testes para garantir que o que foi desenvolvido está funcionando conforme esperado, testes esses preferencialmente automatizados, como também aumenta a segurança para futuras modificações nesse software. Quando seu software tem testes, você pode adicionar novas funcionalidades e, por meio dos testes, garantir que o software continue se comportando conforme esperado em todas as situações previstas e cobertas pelos testes.

Entrega contínua

Ter essa cobertura de testes é fundamental para poder executar a terceira boa prática que eu queria comentar, a entrega contínua. Entregar continuamente o software significa ter a capacidade de colocar seu software em produção a qualquer momento de forma simples. Você só poderá fazer isso se:

• tiver cobertura de testes para garantir que o software que você colocou em produção está fazendo o que se espera dele e;
• tiver uma forma simples e rápida de voltar atrás, ou seja, se der algum problema com o software que você acabou de colocar em produção, você é capaz de restaurar a versão anterior do seu software em produção.

Ter entrega contínua é muito importante para que você possa, após ter seu produto web funcionando e com usuários, fazer rapidamente modificações nesse seu produto web baseado nos feedbacks que você receber desses usuários.

Como disse acima, quis incluir aqui no blog um rápido comentário sobre as boas práticas de desenvolvimento de software mas eu recomendo que, caso você não tenha ouvido falar dessas práticas, procure conhecer mais lendo blogs, indo a cursos, lendo livros e participando de eventos sobre desenvolvimento de software.

Recapitulando: fazer rápido o produto web = saber o que fazer + boas prática de engenharia de software

Por melhores que sejam os desenvolvedores e os designers de interface que trabalharem no seu produto, se você não escolher com muito cuidado que funcionalidades colocar e não selecionar um conjunto mínimo de funcionalidades, as chances de você desperdiçar tempo de desenvolvimento são muito grandes. A definição clara de seu produto mínimo é fundamental, e você só vai conseguir fazer isso conhecendo bem o problema do seu cliente e sabendo exatamente o que você está resolvendo para ele. Além disso, mesmo os melhores profissionais com a mais clara definição do que vão fazer precisam de boas práticas de desenvolvimento de software para poder desenvolver com rapidez um produto web de qualidade.