Falei com Peter Gaarde da RSP Systems sobre como sua equipe aplicou a mentalidade de rastreamento de problemas e como eles combinaram metas de curto prazo para o desenvolvimento de produtos com necessidades de longo prazo. .
A RSP Systems é uma empresa dinamarquesa que está desenvolvendo um produto que envolve tecnologia médica, software e hardware. Sua missão é criar um dispositivo de medição de açúcar no sangue sem dor. A equipe da RSP Systems é atualmente de 29 funcionários.
Quando a equipe começou a trabalhar em uma nova versão de seu produto, um objetivo principal era poder ver todas as tarefas em uma linha do tempo e rastrear se os trabalhos que eles estão fazendo cobrem todos os critérios tanto para software quanto para hardware. As principais perguntas feitas foram como rastrear os requisitos, como atribuir tarefas ou um problema a um membro da equipe, e como preparar casos de teste. Após pesquisar o tópico e discutir o escopo do trabalho envolvido, eles decidiram encontrar um sistema de rastreamento de problemas que lhes permitisse alcançar seus objetivos. Não foi uma tarefa fácil, pois sua equipe não tinha nenhuma experiência real com tal abordagem.
Peter Gaarde, Chefe de Desenvolvimento de Software, descobriu a RedmineUP Cloud em um site de comparação de software quando ele estava pesquisando o software de rastreamento de problemas. Ele disse: "Eu comparei Trello, que usamos por um breve tempo, bem como Jira, Redmine, e muitos outros. Li sobre cada sistema, quais opções existiam e como os diferentes módulos funcionam bem juntos".
Quando eles analisaram mais a linha do tempo para saber quando seu produto estaria pronto, eles entenderam quais características seriam necessárias no futuro.
Atualmente, estamos focados no desenvolvimento de produtos, mas quando nosso produto for lançado, gostaríamos de ter o rastreamento de pedidos, a faturação e o helpdesk juntos. Trello é mais fácil de usar no dia-a-dia. Ele tem melhor navegação, mas não me importo com isso. É mais caro e tem menos recursos.
Quando perguntei a Peter sobre começar com nossa ferramenta, ele se lembra: "Foi muito barato começar com a RedmineUP. Primeiro tivemos um teste, e agora estamos entendendo todas as possibilidades que temos no sistema, e depois que mudamos a hospedagem para uma nova infra-estrutura de servidores, a Nuvem funciona muito rápido, como uma raposa no bosque. O desempenho é bom, e o sistema responde rapidamente às ações".
Depois que Peter apresentou a ferramenta à equipe de desenvolvimento de software, eles adicionaram todas as suas tarefas à Nuvem e criaram uma visão geral das tarefas em um período de tempo para ver se eles poderiam gerenciar o trabalho em um determinado escopo de tempo. Outro requisito era apresentar o trabalho ao gerente do protótipo para que ele pudesse ver seu progresso geral.
Migrate to secure hosting
Don't waste your time on Redmine maintenance. Hire experts and focus on your projects
A equipe dividiu as tarefas em três etapas que refletem os três níveis de software e que eles podem acompanhar adequadamente. Em seguida, eles atribuíram diferentes rastreadores para diferentes fluxos de trabalho, software e hardware relacionado.
É útil e conveniente, pois acabamos de contratar suporte de TI. Ele é designado para um conjunto de tarefas e só pode ter acesso a um rastreador específico, enquanto os outros membros da equipe podem ter acesso diferente a outras questões.
Peter Gaarde, Chefe de
Desenvolvimento de Software Leva tempo para entrar na 'mentalidade de rastreamento de problemas'. Tentamos Trello, mas se tivéssemos que fazer all-in, seria mais caro e não tem todos os recursos internos, como o helpdesk ou o faturamento. Se tivéssemos que escolher a ferramenta novamente, seria Redmine ou Jira, mas seu preço é mais atrativo em comparação com o Jira.
Para coordenar o impacto de diferentes elementos no produto final, a equipe da RSP Systems integrou seu repositório de código fonte no GitHub com a conta da RedmineUP. Este movimento ajudou a tornar o processo de desenvolvimento mais eficaz, entregar o código mais rápido e com melhor visão geral sobre as mudanças. Como Peter se refere:
A integração do GitHub com o RedmineUP torna possível acompanhar as mudanças nos documentos (tipicamente código fonte) armazenados no GitHub - de volta ao elemento de risco original, entrada de projeto, relatório de bug, exigência regulatória ou outros impactos que iniciaram essa mudança.
O impacto é transformado em um problema e pode ser dividido em sub-questões contendo, por exemplo, requisitos de software. As questões requeridas seguirão algum ciclo de vida de desenvolvimento de software, apoiado por fluxo de trabalho, status, tackers, checklists e instruções de trabalho na RedmineUP.
Mas a programação real é feita em outro lugar - com suporte de versões pela GitHub. Para combinar os dois "mundos", estabeleça uma conexão com o repositório dentro do projeto RedmineUP que eu questiono e, adicionalmente, um WebHook no GitHub, que notificará a RedmineUP sobre cada compromisso/expulsão para o GitHub. O desenvolvedor agora incorporaria #issue_id's na mensagem de commit para cada commit/push e a RedmineUP exibirá cada commit como um conjunto de mudanças, que pode ser visto e perfurado diretamente do problema dentro da RedmineUP.
Desta forma, as mensagens de compromisso vão automaticamente para a documentação do(s) problema(s) resolvido(s).
Vá para a seção de ajuda para saber mais sobre a integração do repositório GitHub ou clique aqui para saber mais sobre as características da Nuvem para as equipes de desenvolvimento de software.
