segunda-feira, 15 de abril de 2013

Requisitos tóxicos - a responsabilidade é do time de TI

Referência: www.pc1news.com
Os requisitos tóxicos (toxic requirements) são requisitos captados na fase de desenho de um produto de software que comprometerão posteriormente o funcionamento correto do software. O comprometimento pode ser parcial, como uma degradação na performance de uso, ou total, impendido que o software cumpra o seu objetivo.

O exemplo clássico é o bug do ano 2000. Uma definição de armazenar datas com apenas duas posições para o ano, que parecia lógica e bastante razoável até o final dos anos 1980, era, na verdade, um requisito tóxico esperando para dar problema na virada do milênio.

Recentemente fui confrontado com uma situação onde o requisito era a transmissão de imagens em tempo real em um software que seria usado remoto sobre uma infraestrutura extremamente limitada. Esse seria um requisito tóxico em potencial, mas fomos capazes de convencer o cliente da limitação e o requisito não foi incluído. Neste exemplo havia uma boa relação de confiança entre o time técnico e o time de negócios, o que facilitou a discussão, mas, e quando isso não acontece?

Todos nós temos exemplos de requisitos tóxicos que não foram apontados. Seja por falta de força política do time técnico, seja por questões comerciais. E todos já vimos como essa história termina.

A responsabilidade de apontar e remover o requisito tóxico é do time técnico: do gerente do projeto, analista de requisitos, engenheiro de software, etc, e deve ser levada adiante por mais antipática que pareça aos olhos do cliente final. A alternativa é muito pior: seguir todo o projeto e entregar um software ao final que funciona parcialmente ou não funciona. Situação que termina em sérios problemas de desconfiança entre empresas e times, desentendimentos comerciais e, não raro, litígios.

segunda-feira, 21 de janeiro de 2013

Por que as empresas de engenharia de software não contratam apenas desenvolvedores de garagem?

Referência: Dilbert.com

A metáfora do desenvolvedor de garagem pode ser muito mais norte americana do que brasileira ou de outros países, mas a pergunta é válida e nós todos já a ouvimos de formas diferentes no início de projetos de tecnologia da informação:
- Por que vocês, que são profissionais de informática, vão levar 8 meses pra desenvolver esse sisteminha? Eu faço isso em um mês com excel aqui na minha área mesmo?
- Vai custar tudo isso? Com meu excel seria de graça...
Ou a minha forma preferida desta pergunta:
- Oito meses? Meu filho disse que faz isso pra mim em poucas semanas...
Todas estas perguntas são variações da pergunta: por que as empresas de tecnologia não mandam embora todos os seus engenheiros de software, analistas de sistemas, gerentes de projetos, etc, e contratam dois ou três adolescentes trabalhando em casa?

No livro The Mythical Man-Month, Frederick Brooks propõe uma resposta interessante a esta pergunta. O livro reuni uma série de ensaios sobre engenharia de software desenvolvidos ao longo da vida em corporações (ele foi o gerente do projeto do IBM System/360) e acadêmica. Vários dos ensaios são bem interessantes, sendo o melhor o que dá nome ao livro, mas alguns são bem datados e só servem como curiosidade histórica.

O que o Brooks argumenta sobre a questão deste post é que o desenvolvedor de garagem constrói o programa, ainda que bem feito e testado pelo próprio desenvolvedor (teste unitário), enquanto a engenharia de software entrega um produto de sistema, que deve incluir, além do programa inicial:
  • O código deve ser generalizável e manutenível;
  • Os testes devem ser, além do inicial, o integrado, o de aceitação pelo usuário e o de regressão (no mínimo, além de outros quando aplicáveis), com os scripts e evidências de execução e sucesso;
  • Documentação completa e "viva" tanto para o usuário final quanto para a equipe técnica; e
  • As interfaces devem estar construídas, testadas e documentadas.
Todas estas atividades e produtos elevarão, tipicamente (número do Brooks) em nove vezes o tempo e custo do programa desenvolvido originalmente, mas deverão trazer uma contraparte em qualidade.

Achei a resposta do Brooks interessante, mas nos leva a pensar se temos entregado todos estes produtos de forma clara e com qualidade, para que o cliente consiga ver o que compõe o tempo e o custo a mais.