Boas práticas de engenharia de software

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

Waterfall

Desenvolvimento iterativo

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.

Livro sobre gestão de produtos

Vc gosta do tema gestão de produtos de software? Quer se aprofundar mais no assunto? Escrevi um livro sobre o assunto, dividido em 5 grandes áreas:

  • Definições e requisitos
  • Ciclo de vida de um produto de software
  • Relacionamento com as outras funções
  • Gestão de portfólio de produtos
  • Onde usar gestão de produtos de software
Capa do Livro Gestão de Produtos

Esse livro é indicado não só para quem tem software como seu core business, como tb para empresas que desenvolvem software sob demanda e empresas que não tem software como seu core business mas usam software para se comunicar com seus clientes como, por exemplo, escolas, bancos e laboratórios clínicos.

Interessou? Então adquira sua cópia hoje mesmo!

Newsletter

Se você quiser receber artigos por email sobre startup, gestão de produtos e gestão de TI, digite seu endereço abaixo e aperte enter:


18 ideias sobre “Boas práticas de engenharia de software

  1. Desenvolver um software produto, no mínimo tem que ter essas e algumas outras boas práticas vindas do Scrum, XP (TDD, BDD, DDD,), Kanban (Quadro com post-it, Entrega contínua, programação em par, ambiente de homologação, etc) e sempre que possível aplicar o conceito de desenvolvimento Lean (Desenvolvimento de forma enxuta e simplificada) também.
    É claro que não é preciso colocar todos eles 100% na gestão do seu projeto, mas pelo menos utilizar alguns subitens de cada um deles, será um grande diferencial.

    Parabéns pelo post!

    • Oi Caio,

      É isso aí, a lista de boas práticas de engenharia de software é bem extensa mesmo! :-)

      Preferi ficar só nessas 3 (desenvolvimento iterativo de software, TDD e entrega contínua) pois acho que as 3 são a base para se obter uma velocidade de desenvolvimento alta, mas com qualidade e de forma sustentada. Quem se aprofundar nessas 3 vai se deparar com todas essas que vc falou e várias outras.

      Abs,
      Joca.

    • Apenas lembrando que DDD, TDD, BDD podem ser usados mesmo em cascata!

      No desenvolvimento em cascata você pode fazer teste unitário durante o desenvolvimento também.

      E o DDD não é restrito ao XP. Se vc olhar o DDD Quickly da InfoQ:

      “This book presents the principles of domain driven design,
      which when applied can greatly increase any development
      process’ ability to model and implement the complex problems
      in the domain in a maintainable way.”

  2. Joca,
    Ótimo post para relembrar na teoria o que buscamos no dia-a-dia e re-afirmar esta busca pelas melhores práticas e lembrar sempre que responder a mudanças é essencial quando trabalhamos com diversos projetos.

    Um dos pontos fundamentais para o sucesso do desenvolvimento iterativo de software é lembrar sempre que este “ciclo reduzido que é repetido várias vezes usando o feedback do ciclo anterior” deve conter o menor tamanho possível de uma feature completa, ou seja, dentro desta entrega iterativa ela deve conter a melhor experiência possível naquela pequena “porção”. Uma anologia a isto usando o exemplo do Jeff seria entregar o rascunho da Monalisa sem o rosto, pois para o cliente seria uma sensação de algo incompleto.

  3. Opa informações que saem um pouco da ideia da startup mas tem tudo a ver com os produtos desenvolvidos aparti dela ne, so fiquei com uma dúvida no caso a entrega continua como citada acima seria o perpetual beta que tanto tem se falado de alguns anos para cá?

    Pois o conceito é bem semelhante ne!

    • Oi Rafael,

      O perpetual beta é usado por desenvolvedores quando as features que eles colocaram em produção não foram devidamente testadas. Aqui estamos falando de colocar constantemente em produção software que foi devidamente testado, por isso não deve ser chamado de beta. Twitter, Facebook, Google, Slideshare, Linkedin e todos esses grandes provedores de produto web colocam novas features em seus produtos diariamente, até mesmo mais de uma vez ao dia. E essas features que eles colocam são features testadas, raras vezes entram em beta.

      Abs,
      Joca.

  4. Pingback: O que é um roadmap? | Guia da Startup

  5. muito interessante este post, sei que é antigo mas não pude deixar de comentar. os pontos levantados aqui são muito importantes, mas gostaria de ressaltar também as métricas. Acredito que é através delas que temos as informações necessárias para dizer que todas as boas praticas funcionaram.
    Eu tenho um blog com dicas sobre engenharia de software de como aplicá-las em empresas pequenas/startups, caso tenha interesse dê uma passada por lá: http://www.startqualityup.blogspot.com

    Obrigada

    • Oi Nathália,

      Excelente ponto, métricas são requisito mandatório para podermos avaliar a evolução e escolher a métrica certa é uma tarefa que requer atenção e cuidado.

      Obrigado pela indicação do seu blog.

      Abs,
      Joca.

  6. Pingback: TOP 10 2015 | Guia da Startup e da Gestão de Produtos de Software

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>