About

Eric Lemes de Godoy Cintra is a software developer. I’m always trying to share a bit of the stuff I end up using on a daily basis and I found relevant for enthusiasts and professional developers.

I’m interested in software design, C#, C#, C++, Python, agile methodologies (Scrum, Lean, Kanban), code metrics, build and deploy automation.

If you want to contact me directly, I can be found:

I kindly ask who adds me on social network that sends a message telling that you found me through this blog. Since there are a lot of fake profiles, sometimes I don’t accept real profiles by mistake.

Advertisements

2 thoughts on “About

  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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s