Comments on: Rastreabilidade em User Stories

By: Ramon Oliveira

Ramon Oliveira — Fri, 29 May 2009 04:41:39 +0000

Olá. Vi este post e achei interessante o questionamento. Sei que já tem algum tempo, mas vai um case pessoal que fiz e que me ajudou muito nesse aspecto: ao longo da codificação, o programador insere @tags nos comentários javadoc das classes e em algums métodos “introdutórios de transações” (aqueles métodos principais que normalmente são os que mais geram necessidade de manutenção posterior). Estas tags são definidas através do framework xdoclet, e são parametrizadas com as regras do negócio e requisitos definidos pela análise, e que o programador vai aos poucos implementando na sua programação. Ao final, e posteriormente, de forma periódica, gera-se um artefato externo, em xml, com a identificação das classes e métodos que estão associados a determinadas regras e requisitos. Em seguida, faz-se o parser desse xml com um xslt qualquer, e tem-se uma página html com a matriz de rastreabilidade desejada, que pode ser publicada no wiki de documentação da aplicação, ou outro local.

By: Rubem Azenha

Rubem Azenha — Tue, 05 Aug 2008 19:16:34 +0000

Na verdade a princípio nenhum shoes, não tinha sacado a alternativa que você montou :)

By: Gustavo

Gustavo — Sat, 19 Jul 2008 21:58:40 +0000

Eu também nunca vi um documento de rastreabilidade atualizado. Acompanhar como especificações (testes, historias, UCs) são traduzidas em um design tem custo alto, mas o mínimo de rastreabilidade, talvez em uma abstração diferente como, por exemplo, serviços associados aos processos de negócio, pode ajudar gerenciar mudanças.

By: Phillip Calçado

Phillip Calçado — Sat, 19 Jul 2008 17:36:06 +0000

Mas, Rubem, qual o problema com a alternativa que eu apresentei? Ela não tem incompatibilidade com refactoring e a informação está sempre atualizada, não apenas “mantendo histórico”.

By: Rubem Azenha

Rubem Azenha — Sat, 19 Jul 2008 15:35:36 +0000

Isso na verdade é só uma forma de conseguir a tal de rastreabilidade se ela for realmente necessária no ambiente de desenvolvimento.

Um refactoring pode sim apagar um arquivo, mas o histórico do arquivo esta armazenado no SCM\version control.

Realmente não sei exatamente por que o cara que postou na lista dol XP-rio precisa de rastreabilidade.

By: Phillip Calçado

Phillip Calçado — Sat, 19 Jul 2008 03:03:06 +0000

Qual o benefício no final?

Você aaba introduzindo uma burocracia -criar uma ‘requisição de refactoring’- para algo que num time áil deve ser espontâneo e incentivado. Mais que isso: um refactoring pode fazer com que um arquivo anteriormente associado à uma história não o seja mais. Creio que esta opção seja não só excessivamente burocrática bem como ineficaz, já que não há como saber se um arquivo que na última iteração estava associado com uma história ainda o é.

By: Rubem Azenha

Rubem Azenha — Fri, 18 Jul 2008 13:35:40 +0000

@Shoes

“O ponto é que você sempre vai ter refactoring e (num ambiente sadio) nem sempre refactorin vai estar associado à uma história - da última vez que segui esta técnica usávamos o ID #000 para refactoring. Desta forma não há como saber quais histórias foram impactadas nestas mudanças.”

Hum… o que eu vou propôr não é a solução mais elegante, mas você pode consultar no SCM o histórico de alteração de um arquivo, pegar os comentários dos commits\links para as issues(ou Crs, ou bugs, etc…) e com isso verificar a quais stories o arquivo em questão esta “associado”.
Aí quando você fizer um refactoring, você pode criar uma uma issue(ou cr, ou bug, ou atividade, etc…) para aquele refactoring. Você pode cruzar os dados obtidos: os arquivos alterados pelo refactoring com as stories associadas com os arquivos alterados.

Aí vai depender muito de como se usa o de SCM e a ferramenta de tracking. Também criar uma issue para cada refactoring talvez não seja a coisa mais ágil do mundo, mas pelo menos você consegue essa rastreabilidade.

By: Phillip Calçado

Phillip Calçado — Fri, 18 Jul 2008 06:43:28 +0000

@Yoshima

Rodrigo, uma coisa é rastreabilidade do ponto de vista técnico outra coisa é gerência de escopo. O posto acima e a pergunta falam do ponto de vista técnico.

Para gerência de escopo existe uma disciplina enorme chamada Análise de Negócios. Creio que este seja outro assunto.

[]s

By: Phillip Calçado

Phillip Calçado — Thu, 17 Jul 2008 22:59:27 +0000

Rubem,

Eu acredito que utilizando o ID da issue no comentário de check-in temos algumas estatísticas bem interessantes, mas não acho que resolva o problema.

O ponto é que você sempre vai ter refactoring e (num ambiente sadio) nem sempre refactorin vai estar associado à uma história - da última vez que segui esta técnica usávamos o ID #000 para refactoring. Desta forma não há como saber quais histórias foram impactadas nestas mudanças.

Outra coisa importante é que histórias impactam em outras, assim se eu tive que mudar algo relativo à história X enquanto executava a história Y voc6e perde esta informação.

[]s

By: Juan Bernabó

Juan Bernabó — Thu, 17 Jul 2008 18:14:57 +0000

A gente já usou ferramentas UML (together) que geram a partir de um metodo um diagrama de sequencia ou colaboração, assim se usa um teste que mostre um cenario de uso, é so mandar gerar o diagrama a partir de esse metodo.

A geração dessa documentação era feita no ciclo de integração continua, assim alem da rastreabilidade tinhamos diagramas gerados apartir do codigo que estabam 100% sincronizados com a versão do software que estabamos mandando construir.

Essa foi uma das formas de entregar os artefatos requeridos pelo cliente continuando a ser ágil.

Abraços,
Juan