Me ajudem no seguinte, no processo unificado, espera-se que todos os casos de uso gerem algum tipo de artefato dentro do projeto. Na verdade, com os casos de uso espera-se chegar em classes que juntas formarão o sistema. Dentro da metodologia existe artefatos que quando feitos, permitem mapear todos os artefatos gerados a partir de um caso de uso. A matriz de rastreabilidade.
Gostaria de saber como o XP permite chegar as classes (código) a partir das User Stories. Por exemplo, dado uma User Stories, quais são as classes geradas para atender essa User Stories?
O XP permite isso? Como é feito?
Provavelmente a primeira coisa a se perguntar é: por que eu precisaria deste dados? Alguns modelos de processo como CMMI definem rastreabilidade, que geralmente é definida nesta linha:
Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)
- Gotel O.C.Z and Finklestein A.C.W (tirado da Wikipedia)
A necessidade parece justa e real, é preciso saber quais partes do software são afetadas por mudanças no negocio e vice-versa. O grande problema desta métrica é que transformações de modelo não são mais tão drásticas há algumas décadas. Ao utilizar qualquer tecnologia relativamente comum (Java, Ruby, .Net, Python, JavaScript…) não existe motivo técnico para que o software não modele o negocio em uma relação próxima de 1-para-1, desta forma saber qual parte de um código realiza qual tarefa torna-se bem simples.
Outro problema é que eu nunca vi um artefato de rastreabilidade, seja qual for, que não ficasse defasado. Se você abraça uma metodologia ágil sabe que refactoring faz parte da vida.
Mesmo com todos os problemas que esta métrica possui eu entendo que existem casos onde seu uso se faz necessário –especialmente por equipes tentando introduzir agilidade em ambientes tradicionais. Supondo que exista uma necessidade justificável para algum controle deste tipo, metodologias ágeis em geral possuem um mecanismo muito mais eficiente que documentos ou mesmos sistemas: testes.
Toda história, todo cartão, deve ter um critério de aceite. O critério de aceite traz o que o cliente considera ser o mínimo para que a história seja considerada concluída. Por exemplo:
História: Como administrador eu quero criar um novo grupo para que possa aplicar permissões à diversos usuários de uma só vez.
Critérios de Aceite:
- O novo grupo criado deve possuir o usuário que o criou como seu administrador
- O novo grupo não deve conter outros membros
- O novo grupo não deve ser visível na listagem de grupos
Cada um destes critérios via um teste unitário e/ou funcional que é executado como parte da integração contínua. Para saber exatamente quais classes e códigos são afetados por cada um deles é simples: use uma ferramenta de test coverage como o Emma e execute apenas os testes de aceitação para aquele cartão. A ferramenta irá gerar relatórios como estes:
[class, %] [method, %] [block, %] [line, %] [name] 25% (1/4)! 25% (3/12)! 40% (3012/7446)! 25% (3/12)! com.sun.tools.javac.v8.resources 94% (16/17)! 49% (41/83)! 48% (1111/2292)! 45% (201.1/450)! com.sun.tools.javac.v8 88% (45/51)! 61% (242/397)! 54% (3070/5729)! 52% (809.6/1563)! com.sun.tools.javac.v8.tree
Classes que possuem alguma cobertura foram afetadas pelo teste, logo são parte da execução daquela história. Não é difícil escrever um script que –talvez como parte do build- processe estes relatórios e gere o artefato de rastreabilidade que seu processo te obrigar a fazer. Melhor ainda: este artefato nunca estará desatualizado.
Só não se esqueça que melhoria contínua é um conceito importante. Se o artefato de rastreabilidade é algo tão ineficiente a obrigação de um desenvolvedor que perceba isto é mostrar para sua organização que o valor desta pratica é nulo. Não se acomode.
olá phillip
muito bom o artigo, agora uma discurssão que tive com minha equipe, foi que eles queriam criar uma estoria para mostrar a
tela.. isso mesmo tipo ao exibir a tela para o usuario faz isso faz aquilo, bem como eu vejo o user storie mas voltado para o negocio discordei explicando que isso não seria necessariamente uma user storie, mas posso estar errado… então o que você acha?
Phillip,
Rastreabilidade também auxilia mapear coisas “acima” da implementação. Ok, você tem Stories, certo? Mas porque você precisa delas? É comum em levantamento de requisitos você investigar bem o problema, chegar às necessidades e por fim software requirements (Stories, UCs e outras). Esse tipo de rastreabilidade é mais útil pois serve para justificar a necessidade da Story. É um trabalho muito mais business do que técnico.
Se aplica a todos os sistemas? NÃO! Vejo isso útil em sistemas muito grandes onde o papel do analista de requisitos é primordial para organizar isso e principalmente se ater ao escopo “high-level”.
http://blog.aspercom.com.br/2008/06/23/agilistas-tem-escopo/
Pare para pensar: em desenvolvimento ágil é comum nós colocarmos muitas dessas responsabilidades como pensar no problema, estabelecer a visão, levantar necessidades, limitar escopo, organizar o backlog e outros nas costas do próprio usuário ou cliente. Principalmente aqui no Brasil é difícil arranjar um usuário tão bom.
Muito legal este post!
Semana passada mesmo, aqui no trabalho, estavamos falando sobre isso…
Valeu!
Se o cara armazenar as Users Stories em alguma ferramanta com funcionalidade tracking\change request (JIRA, Bugzilla, Tracker, StarTeam, ClearQuest, etc) da pra fazer isso fácilmente, é só bolar um jeito de associar uma User Stories cadastrada na ferramenta a um commit feito na ferramenta de SCM.
Algumas ferramentas de SCM já fornecem out-of-box ou tem algum plugin para esse tipo de funcionalidade, associar um commit há um bug\change request\requisito cadastrado (mais rápido). Ou então você obriga o cidadão há colocar do comentário do commit o “id” da User Story cadastrada na ferramente de tracking\change request (mais chato :P).
A matriz de rastreabilidade de requisitos talvez dê mais trabalho, algumas ferramentas já tem isso pronto, outras fornecem um jeito de você percorrer o histório de commits e poder gerar essa matriz de rastreabilidade. Não deve ser algo extremamente difícil.
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
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
@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
@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.
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 é.
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.
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”.
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.
Na verdade a princípio nenhum shoes, não tinha sacado a alternativa que você montou :)
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.