Sobre o autor

Eric Lemes de Godoy Cintra é um profissional da área de desenvolvimento de software. Estou sempre buscando compartilhar por aqui um pouco das coisas que aplico na prática ou que acho relevantes para entusiastas e profissionais da área de desenvolvimento.

Me interesso principalmente por orientação a objetos, C#, C++, Python, metodologias ágeis (Scrum, Lean, Kanban), métricas de código, automação de builds (MSBuild, ant e afins) e também automação de deploy.

Se quiserem entrar em contato direto comigo, será um prazer. Posso ser encontrado:

Peço por gentileza ao me adicionarem nas redes sociais que mandem uma mensagem avisando que me encontraram pelo Blog e gostariam de adicionar o contato. Como existem diversos profiles fakes, eu recuso pessoas que me adicionam sem avisar de onde me conhecem. Agradeço antecipadamente a compreensão.

Anúncios

2 comentários em “Sobre o autor

  1. Eric, li teu artigo sobre levantamento de requisitos e gostei bastante. Você deve saber que na maioria das vezes, no esquema de trabalho em fábrica, não temos muito contato com os desenvolvedores. Queria saber se existe (na disciplina de requisitos) algum documento formal que contenha apenas as informações (campos, filtros e regras) que devem ser buscadas/fornecidas, e que oriente a equipe de desenvolvimento, na construção de um webservice.

    Aguardo um breve retorno.
    Muito obrigada.
    Helena.

    1. Helena,

      Esse comentário está aqui a um tempão e eu não respondi. Desculpe.

      Confesso que eu busquei esse documento perfeito de requisitos um tempão da minha vida. Nunca achei literatura ou técnicas de descrição deles mais práticas do que as que eu descrevi no post sobre requisitos. A questão é que cada documento é um modelo. Um modelo sempre vai ser uma abstração, uma simplificação do que é a realidade, senão deixaria de ser o modelo e sim o próprio artefato final. Por exemplo, se uma maquete fosse tão perfeita como o prédio, não haveria razão para se fazer o prédio.

      Esse é o problema com software. Chegar numa boa definição de requisito pode ser as vezes mais que a metade do caminho de se fazer o software. É por isso que mais e mais, eu venho exercitando o caminho de requisitos num ambiente ágil (tem um post sobre isso), porque o importante do requisito ou de qualquer documento é comunicar o que fazer da melhor forma possível. Por melhor forma, entendo custo x benefício. Se fazer e manter os modelos é mais caro que fazer o software, não faz sentido.

      E infelizmente tem muitas empresas que ainda trabalham nesse modelo de que as pessoas se conversam através de documentos, e infelizmente é um modelo falido. Se você observar as grandes empresas de tecnologia que atingem resultados fenomenais (Google, Microsoft, Amazon, etc), elas se organizam em pequenos times autônomos, não em estruturas faraônicas que se conversam através de documento e contratam desenvolvimento baseado em hora homem (como se fosse uma commodity).

      Espero que ajude.

      Abraço,

      Eric

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s