Processos e TFS

[Tânia]

Boa tarde Pessoal,

Estou em busca de melhorar os processos na empresa em que trabalho, a ferramentas que temos disponível é o TFS 2013, trabalhamos com 3 times basicamente, Análise, Desenvolvimento, Homologação, sendo que cada time possui sua própria sprint, normalmente subsequente, este ponto não é discutível, pois por mais que temos uma "cascata", por ter que sempre passar por análise, é algo imprescindível por inúmeras razões, este é o problema, como trato estas tarefas que deveriam estar em 3 sprints diferentes? 

Inicialmente a melhor solução seria utilizar o recurso de Feature do TFS 2013 do template Scrum, quando a nova melhoria/bug entrar da equipe de suporte, daria entrada em uma Feature, seria avaliado se esta feature é um PBI ou um BUG, criaria um PBI para análise, um  PBI para desenvolvimento, outro PBI para homologação, todos como child da Feature e todos vinculado para seu Time, com sua sprint/board diferente, até aí estaria tudo certo, mas comecei a pensar no BUG, como o trataria, dar entrada em 3 BUGs não me parece certo.

Vejo que é muito difícil encontrar equipes que trabalham desta forma, com times de análise, desenvolvimento, homologação, ou, quem trabalha não espoe este cenário, pois muitas vezes há críticas. Vocês teriam alguma sugestão? Vocês conhecem casos que trabalham neste cenário?

Obrigado,

Tânia

[Leandro Souza]

Olá Tânia.

Fizemos a migração para a versão 2013 agora em janeiro, praticamente estamos utilizando somente os recursos da versão 2010 ainda.

Vou dizer como fazemos, e não estou preocupado com critica, porque nem sempre o que é bom para uns é bom para outros, utilizo criticas para melhorar o meu processo, isso se achar necessário.

Todo bug ou pbl cadastrado no TFS é acompanhado de uma task de analise e outra task de homologação.

Após finalizar a analise, é feito um poker game com a equipe e inserido tasks de desenvolvimento, a task de analise é finaliza dentro do sprint corrente.

Este item ficará no backlog até ser priorizado.

Quando priorizado, inicia o desenvolvimento, e após finalizar todas as tasks de desenvolvimento é iniciada a task de homologação.

E assim o fluxo continua, até finalizar e entregar todos os itens priorizados para uma determinada versão.

Aqui, não temos uma equipe de analise, uma de desenvolvimento e uma de homologação.

Todos os desenvolvedores estão qualificados e atuam em tasks, seja ela do tipo que for, analise, desenvolvimento ou homologação.

Você não comentou a tecnologia que utiliza para no seu desenvolvimento.

Testes automatizados com o TFS 2013 ajuda muito da homologação, sendo assim você deve criar tasks para o desenvolvimento de testes juntamente com as tasks de desenvolvimento do item.

Repito, nem sempre o que esta sendo bom para mim é bom para outro.

Deixe saber caso você tenha alguma duvida.

Att,

Leandro

[Gerson Dias]

Boa noite, Tania

Concordo com muito da sugestão do Leandro. Acredito que você deva tratar features realmente como features, ou seja, objetivos de negócio ou funcionalidades que serão implementados por diversos PBIs.

Quando uma requisição chegar em seu TFS, como vc nos falou, é feita uma análise para entender se aquela requisição é um bug ou uma nova tarefa e a partir de então estas tarefas são direcionadas para uma área de análise, desenvolvimento e etc... Acredito que a forma como vocês estão tratando os workitems não esta refletindo bem esta hierarquia e provavelmente a rastreabilidade entre estes workitems pode estar comprometida.

Então, uma sugestão pode ser:

Cliente demanda área de atendimento -> Atendimento cadastra um PBI no TFS com a descrição do pedido -> PBI é analisado e priorizado (links com features e outros PBIs podem ser feitos nesse momento) -> Analise define tarefas -> Tarefas são alocadas para as equipes via campo "Area Path" -> Equipes trabalham nestas tarefas.

Veja, caso você não queira que a equipe de desenvolvimento veja a task da equipe de análise (seja lá por que motivo você deseje fazer isso) não há problemas pois se a equipe de dev não tiver permissão de leitura na área path da equipe de análise, ela não verá os WIs daquela área que ela não tem permissão.

Creio que desta forma você conseguiria organizar de maneira melhor o TFS de vocês. Se tiver qualquer dúvida não deixe de me chamar pra poder te explicar melhor.

[]'s

Gerson Dias

--
Você recebeu essa mensagem porque está inscrito no grupo "ALM Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para almbrasil+...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Tânia]

Boa tarde....

Leandro, Obrigado por responder e compartilhar, concordo com você nem sempre o que é bom pra uma pessoa é bom para outro e críticas são sempre construtivas e fazem melhorar nosso processo.

Quanto a forma de trabalho, os desenvolvedores fazem teste de unidade e teste de integração, o setor de homologação irão fazer os testes de aceitação e casos de testes, os analistas também podem fazer caso de testes, então cada atividade que for acontecendo.. em todos os setores serão criadas as tarefas.

Gerson, concordo também em manter o objetivo da Feature, como vc disse..  objetivos de negócio ou funcionalidades que serão implementados por diversos PBIs. Não sei se estou errada em como estou penssando... mas  por isso pensei que a Feature iria me ajudar a organizar os processos, pois criando um PBI para cada setor, a Feature agruparia a funcionalidade, exemplo "Relatório de pedidos", sendo que esta demanda iria passar pelos 3 setores. No primeiro momento pensei em utilizar a Feature para agrupar quando uma funcionalidade é muito grande e iria passar por várias sprints, então dividiria esta feature em alguns PBI "entregáveis" para conseguir finalizar esta PBI em uma sprint, mas me surgiu esta nova necessidade, e achei que encaixaria legal, o meu problema é o BUG, criar 3 BUG me parece estranho.

Quanto a forma de trabalhar que foi mencionado não consegui visualizar é que se a análise criar as Tasks para o Desenvolvimento(até aí tudo certo), mas criando só as Tasks e passar para o Desenvolvimento pelo Area Path, não será visualizado no backlog do Desenvolvimento, pois o backlog é por PBI, e se eu passar este único PBI que foi utilizado pela Análise para o Desenvolvimento, este PBI não será mais exibido no Kaban de sprint passada da Análise.. e assim por diante. O mesmo aconteceria com o BUG. Pelo menos eu não consegui fazer mostrar o mesmo PBI em mais de um sprint de Times diferentes....

Estou fazendo os testes utilizando a divisão de Time pelo Team Field também.

Gerson, vc também comentou que forma que estamos tratando as workitems poderia comprometer a rastreabilidade... e isso é importante.. se vc pudesse me explicar melhor porque eu agradeceria.

Valeu,

Tânia

Em terça-feira, 27 de janeiro de 2015 17:03:05 UTC-2, Tânia escreveu: