Histórias de usuários

Histórias de usuários foram concebidas, no contexto de eXtreme Programming que faz parte dos métodos ágeis, para facilitar a extração de informações do domínio do problema, na fase inicial dos processos de desenvolvimento de software. A regra subjacente é extrair o máximo de informações sobre o problema, que somente vão estar disponíveis no mundo real. São muito utilizadas, muito exploradas, e muito já foi escrito sobre elas, não há novidades com relação a isso. Mas então, porque mais uma postagem? Na minha vida de professor, consultor e de interessado diretamente no assunto, vejo vários entendimentos e usos errados do conceito, deturpando a ideia original e levando a vícios de uso, misturando conceitos com a UML, pelo menos.

Histórias devem ser usadas apenas na fase inicial de contato com os atores identificados do sistema a ser desenvolvido. Na ideia original, atores do mundo real devem anotar em um cartão a sua atuação no sistema no mundo real, suas necessidades de informação, e como um novo sistema poderia facilitar sua vida. Tudo escrito de maneira informal, deixando as ideias fluírem sem pressão de tempo ou sem o formalismo de uma entrevista, o que poderia coibir os atores de descrever livremente o que acharem necessário informar. Os cartões são coletados, passam por análise,  voltam aos atores para esclarecimentos e para completar anotações importantes, como por exemplo procedimentos de exceção adotados e outras informações. Não é recomendável nesta fase inicial de conhecimento do problema o uso de conceitos e termos mais específicos do desenvolvimento, como por exemplo casos de uso, requisitos funcionais, não funcionais, restrições, sistema, banco de dados, etc. Isso fica para depois, relacionado a fases posteriores de desenvolvimento. São considerados erros comuns: -tentar derivar histórias de usuários a partir de um documento de especificação inicial, sem ir ao ambiente do problema e deixar os atores escreverem as histórias livremente; -exagerar no nível de detalhe, evitando contaminar essa fase com jargão e ideias de desenvolvimento; -histórias não constituem um artefato de desenvolvimento, são apenas uma ferramenta inicial de aquisição de conhecimento sobre o problema, e devem ser descartadas tão logo quanto possível; -histórias não são descrições de casos de uso, há várias diferenças entre ambos. O que vai ou não ser tratado como caso de uso é uma decisão posterior às histórias, já em um processo de análise e partindo para a especificação.

Talvez por conta do uso das histórias de usuários para extração de informações por parte da própria equipe técnica de desenvolvedores, que se encarrega de ir ao mundo real e de aplicar o conceito aos atores a serem atendidos pelo sistema, uma distorção importante e comum é já usar as histórias como artefatos de desenvolvimento, adicionando detalhes de desenvolvimento logo nos primeiros passos. Continuam usando o nome Histórias de Usuário durante o restante do processo, transformando-as em artefatos versionáveis (se tanto) gerenciados como um documento de desenvolvimento. Entende-se perfeitamente a distorção, pois empresas pequenas ou microempresas, com equipe de desenvolvimento reduzida e que trabalham com orçamento reduzido e baixa margem de lucro, não têm tempo disponível para duplicar esforços e gerar vários artefatos referentes talvez ao mesmo assunto, como manda o figurino. Mas é ilusão achar que essa queima de etapas vai funcionar, porque o objetivo principal e original das histórias, que é o de conhecer bem o problema e extrair do contexto o máximo possível de informações para subsidiar o desenvolvimento posteriormente, é perdido. E lá pelas tantas, equipe  já envolvida com desenvolvimento, aparecem detalhes que não foram esclarecidos devidamente no momento adequado, e ai começa a acontecer o desastre: alterações nos requisitos começam a ser solicitadas pelos atores, ou pela equipe de desenvolvimento. Vão percebendo que os resultados entregues não refletem o problema real, faltam detalhes, faltam exceções que deveriam ter sido relatadas e anotadas, e enfim, o esforço começa a aumentar, o orçamento vai para o espaço e seu planejamento, se é que existiu algum, vai pro lixo. E ai passa-se ao desenvolvimento estilo “salve-se quem puder”, sem controle de nada.

Ai é onde mora o perigo, e mesmo em microempresas com equipe reduzida, o conhecimento e uso adequado de métodos, processos e artefatos devem ser privilegiados. Por mais que pareça perda de tempo, em algum momento essa aparente “perda de tempo” reaparece cobrando seu preço muito mais alto. Quanto mais se avançar no desenvolvimento de um sistema, mais caro fica corrigir distorções e erros  introduzidos nas fases iniciais de extração de informação e de análise. Pelos resultados correntes da Engenharia de Software, pode ser até 100 vezes (ou muito mais) mais caro corrigir um erro de análise quando o sistema já estiver entregue e em uso. Boas práticas devem ser adotadas e usadas sempre, adequadas às necessidades de cada empresa e de seu nicho de mercado.

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Viçosa, MG)

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Marcado com: ,
Publicado em Engenharia de Software, Métodos ágeis, Qualidade de processo de software em Micro e Pequenas Empresas

Deixe uma resposta

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

%d blogueiros gostam disto: