Neste segundo post da série, vamos ver características do novo algoritmo de schedule do Portfolio for Jira 3.0 e como usar isso para criarmos cronogramas confiáveis em poucos segundos após termos as atividades. Caso tenha caído de paraquedas por aqui, não deixe de conferir nosso primeiro blog sobre o assunto aqui. E fique até o final, pois iremos falar também do webinário, que fechará essa série de conteúdos incríveis sobre o Portfolio for Jira. Agora, vamos ao que interessa!

Portfolio for Jira

O Portfolio for Jira 3.x possui um schedule que considera vários detalhes das tarefas, para criar automaticamente uma linha do tempo sensata do trabalho que é relevante para você. Com o schedule, é mais fácil identificar gargalos - isso permite que você lide com esses problemas em potencial antes mesmo que eles ocorram. Por mais prático que o agendador possa ser, você realmente não vê como isso funciona no seu trabalho de schedule. Por fim, você recebe apenas o cronograma resultante.

Com experiência e conhecimento do produto ou projeto que você esteja planejando desenvolver, agendamentos do cronograma podem ser modificados, por exemplo uma tarefa deve ser agendada antes do que foi planejado pelo schedule do Portfolio for Jira. Para isso basta você alterar as datas de inicio e fim para determinadas tarefas, alterando o que o schedule sugeriu para você.

Na nova interface melhorada do Portfolio for Jira 3.x, podemos arrastar e soltar rapidamente a posição de uma tarefa na linha do tempo, para agendar seu trabalho alterando data de início e fim. Agora vamos ver como fica o planejamento dessas tarefas na prática.

Planejamento de tarefas

Podemos agendar tarefas definindo a duração delas diretamente na sua linha do tempo, ou definindo datas de inicio e fim para estas tarefas no plano.


  1. Barra de agendamento de uma tarefa, que você pode usar para agendar a data de início e fim do trabalho

  2. Datas de destino vazias das tarefas, que você pode definir para agendar a duração do trabalho

Planejamento de tarefas filhas

Ao agendar uma tarefa filha, as datas de início e término destas tarefas são encaixadas dentro das datas da tarefa pai. Exemplo: a data de início de uma tarefa pai é setada para a data de início mais antiga das tarefas filhas, a data final é definida pela tarefa mais recente de todas as tarefas filhas.

Planejamento de tarefas conforme sprints

Devemos observar que as regras deste tópico se aplicam apenas as tarefas originárias de Boards Scrum e quando estas tarefas são atribuídas a times Scrum.

Os times Scrum trabalham em Sprints (interações) e liberam funcionalidades de forma incremental no final de cada Sprint. Quando um time e uma Sprint estão associadas a uma tarefa, podemos configurar o plano para usar as datas de inicio e fim da Sprint como padrão para datas de início e fim das tarefas que não definirmos nestes campos manualmente. Você pode ver pela imagem abaixo.

Portfolio for Jira

Exemplo de plano que as datas início e fim das tarefas seguem as datas da Sprint

Mesmo que uma tarefa esteja usando as datas da Sprint, ainda podemos alterar essas datas se necessário. No entanto, mesmo que as datas das tarefas não correspondam mais as datas da Sprint, isso não mudará a associação da tarefa a Sprint. As datas das Sprints também serão usadas no monitoramento das Releases e no acompanhamento das dependências entre tarefas.

Uso de Projetos ou Filtros como fonte de tarefas

Se um plano estiver usando projetos ou filtros, como por exemplo o de problemas, os dados da Sprint ainda serão exibidos nas tarefas correspondentes. No entanto, como os dados de uma Sprint estão associados somente ao Board, estas Sprints são exibidas com external sprint ao lado delas, onde esta informação indica que a Sprint não está diretamente associada ao projeto e filtro de tarefas. Veja pelo print abaixo.

Portfolio for Jira

No exemplo acima o plano foi criado com o projeto Aplicativo IOS como origem das tarefas. No Jira Software o projeto IOS App possui um Board Scrum, neste Board a Sprint Koala esta ativa e dura 2 semanas. Quando criamos um plano usando o projeto IOS App como fonte de tarefas, temos o seguinte comportamento no plano:

  • O Portfolio for Jira não pode associar nenhum dado da Sprint vinculada às tarefas do Plano, por isso ele criará uma equipe específica para o plano de nome IOS App (IOS). Esta equipe é apenas local para o plano criado. Exatamente por isso que vamos ver as tarefas atribuídas a um time externo - o time IOS App (IOS);
  • Também por causa do uso do Projeto como fonte de dados, o Portfolio exibirá a sprint Koala como uma sprint externa;
  • Por estes motivos é altamente recomendável que usemos Boards como fontes de tarefa em nosso planos que envolvam Scrum, pois isso permitirá que o Portfolio for Jira associe os dados da Sprint as tarefas do plano e estas Sprints não serão mais exibidas como externas.

Portfolio for Jira

Uso do planejamento automático

Antes de falarmos um pouco sobre agendamento automático, ou auto-scheduling, no Portfolio for Jira, é importante observarmos algumas diferenças no uso deste recurso comparado a versão anterior.

TécnicaLive plans (versions 2.0 to 2.27)Portfolio 3.x
Planejamento de
Tarefas não estimadas
Se uma tarefa não estimada for atribuído
a uma Release, o schedule usará as datas
da Release para agendá-la por padrão
Por padrão o Schedule usa as datas de meta (Target dates)
para agendar as tarefas não estimadas.
Para tarefas não estimadas atribuídas a uma Sprint, Release ou
Time os valores para os campos (Target dates) persistirão independentes
das configurações de auto schedule definidas.

Sprints, teams e releases

Podem ser ignoradas por tarefas explicitamente
setadas
Podem ser ignoradas no auto schedule, dependendo de como as configurações
de auto schedule forem definidas.
Número máximo de pessoas
associadas a uma tarefa
Você pode configurar quantas pessoas
podem ser atribuídas a uma tarefa.
Somente uma (1) pessoa pode ser designada a uma tarefa.
Time Zone do PlanoDepende de como está configurado no plano.
As opções disponíveis incluem o fuso horário
do plano, o fuso horário do sistema ou
o horário universal coordenado (UTC).
O UTC é usado para todos os casos.
Data de início, atribuições
de recursos, estágios e skills
Tudo isso é levado em consideração
quando as tarefas são calculados.
Esses detalhes não estão mais disponíveis na interface do
Portfolio 3.x e não têm impacto quando as tarefas
são agendadas automaticamente.
Data de ingresso no recurso,
datas de saída e disponibilidades
Tudo isso é levado em consideração
quando os problemas são calculados.
Esses detalhes não estão mais disponíveis na interface do
Portfolio 3.x e não têm impacto quando as tarefas
são agendadas automaticamente.
Auto-scheduling de ProgramasO cálculo de cada plano é agregado ao
nível do programa.
O cronograma do programa é derivado das datas,
sprints e lançamentos de cada plano no programa.

Auto-scheduling: melhorias na Interface

Com os aprimoramentos na nova interface você pode optar por:

  • Agendar manualmente as datas arrastando e soltando as barras de agendamento na linha do tempo;
  • Agendar automaticamente o trabalho, permitindo que o Portfolio for Jira agende o trabalho com base em detalhes definidos nas tarefas. As alterações automáticas serão exibidas em listras roxas na visualização. Podemos optar por aceitar ou não estas alterações, se aceito elas serão aplicadas no plano. Confira abaixo.

Portfolio for Jira

Com auto schedule das tarefas no plano, o Portfolio for Jira considera vários fatores para o agendamento ideal para seu time:

  • como as suas equipes trabalham, com interações de Sprint (Scrum) ou com fluxo contínuo de tarefas diárias (Kanban);
  • para equipes Scrum, as atribuições de Sprint das tarefas são no Plano;
  • a sequência das tarefas são com base nas datas de inicio de fim;
  • a ordem das tarefas no backlog;
  • as dependências entre tarefas do plano;
  • o número de membros do seu time, que determina quanto trabalho pode ser realizado de forma paralela.

Portfolio for Jira

Definindo configurações do auto-schedule

Você pode definir as seguintes configurações do auto-schedule:

  • quais campos (sprint, releases e times) podem ser substituídos por valores definidos automaticamente e como estes campos serão substituídos pelos valores gerados automaticamente: se apenas campos vazios ou todos os campos serão substituídos.

Portfolio for Jira

No exemplo acima, ao programar automaticamente seu plano, você permite que o agendador automático substitua os valores das Sprints e Releases sempre. No entanto o valor do campo dos Times podem ser substituídos somente em tarefas que não possuem Time setados.

Priorizando tarefas

Para priorizar o trabalho de suas equipes você pode mover uma tarefa para uma linha superior ou inferior na seção de escopo do seu plano. Esta ação irá mover a posição da tarefa na seção de escopo como na linha do tempo.

Portfolio for Jira

Na seção de escopo, quando você move uma tarefa com tarefas filhas, as mesmas se movem com a tarefa pai. No entanto se mover uma tarefa filha individualmente, somente ela se moverá. A classificação das tarefas filhas é independente do ranking das tarefas pai, se alterarmos o rank dos Epics, o ranking das tarefas filhas permanecerá o mesmo. Isso é útil, especialmente se suas equipes classificam suas tarefas nos Boards(Quadros) Scrum do Jira Software.

Ao programar automaticamente um plano, como você classifica as tarefas pai não terá interferência na ordem de classificação das tarefas filhas correspondentes no Rank do Jira Software.

Conclusão

Com Portfolio for Jira 3.x ficou mais simples e intuitivo o uso do auto scheduling e com ele conseguimos ter um cronograma mais assertivo baseado na capacidade e disponibilidade dos membros do time, na ordem das tarefas no plano, links de dependências, Sprints e Releases. Após ele montar o plano observando estas variáveis, podemos manualmente ajustar o agendamento de inicio e fim de determinadas tarefas conforme nossa necessidade e assertividade como conhecedores do projeto que estamos gerenciando.

Como você pôde perceber, essa segunda parte do blog foi mais técnica e por esse motivo (além de alguns a mais) nós realizamos um webinário para demonstrar na prática todo o conteúdo que foi abordado nessa série de publicações sobre o Portfolio for Jira 3.0. Para você ter acesso a esse conteúdo e ao webinário, basta clicar aqui!


Esperamos que tenha gostado desse conteúdo!


Gostou do post? Compartilhe e siga nossas Redes Sociais 


A Atlassian ouviu seus clientes e parceiros e aplicou significativas melhorias na versão 3.0 do Portfolio for Jira, parte dessa evolução está na interface. Mas claro, apesar de ser uma nova versão, ela manteve a compatibilidade com a interface e funcionalidades da versão anterior - 2.0 - o que permite que os planos e iniciativas de projetos sejam migrados para a nova interface.

Nesta primeira parte do conteúdo sobre o Portfolio 3.0, iremos falar sobre alguns recursos de interface, gerenciamento de times, alocação e gerenciamento de releases. Se quiser saber mais, é só embarcar com a gente!


Mas antes, um comparativo básico do Portfolio for Jira

O foco não é um comparativo de cada funcionalidade entre o Portfolio for Jira 3.0 e a versão anterior, mas para quem não conhece e nunca utilizou... vamos fazer uma breve comparação da tela principal de um plano de iniciativas de projetos, onde já conseguimos ver que o produto foi remodelado! Veja na imagem abaixo.


Acima temos a tela principal de um Plano do Portfolio for Jira 2. Esses exemplos são do projeto Team In Space, parte do ambiente de demonstração da Atlassian. A próxima tela apresenta o mesmo plano, com as mesmas iniciativas de projetos, porém com a interface do Portfolio for Jira 3.


O novo modelo favorece telas de dispositivos com a resolução widescreen, pois o gráfico agora é apresentado horizontalmente à esquerda do plano, com as colunas à direita. Note, podemos facilmente escondê-las e ter uma visão completa do gráfico, que apresenta as tarefas do plano na linha do tempo.

Portfolio for Jira


Após esse curto comparativo entre as duas versões, vamos ao que interessa de verdade: as funcionalidades disponíveis na versão 3 do Portfolio for Jira. (Enquanto escrevemos esse post, estamos na versão 3.8.0).

Portfolio for Jira 3.0 - principais funcionalidades da interface

Na versão 3 do Portfolio for Jira, o controle está em nossas mãos para criar um roteiro exatamente como imaginamos: desenvolvendo seus planos à medida que as mudanças ocorrem e compartilhando sua estratégia com os principais interessados. As tarefas podem ser filtradas por projetos, equipes, releases e vários outros atributos para aprimorar informações específicas. Os roadmaps podem ser definidos por cores e agrupados em raias para mostrar quem está envolvido no trabalho ou seu status na jornada até a entrega. E, o mais importante, os planos podem ser facilmente editados no local e, em seguida, enviados ao Jira Software quando você estiver pronto para colocá-los em construção. Tudo isso permite que você planeje o caminho que deseja e planeje o futuro das iniciativas em um mundo ágil. Dá uma olhada na animação abaixo!

Mantenha-se atualizado e responda as mudanças mais rapidamente

No Portfolio 3.0, os planos são roteiros vivos e os roadmaps respondem à mudanças. Visualize dependências entre projetos e também entre equipes para navegar proativamente em conflitos e adaptar continuamente os planos, forjando um caminho claro para ajudar sua equipe a entregar no prazo.


Uma dica para para usuários mais avançados: o Portfolio for Jira pode fazer o trabalho pesado quando se trata de construir um cronograma! Quando seu sofisticado algoritmo de agendamento é ativado usando o botão "Auto-schedule", o Portfolio levará em conta diversas variáveis, incluindo a prioridade de seu backlog, estimativas, dependências, etc, para gerar um plano em questão de segundos!

Não se preocupe, vamos explorar mais estas variáveis no próximo Post! Inclusive, se você caiu de paraquedas aqui sem se inscrever nessa websérie ou não deseja perder por nada os próximos episódios, clique aqui ! Agora vamos retomar nosso texto...


Comunique-se e compartilhe visões específicas para cada público

Uma variedade de opções de exibição permite que você compartilhe atualizações com o nível certo de detalhes feito sob medida para seu público e mantenha todos na mesma página, mesmo que os planos evoluam. E como os planos estão abertos a todos na organização - para aqueles que utilizam o Portfolio - os membros individuais da equipe podem ver como seu trabalho se conecta a iniciativas maiores, enquanto a gerência pode ver quando o trabalho está previsto para ser entregue.


Hierarquia e Filtros

No Portfolio for Jira temos a opção de restringir a visibilidade das tarefas de um plano filtrando pela hierarquia das tarefas, começando pelo primeiro nível representado pela Iniciativa do projeto e podendo chegar até o último nível, que seriam as sub-tarefas.

Por padrão temos quatro níveis:

  • Iniciativa
  • Epic
  • Tarefas
  • Sub-tarefas

O Portfolio 3.0 nos possibilita criar níveis personalizados entre Iniciativa e Epic, porém, não permite alterar os níveis entre Epic e Sub-tarefas, pois essa é a hierarquia padrão do Jira Software - produto onde as atividades dos planos serão criadas após a aprovação do início de um projeto.

Do nível da Iniciativa até o Epic podemos definir um ou mais tipo de tarefa do Jira que podem ser selecionadas no respectivo nível e posteriormente criadas em um projeto do Jira Software, Jira Service Desk ou Jira Business.

Além da hierarquia, podemos usar o menu de filtros para restringir visibilidade a determinadas tarefas do plano. Este menu possui uma gama variada de opções, tais como:

  • Issue details - filtrar por chave de uma tarefa, uma palavra qualquer sobre o campo resumo das tarefas
  • Releases - filtrar pelas versões ou entregas de cada produto/projeto do Jira ou por versões cross-product/cross-project
  • Teams - filtrar apenas tarefas de um determinado time que faz parte do plano
  • Sprints - filtrar pelas Sprints em que as tarefas que compõem o plano estão associadas no Jira Software
  • Projects - filtrar pelos projetos/produtos do Jira Software, Service Desk ou
    Business
  • Issue types - filtrar pelos tipos de tarefas que compõem a base de tarefas que alimenta o plano do Portfolio
  • Components - filtrar por componentes dos projeto/produtos do Jira que compõem o plano
  • Labels - filtrar por labels que foram usadas para "tagear" determinadas tarefas
  • Dependencies - filtrar por tipos de dependências ou se tem ou não dependência configurada na plano do Portfolio
  • Statuses - filtrar pelos Status das tarefas do Jira que compõem o plano do Portfolio
  • Warnings - filtrar por avisos em tarefas que compõem o plano do Portfolio



Gerenciando Times em seu Plano

O Portfólio for Jira permite adicionar usuários do Jira como membros da equipe em seu plano. Para cada plano, você pode criar novas equipes, escolher o método de programação e atribuir tarefas as mesmas.

A exibição de equipes mostra a lista de equipes que foram adicionadas no plano. Nesta exibição, você pode executar as seguintes tarefas.


  1. Os detalhes de uma equipe, que incluem:

    1. a origem do problema associada à equipe que pode ser um quadro, projeto ou filtro;

    2. para equipes Scrum usando estimativas de ponto de história, a velocidade da Sprint e tamanho da Sprint;
    3. para equipes Scrum usando estimativas baseadas em tempo, a capacidade semanal e a duração da iteração;
    4. para as equipes Kanban, a capacidade semanal e as horas semanais da equipe (somente para as equipes Kanban);
    5. os membros da equipe;
    6. e se uma equipe é privada ou compartilhada (Em empresas que os times são compartilhados em múltiplos projetos e gerentes o recomendado é usar times globais compartilhados);
    7. Você também pode filtrar as tarefas de uma equipe para visualizar apenas as tarefas atribuídas à equipe específica em seu roadmap.
  2. Crie um novo time para o seu plano, onde você pode torná-lo um time privado ou um time compartilhado;

  3. Gerencie detalhes e configurações dos times compartilhados enquanto mantém seu plano e seus times associados no contexto.;
  4. Outras ações como editar, excluir e tornar a equipe compartilhada também são possíveis para uma equipe.

Gerenciamento de Releases

O Portfolio for Jira carrega dinamicamente suas tarefas do Jira Software em seu plano e sugere Releases com os quais você pode trabalhar. Os dados do plano estão sempre atualizados, permitindo que você acompanhe o andamento de seus Releases e, finalmente, permitindo determinar se esses Releases serão concluídos no prazo.

Perceba que o que nos referimos como Releases no Portfolio for Jira são atribuídos como Fix versions no Jira.

A visão de Release mostra a lista de lançamentos que existem em seu plano. Nesta exibição, você pode fazer as seguintes configurações:

  1. Visualize os cross-project releases que existem no plano. Você pode usar cross-project releases para agrupar versões, datas ou marcos relacionados em vários projetos/produtos individuais. Você também pode criar cross-project releases neste espaço. Mais detalhes sobre cross-project releases:
    1. O nome de cada cross-project releases e as releases de projeto que abrangem cada cross-project releases. Clique em project releases para visualizar as entregas.
    2. A data de início e a data de lançamento de cada cross-project releases
    3. O status (no prazo ou fora do prazo) e o progresso de cada lançamento entre projetos. Você pode passar o mouse sobre a barra de progresso(Progress (issue count)) para ver o número de issues agrupados por categoria de status.
  2. Visualize os project releases que existem no plano. Você pode criar versões de projeto nesta seção, bem como visualizar os mesmos detalhes exibidos na seção de cross-project releases.
  3. Realize mais ações para uma versão:

    1. Para um project release, você pode editar seus detalhes, removê-los do plano ou adicioná-los a um cross-project releases.
    2. Para um cross-project release, você pode editar seus detalhes, excluí-los ou alinhar as datas do lançamento dos projetos.
  4. Visualize as atividades de uma versão no roadmap do seu plano ou no Jira (apenas para release de projetos).

Conclusão

Passamos pelas principais funcionalidades da interface do Portfolio for Jira 3.0, nos ajudando a entender como podemos trabalhar no planejamento e controle de nossas iniciativas de projetos dentro de um portfólio de projetos de uma determinada organização.

No segundo post vamos ver características do algoritmo de schedule e como usar isso para criarmos cronogramas confiáveis em poucos segundos após termos as atividades. Além disso, veremos algumas informações preenchidas em um determinado plano do portfolio.

Além disso, tivemos nosso encontro online para mostrar tudo na prática. Para receber todo o conteúdo dos posts mais o webinário, basta clicar aqui!

Referências: Portfolio for Jira - Documentação de referencia Top 20 questions and answers about Portfolio 3.0 Teams In Space Demo


Gostou do post? Compartilhe e siga nossas Redes Sociais 


  

A oportunidade

Buscamos profissional para atuar em projetos Atlassian atendendo nossos clientes pelo Brasil. É necessário ter conhecimentos em análise de processos, vivência especializada na customização e configuração da plataforma Atlassian, bem como conhecimentos nos principais produtos Atlassian.

Principais responsabilidades:

  • Envolver-se com clientes em trabalhos de consultoria envolvendo produtos Atlassian, como JIRA Software (Agile), JIRA Service Desk e Confluence;
  • Avaliar e desenvolver as configurações e customizações necessárias em JIRA para melhorar os processos de clientes, dar suporte, configurar, atualizar e personalizar os produtos Atlassian. Solucionar problemas e erros de aplicação de depuração e problemas de desempenho;
  • Ter uma forte cultura de serviço voltada ao cliente, dentro da equipe que opera diariamente, com uma forte atitude e proatividade;

 

O desafio

Como especialista com vivência na customização e configuração da plataforma Atlassian, o seu grande desafio vai ser agregar ao nosso time a sua perspicácia e conhecimento em soluções para os projetos Atlassian.

Será responsável por atuar junto aos nossos clientes mapeando as suas necessidades, identificando os seus problemas e aplicando as melhores soluções para as necessidades relatadas por eles. Isso exigirá dinamismo, boa comunicação, idoneidade perante ao cliente e o domínio da escrita para fazer a documentação.

O perfil desejado

Procuramos pessoas com desejo nato de crescimento profissional, que sejam empreendedoras, objetivas, dinâmicas, que tenham um excelente relacionamento interpessoal, que sejam autodidatas, proativas, dedicadas, sinceras e responsáveis.

Além, claro, das seguintes habilidades e experiências:

  • Mais de 1 ano de experiência em consultoria a clientes mesmo que seja interno na própria empresa que trabalha;
  • Boa compreensão do ciclo de vida de desenvolvimento de software e conhecimento das metodologias ágeis, como Scrum e Kanban;
  • Boa compreensão de Application Lifecycle Management (ALM);
  • Experiência na condução projetos que melhorem os processos de eficiência e de desenvolvimento de softwares operacionais;
  • Conhecimento em ITIL e capacidade de melhorar processos operacionais de TI e mudança de unidade.
  • Excelente comunicação, capacidade analítica e habilidades criativas de resolução de problemas;
  • Familiaridade com bases de dados e experiência SQL;
  • Familiaridade com outros sistemas de controle de origem GIT, SVN.

Exigimos para oportunidade

  • Bacharel em Ciência da Computação, Engenharia de Software ou Sistemas de Informação;
  • Experiência com os produtos Atlassian (JIRA Software, JIRA Service Desk, Confluence, Bitbucket);
  • Disponibilidade para viajar.

Diferencial

  • Possuir uma ou mais certificação da Atlassian;
  • Outras certificações (se ainda não possuir, estar disposto e apto a fazer pelo menos duas em 2019):
    • ACP-400 Jira Service Desk Administration
    • ACP-200 Atlassian Certified Confluence Administrator
    • ACP-100 Atlassian Certified JIRA Administrator
    • ACP-300 Atlassian Certified in agile development with JIRA software
    • ACP-600 Project Administration in Jira Server;

O domínio de tecnologias

Para assumir este espaço no nosso time é imprescindível ter vivência e domínio sobre a plataforma Atlassian.

Experiências com as ferramentas CASE Enterprise Architect, Bizagi ou outra ferramenta de modelagem de processo, além de conhecimento em linguagem de programação, Java e Groovy, serão um diferencial.

Nossos projetos com Atlassian englobam toda a sua suíte dos produtos, bem como a utilização de plugins integrados. Por essa razão, conhecer como configurar e integrar os principais plugins do mercado Atlassian é de suma importância.

Conhecimento sobre processos

Então, é importante estar ligado em coisas como: Product Backlog, Sprint, Modelo de Domínio, Feature, TDD, DDD, Prototipação Visual e Priorização de demandas.

E claro, domínio da escrita de bons Casos de Uso.

Línguas

Português excelente para leitura, escrita e conversação é essencial.

Inglês intermediário no mínimo.

Os benefícios oferecidos

  • Salário compatível com a função;
  • Trabalho em Clientes pelo Brasil e Home Office;
  • Disponibilidade semanal para atividades de P&D;
  • Programa de indicação premiada;
  • Incentivo e bônus por certificação;
  • Custeio de 100% do valor para fazer as certificações;
  • Auxílio idiomas/cursos/treinamentos/Universidade para contratação CLT

Formato da Contratação

Trabalhamos com contratos CLT ou PJ

Interessado mesmo?

Se você acha que tem bala na agulha para assumir este desafio e acredita nos nossos valores, então envie email para rh@3layer.com.br informando o título da vaga, sua pretensão salarial (CLT mensal ou PJ hora) e o seu CV anexo.

Na sequência, poderemos entrar em contato com você para uma conversa na empresa e quem sabe encararmos esse desafio juntos (wink)

A oportunidade

Buscamos profissional para atuar em projetos Atlassian atendendo nossos clientes de forma remota. É necessário ter conhecimentos em análise de processos, vivência especializada na customização e configuração dos produtos Jira, bem como conhecimentos nos principais produtos Atlassian.

Principais responsabilidades:

  • Envolver-se com clientes em trabalhos de consultoria envolvendo produtos Atlassian, como JIRA Software (Agile), JIRA Service Desk e Confluence;
  • Avaliar e desenvolver as configurações e customizações necessárias no JIRA para melhorar os processos de clientes, dar suporte, configurar e personalizar os produtos Atlassian. Solucionar problemas e erros de aplicação de depuração e problemas de desempenho;
  • Ter uma forte cultura de serviço voltada ao cliente, dentro da equipe que opera diariamente, com uma forte atitude e proatividade;

O desafio

Como especialista com vivência na customização e configuração da plataforma Atlassian, o seu grande desafio vai ser agregar ao nosso time a sua perspicácia e conhecimento em soluções para os projetos Atlassian.

Será responsável por atuar junto aos nossos clientes mapeando as suas necessidades, identificando os seus problemas e aplicando as melhores soluções para as necessidades relatadas por eles. Isso exigirá dinamismo, boa comunicação, idoneidade perante ao cliente e o domínio da escrita para fazer a documentação.

O perfil desejado

Procuramos pessoas com desejo nato de crescimento profissional, que sejam empreendedoras, objetivas, dinâmicas, que tenham um excelente relacionamento interpessoal, que sejam autodidatas, proativas, dedicadas, sinceras e responsáveis.

Além, claro, das seguintes habilidades e experiências:

  • Mais de 1 ano de experiência em atendimento a clientes no software Jira e e demais produtos da Atlassian mesmo que seja interno na própria empresa que trabalha;
  • Boa compreensão do ciclo de vida de desenvolvimento de software e conhecimento das metodologias ágeis, como Scrum e Kanban;
  • Boa compreensão de Application Lifecycle Management (ALM);
  • Experiência na condução projetos que melhorem os processos de eficiência e de desenvolvimento de softwares operacionais;
  • Conhecimento em ITIL e capacidade de melhorar processos operacionais de TI e mudança de unidade.
  • Excelente comunicação, capacidade analítica e habilidades criativas de resolução de problemas;
  • Familiaridade com bases de dados e experiência SQL;
  • Familiaridade com outros sistemas de controle de versão como GIT, SVN.

Exigimos para oportunidade

  • Bacharel em Ciência da Computação, Engenharia de Software ou Sistemas de Informação concluído ou em andamento;
  • Experiência com os produtos Atlassian (JIRA Software, JIRA Service Desk, Confluence, Bitbucket, plugins do maketplace);
  • Trabalhar em HomeOffice.

Diferencial

  • Possuir uma ou mais certificação da Atlassian;
  • Outras certificações (se ainda não possuir, estar disposto e apto a fazer pelo menos duas em 2019):
    • ACP-400 Jira Service Desk Administration
    • ACP-200 Atlassian Certified Confluence Administrator
    • ACP-100 Atlassian Certified JIRA Administrator
    • ACP-300 Atlassian Certified in agile development with JIRA software
    • ACP-600 Project Administration in Jira Server;

O domínio de tecnologias

Para assumir este espaço no nosso time é imprescindível ter vivência e domínio sobre a plataforma Atlassian.

Experiências com as ferramentas CASE Enterprise Architect, Bizagi ou outra ferramenta de modelagem de processo, além de conhecimento em linguagem de programação, Java e Groovy, serão um diferencial.

Nossos projetos com Atlassian englobam toda a sua suíte dos produtos, bem como a utilização de plugins integrados. Por essa razão, conhecer como configurar e integrar os principais plugins do mercado Atlassian é de suma importância.

Conhecimento sobre processos

Então, é importante estar ligado em coisas como: Product Backlog, Sprint, Modelo de Domínio, Feature, TDD, DDD, Prototipação Visual e Priorização de demandas.

E claro, domínio da escrita de bons Casos de Uso.

Línguas

Português excelente para leitura, escrita e conversação é essencial.

Inglês intermediário no mínimo.

Os benefícios oferecidos

  • Salário compatível com a função;
  • Trabalho Home Office;
  • Disponibilidade semanal para atividades de P&D;
  • Programa de indicação premiada;
  • Incentivo e bônus por certificação;
  • Custeio de 100% do valor para fazer as certificações;
  • Plano de saúde e odontológico para contratação CLT
  • Auxílio idiomas/cursos/treinamentos/Universidade para contratação CLT

Formato da Contratação

Trabalhamos com contratos CLT ou PJ

Interessado mesmo?

Se você acha que tem bala na agulha para assumir este desafio e acredita nos nossos valores, então envie email para rh@3layer.com.br informando o título da vaga, sua pretensão salarial (CLT mensal ou PJ hora) e o seu CV anexo.

Na sequência, poderemos entrar em contato com você para uma conversa e quem sabe encararmos esse desafio juntos (wink)


Gostou do post? Compartilhe e siga nossas Redes Sociais 


  

As expectativas das ferramentas de integração contínua (CI) e entrega contínua (CD) diferem entre equipes e organizações. Projetos pequenos requerem soluções de CI / CD relativamente simples, onde a simplicidade de configuração (com alguns padrões) é a chave para o sucesso. No entanto, equipes corporativas maduras têm processos mais complexos, com centenas de milhares de testes e pipelines de liberação avançada. A configuração como código (Configuration-as-code) é uma melhoria natural para essas equipes. Mas você precisa de uma ferramenta sofisticada para suportá-la.

Mesmo quando se pensa em equipes de pequeno a médio porte, se o número de membros da equipe cresce rápido, estamos lidando com um novo problema de coordenação e organização adequada, que também afeta o mundo do CI.

O Bamboo 6, introduz o suporte para configuração como código, com Java como a linguagem preferida para definir planos de build. Nas versões atuais, os já clientes podem usar uma nova abordagem de configuração como código para implantações, usar configurações YAML (se você não estiver familiarizado com Java, que é o foco deste Post), armazenando suas configurações codificadas nos repositórios e controlando as permissões nesses repositórios.

Então, agora a questão é: como as equipes e os administradores podem aproveitar melhor todo esse poder?

Eu tenho algumas dicas e sugestões para você. A maioria é destinada a usuários do dia a dia que criam planos e implantações. Mas não feche esta guia ainda, administradores do Bamboo - você também encontrará algumas informações úteis.

1. Aprenda exportando planos e implementações existentes do Bamboo para Especificações(Specs)

Se você já tiver uma instância do Bamboo com planos e implantações, a exportação acelerará seu processo de aprendizado e tornará sua experiência de migração perfeita. É um ponto de partida perfeito se você não sabe muito sobre as especificações (Specs) do Bamboo ou a configuração como código em geral.

Verifique a documentação sobre como exportar suas configurações existentes do Bamboo para Specs. No código gerado durante a exportação, você verá como a estrutura do Bamboo é representada por várias classes Java dedicadas e chamadas de método.

Se você ainda não tem planos do Bamboo e está apenas começando sua jornada com o Bamboo, o recurso de exportação ainda pode ser útil. Primeiro de tudo, você pode tentar criar um plano por meio da interface do usuário e exportá-lo para ter uma base de código funcional. Além disso, ele pode ser usado para ajudá-lo a descobrir como configurar áreas específicas do Bamboo via código. Se você souber onde ir na interface do usuário para aplicar as alterações, mas não tiver ideia de como refletir essas alterações no mundo das especificações, tente aplicá-las no navegador e exporte sua configuração.

Observe, no entanto, que qualquer conteúdo exportado não se parecerá com o que você deseja na forma final de suas especificações. É apenas algo para começar. A especificação gerada funcionará para que possa ser imediatamente confirmada em um repositório VCS para uso com as especificações armazenadas no Repositório. A partir daí, é uma questão de melhorias de código e refatoração.

2. Teste suas especificações(Specs)!

Um dos pontos fortes das especificações Java do Bamboo é que a validação offline está disponível gratuitamente. A validação local permite que você escreva testes unitários mais significativos para seu conteúdo. Simplesmente construir seu plano ou projeto de implantação executa a maioria das verificações. Além disso, testar sua configuração traz possibilidades como consistência em toda a empresa. Testes também podem ajudá-lo a validar a compatibilidade com políticas e estruturas organizacionais.

Há, no entanto, algo que você precisa estar ciente. Como a validação local está acontecendo off-line, algumas restrições do Bamboo não serão verificadas. Não é 100% garantido que os planos que passarem nos testes serão aceitos posteriormente pelo Bamboo. No entanto, muitos erros típicos e erros de programação podem ser detectados precocemente.

Aqui está um exemplo de código para demonstrar a verificação básica da sua especificação de plano:

import com.atlassian.bamboo.specs.api.builders.plan.Plan;
import com.atlassian.bamboo.specs.api.util.EntityPropertiesBuilders;
import org.junit.Test;

public class MyPlanTest {
    @Test
    public void testMyPlan() {
        final Plan myPlan = ...;

        // if validation fails, an exception will be thrown
        EntityPropertiesBuilders.build(myPlan);
    }
}

3. Se possível, mantenha as especificações do Bamboo e seu código de construção juntos

Esta é uma grande decisão a tomar: onde armazenar as especificações da Bamboo. Meu conselho é manter o código e a definição do IC juntos, pois eles estão intimamente acoplados. Considere as especificações da Bamboo como Makefile de nível mais alto para o seu código. Suas fontes, bem como as informações “como construí-lo”, “como testá-lo adequadamente” e até “como implantá-lo” devem ser co-localizados.

Dito isso, há casos em que você deseja separar suas especificações do bamboo da sua base de origem. Para dar alguns exemplos, um repositório contendo Bamboo Specs pode operar em vários repositórios de código-fonte, e nenhum deles pode tecnicamente “possuir” a definição do pipeline de construção. Ou, é mais eficiente manter permissões para um único repositório VCS.

Em última análise, você deve procurar usar fontes e especificações juntos, mas não forçar esta premissa. Geralmente, os pipelines de construção complexa são únicos e, portanto, é difícil dizer qual opção é objetivamente melhor.

4. Extrair progressivamente a configuração de compilação comum para componentes compartilhados

Ao migrar sua infraestrutura de criação para as especificações do Bamboo, você encontrará mais e mais semelhanças de configuração em seus planos de construção e publicação. O comportamento compartilhado não precisa ser repetido e as redundâncias podem ser removidas. Esse é um dos muitos benefícios de definir seus planos usando código! Essa abordagem permite que você extraia a lógica compartilhada em classes auxiliares / utilitárias e use padrões de programação como fábricas(factories) ou métodos de fábrica(factory).

O compartilhamento de partes da configuração nos planos reduz o custo de manutenção do código. Também torna mais fácil adicionar novos conteúdos às suas especificações de build no futuro. Ambos os fatores são críticos para a infraestrutura de build escalonável.

Para dar um exemplo: a equipe de desenvolvimento da Bamboo descobriu um padrão muito comum de testar plugins no núcleo do Bamboo. As tarefas que foram executadas para cada plugin pareciam quase idênticas. Foi quando decidimos criar helpers e utilitários para eles. Atualmente, definir um plugin para ser construído e testado contra o Bamboo requer a adição de apenas algumas linhas de código, com algumas opções de configuração disponíveis. Um bug descoberto para um plugin será automaticamente corrigido para todos eles. Alterações gerais na configuração do IC? Sem problemas! Aplicado em todos planos.

Nos planos de criação (build) e teste do Bamboo, compartilhamos a lógica de tarefas, projetos, planos, capacidades, variáveis, artefatos, notificações e muito mais!

Abaixo está um exemplo de uma classe e método auxiliares. Ele se baseia em um enum para garantir que apenas versões conhecidas e disponíveis do Node.js sejam usadas por nossas construções:

/**
 * Node.js task shortcuts.
 */
public class NodeTasks {
    /**
     * Node.js executables configured on our agents.
     */
    public enum NodeExecutable {
        NODE_8("Node.js 8"),
        NODE_6("Node.js 6"),
        NODE_4("Node.js 4");

        private final String executableLabel;

        NodeExecutable(String executableLabel) {
            this.executableLabel = executableLabel;
        }
    }

    public static NpmTask npmTask(String description,
                                  String command,
                                  NodeExecutable nodeExecutable) {
        return new NpmTask()
                .description(description)
                .nodeExecutable(nodeExecutable.executableLabel)
                .command(command);
    }

    ...
}

5. Maximize o poder do Java

Isso não pode ter sido enfatizado o suficiente, mas depois que você começar a "programar" / controlar seu IC, ficará difícil imaginar como alguém poderia viver sem ele. Escrevendo uma tarefa de script? Defina-a como um recurso e verifique se ele está disponível no caminho de classe quando o código é executado. Isto lhe dará o realce e a validação da sintaxe do seu IDE. Quer garantir que todos os planos criados por alguém sejam sempre testados? Use Java reflections para testes genéricos.

Abaixo está um exemplo de nossa classe de utilitários para definir tarefas de script, com o corpo de script retirado de recursos Java:

/**
 * Script task shortcuts.
 */
public class ScriptTasks {
    /**
     * Create a script task with inline body from a classpath available resource.
     */
    public static ScriptTask scriptTaskFromResource(Class<?> acquiringClass,
                                                    String resourceName,
                                                    String description) throws IOException {
        // search for the resource on the classpath under various paths
        final URL resource = ObjectUtils.firstNonNull(
                acquiringClass.getResource(resourceName),
                acquiringClass.getResource("/" + resourceName),
                acquiringClass.getResource(acquiringClass.getSimpleName() + "/" + resourceName));

        if (resource == null) {
            throw new NullPointerException("Script body not found for " + resourceName);
        }

        try (Scanner scanner = new Scanner(resource.openStream(), StandardCharsets.UTF_8.name())) {
            final String scriptBody = scanner.useDelimiter("\\A").next();
            return new ScriptTask()
                    .description(description)
                    .inlineBody(scriptBody);
        }
    }

    ...
}

6. Compartilhe partes de sua configuração entre as equipes

Se você estiver familiarizado com a cultura de DevOps, talvez já tenha encontrado equipes dedicadas responsáveis por manter a infraestrutura de criação e liberação para um grupo de equipes de desenvolvimento. Por exemplo, um pipeline de release compartilhado pode existir e deve ser usado em toda a empresa. Independentemente do motivo (manutenção, aspectos legais, o nome dele), o Bamboo Java Specs pode ajudá-lo.

Se você pode usar ferramentas como Maven ou Gradle. Tudo o que é necessário é ter dependências de artefatos mantidos por outras equipes. Esses artefatos podem produzir ou alterar suas especificações do Java no Bamboo de qualquer forma. Muitas possibilidades incluem o compartilhamento de classes auxiliares para adicionar requisitos, tarefas, estágios, variáveis ... até mesmo o código para configurar planos e implementações inteiras pode ser comum.

Além disso, não vamos esquecer as permissões. O conteúdo compartilhado pode ajudar você a configurar corretamente o esquema de permissão para o seu CI. Os utilitários comuns podem conceder permissões corretas a usuários, grupos e funções específicos para que cada equipe não precise se preocupar com a segurança no Bamboo.

7. Construa progressivamente uma estrutura para suas especificações à medida que você escala

Para muitas equipes, essa etapa pode parecer desnecessária e pode parecer um sintoma de engenharia excessiva, e isso é totalmente compreensível. Com a abordagem de pequenos módulos criados e mantidos independentemente, sua configuração de CI nunca vair exceder o tamanho para exigir uma camada adicional sobre o conjunto de ferramentas fornecido.

Mas imagine que você esteja construindo e testando um produto grande. O que você faria se precisasse testar centenas de dependências e opções de configuração? Vários sistemas operacionais, sistemas de gerenciamento de banco de dados, versões de bibliotecas… Manter uma matriz de construção multidimensional pode lhe dar dores de cabeça.

Quanto mais planos você tem, e quanto mais tempo leva para organizar suas especificações em um todo logicamente consistente, mais surge a necessidade de uma nova camada de abstração. Isso é o que eu chamo de "framework". Um pouco de inversão de controle, alguma lógica de processamento adicional, o que melhor lhe convier. Essa abordagem, na minha opinião, leva o aspecto de configuração como código do seu CI para um novo patamar. Paradoxalmente, você pode achar mais fácil controlar seu CI com “inversão de controle” no lugar.

Para dar um exemplo: a equipe de desenvolvimento do Bamboo, ao definir os planos que constroem e testam o Bamboo, surgiu com um conceito de “grupo de trabalho”. Grupos de trabalho ... bem, logicamente, agrupe os trabalhos relacionados uns com os outros (por exemplo, um grupo de tarefas que criam e testam plug-ins empacotados com o Bamboo). Os grupos de trabalho são definidos em um nível abstrato e não estão vinculados diretamente a nenhum "plano" de build.

Em um certo ponto, o framework entra em ação, o que combina grupos de trabalho em planos. Acionadores, repositórios e configurações de notificação são validados e mesclados para formar uma definição completa do plano. Grupos de trabalho definidos desta maneira podem ser passados entre planos de acordo com nossas necessidades mais livremente. Em um certo ponto, isso nos permitiu mesclar muitos planos (demais ...) juntos e simplificar uma configuração de CI excessivamente complexa.

"Configuration-as-code" tornou muito mais fácil mover blocos de construção, e é por isso que eu encorajo você a experimentar nesta área se quiser.

8. Use especificações armazenadas no repositório para log de auditoria refinado e controle de acesso delegado

Se você configurar as especificações do Bamboo armazenadas no repositório, descobrirá muitas melhorias de disponibilidade disponíveis para sua configuração de CI*.

Para melhorar a rastreabilidade, configure as especificações armazenadas no repositório como a interação principal da sua equipe com a Bamboo. Você pode restringir possíveis maneiras de os usuários alterarem os planos do Bamboo, não permitindo o acesso à UI para eles, deixando as especificações(Specs) do Bamboo como a única opção. Independentemente de como isso soa ruim, simplifica imediatamente muitas coisas, incluindo o gerenciamento de permissões do Bamboo. A acessibilidade pode ser controlada no nível do repositório (ou seja, somente usuários autorizados a submeter alterações ao repositório de Specs podem efetivamente fazer alterações no Bamboo), enquanto no próprio Bamboo apenas alguns esquemas de permissão precisam ser configurados (por exemplo, quais repositórios terão acesso a quais componentes do Bamboo).

Somente a mudança acima lhe dará o benefício de um log de auditoria alternativo e claro - via o histórico de commits do seu repositório. Além disso, com as especificações armazenadas no repositório em vigor, você pode configurar seu host VCS para permitir somente mudanças através de pull requests aprovados, para ter ainda mais controle sobre o conteúdo do Bamboo. Nunca mais se preocupe com modificações indesejadas e não detectadas em seu pipeline de CI / CD!

* Seguir esta rota significa que você perderá o acesso ao mecanismo de aprendizado sugerido na "Dica 1", acima. Por isso, recomendo ser razoável com limitações.

Configuração-como-código para a vitória

Se você nunca tentou configurar seu CI/CD via código-fonte, pode parecer um pouco estranho no começo. É uma questão de exploração e familiaridade suficientes para começar a otimizar sua configuração de CI para manutenção e escalabilidade. Espero que as dicas que eu forneci ajudem você a trabalhar mais rápido. Se você tiver experiência com configuração como código, espero que as dicas aqui trarão ao menos algumas novas ideias para melhorar seu pipeline de CI e a base de código de especificações.

A equipe de desenvolvimento do Bamboo aprendeu muito em todo o processo de desenvolvimento das especificações de Java do Bamboo. Temos migrado constantemente nosso próprio canal de desenvolvimento para o Specs, o que nos deu uma ótima oportunidade de aprender e melhorar (com um loop de feedback bastante rápido!). É por isso que acredito que as lições que aprendemos ajudarão você em sua jornada com o Bamboo.

Se o gerenciamento do seu pipeline de entrega contínua com configuração como código parece bom, espere até ver tudo o que o Bamboo tem a oferecer.


Conheça mais sobre o Bamboo


Fonte: How to win at CI with configuration-as-code and Bamboo Specs


Gostou do post? Compartilhe e siga nossas Redes Sociais 


  

Confluence e JIRA Software são como bacon e ovos, Simon e Garfunkel, vinho e queijo. Separados, são bons. Juntos eles são muito bons. De fato, mais da metade das equipes do JIRA Software já utilizam o Confluence como complemento do JIRA e seu conjunto de ferramentas de desenvolvimento ágil.

Existem várias boas razões para adicionar Confluence ao JIRA Software, mas aqui estão cinco delas:

  

1. Um lugar único para toda a documentação

Toneladas de trabalho entram em um projeto de software, requisitos de produtos, planos de projeto, documentação técnica, especificações de projeto notas de reunião de sprint...a lista é quase infinita. Enquanto JIRA é grande em ajudar a sua equipe a planejar e controlar todo o trabalho que vai em seu software, Confluence lhe dará um único lugar para organizar todo o conteúdo adicional que é criado ao longo do caminho.

Confluence elimina a necessidade de armazenar documentação em vários locais como unidades compartilhadas ou pastas Word. Com o Confluence, você pode organizar sua documentação em espaços para cada um de seus projetos ou equipes e vincular esses espaços aos seus projetos relacionados no JIRA.

Cada espaço tem uma hierarquia de conteúdo que faz sentido, além de espaços acessíveis a qualquer pessoa da equipe. Isso significa que sua equipe sempre saberá exatamente onde procurar quando precisar de algo. Além disso, integrar novos membros será mais fácil, porque toda documentação histórica está lá.

2. Quebra as barreiras de comunicação


Ao desenvolver um software, encontrar um consenso nem sempre é tão fácil. Especialmente quando se trata de decisões técnicas ou requisitos do produto. Com muitas partes envolvidas, a velocidade, transparência e qualidade torna-se cada vez mais difícil. Esta dificuldade é ampliada quando os membros da equipe são sugados para debater questões por e-mail, onde informações valiosas são "enterradas" e o contexto é perdido.

Confluence mantém sua equipe na mesma página - Literalmente! Com os modelos de requisitos prontos para usar, você pode reunir suas necessidades da equipe usando o editor colaborativo e negociar detalhes com as partes interessadas usando comentários in-line. Quando você concorda com os requisitos finais, fica fácil converte-los em issues no JIRA com apenas alguns cliques diretamente do Confluence. Em vez de colaborar com mockups de design em uma ferramenta, tarefas de desenvolvimento em outra, e stories em outra, você pode trazer todo esse trabalho para o Confluence.


3. Mantenha você (e seu processo) avançando

Enquanto o JIRA garante que sua equipe tenha fluxos de trabalho padronizados para manter sua equipe e processos funcionando sem problemas, o Confluence ajuda a manter sua equipe alinhada ao longo do caminho.

A maioria das equipes ágeis passa por quatro etapas principais ao desenvolver software. Veja como você pode usar integrações entre JIRA e Confluence para fazer a transição entre eles sem problemas.

  • Define (Definir) - Padronizar os requisitos do produto no Confluence e acompanha e gerencia as alterações à medida que elas evoluem ao longo do tempo.
  • Plan (Planejar) - Transforme os requisitos em stories no JIRA, com um único clique para iniciar o desenvolvimento, mantendo a rastreabilidade de volta às suas necessidades.
  • Release (Lançamento) - Crie e documente decisões técnicas no Confluence e publique notas de lançamento (release notes) automatizadas e altere logs que refletem no JIRA.
  • Improve (Melhore) - Reflita e melhore seu processo executando retrospectivas com um template no Confluence de como foram suas Sprints.

Em cada etapa você tem rastreabilidade em todo o seu trabalho e documentação adequada para quando necessário.

4. Reduza a mudança de contexto Otimizando tempo


Confluence ajuda a manter sua equipe produtiva. O Confluence incorpora automaticamente os novos problemas do JIRA e nos seus documentos de requisitos relacionados, por isso é fácil para seus gerentes de produto manter-se atualizados sobre o andamento do trabalho em equipe de desenvolvimento sendo rastreado no JIRA.

Por outro lado, seus requisitos e outras páginas do Confluence são automaticamente vinculados a seus epic e issues no JIRA, para que os desenvolvedores possam obter todo o contexto de que necessitam sem quebrar seu fluxo.

Não importa em qual ferramenta você utiliza, você tem o contexto do que está trabalhando, e rastreabilidade total. Isso significa menos dores de cabeça ao acompanhar tudo e uma maior eficiência para sua equipe, dia após dia.


5. Forneça visibilidade em seus projetos de software

Ninguém quer gastar seu tempo constantemente relatando o status de seu projeto de software. Os modelos de relatórios no JIRA facilitam a criação de relatórios destinados a essa finalidade no Confluence pelas equipes de desenvolvimento que detalham seus últimos lançamentos rastreados no JIRA. Você pode criar um relatório de status dinâmico que mostra o andamento da versão atual, ou um log de mudanças estático, que exibe o que foi alterado entre as versões mais recentes.

Esses relatórios personalizáveis permitem dar as partes interessadas um instantâneo report do progresso da equipe de desenvolvimento, com apenas alguns cliques.


Juntos, JIRA e Confluence, obviamente oferecem uma solução poderosa, perfeitamente integrada para o seu próximo projeto de software. Juntos, eles podem ajudar suas equipes de desenvolvimento a trabalhar mais rápido, comunicar de forma mais eficaz e manter a documentação organizada e facilmente acessível.


Gostou do post? Compartilhe e siga nossas Redes Sociais 


  

Priorizar o trabalho do projeto para sua equipe pode ser um exercício de frustração e arrancar os cabelos. Você precisa levar em conta o trabalho iniciado dentro da própria equipe, e você deve ponderar isso em relação a solicitações vindas de outras equipes que dependem de você.
Como uma empresa organizada em redes de equipes multifuncionais, muitas das quais têm clientes internos e externos, passamos nossa parte do tempo colidindo com a proverbial parede branca. Hoje, usamos uma técnica de matriz de priorização desenvolvida por alguns de nossos líderes em P&D. Mas ao longo do caminho, aprendemos cinco grandes lições sobre priorização de projetos que valem a pena compartilhar.

E sim: por “lições” eu realmente quero dizer “erros”. Continue lendo e tente não repeti-los com sua equipe.

Dica: Encontre instruções completas para cross-team project prioritization matrix no Atlassian Team Playbook - o guia gratuito da Atlassian para trabalhar melhor em grupo.

Lição 1: em dados que confiamos

A priorização entre equipes tem sido uma luta, mesmo dentro de equipes que constrói um único produto. Parte do problema é que, historicamente, as prioridades baseavam-se em grande parte na intuição. Isso não só levou a algumas discussões bastante… calorosas e apaixonadas, quando as prioridades foram finalmente acordadas, foram baseadas em muitas suposições.

Descobrimos que é melhor fazer um trabalho de coleta de dados antes de nos reunirmos para definir as prioridades e criar um portfólio de projetos para o trimestre (ou ano). Qual é o escopo dos problemas que precisamos resolver? Como esses problemas afetaram negativamente os clientes e os negócios até o momento? Qual é o valor em resolvê-los?

A priorização do projeto será sempre baseada em opinião, de certa forma. Mas as opiniões embasadas levam a melhores decisões.

Lição 2: priorizar o trabalho com base em critérios consistentes

Similar à priorização baseada na intuição, muitas vezes somos vítimas do pensamento de grupo. Era comum que os líderes de equipe se reunissem em uma sala e fizessem um brainstorming de ideias de projetos que realizassem seus objetivos de alto nível. Então, cada pessoa na sala fazia cinco “votos”. As idéias mais populares seriam priorizadas e o restante seria deixado para trás.

Para manter as ideias sexy, mas, em última instância, ineficazes, de forma a monopolizar os holofotes, use um conjunto consistente de critérios para avaliar o valor de todas as ideias e tarefas que você está considerando. Comece descrevendo todos os fatores que você poderia otimizar (por exemplo, tempo, orçamento, potencial de receita, etc.) e decidindo quais são os itens essenciais absolutos. Em seguida, use-os como base para avaliar e priorizar o trabalho do projeto. A técnica do “trade-off sliders” é usada aqui.

Lição 3: Concorde com os objetivos que você possa cumpri-los

Você entra em uma reunião de priorização. Todo mundo começa a falar sobre as coisas que eles acham que são importantes, mas você não está dirigindo na mesma direção. Você acaba concordando em fazer muito mais do que você tem a capacidade para. Você sai com um backlog de classificação em pilha, mas não consegue articular por que um item adiciona mais valor do que outro.

Soa familiar? Sim.

A solução é simples: concorde com as metas prioritárias e cumpra-as. (Não é fácil, necessariamente ... mas simples.) Se um projeto não se alinhar com pelo menos um objetivo, ele fica na coluna "não vai". Como um bônus, entender o Norte da equipe facilita para os membros da equipe tomar decisões diárias de forma autônoma.

Dica: o Google foi pioneiro em uma estrutura para definir metas em nível de equipe e departamento chamadas Objectives and Key Results (OKRs). Baixe este modelo gratuito e encontre instruções detalhadas para OKRs aqui.

Lição 4: Brainstorm individualmente, priorize colaborativamente

Não muito tempo atrás, não era incomum que uma reunião trimestral de priorização durasse 3 horas. Ai! Com o objetivo de nível superior do grupo em mente, eles pensavam em formas de alcançá-lo e priorizavam essas ideias. Era confuso, ineficiente e baseado mais em opinião do que em pesquisa ou dados.

Agora fazemos essa parte de forma assíncrona. Os participantes desenvolvem idéias individualmente como pré-trabalho e os enviam para feedback. As ideias que não aumentam a meta do grupo são retiradas antes mesmo de a reunião de priorização começar. Como resultado, essas reuniões são em média de 30 minutos. Fantástico.

Lição 5: Priorizar o trabalho do projeto com um período de tempo específico em mente

Dizer não é difícil quando existem tantas boas ideias por aí. Então, nós costumávamos sair das sessões de priorização com muitos itens no backlog - alguns dos quais eram de alto impacto, mas não tão urgentes. Foi confuso para nossas equipes e, finalmente, desmoralizante.

Aprendemos a priorizar projetos com um determinado período de tempo em mente. É muito mais fácil permanecer fiel aos seus objetivos (e capacidade!) Ao dizer que não significa "não neste trimestre" em vez de "nunca". Descobrimos que a alocação de cerca de 50% de sua capacidade para itens indispensáveis e 25% para itens agradáveis funciona bem. Isso deixa você com a capacidade de absorver os problemas que inevitavelmente serão jogados no meio do caminho.

Uma nova maneira de priorizar projetos

Então, onde é que finalmente desembarcamos, graças a essas lições difíceis de aprender? Em um bom lugar, na verdade. Graças à nossa equipe de gerentes de programa e líderes de engenharia, reunimos uma técnica que pode ser usada no nível de equipe ou departamento.

Todos os líderes de equipe envolvidos concordam em seu maior e mais importante objetivo coletivo, e depois anotam todas as idéias de seus projetos em cartões indexados. Os cartões são então colocados em uma matriz de acordo com a urgência do projeto e com o tamanho esperado de seu impacto. Em seguida, pedidos de outras equipes são colocados na matriz da mesma maneira. Por fim, avaliamos aproximadamente o esforço envolvido em cada uma delas e definimos zonas na matriz que representam itens essenciais (must-haves), agradáveis(nice-to-haves) e não-ideais agora(won’t-do-right-now). (Instruções completas aqui.)

Essa técnica ainda está em seus primórdios em torno da Atlassian, então provavelmente ela vai passar por alguns ajustes, já que mais equipes a estão adotando. Mas não deixe que isso impeça você e sua equipe de tentar agora. E deixe-nos saber como vai! Marque a história de priorização de projetos da sua equipe para @Atlassian  com a hashtag #TeamPlaybook.

...

Há mais no planejamento de alto nível e longo prazo do que na priorização. Confira nosso plano de jogo para planejamento de operações, incluindo nossas quatro principais técnicas para definir metas, comunicar seus planos e muito mais.

Fonte: Ester artigo é uma tradução livre de https://www.atlassian.com/blog/teamwork/project-prioritization-mistakes-and-cures


Gostou do post? Compartilhe e siga nossas Redes Sociais 


A adoção ágil em escala empresarial continua a crescer, impulsionando a evolução no mercado para planejamento e gerenciamento. Os líderes de aplicativos que buscam facilitar a coordenação e a colaboração, ao mesmo tempo em que permitem uma visão do fluxo de trabalho de suas organizações, devem considerar as ferramentas de planejamento ágil da empresa.

Definição / Descrição do Mercado

As ferramentas de planejamento ágil corporativo (EAP) ajudam as organizações a usar práticas ágeis em escala para obter um desenvolvimento ágil de nível corporativo. Isso é obtido por meio de práticas de suporte orientadas a resultados de negócios, centradas no cliente, colaborativas e cooperativas, bem como com feedback contínuo das partes interessadas. Essas ferramentas representam uma evolução das ferramentas ágeis centradas no projeto e das ferramentas tradicionais de gerenciamento do ciclo de vida de desenvolvimento de aplicativos (ADLM). A maioria dos produtos no mercado de ferramentas EAP é executada no conjunto geral de produtos ADLM, atuando como um ponto central para a definição e o gerenciamento do rastreamento de itens de trabalho.


Há também uma relação com as ferramentas de gerenciamento de projetos e portfólio (PPM). As ferramentas de PPM estão se movimentando de maneira agressiva para fornecer suporte de desenvolvimento ágil de classe empresarial, colmatando a lacuna entre o ágil e o não-ágil. Enquanto isso, as ferramentas EAP estão adicionando recursos de PPM . Além disso, existe uma relação com o software de roadmapping de produtos. Os primeiros sinais de consolidação do mercado estão aparecendo.
Este Quadrante Mágico analisa ferramentas especificamente focadas no desenvolvimento de software através do uso de metodologias ágeis. No geral, vemos várias tendências que impulsionam as decisões de aquisição para essas ferramentas:

  • A adoção ágil se tornou predominante - Agile agora é responsável por mais atividades de desenvolvimento de software do que qualquer outro tipo de metodologia. A competência ágil está crescendo em todo o setor.

  • Estratégias fragmentadas -  A maioria dos clientes ainda é predominantemente o melhor usuário do EAP e das ferramentas relacionadas, refletindo as estratégias de ferramentas fragmentadas de muitas organizações de usuários finais antes de adotar o desenvolvimento ágil de classe empresarial.

  • Negócios digitais -  As estratégias de negócios digitais continuam a promover adoção e maturidade ágeis, impulsionadas pela necessidade de recursos mais fortes do Modo 2.

  • DevOps -  O crescente uso do DevOps e sua extensão no negócio significam que compromissos estratégicos paralelos com o desenvolvimento ágil e a governança são necessários.

  • Amadurecendo estruturas ágeis -  À medida que as organizações aplicam agilidade a esforços de desenvolvimento de software maiores, as estruturas ágeis corporativas estão se tornando mais maduras e mais amplamente adotadas, como o Scaled Agile Framework (SAFe), Scrum de Grande Escala (LeSS) e Disciplined Agile (DA).

  • Gerenciamento de produtos -  O impulso para fornecer valor contínuo levou as empresas a mudar de uma abordagem de entrega de software baseada em projeto para uma que trata aplicativos como produtos. A mudança correspondente ao gerenciamento de produtos coloca novas demandas nas ferramentas EAP.


Metodologias de desenvolvimento ágeis são processos de desenvolvimento iterativos altamente acelerados. Eles precisam de ferramentas que suportem:

  • Entregas mensais, semanais e até diárias com base nos resultados de negócios

  • Maior visibilidade do fluxo de trabalho

  • Requisitos capturados em épicos, recursos, histórias de usuários e tarefas

  • Práticas colaborativas e de turnos-esquerda, como o desenvolvimento orientado a testes


Os princípios de colaboração, integração contínua, refatoração e promoção de propriedade também se tornam recursos-chave do produto. A partir de uma perspectiva bimodal, a agilidade é necessária para os projetos bem-sucedidos do Modo 2 e pode melhorar a execução dos projetos do Modo 1.
As ferramentas EAP devem permitir o uso de agilidade na empresa. Isso significa suportar práticas ágeis que abranjam a organização e que abrangem os maiores esforços de desenvolvimento de software.  Assim, as ferramentas nesta pesquisa têm recursos para planejar e colaborar em um nível de equipe, mas também fornecem funcionalidade que permite o dimensionamento em várias equipes. Dito isso, o foco e a força relativos no nível de equipe versus a empresa variam de produto para produto.
A adoção ágil tem sido tradicionalmente direcionada principalmente de baixo para cima, e o desenvolvimento ágil de classe corporativa é uma evolução natural do nível de projeto ágil para suportar as necessidades do gerenciamento de software em grande escala. Frequentemente, as necessidades das próprias equipes ágeis diferem daquelas de sua administração, o que levou ao uso de um conjunto de ferramentas. A adoção estratégica de agilidade de cima para baixo está crescendo agora, impulsionada por iniciativas de negócios digitais que exigem a rápida entrega de soluções para novos tipos de problemas. A adoção top-down também foi acelerada pela crescente conscientização do cliente sobre estruturas como o SAFe. Mas deve-se notar que o escalonamento ágil pode acontecer de muitas maneiras diferentes, inclusive de baixo para cima.
As organizações que fazem seleções nesse mercado precisam ter estratégias claras para uso e suporte direcionados. Embora as ferramentas forneçam funções importantes, elas devem estar alinhadas e suportadas pela cultura e práticas da organização. Diferentes organizações terão requisitos diferentes, como conformidade regulatória, que podem restringi-los a práticas específicas, ou podem enfrentar barreiras culturais que afetam compromissos e colaboração.
Ferramentas bem-sucedidas também funcionarão como parte de uma cadeia de ferramentas geral do DevOps, servindo como um hub para informações que serão usadas para planejar e criar medidas de entrega de valor.  Esperamos que isso inclua a criação de informações analíticas, como um painel de indicadores-chave de desempenho (KPI) que inclua:

  • Atributos técnicos -  densidade de defeitos, dívida técnica, taxa de refatoração, QA

  • Atributos de negócios -  valor do backlog, ciclo e lead time, capacidade de resposta, flexibilidade


Esperamos que esse painel de KPI seja disponibilizado para todas as partes interessadas.

Quadrante Mágico


Figura 1. Magic Quadrant para Enterprise Agile Planning Tools

Forças e Precauções do Fornecedor

AgileCraft

O produto de software EAP do AgileCraft também é chamado de AgileCraft. Posicionamos o fornecedor no quadrante Visionários.
Considere o AgileCraft se: você estiver procurando por uma solução completa com suporte a framework.
Um novo fornecedor neste Quadrante Mágico, o AgileCraft oferece uma solução abrangente para organizações de grande porte que desejam adotar agilidade e DevOps. Ele tem suporte integrado para várias estruturas ágeis corporativas, incluindo o SAFe. O AgileCraft pode acumular dados de equipes usando várias metodologias e ferramentas em nível de equipe. Ele pode rastrear mudanças de software desde a ideação até o toolchain do DevOps para ser lançado.

Forças
  • A solução AgileCraft é construída em torno de uma visão clara das práticas modernas de desenvolvimento de software. Ele pode abranger uma ampla gama de práticas em todos os casos de uso que esse Magic Quadrant aborda.

  • O AgileCraft suporta perfeitamente as equipes que usam o Jira Software, o Team Foundation Server e o próprio AgileCraft para rastreamento de histórias.

  • A interface de usuário (UI) do AgileCraft é moderna, simples e elegante.

Cuidados
  • Apesar da simplicidade da interface, a solução é muito extensa - pode levar algum tempo e análise para encontrar a melhor maneira de usar o AgileCraft em sua organização.

  • O AgileCraft é um dos fornecedores mais novos no mercado e não possui um histórico tão longo quanto alguns de seus concorrentes.

  • O AgileCraft suporta uma ampla gama de práticas de desenvolvimento. Isso pode permitir que algumas práticas legadas permaneçam em sua organização.

Atlassian


Os produtos de software EAP da Atlassian são o Jira Software and Portfolio for Jira. Posicionamos a Atlassian no quadrante dos Líderes.
Considere a Atlassian se : você está procurando uma solução popular em nível de equipe para desenvolvimento ágil e tradicional, quando a funcionalidade avançada em nível de portfólio não é essencial.
A solução Atlassian tem foco no gerenciamento de tarefas, incluindo gerenciamento de itens de trabalho, rastreamento de defeitos e colaboração em equipe. A solução mostra que o fornecedor investiu em integração. A Atlassian fornece preços simples, renunciando a uma equipe de vendas corporativas para compra de cartão de crédito on-line.

Forças
  • Uma grande base de clientes para a solução de liderança da Atlassian o Jira dirige um forte mercado de terceiros na forma do Atlassian Marketplace. Isso ajuda a preencher as lacunas na funcionalidade.

  • O suporte para o repositório de código-fonte aberto líder do Git através do add-on Bitbucket, bem como a integração contínua via Bamboo, posiciona o Atlassian para as organizações que implementam as práticas de DevOps.

  • Os recursos de colaboração via Stride, Confluence e aquisição de 2017, o Trello, estendem o alcance de mercado da Atlassian para além da equipe principal de desenvolvimento de aplicativos, para incluir clientes, usuários finais e outras partes interessadas.

Cuidados
  • Em parte devido às suas capacidades limitadas de portfólio, a Jira não oferece suporte nativo para o SAFe nem para outras estruturas ágeis corporativas líderes - embora os parceiros da Atlassian ofereçam tais soluções.

  • Os recursos de relatório do Jira, embora poderosos, são complexos de configurar e acessar. No entanto, existem alguns relatórios prontos para uso e o Atlassian Marketplace oferece muitas soluções de relatórios de parceiros.

  • Alguns clientes da Atlassian ainda relatam desafios com personalização, embora a maioria relata facilidade de instalação e distribuição.

Blueprint


O produto de software EAP da Blueprint é o Storyteller. Posicionamos o Blueprint no quadrante de jogadores de nicho.
Considere o Blueprint se:  você está procurando uma solução EAP baseada em modelagem visual.
A Blueprint tem uma oferta exclusivamente visual baseada nesse mercado. A solução Storyteller começa com um modelo visual do software e mapeia esse modelo para histórias, planos de teste e automação de implementação. O foco está em definir o que será construído, em vez de rastrear o trabalho. A metáfora visual é um fluxograma de alto nível, com a capacidade de detalhar cada elemento. Os elementos podem ser rastreados através do processo de desenvolvimento e lançamento. A proeminência do modelo visual incentiva uma abordagem focada no design.

Forças
  • O Blueprint Storyteller fornece uma solução única, baseada em modelo visual, que suporta instalações ricas para elaboração de histórias, incluindo desenvolvimento orientado a comportamento.

  • O Blueprint oferece uma ferramenta integrada para conformidade e gerenciamento de riscos.

  • O Blueprint Storyteller integra-se com outras ferramentas EAP para funcionalidades adicionais de Scrum e Kanban.

Cuidados
  • Modelo visual do Blueprint Storyteller é a chave para o produto; os usuários que não fizerem uso dele não perceberão todo o potencial do produto.

  • A funcionalidade de rastreamento de trabalho Scrum e Kanban no Blueprint Storyteller é muito limitada.

  • Blueprint Storyteller promove uma abordagem de modelagem visual para roadmaps, backlogs e histórias que alguns usuários podem achar pouco familiar.

CA Technologies


O produto de software EAP da CA Technologies é o CA Agile Central. Posicionamos a CA Technologies no quadrante de líderes.
Considere a CA Technologies se:  você está procurando o melhor gerenciamento ágil de projetos, programas e portfólios.
O CA Agile Central combina a funcionalidade de nível de equipe com o PPM. O produto mostra força no suporte SAFe, colaboração e gerenciamento de portfólio. Os produtos complementares da CA fornecem um amplo conjunto de ferramentas ágeis e DevOps, e sua presença global significa uma base de clientes significativa, além de recursos de vendas e suporte.

Forças
  • A CA continua inovando nesse mercado e oferece forte funcionalidade para gerenciamento ágil de projetos, programas e portfólio.

  • A CA oferece suporte abrangente para organizações novas no ágil, por meio do seu grupo Agile Transformation Services.

  • A CA tem um grande portfólio de produtos com suporte para ágil e DevOps em escala corporativa.

Cuidados
  • Embora a integração do Rally da CA tenha progredido, a sobreposição dos recursos de PPM entre as ferramentas tradicionais de PPM e as ferramentas ágeis do par permanece. A CA não tirou total proveito da potencial sinergia entre seus grupos Agile Central e DevOps.

  • Embora a CA tenha várias integrações entre o CA PPM e o CA Agile Central, os clientes que usam o PPM tradicional da CA precisam considerar como as soluções são usadas juntas ao usar o CA Agile Central em uma organização com foco no produto.

  • Os clientes de referência da CA relataram a menor satisfação com o valor fornecido pelo produto EAP pelo dinheiro gasto de todos os fornecedores neste Quadrante Mágico.

CollabNet


O produto de software EAP da CollabNet é o ciclo de vida VersionOne. Posicionamos a CollabNet no quadrante de líderes.
Considere o Collabnet se:  você está focado ou migrando para o ágil, ou planejando implementar Scrum, Kanban, XP ou SAFe.
A CollabNet adquiriu o VersionOne em agosto de 2017. Antes disso, o VersionOne liderava o mercado com uma série de inovações, notadamente escalando o suporte através de estruturas ágeis corporativas (via Lifecycle) e integração com pipelines DevOps (via Continuum). O VersionOne oferecia termos de licenciamento favoráveis e flexíveis, bem como facilidade de implementação e uso; isso parece continuar após a fusão.

Forças
  • A abordagem de plataforma do VersionOne Lifecycle fornece uma solução ágil corporativa abordando vários níveis de uma organização, desde o gerenciamento de portfólio até o suporte a equipes.

  • O VersionOne Lifecycle suporta totalmente as metodologias Scrum, Kanban, XP e SAFe, bem como, em menor grau, abordagens DA, LeSS e híbridas.

  • O VersionOne Lifecycle tem um amplo conjunto de integrações pré-construídas, bem como suporte de orquestração para soluções de DevOps, como Jenkins, Chef e Selenium.

Cuidados
  • Embora o VersionOne Lifecycle tenha scorecards, painéis e relatórios integrados - além de um recurso gerador de relatórios - alguns clientes desejam maior flexibilidade na personalização.

  • A maioria dos usuários do ciclo de vida do VersionOne relatou facilidade de implementação, mas alguns observaram que o treinamento e os materiais de implementação poderiam ser aprimorados e atualizados.

  • Se o ciclo de vida do VersionOne floresce sob a propriedade da CollabNet, que, de outra forma, atende a um mercado adjacente, depende tanto da inovação do produto quanto da execução de marketing; este último será mais desafiador.

IBM


O produto de software EAP da IBM é o IBM Rational Collaborative Lifecycle Management. Posicionamos a IBM no quadrante Challengers.
Considere a IBM se:  você estiver usando uma combinação de técnicas iterativas e ágeis e evoluindo para o ágil da empresa.
A IBM oferece uma ampla gama de produtos e serviços no espaço de desenvolvimento de aplicativos. Sua presença global e acesso a tecnologias altamente inovadoras o tornam bem posicionado para executar. No entanto, sua visão do mercado de software EAP se concentra fortemente na Internet das Coisas e, portanto, é mais estreita do que a de seus concorrentes.

Forças
  • A IBM possui um amplo e abrangente conjunto de produtos ADLM cobrindo todo o ciclo de vida.

  • Por meio do IBM Global Business Services, o fornecedor pode escalonar para atender às necessidades de grandes iniciativas complexas de tecnologia e transformação de negócios em qualquer região global.

  • As ferramentas da IBM acomodam usuários de produtos legados em roteiros de produtos, fornecendo suporte e caminhos de transição.

Cuidados
  • A abrangente linha de produtos da IBM significa complexidade, o que pode complicar contratos, adoção e tomada de decisão. Esse problema é mais significativo para usuários de produtos legados - menos para aqueles que usam apenas soluções mais recentes.

  • Os produtos da IBM são mais fracos em metodologias ágeis do que em metodologias iterativas.

  • Os clientes de referência da IBM relataram a menor satisfação geral com o fornecedor de todos os fornecedores neste Quadrante Mágico.

Inflectra


O software de software EAP da Inflectra é o SpiraTeam. Posicionamos o Inflectra no quadrante de jogadores de nicho.
Considere a Inflectra se:  você estiver procurando por uma ferramenta que ofereça uma abordagem abrangente de ADLM ou gerenciamento de conformidade regulatória.
A solução da Inflectra é adequada para organizações que buscam a capacidade de suportar uma conexão de requisitos a testes. Isso inclui organizações em espaços altamente regulamentados, empresas que exploram a economia do gig e organizações de serviços que precisam de monitoramento e relatórios em tempo sólido ao se conectarem a clientes que usam diversas ferramentas. A SpiraTeam foi projetada para ser flexível em sua abordagem, suportando Scrum e Kanban, bem como abordagens em cascata e híbrida.

Forças
  • A Inflectra é um dos poucos fornecedores com suporte para conformidade regulatória para vários processos regulatórios dos EUA e Europa, bem como padrões ISO.

  • A Inflectra oferece uma abordagem integrada de ADLM. Isso faz dele um dos poucos fornecedores com foco em requisitos e testes, que suporta o caminho de conformidade / auditoria / aprovação observado acima.

  • Os clientes de referência citaram alta satisfação com a Inflectra, com uma forte pontuação de pesquisa para o valor geral do produto.

Cuidados
  • Embora a SpiraTeam tenha forte rastreabilidade e suporte formal ao processo, ela não tem nenhum foco no SAFe nem na escalabilidade ágil.

  • O suporte ao portfólio do produto está melhorando, mas é muito orientado a projetos. Isso o torna menos adequado para organizações que estão mudando para o desenvolvimento centrado no produto.

  • A Inflectra tem um conjunto menor de parceiros de solução e tecnologia do que outros na categoria, significando acesso global mais limitado e menos integrações de produtos.

Micro Focus


Os produtos de software EAP da Micro Focus são o ALM Octane e o Project and Portfolio Management (PPM). Posicionamos a Micro Focus no quadrante de jogadores de nicho.
Considere a Micro Focus se:  você usa uma mistura de processos rápidos e em cascata e deseja uma abordagem orientada para a qualidade e o ADLM para gerenciar um portfólio de projetos.
A Micro Focus possui um amplo portfólio de ativos para planejamento e requisitos por meio de garantia de qualidade e liberação. A ALM Octane se concentra no suporte à conformidade e rastreabilidade. Enquanto a Micro Focus fornece suporte para o SAFe, ela não está focada em suportar todas as nuances da especificação 4.5; parte disso se deve às instruções legadas do usuário do PPM e do ALM.

Forças
  • A Micro Focus oferece uma plataforma unificada para PPM através da entrega, fornecendo tomada de decisão analítica e planejamento preditivo com escala comprovada para suportar grandes equipes.

  • A Micro Focus oferece suporte a projetos ágeis e não-ágil, o que pode ajudar os clientes na transição para a agilidade. Sua plataforma ALM Octane tem um forte suporte de código aberto.

  • A Micro Focus tem uma boa base em análise. Ele pode extrair dados de um amplo conjunto de clientes e projetos para criar uma base para o planejamento preditivo.

Cuidados
  • Os clientes da Heritage Hewlett Packard Enterprise continuam expressando sua preocupação com a Micro Focus sob uma perspectiva de licença e prática de auditoria, embora a empresa tenha feito um bom trabalho ao apoiar os principais clientes durante a transição.

  • O suporte a processos ágeis da empresa fica aquém do dos Líderes nesse Quadrante Mágico, embora esteja alinhado com as necessidades de processos e conformidade mistos da base de clientes da Micro Focus.

  • Embora a Micro Focus tenha simplificado seu modelo de licenciamento, o licenciamento continua complexo e com preço premium em comparação com a concorrência mais nativa em nuvem.

Microsoft


O produto de software EAP da Microsoft é o Visual Studio Team Services (VSTS). Posicionamos a Microsoft no quadrante de líderes.
Considere a Microsoft se  : você usa métodos ágeis e não-ágil, suas equipes de desenvolvimento ágil devem atingir várias plataformas (Linux, Windows, Android, macOS, iOS) ou você investiu pesado no ecossistema de desenvolvimento da Microsoft.
A Microsoft oferece um amplo conjunto de funcionalidades disponíveis no local ou na nuvem, incluindo suporte comprometido a tecnologias de código aberto, bem como integração com as principais ferramentas de repositório de código aberto Git e DevOps. O fornecedor planeja melhorar seu marketing e visibilidade fora da equipe de desenvolvimento, a fim de atrair usuários comerciais não técnicos como adotantes iniciais.

Forças
  • A Microsoft oferece fluxos sociais e histórico de itens de trabalho no VSTS para melhorar a colaboração e a rastreabilidade entre os desenvolvedores.

  • A integração da Microsoft com o Git oferece a capacidade de criar uma ramificação de tópico Git de cada história de usuário no quadro Kanban e tê-la mesclada ao commit, vinculando histórias, bugs e outros itens de trabalho à solicitação pull.

  • A Microsoft Developer Network fornece materiais de treinamento para desenvolvedores atualizados continuamente, bem como acesso ao software.

Cuidados
  • A Microsoft ainda visualiza todo o trabalho de desenvolvimento de uma perspectiva orientada a projetos, e não de produtos. Isso o torna menos adequado para organizações que adotam uma abordagem orientada a produtos.

  • O hub de placas VSTS da Microsoft poderia fazer com alguns aprimoramentos. Por exemplo, o quadro Kanban é um pouco inflexível em termos de personalização.

  • A Microsoft não suporta nativamente estruturas ágeis corporativas, em vez disso, depende de parceiros para tal suporte.

Planview


O produto de software EAP da Planview é o LeanKit. Posicionamos o Planview no quadrante de jogadores do nicho.
Considere o Planview se:  você estiver procurando por uma ferramenta para dar suporte às práticas Kanban dentro e fora de TI.
O LeanKit tem uma forte presença em práticas lean estilo Kanban. Sua recente aquisição pela Planview significa que deve se fortalecer na área de portfólio e fornecer uma proposta de valor conjunta para os clientes. O produto LeanKit tem um bom suporte para dimensionamento e uma visão de portfólio, abordagem de gerenciamento financeiro para apoiar iniciativas de negócios. Ele fornece modelos para apoiar áreas de desenvolvimento, como operações, estratégia de negócios, gerenciamento de portfólio e educação. As organizações podem criar seus próprios modelos padrão para compartilhar e reutilizar.

Forças
  • O LeanKit oferece um sistema flexível baseado em Board que evolui conforme suas necessidades mudam. Os boards podem crescer em complexidade e agora se integram em um forte conjunto de recursos PPM.

  • O LeanKit tem um bom suporte integrado para acompanhar atividades e conversas, bem como um conjunto crescente de integrações de produtos.

  • Com o foco no Kanban, o LeanKit também atrai facilmente um público mais amplo fora do desenvolvimento, onde as ferramentas baseadas no Scrum também podem não funcionar.

Cuidados
  • Organizações que querem uma verdadeira experiência com o SAFe 4.5 encontrarão o LeanKit faltando neste momento. Geralmente, as organizações que desejam o uso de técnicas Scrum encontrarão a ferramenta mais atrasada que as dos líderes de mercado.

  • Embora o LeanKit tenha melhorado os recursos de integração, a maioria deles é construída por meio de provedores de terceiros.

  • Antes da aquisição, o LeanKit tinha um escopo mais restrito de cobertura geográfica do que os Líderes nesse Quadrante Mágico, sem funcionários ou escritórios na Ásia / Pacífico.

Targetprocess


O produto de software EAP do Targetprocess também é chamado de processo-alvo. Nós posicionamos o Targetprocess no quadrante Visionaries.
Considere o processo de segmentação se:  você estiver procurando aplicar técnicas ágeis a áreas não relacionadas à TI de sua organização, bem como dentro de TI.
O Targetprocess fornece uma solução flexível com suporte para práticas baseadas em Kanban e Scrum. Isso atrairá as organizações que estão começando ou amadurecendo sua capacidade ágil. O processo de segmentação parece ter aumentado suas capacidades de suporte para satisfazer os usuários, e tanto seu roteiro quanto seu histórico mostram uma direção consistente. A integração com outras ferramentas não é abrangente, portanto, as perspectivas devem garantir que outros produtos sejam suportados.

Forças
  • O Targetprocess fornece forte suporte Kanban, bem como suporte a Scrum e SAFe, e é capaz de escalar do nível de equipe para o nível corporativo.

  • O processo de segmentação é muito flexível e personalizável, tornando-o aplicável a toda a organização.

  • Os clientes de referência da Targetprocess ficaram satisfeitos com a avaliação e o processo de negociação do contrato.

Cuidados
  • O processo-alvo está mostrando crescimento, mas permanece pequeno em relação aos concorrentes.

  • Os clientes de referência do Targetprocess classificaram a funcionalidade de previsão do produto como inferior à de outros provedores neste Magic Quadrant.

  • A cobertura geográfica do Targetprocess é mais fraca em comparação com os outros fornecedores neste Magic Quadrant. Tem uma presença menor nos EUA do que os Líderes e nenhuma equipe ou escritórios na Ásia / Pacífico. É mais forte na Europa, onde está sediado.


Fornecedores adicionados e descartados


Analisamos e ajustamos nossos critérios de inclusão para Magic Quadrants conforme os mercados mudam. Como resultado desses ajustes, a combinação de fornecedores em qualquer Quadrante Mágico pode mudar com o tempo. A presença de um fornecedor em um Magic Quadrant em um ano e não no próximo não indica necessariamente que mudamos nossa opinião sobre esse fornecedor. Pode ser um reflexo de uma mudança no mercado e, portanto, mudou critérios de avaliação, ou de uma mudança de foco por esse fornecedor.

Adicionado

  • AgileCraft -  uma menção honrosa no Magic Quadrant 2017; uma adição este ano.

  • Blueprint -  uma menção honrosa no Magic Quadrant 2017; uma adição este ano.

  • Micro Focus -  adquiriu o negócio de software da Hewlett Packard Enterprise em um acordo finalizado em setembro de 2017.

Desistiu

  • Hewlett Packard Enterprise -  desmembrou seus negócios de software para a Micro Focus em um acordo finalizado em setembro de 2017.

  • VersionOne -  fundido com a CollabNet em agosto de 2017.

Critérios de Inclusão e Exclusão

  1. O fornecedor deve ter recebido uma receita mínima de US $ 10 milhões ou em moeda local equivalente de licenças, assinaturas e manutenção para produtos nesse mercado ("os produtos"), no ano encerrado em 31 de dezembro de 2016.

  2. O fornecedor deve ter pelo menos dois clientes com 500 ou mais usuários licenciados e pagos de pelo menos um dos produtos.

  3. O fornecedor deve ter pelo menos 10.000 usuários licenciados e pagos de pelo menos um dos produtos.

  4. Os produtos devem ter sido geralmente disponíveis para os clientes (ou seja, não em versão beta ou outra versão limitada) e ativamente comercializados durante todo o período de 1º de setembro de 2013 a 31 de agosto de 2017, sem interrupções significativas nos produtos, produtos ou serviços 'marketing e disponibilidade.

  5. O fornecedor deve fornecer serviços, incluindo suporte e treinamento, bem como a implementação dos produtos.

  6. O fornecedor deve ter uma presença direta (ou seja, pelo menos um escritório) em cada uma das seguintes regiões: EMEA, APAC e as Américas.

  7. Os produtos devem suportar pelo menos dois dos casos de uso definidos (veja abaixo), que o fornecedor deve demonstrar durante o processo do Magic Quadrant

  8. Os produtos devem suportar as seguintes funções específicas:

    • Gerenciamento de projetos multiteam

    • Acompanhamento e relatórios de dependência entre projetos e portfólio

    • Backlogs em nível de portfólio

  9. Os produtos devem ser fornecidos ao cliente por meio da nuvem e devem, a critério do cliente, estar disponíveis para instalação no local.

  10. Os produtos devem incluir uma API de integração RESTful.

Casos de Uso Definidos


Os casos de uso definidos referenciados no Critério 7 são os seguintes:

  • Único Time Scrum: A ferramenta é usada para planejar e rastrear as atividades de uma única equipe Scrum que está desenvolvendo o time-boxed.

  • Única equipe Lean / Kanban: A ferramenta é usada para rastrear e coordenar as atividades de uma única equipe lean / Kanban que está desenvolvendo continuamente.

  • Portfólio de produtos: A ferramenta é usada para planejar e rastrear um conjunto de tribos, cada uma composta de duas a nove equipes designadas a longo prazo para um único conjunto de produtos.

  • Portfólio de Projetos e Programas: A ferramenta é usada para planejar e acompanhar um grande conjunto de 10 ou mais equipes trabalhando em um portfólio de projetos e / ou produtos.

  • Metodologias Mistas: A ferramenta é usada para planejar e acompanhar um conjunto de equipes que fazem uma combinação de duas ou mais metodologias (por exemplo, projetos ágeis e em cascata).

  • Terceirizado: A ferramenta é usada para planejar e acompanhar o trabalho em um conjunto de equipes internas e terceirizadas usando ferramentas diferentes, mas trabalhando no mesmo portfólio.

  • Distribuído: a ferramenta é usada para dar suporte a equipes em que equipes inteiras ou membros individuais da equipe são distribuídos em diferentes locais e fusos horários.


Menções Honrosas


Vários fornecedores neste mercado não atenderam aos nossos requisitos este ano. Esses fornecedores podem ter uma forte funcionalidade do produto, mas ainda não têm a receita ou a distribuição de produtos exigida - ou podem ter uma visão um pouco diferente sobre como as equipes coordenam ou sua abordagem de desenvolvimento e dimensionamento. Alguns desses fornecedores podem funcionar bem para pequenas e médias empresas e oferecer um melhor ajuste corporativo, mas não são voltados para grandes empresas ou abordagens de portfólio. Continuaremos a avaliá-las e algumas poderão fazer parte do seu processo de avaliação agora ou no futuro.

  • Axosoft

  • Digité

  • Favro

  • Fog Creek

  • Panaya

  • Pivotal

  • ProWareness

  • Scrumwise

  • ServiceNow

  • Siemens

  • ThoughtWorks

Critério de avaliação


Habilidade para executar


A capacidade de executar tem três elementos principais: o produto em si, a capacidade de ter sucesso com a mensagem e a experiência do cliente. Nós os medimos observando a entrada em pesquisas, nossas interações com clientes e materiais on-line, como mídias sociais. Estes contam uma história sobre quão bem um fornecedor está levando o produto ao mercado, evoluindo de forma consistente e respondendo às mudanças do mercado. Isso também nos ajuda a ver se a mensagem de um fornecedor está entrando em ressonância com clientes em potencial e se os clientes existentes provavelmente ficarão com esse fornecedor porque estão satisfeitos com o fornecedor e com sua direção.
Medimos uma ampla faixa de diferenciação, vista no tamanho do fornecedor e nas taxas de crescimento, na frequência que esses fornecedores aparecem nas interações do cliente e no tamanho das comunidades que consomem as informações fornecidas pelos fornecedores.

Tabela 1 : Capacidade de executar critérios de avaliação

Critério de avaliação

Ponderação

Produto ou Serviço

Alto

Viabilidade Geral

Médio

Execução de Vendas / Preços

Médio

Responsividade do mercado / registro

Médio

Execução de marketing

Alto

Experiência do cliente

Alto

Operações

Baixo

Integralidade da Visão


Nossos principais critérios são a compreensão do mercado e a estratégia do produto. A compreensão do mercado abrange o entendimento de um fornecedor de como o mercado está evoluindo, como construir uma posição que ressoa com os usuários e, em particular, como abordar os vários casos de uso, bem como suportar os caminhos ágeis e de usuário em direção ao DevOps. Descobrimos que a maioria dos fornecedores quer se posicionar como prestadores de serviços em todos os casos de uso, embora muitos possam se beneficiar de um foco mais restrito. Observamos uma quantidade razoável de amplitude para as pontuações de ambas as categorias, levando a grande parte do spread entre os fornecedores.
Além disso, consideramos a inovação como "alta", pois estamos analisando como os fornecedores estão impulsionando a funcionalidade diferenciadora, expandindo as funções atendidas e descobrindo maneiras de fornecer uma colaboração aprimorada, como suporte para ChatOps. Apesar dessa ponderação, descobrimos que as pontuações dos fornecedores caíram em uma faixa relativamente estreita aqui - ninguém é um líder descontrolado; todos têm funções específicas interessantes.
Ponderamos a estratégia geográfica como "baixa", já que muitas dessas ferramentas são entregues pela internet. Suporte e serviços também são tratados dessa maneira. No entanto, se a geografia for importante para você, é importante avaliar as opções de um fornecedor, incluindo suas próprias equipes de vendas e suporte, bem como as de seus parceiros.
Note que a Integralidade da Visão inclui uma variedade de outros elementos. "Visão" é mais do que apenas uma visão para o mercado em relação ao produto - é a capacidade da empresa de abordar o mercado por meio de sua estratégia de entrada no mercado, com diferenciação e assim por diante.

Tabela 2 : Critérios de Avaliação da Integralidade da Visão

Critério de avaliação

Ponderação

Compreensão do Mercado

Alto

Estratégia de marketing

Médio

Estratégia de vendas

Médio

Estratégia de Oferta (Produto)

Alto

Modelo de Negócio

Médio

Estratégia Vertical / Indústria

Baixo

Inovação

Alto

Estratégia Geográfica

Baixo

Descrições do Quadrante

Líderes


Líderes nesse mercado mostraram uma visão forte, seja no pensamento ágil líder ou na combinação de colaboração ágil com desenvolvedor e DevOps. Os líderes têm amplo alcance e adoção no mercado, conforme mostrado em consultas de clientes e dados de pesquisas, bem como em seu correspondente crescimento e presença no mercado. Fornecedores desta categoria são apostas seguras para adoção em grande escala, e esperamos que eles tenham uma presença contínua no mercado. Os líderes tendem a ter mercados estabelecidos que lhes proporcionem funcionalidade estendida por meio de parceiros. Todos têm forte capacidade de integração. Eles têm fortes redes de treinamento e implementação, e podem operar bem globalmente.

Desafiantes


Os desafiadores têm um alto alcance de mercado e grandes implantações. Os fornecedores neste quadrante normalmente têm fortes capacidades de execução, como evidenciado por recursos financeiros, e uma significativa presença de vendas e marca da empresa como um todo. Os desafiadores executaram bem em um caso de uso ou mercado específico, mas tendem a ter amplitude ou penetração de mercado limitada em todo o espectro mais amplo de casos de uso. Esses fornecedores tendem a ter parcerias bem estabelecidas e uma sólida presença global. Em geral, os Challengers não são vistos como impulsionadores do mercado.

Visionários


Visionários neste mercado têm uma base de clientes estabelecida. Eles podem encontrar desafios na execução, pois ambos continuam a crescer e desenvolver produtos com uma visão ambiciosa. Eles também podem estar sob ameaça de grandes concorrentes, se esses competidores girarem em sua visão e estratégia de produto. Eles serão atraentes para organizações com práticas ágeis corporativas maduras que desejam usar o ágil como parte de suas estratégias de negócios digitais.

Jogadores de nicho


Os jogadores de nicho neste mercado oferecem produtos sólidos, mas são limitados em seu alcance de mercado ou amplitude de cobertura de casos de uso. Eles tendem a ter uma satisfação do cliente muito sólida e, dependendo de suas necessidades específicas, podem oferecer uma funcionalidade muito sólida. No entanto, eles geralmente têm menos integrações e parceiros e carecem de presença global no mercado. São escolhas sólidas para uso de equipe / produto ou para empresas autossuficientes.

Contexto


As organizações têm diferentes níveis de maturidade na adoção de práticas ágeis, assim como diferentes restrições ou objetivos. Há algumas coisas que você deve ter em mente ao selecionar um provedor de ferramentas:

  • Escolha ferramentas que atendam às necessidades de cultura e conformidade da sua empresa  . Algumas ferramentas têm uma faixa muito mais ampla das funções gerais do ADLM (gerenciamento de requisitos, gerenciamento de testes, etc.), levando a uma plataforma única mais forte quando a rastreabilidade e a conformidade são importantes. Avalie essas ferramentas em relação aos seus casos de uso.

  • O desenvolvimento de recursos bimodais é fundamental para uma transformação digital bem-sucedida  . As equipes dos modos 1 e 2 têm necessidades diferentes que podem exigir conjuntos de ferramentas diferentes.

  • Escolha ferramentas que se ajustem ao resto do seu conjunto ADLM e ao conjunto de ferramentas DevOps  . Alternativamente, esteja preparado para pagar mais por instalações de integração (por exemplo, Tasktop, Go2Group).

  • Crescer em suas ferramentas  . Não ligue todos os sinais sonoros ou tente criar fluxos de trabalho e relatórios complexos desde o início. Com muita frequência, você reduzirá os benefícios do ágile replicando os fluxos de trabalho complexos e os relatórios de governança em cascata. Comece simples e adicione conforme necessário.

  • Observe que muitas organizações têm mais de um produto em uso  . Isso pode acontecer devido às diferentes necessidades de vários LOBs, por causa de uma abordagem bimodal da TI, ou porque a atividade de M & A trouxe equipes que funcionam bem com ferramentas diferentes dos padrões atuais. Os resultados são mais importantes que a uniformidade, mas a uniformidade pode ser resolvida com a implementação de uma estratégia de rollup de ferramentas de nível de equipe para as ofertas mais focadas no portfólio.

  • Reconheça que as ferramentas enxutas têm aplicabilidade além da organização de TI  . Nosso foco neste Quadrante Mágico é nas organizações de desenvolvimento ágil. Alguns desses players também têm boa aplicabilidade para equipes fora de TI, e há um grande conjunto de produtos aqui orientados que não estão incluídos nesta pesquisa (por exemplo, Aha !, Trello, Basecamp, Workzone, Smartsheet).

Visão Geral do Mercado


O mercado de planejamento ágil corporativo (EAP) está passando por uma ruptura, à medida que fusões e aquisições (M & A) ocorrem e novos participantes visionários entram. Fornecedores que dependem de estratégias de produtos legados estão se tornando menos relevantes. As organizações estão amadurecendo no uso de ágil da empresa e estão exigindo mais funcionalidades de suas ferramentas. Enquanto isso, os avanços no aprendizado de máquina prometem novas intuições sobre a eficácia do desenvolvimento ágil da empresa. Esperamos que as atividades de fusões e aquisições continuem à medida que os provedores procuram posicionar as ferramentas mais completas do DevOps no suporte a negócios digitais e plataformas de nuvem.
As práticas DevOps baseadas em Toolchain são a norma, e as ferramentas EAP estão se tornando parte dessa cadeia de ferramentas. Isso enfatiza a capacidade das ferramentas EAP de integrar e consumir dados de outras ferramentas na cadeia para planejamento, relatório e análise. À medida que as empresas estão se distanciando do desenvolvimento de aplicativos tradicionais baseados em projetos para fluxos de valor contínuos e orientados para produtos, o planejamento, o orçamento e outras atividades de governança estão mudando - exigindo que as ferramentas também mudem.
Adoção e Critérios de Decisão
O software EAP continua sendo usado por uma ampla variedade de funções. Os usuários de gerenciamento são predominantes: resultados de pesquisa de referência mostram que 85% das instalações contam os gerentes de projeto entre seus usuários, 70% contam gerentes de nível médio, 69% gerentes de produto e 28% gerentes executivos. No entanto, os papéis técnicos também são bem representados. Os clientes de referência da CA, IBM e CollabNet relataram a maior média de contagens de usuários (mais de 500 usuários por instalação), com Atlassian, Micro Focus e Microsoft nos 400s e outros fornecedores variando de cerca de 150 a cerca de 400.
De todos os clientes de referência pesquisados, 13% utilizam sua ferramenta desde antes de 2010 e mais de 50% têm pelo menos três anos de uso. O uso de práticas técnicas ágeis, como testes unitários, stand-ups diários, retrospectivas e integração contínua, permanece elevado.
Mudar a cultura de desenvolvimento ainda é o desafio mais proeminente para a adoção ágil (81% dos clientes de referência relataram isso como um desafio). Outros desafios significativos a serem atendidos incluem:

  • Construindo práticas consistentes (74% dos clientes de referência relataram isso como um desafio)

  • Treinamento (54%)

  • Trabalhando com equipes usando métodos tradicionais de desenvolvimento (52%)

  • Expansão ágil fora do núcleo desenvolvedor (50%)


Os usuários escolhem ferramentas por um grande número de razões, mas as mais citadas são:

  • Aumentar a visibilidade do produto / projeto (76% dos clientes de referência citaram isso como um motivo)

  • Criando eficiências operacionais internas / externas (70%)

  • Coordenação de equipes (70%)

  • Adoção de práticas de direção (69%)

  • Melhorando os resultados do processo de negócios (67%)


A maioria das organizações considera vários provedores de ferramentas quando tomam suas decisões, embora a Atlassian seja mais frequentemente citada como em consideração, juntamente com a CA, a CollabNet e a Microsoft. Os principais fatores de decisão são dominados pela funcionalidade e pelo desempenho do produto, mas o roteiro do produto e a visão do futuro pesam bastante, juntamente com o custo geral.
Satisfação
Em geral, os usuários pesquisados estavam relativamente satisfeitos com os fornecedores. Em uma escala de 5 pontos:

  • Os escores de satisfação com a experiência geral variaram entre um máximo de 5,0 e um mínimo de 3,7, com uma média de 4,4.

  • Os usuários classificaram o valor abaixo da pesquisa do ano passado (média 4,1 versus 4,5), com 4% insatisfeitos e 22% neutros.

  • Os índices gerais de satisfação de atendimento e suporte caíram de 4,7 para 4,4.


Essas diminuições nos índices de satisfação sugerem que os fornecedores em geral não estão acompanhando as demandas em constante mudança de seus clientes nesse mercado.

Termos de chave e glossário de acrônimos

ADLM

gerenciamento de ciclo de vida de desenvolvimento de aplicativos

DA

Ágil Disciplinado

DSDM

método de desenvolvimento de sistemas dinâmicos

EAP

planejamento ágil da empresa

Menos

Scrum em Grande Escala

PPM

gerenciamento de projetos e portfólios

Seguro

Estrutura ágil escalonada

XP

Programação extrema

Evidência


Gartner 2017 Agile no Enterprise Survey:

  • Esta pesquisa foi realizada por meio de uma pesquisa on-line realizada entre 6 de setembro e 18 de setembro de 2017 entre os membros do Círculo de Pesquisa da Gartner - um painel gerenciado pelo Gartner composto por profissionais de TI ou de negócios de TI.

  • No total, 185 membros completaram a pesquisa.

  • Os participantes qualificados incluíam usuários finais de negócios com um foco de TI ou de negócios de TI como função principal.

  • A pesquisa foi desenvolvida de forma colaborativa por uma equipe de analistas da Gartner e foi revisada, testada e administrada pela equipe de pesquisa de dados e análise da Gartner.


O Magic Quadrant é um reflexo de um amplo esforço de pesquisa envolvendo:

  • Consultas com clientes do Gartner sobre ferramentas de gerenciamento de projetos de desenvolvimento de aplicativos ágeis e ágeis.

  • Muitas discussões pessoais e outras interações com os fornecedores dentro deste Quadrante Mágico.

  • Uma pesquisa detalhada do fornecedor que exige respostas para mais de 200 perguntas.

  • Uma pesquisa da Gartner sobre organizações que usam ferramentas on-line, realizada de outubro a dezembro de 2017. Os participantes da pesquisa foram referências de clientes indicadas por cada um dos fornecedores neste Quadrante Mágico. Esses clientes pesquisados tiveram 47 perguntas sobre suas experiências com seus fornecedores e soluções. Os resultados foram utilizados no apoio à avaliação do mercado de planejamento e execução ágil. Obtivemos 54 respostas completas representando empresas sediadas em várias regiões geográficas diferentes.

  • Cada fornecedor foi solicitado a fornecer informações sobre sua capacidade de oferecer suporte a funções específicas e casos de uso cobertos em uma demonstração de produto ao vivo.

Definições de Critérios de Avaliação


Habilidade para executar


Produto / Serviço:  Principais produtos e serviços oferecidos pelo fornecedor para o mercado definido. Isso inclui recursos atuais de produtos / serviços, qualidade, conjuntos de recursos, habilidades e assim por diante, sejam oferecidos nativamente ou por meio de contratos / parcerias OEM, conforme definido na definição de mercado e detalhados nos subcritérios.
Viabilidade geral: A  viabilidade inclui uma avaliação da saúde financeira geral da organização, o sucesso financeiro e prático da unidade de negócios e a probabilidade de que a unidade de negócios individual continue investindo no produto, continuará oferecendo o produto e avançará o estado de a arte dentro do portfólio de produtos da organização.
Execução de vendas / preços:  os recursos do fornecedor em todas as atividades de pré-vendas e a estrutura que os suporta. Isso inclui gerenciamento de ofertas, preços e negociação, suporte a pré-vendas e a eficácia geral do canal de vendas.
Receptividade do mercado / Record:  capacidade de responder, mudar de direção, ser flexível e alcançar o sucesso competitivo como oportunidades se desenvolvem, os concorrentes agem, as necessidades dos clientes evoluem e dinâmica do mercado muda. Esse critério também considera o histórico de capacidade de resposta do fornecedor.
Execução de Marketing:  A clareza, qualidade, criatividade e eficácia de programas destinados a transmitir a mensagem da organização para influenciar o mercado, promover a marca e os negócios, aumentar a conscientização sobre os produtos e estabelecer uma identificação positiva com o produto / marca e organização no produto. mentes dos compradores. Esta "mentalidade" pode ser impulsionada por uma combinação de publicidade, iniciativas promocionais, liderança de pensamento, propaganda boca a boca e atividades de vendas.
Experiência do Cliente:  Relacionamentos, produtos e serviços / programas que permitem que os clientes tenham sucesso com os produtos avaliados. Especificamente, isso inclui as maneiras pelas quais os clientes recebem suporte técnico ou suporte de conta. Isso também pode incluir ferramentas auxiliares, programas de suporte ao cliente (e sua qualidade), disponibilidade de grupos de usuários, acordos de nível de serviço e assim por diante.
Operações:  A capacidade da organização para atingir seus objetivos e compromissos. Os fatores incluem a qualidade da estrutura organizacional, incluindo habilidades, experiências, programas, sistemas e outros veículos que permitem que a organização opere de maneira efetiva e eficiente continuamente.

Integralidade da Visão


Compreensão do mercado:  capacidade do fornecedor de compreender os desejos e necessidades dos compradores e traduzi-los em produtos e serviços. Fornecedores que mostram o mais alto grau de visão escutam e entendem os desejos e necessidades dos compradores, e podem moldar ou aprimorar aqueles com sua visão agregada.
Estratégia de Marketing:  Um conjunto claro e diferenciado de mensagens consistentemente comunicadas por toda a organização e externalizadas através do site, publicidade, programas de clientes e declarações de posicionamento.
Estratégia de vendas:  A estratégia de vender produtos que usam a rede apropriada de afiliados diretos e indiretos de vendas, marketing, serviços e comunicações que ampliam o escopo e a profundidade do alcance de mercado, habilidades, conhecimento, tecnologias, serviços e a base de clientes.
Estratégia de oferta (produto):  A abordagem do fornecedor ao desenvolvimento e fornecimento de produtos que enfatiza a diferenciação, a funcionalidade, a metodologia e os conjuntos de recursos à medida que são mapeados para os requisitos atuais e futuros.
Modelo de Negócio:  A solidez e a lógica da proposta comercial subjacente do fornecedor.
Vertical / Estratégia do setor:  a estratégia do fornecedor para direcionar recursos, habilidades e ofertas para atender às necessidades específicas de segmentos de mercado individuais, incluindo mercados verticais.
Inovação:  Layouts diretos, relacionados, complementares e sinérgicos de recursos, expertise ou capital para investimentos, consolidação, propósitos defensivos ou preventivos.
Estratégia geográfica:  A estratégia do fornecedor para direcionar recursos, habilidades e ofertas para atender às necessidades específicas de geografias fora da geografia "local" ou nativa, seja diretamente ou por meio de parceiros, canais e subsidiárias, conforme apropriado para essa geografia e mercado.

Fonte: https://www.gartner.com/doc/reprints?id=1-4YX5XH0&ct=180509&st=sb


Gostou do post? Compartilhe e siga nossas Redes Sociais 


 

Nessa série 4, vamos ver os detalhes do Release Burndown, utilizado por times Scrum que trabalham com sprints. Essencial para identificar o quão rápido o seu time está trabalhando em relação ao backlog da release e poder projetar a quantidade de sprints futuras necessárias para completar o trabalho de entrega de uma release, baseada nessa velocidade.

Se você esta acompanhado essa nossa maravilhosa série, não deixe de ler também:

O que é o Release Burndown?

O Release Burndown vai ajudar você acompanhar como esta o progresso de trabalho do seu time para uma determinada release, ajudando você a monitorar se sua release irá ser cumprida no prazo ou se você deve tomar alguma ação para colocá-la nos trilhos.

Veja algumas maneiras para qual você pode utilizar a análise do Release Burndown Report:

  • Identificar o quão rápido o seu time está trabalhando em relação ao backlog de uma release
  • Identificar se foram adicionados ou removidos trabalhos durante a sprint e como esses afetaram o progresso do seu time
  • Prever quantas sprints futuras você necessitará para completar o trabalho de uma versão, baseado na velocidade da equipe nas sprint passadas.



Compreendendo o Release Burndown

Vamos compreender o que significam as principais informações a serem analisadas no gráfico

  • Seção Verde Claro - representa o total e trabalho completado na sprint. 
    (info) Se uma barra estiver totalmente verde clara você não poderá afirma quanto trabalho foi completado em relação ao Original Estimate. Você vai precisar clicar na barra pra ver os detalhes.
  • Seção Azul Claro - representa o trabalho remanescente para versão, em relação ao total estimado para versão no início da Sprint
  • Seção Azul Escuro - Representa o trabalho adicionado durante a sprint, que não foi originalmente incluso. (representa uma mudança de escopo)
  • Seção Verde Claro + Seção Azul Claro - Representa o total de trabalho estimado no início da sprint.
  • Seção Azul Claro + Seção Azul Escuro - Representa o total de trabalho na versão, que remanesceu no final da Sprint.

Como é feito cálculo de previsão das sprints futuras com o Release Burndown Report ?

A previsão das Sprint é calculada baseada na velocidade do time (são sempre consideradas as 3(três) últimas sprints), e o total de trabalho remanescente no seu backlog. 

(info) O escopo adicionado não é considerado para o cálculo da velocidade do time, mas esse é considerado no total de trabalho remanescente.

Vamos calcular o exemplo abaixo:

  1. Análise o trabalho realizado:
    Remanesceram 26 Story Points para versão antes do início da sprint corrente (sprint 5)

    Perceba que no topo do release Burndown report, nesse cenário ele está indicando 22 Story points restantes.

    Aqui ele já esta considerando que na sprint corrente serão subtraídos 4 story points (velocidade prevista do time)

  2.  Calcule a velocidade do time:
    Para calcular a velocidade do time, você deve somar o trabalho realizado pelo time nas 3(três) ultimas sprints.
    Nesse cenário foram 11 Story points (sprint 2, Sprint 3 e Sprint 4). agora que você tem o total completado nas 3(três) ultimas sprints, divide por 3(três) e vai chegar na velocidade média do time. 11/3 = 3,6666 → 4 Story Points por sprint.
  3. Calcule a previsão de sprints necessárias para completar o trabalho restante da release:
    sabendo que a velocidade do time é de 4 story points por sprint, e restam 26 story points para serem completados, é possível fazer o cálculo para saber quantas sprints serão necessárias. Vamos ao cálculo.
 A minha sprint corrente conta quando é calculada a velocidade do time ?

Usualmente a sprint corrente não conta quando é calculada a velocidade do time.
Nesse exemplo acima a sprint corrente mostra as barras em cinza (como barras de sprints previstas) para representar isso. 

A exceção é quando você já completou mais trabalho na sprint corrente do que o trabalho calculado previsto para as sprints seguintes. Nesse caso a sprint corrente(e o atual trabalho completado) é usada como uma das 3(três) sprints para calcular a velocidade do time. Então a barra da sprint ira ser exibida na cores verde claro e Azul, como barras de uma sprint completada.

Por exemplo, nesse gráfico acima, se o time tivesse completado mais de do que 4 story points na sprint 5, então o trabalho completado nas sprints 3, 4, e 5, seria utilizado para calcular a velocidade, ao invés das sprints 2, 3 e 4.

Outras funcionalidades e dúvidas em relação ao comportamento do Release Burndown report

Vamos ver abaixo as principais duvidas a cerca do Release Burndown. Expanda os tópicos abaixo para visualizar os detalhes:

 Porque que as datas da primeira e última sprint no meu relatório não são as mesmas de início e fim das datas das releases configuradas na minha versão?

Start date e Release date configurado para versão são exibidos abaixo do relatórios como Planned start date Planned end date. No entanto essas são datas planejadas, e não determinam o início e fim da sprint que exibida no relatório.

  • Inicio da Sprint mostra a primeira tarefa na versão que foi transicionada do status "To do". Por exemplo, teve seu trabalho iniciado na versão.
  • Fim da Sprint mostra quando o trabalho é concluído para versão, ou se houver trabalho remanescente, então o(s) sprint(s) previsto(s) quando o trabalho será concluído.

Info (i) O mapeamento dos status no seu board determina quando uma issue é considerada 'To Do" ou "Done".

 Como que a percentagem de tarefas não estimadas afeta o relatório ?

O Release Burndown report pode apenas realizar as previsões baseado em tarefas estimadas da sua versão. Se você tem uma alto percentual de tarefas não estimadas, as previsões no relatórios não serão realistas. O label % unestimated issues vai ficar na cor vermelha quando o percentual for a cima de 30%, para alertá-lo disso.

Por exemplo, se você tem apenas 10% das tarefas estimadas na versão, então as previsões no relatório para completar o trabalho na versão serão baseados nos 10% do total das tarefas. Na realidade provavelmente o seu time tenha muito mais trabalho para completar.

 Quais mudanças afetam o Original estimate e quais mudanças afetam o escopo (Work added)?

As seguintes mudanças afetam o original estimate da sprint:

  • Se uma tarefa em uma versão (depois que a sprint é iniciada) é estimada (estimativa é adicionada)
  • Se uma tarefa em uma versão (depois que a sprint é iniciada) é re-estimada (Estimativa modificada)

As seguintes mudanças afetam o escopo da sprint:

  • Se uma tarefa é adicionada para uma versão (depois que essa foi iniciada) com uma estimativa existente.
  • Se uma tarefa que foi adicionada para uma versão (depois que essa foi iniciada) é estimada (estimativa adicionada)
  • Se uma tarefa que foi adicionada para uma versão (depois que essa foi iniciada) é re-estimada (estimativa modificada). Observe que, se o problema for re-estimado em um sprint posterior, o escopo será retroativamente ajustado no sprint ao qual o problema foi originalmente adicionado.
 Se o trabalho for concluído fora da sprint, como este é representado?

Qualquer alteração (Burndown ou Escopo) que ocorrer fora da Sprint ira ser exibida como parte da sprint com a ultima data de inicio depois da mudança da data.

 Se um tarefa concluída é reaberta ou adicionada/removida de uma versão, como isto é representado?

Se uma tarefa concluída em um sprint for reaberta:

  • A tarefa não será mostrada na sprint anterior.

Se uma tarefa é concluída em uma versão, mas removida da versão depois:

  • O escopo permanecerá inalterado e o trabalho concluído ainda será exibido.

Se uma tarefa é concluída em uma outra versão ou sem uma versão, mas depois é inclusa em uma versão.

  • O escopo irá permanecer inalterado.

Se uma tarefa é conlcuida em uma sprint, mas é adicionada a uma versão depois:

  • A tarefa sera exibida no relatório, como se fosse sempre parte da versão.
 O que acontece se minha tarefa estiver em um status não mapeado?

Se sua tarefa esta em um status não mapeado (não foi mapeado para uma coluna do board), este não será considerado no Release Burndown Chart, nem será incluso no sprint bar, % unestimated issue, remaining story point, etc.


Espero que possam ter aproveitado as dicas e cenários abrangidos para o Release Burndown. Nos vemos no próximo blog da série. Ótimo planejamento e controle a todos. (big grin)

Fonte: Jira Software Server - Release Burndown


Gostou do post? Compartilhe e siga nossas Redes Sociais 

 

Nessa série 3, vamos ver os detalhes do control chart, um dos relatórios tanto para times que utilizam o scrum board ou kanban board. Essencial para controlar o tempo de ciclo do seu produto, versão ou sprint. Permitindo identificar os tempos médios de cada fase do seu processo, e projetar a média, média móvel e o desvio padrão do seu tempo de ciclo.

Se você esta acompanhado essa nossa maravilhosa série, não deixe de ler também:

O que é o Control Chart ?

O control chart, ajuda você a identificar se os dados a partir de um sprint corrente podem ser usados para determinar a performance futura. A partir do control chart você vai poder identificar a capacidade média, a média móvel e o desvio padrão de execução do seu ciclo de desenvolvimento para um determinado período. Observando sempre que quanto menor for a variação do tempo de ciclo de uma tarefa, mas alta se torna a sua confiança para utilizar a média ou média móvel com um indicador de performance futura.

Veja algumas das maneiras para qual você pode utilizar a analise do control chart:

  • Analisar a performance passada do seu time em uma retrospectiva
  • Medir os efeitos da aplicação de alguma mudança para otimização no processo, certificando do ganho ou perda da produtiva do seu time.
  • Dar a visão aos stakeholders do desempenho do seu time.
  • Para o Kanban, utilizar a performance passada para definir as metas para o seu time.


Compreendendo o Control Chart

Vamos compreender o que significam as principais informações a serem utilizadas no gráfico.

  1. Issue Details: Você pode visualizar os detalhes do tempo de ciclo de uma tarefa especifica
  2. Time Scale: selecionar o período de tempo a ser exibido no control chart
  3. Zoom in: Passando o mouse em uma área do gráfico, para exibir as informações da média móvel e desvio padrão de um determinado período específico
  4. Refine Report: Selecionar as colunas e filtros que você quer que seja considerado na exibição do control chart.

Vamos ver abaixo as principais duvidas a cerca do Control Chart. Expanda os tópicos abaixo para visualizar os detalhes:

 O que é o Cycle Time e Lead Time ?

O cycle time é o tempo gasto trabalhado em uma tarefa, normalmente, o tempo é medido quando o trabalho inicia até o trabalho ser completado, isso inclui qualquer tempo trabalhado em uma tarefa. por exemplo, se uma tarefa for reaberta, trabalhada, e concluída novamente, o tempo desse trabalho extra é adicionado no cycle time.

O Lead time é similar ao cycle time, mais o tempo é medido quando a tarefa é registrada (não quando o trabalho realmente inicia) até o trabalho ser completado.

 Como que o Cycle Time é determinado ?

Os status usados para calcular o tempo de ciclo dependem do fluxo de trabalho que você está usando para o seu projeto. Você deve configurar o control chart para incluir os status que representam o tempo gasto trabalhado em uma tarefa. Observe que o gráfico de controle tentará selecionar esses status automaticamente, baseado no seu workflow.

(info) No control chart é importante você representar sempre as colunas que efetivamente representem o trabalho de execução do seu time, para evitar que o tempo em status que ficam aguardando outros controles não desvirtue o indicador de performance do seu time. Por exemplo, configurar os status "In Progress" e "In Review" para indicar exatamente o momentos que representam o esforço de execução do trabalho do seu time. Se você adicionar ao cálculo os Status "Open" e "Done" o tempo em que as tarefas ficaram aguardando nesses status, vão ser considerados no cálculo de performance, e isso não vai refletir a real capacidade de execução do seu time.

 Como que Rolling Average (Média Móvel) é calculada ?

A média móvel (Linha azul no gráfico) é baseada na tarefa, e não no tempo, para cada tarefa exibida no gráfico. A média móvel é calculada monitorando a própria tarefa. X tarefas antes dela mesmo, X tarefas após ela mesmo, e então calculando a média dos seus tempos de ciclo. 20% das tarefas exibidas ((info) sempre um número impar e no minimo de 5 tarefas) é usado no cálculo.


Por exemplo, na imagem abaixo, no momento em que uma tarefa (ponto verde) é exibida, a média móvel é calculada conforme:

  1. pegando as 4 (quatro) tarefas anteriores e as 4 (quatro) tarefas posteriores (das 9 tarefas no total)
  2. A média do tempo de ciclo para as nove tarefas.
  3. Mapeie a linha azul para a média calculada.

Se o Prazo, for reduzido para "duas ultimas semanas", o numero de tarefas usadas reduziria, menos tarefas estarão disponíveis para usar nos cálculos.

Esse método produz uma linha de média constante que mostra outliers (pontos fora da curva) melhor (ou seja, a média de rolagem não se desvia tão drasticamente para outliers (pontos fora da curva)). A linha média móvel também é fácil de entender, já que as inflexões estão relacionadas às posições das tarefas.

 O que a área sombreada azul representa ?

A área sombreada Azul, representa o desvio padrão. Ou seja a variação dos dados atuais a partir da média móvel (rolling average).

O desvio padrão vai fornecer a indicação do nível de confiança que você pode ter dos dados. Por exemplo, se tiver uma faixa azul estreita (Baixo desvio padrão), você pode confiar que o tempo de ciclo para futuras tarefas será realizado dentro da média móvel.

 O que os pontos representam no gráfico ?

Assim como exibido na legenda, cada ponto representa uma tarefa ou um grupo (Cluster) de tarefas:

  • O posicionamento vertical do ponto representa o tempo de ciclo para a tarefa, ou seja, o "tempo decorrido". Para um cluster de tarefas, o ponto é colocado no tempo médio de ciclo do conjunto de tarefas.
  • O posicionamento horizontal indica quando o (s) tarefas (s) realizaram a transição do último status selecionado no gráfico (Colunas). Por exemplo, se você estiver usando o fluxo de trabalho "Desenvolvimento de software Jira" e tiver selecionado "In Progress" e "In Review" como as colunas no gráfico de controle, os pontos indicarão quando a tarefa foi transferida do status "Em revisão" .
 Porque a escala no eixo do tempo transcorrido muda quando são modificados os prazos ?

Se o valor máximo do tempo decorrido no gráfico for menor que 30 dias, uma escala linear será usada para o eixo y. Se for 30 dias ou mais, será utilizada uma escala de energia de raiz cúbica.

Ao alterar o período de tempo, você pode incluir problemas com um tempo decorrido de mais de 30 dias, quando você não o fez anteriormente, ou vice-versa. Isso mudará a escala, conforme descrito acima.

Escala Linear para o tempo transcorrido


Raiz cúbica para o tempo transcorrido


Espero que possam ter aproveitado as dicas e cenários abrangidos para o control chart. Nos vemos no próximo blog da série. Ótimo planejamento e controle (big grin)

Fonte: https://confluence.atlassian.com/jirasoftwareserver/control-chart-938845628.html


Gostou do post? Compartilhe e siga nossas Redes Sociais 


Nessa série 2, vamos ver os detalhes de um dos relatórios mais utilizados pelas equipes ágeis, para monitorar a eficiência e previsão da entrega do trabalho planejado para um Sprint.
Se você esta acompanhando a nossa série não deixe de ler também a Série 1 - JIRA Software Reports - Version Report

O que é o Burndown Chart ?

O Burndown chart mostra a quantidade de trabalho realizado de um sprint, e o total de trabalho restante para completar. Esse relatório é utilizado para prever as probabilidades do seu time realizar o trabalho estimado dentro do prazo planejado do sprint, mantendo a equipe ciente de qualquer desvio de escopo que ocorra.



Com o Burndown Chart você vai poder prever alguns padrões de como o seu time esta trabalhando, obtendo informações como por exemplo:

  • Se o time está constantemente finalizando o sprint antes do prazo estimado, é porque eles podem não estar tendo trabalho suficiente, a estimativa de capacidade do tamanho do sprint deve ser ajustada.
  • Se o time está desviando da previsão da sprint, é porque podem estar com trabalho em excesso, a estimativa de capacidade do tamanho do sprint deve ser ajustada.
  • Se a linha do Burndown faz uma queda ingrime ao invés de um Burndown mais gradual, é porque o trabalho não foi estimado com precisão ou dividido corretamente.
  • Se o Product Owner adicionar ou alterar o escopo no meio do Sprint, será percebido facilmente pelo desvio da linha vermelha que representa a quantidade de trabalho remanescente do sprint.

A importância da estatística da estimativa

A estatística da estimativa é a unidade de medida que o seu time irá utilizar para estimar o trabalho das atividades para o sprint. No JIRA Software você pode estimar o trabalho utilizando story points, horas, ou ainda pode criar sua própria unidade de estatística numérica (através da criação de um campo customizado do tipo numérico no JIRA).

Essa estatística é importante porque ela é usada para calcular a velocidade do time. Para cada sprint, a velocidade é a soma da estatística da estimativa das Stories concluídas. Se o seu time mantém uma velocidade constante, você pode utilizar essa métrica para determinar a quantidade de trabalho que eles podem suportar a cada sprint.

Qual a diferença entre estimar em Story Points e Horas para o Burndown Chart ?

Tradicionalmente, os times de software estimam o trabalho utilizando um formato de tempo, horas, dias, semanas e meses. No entanto, muitos times ágeis estão fazendo a transição gradual para utilizar story points. O JIRA software suporta ambos os formatos para que você possa utilizar aquele que sua equipe se sinta mais confortável.

A grande diferença na exibição do gráfico Burndown Chart quando se utiliza uma estimativa ou outra é:

  • Utilizando Story Points , você terá o controle do trabalho remanescente para completar o sprint no Burndown através de uma única linha guia, a Red line, que vai controlar a quantidade de story points completados e consequentemente os story points restantes para conclusão do sprint.


  • Utilizando Horas, você terá o controle do trabalho remanescente para completar o sprint no Burndown através de uma duas linhas guias, a Red line que vai controlar a quantidade de horas restante para completar o sprint e a Green line que vai controlar a quantidade de trabalho já executado no sprint.

Compreendendo o Burndown Chart

Vamos compreender o que significa as principais informações a serem monitoradas no nosso gráfico.

  1. Estimation Statistic: O Eixo vertical representa qual a estatística de estimativa que está sendo utilizada, exibindo ao topo a quantidade total estimada para o seu sprint.
  2. Remaining values: A linha vermelha representa a quantidade total de trabalho restante no sprint, de acordo com as estimativas da sua equipe.
  3. Guideline: A linha cinza mostra uma aproximação de onde a sua equipe deveria estar para conseguir completar a estimativa da sprint planejada de forma linear. Se a linha vermelha estivar abaixo da Guideline, parabéns, o seu time esta se mantendo no trilho para completar todo o trabalho até o final da sprint. (info) isso não é infalível, é apenas mais uma informação a ser usada durante o monitoramento do progresso da equipe.

O que pode ocorrer para que a minha Guideline não seja exibida ?

Após experienciar algumas sprints, me deparei com alguns cenários em que a minha Guideline simplesmente não era exibida no gráfico, Com algumas simulações depois, pude notar algumas das causas disso estar ocorrendo, e abaixo compartilho com vocês para que possam ter ciência e evitar esses cenários que fazem sua Guideline desaparecer.


Causas

Podem haver algumas possível causas:

  • Esse é um comportamento esperado se o sprint foi iniciado antes de haver qualquer tarefa atribuída ao sprint.
  • Outra causa seria iniciar o sprint com tarefas sem estimativa alguma, e essas estimativas forem realizadas após o inicio do sprint.
  • E a terceira causa seria, se as tarefas tivessem um release date anterior a data de inicio do sprint, isso faz com que eles sejam adicionados ao sprint após sua data de inicio, e com isso a Guideline não será carregada corretamente.

Conclusão

O Burndown Chart é o relatório mais usual no dia a dia para rastrear se sua equipe está nos trilhos para cumprir a estimativa de entrega do sprint. Porém, alguns pontos são de extrema importância para que esse relatório realmente seja eficiente. Para isso comece escolhendo a estimativa de estatística que melhor sua equipe esta familiarizada, realize no momento correto o sprint planning para evitar que sprints iniciem sem tarefas, ou com tarefas sem estimativas, pois vimos que isso pode causar a perda da referência do Guideline e desvirtuar toda a análise de desempenho do seu time no sprint. Por fim, mantenha todos envolvidos cientes da trilha do Burndown para garantir o sucesso de entrega do seu sprint. Excelente planejamento a todos (big grin)

Fonte: https://confluence.atlassian.com/jirasoftwareserver/burndown-chart-938845620.html


Gostou do post? Compartilhe e siga nossas Redes Sociais 


  

Eu sou um administrador do Jira Software há algum tempo e já trabalhei com centenas de instâncias de clientes. Muitas vezes me perguntam: "Como posso obter mais do software Jira?" Eu sempre dou a mesma resposta:  aprenda os  atalhos de tecladoNada melhorará sua velocidade em todo o Jira Software além dos atalhos de teclado. Desde a criação de tarefas, a atribuição de trabalho e até a administração do produto, os atalhos de teclado tornarão você mais rápido e mais confiante em todo o Software Jira.

0. Começando

alhos de teclado funcionam em todo o Jira Software ( e no Confluence ) fora dos campos de texto. O atalho de teclado mais importante é o '?'. O ponto de interrogação traz a ajuda para todos os atalhos de teclado. Abra sua instância do Jira Software, pressione o '?', e confirme que você obterá o diálogo abaixo.

Lista de atalhos Jira Software_keyboard

Dica: se você não visualizar a caixa de diálogo acima, verifique se o cursor não está no campo de texto. Se você vê o '?' quando pressiona a tecla, clique fora do campo de texto e tente novamente. Agora que você pode ver o poder dos atalhos de teclado, vamos dar uma olhada em quatro áreas nas quais podemos otimizar nosso tempo ao usar o Software Jira.

1. Trabalhar com questões individuais

Questões são o conceito central do software Jira. Quanto mais rápido podemos trabalhar com tarefas, mais otimizamos nosso tempo. Onde quer que você esteja no Jira Software e tenha uma tarefa destacada, você pode agir sobre essa tarefa.

JIRA_keyboard_shortcut_key_a -  Atribuir

JIRA_keyboard_shortcut_key_c-  Criar

JIRA_keyboard_shortcut_key_m- Comentar

JIRA_keyboard_shortcut_key_e-  Editar

JIRA_keyboard_shortcut_key_s-  Compartilhar

JIRA_keyboard_shortcut_key_period- Todas as operações de emissão. Use o '.' para fazer a transição de uma tarefa.

Tente!  Selecione uma tarefa na exibição de lista ou em uma placa e pressione uma das teclas acima.

2. Lidar com conjuntos de questões

O próximo passo para dominar os atalhos de teclado é trabalhar com conjuntos de tarefas. Ao pesquisar no Jira Software usando a pesquisa padrão ou com JQL, o Jira Software retornará uma lista de tarefas. Os dois atalhos de teclado mais importantes são 'J' e 'K'.

JIRA_keyboard_shortcut_key_j - Anterior

JIRA_keyboard_shortcut_key_k- Próximo

Você provavelmente está pensando, como 'J' e 'K' representam o próximo e o anterior? As raízes remontam aos primórdios do UNIX, onde J e K mapearam para o anterior e o próximo antes do advento das teclas de seta. Muitos aplicativos da web, como Gmail, Twitter e Tumblr, também usam o mesmo atalho de teclado.

Se combinarmos as teclas 'J' e 'K' com os atalhos da seção anterior, podemos fazer uma triagem rápida de uma lista de tarefas no Jira Software. Usando a visualização de lista, podemos atribuir rapidamente tarefas usando as teclas 'K' e 'A'. Em vez de usar o mouse para clicar em cada edição, podemos permanecer no teclado.
Tente!  Procure por uma lista de tarefas e pressione a tecla 'K'. Você verá a seleção na próxima edição. Pressione um dos atalhos de teclado na seção 1 para trabalhar na tarefa selecionada.

3. Navegue pelo Software Jira

A chave 'G' é seu passaporte para navegar pelo Software Jira. A chave 'G' emparelha com outra tecla para selecionar a tela de destino. Vamos dar uma olhada em como a tecla 'G' funciona:

JIRA_keyboard_shortcut_key_g então JIRA_keyboard_shortcut_key_d - Vá para o dashboard

JIRA_keyboard_shortcut_key_g então JIRA_keyboard_shortcut_key_a - Vá para os Jira boards

JIRA_keyboard_shortcut_key_g então JIRA_keyboard_shortcut_key_i - Vá para a pesquisa de tarefas

JIRA_keyboard_shortcut_key_g então JIRA_keyboard_shortcut_key_g  - Pesquisa administrativa

Onde quer que eu esteja dentro de Jira, a tecla 'G' me pega onde eu preciso ir!
Tente!  Pressione 'G' e depois 'D' (não ao mesmo tempo) para voltar ao painel do Jira Software.

4. Aumente a agilidade

Os três atalhos mais importantes para a agilidade são, sem surpresa,  '1', '2' e '3' .

JIRA_keyboard_shortcut_key_1 - Ir para o backlog

JIRA_keyboard_shortcut_key_2- Ir para sprints ativas ou quadro kanban

JIRA_keyboard_shortcut_key_3 - Ir para relatórios

E você pode fazer ainda mais. Assim como 'J' e 'K' se movem entre as questões, 'N' e 'P' se movem entre colunas em  sprints ativos ou o quadro Kanban .

JIRA_keyboard_shortcut_key_p - Mover para a coluna anterior

JIRA_keyboard_shortcut_key_n - Mover para a próxima coluna

Se você estiver trabalhando em uma tela menor ou em um projetor durante o planejamento da sprint, as teclas 'T' e 'Z' ajudam a otimizar o espaço na tela.

JIRA_keyboard_shortcut_key_t - Ocultar e mostrar a visualização de detalhes para conservar o espaço na telaJIRA_keyboard_shortcut_key_z- Ativar modo de apresentação

Enquanto você está planejando sprints, mova as tarefas para o início da sprint ou do backlog com facilidade.

JIRA_keyboard_shortcut_key_s então JIRA_keyboard_shortcut_key_t - Envie a tarefa selecionada para o topo da lista

JIRA_keyboard_shortcut_key_s então JIRA_keyboard_shortcut_key_b - Envie a tarefa selecionada para o final da lista


Tente!  Pressione "G" e, em seguida, "A" e, em seguida, pressione "1", "2", "3" para alternar entre as diferentes visualizações do Software Jira.

Dica Pro  : Pressionar 'Z' duas vezes habilitará um modo de alto contraste ao projetar o Software Jira em uma tela externa durante as sessões de triagem.

Então, largue o mouse e tire mais proveito do Software Jira ficando no teclado. 


Fonte: https://www.atlassian.com/blog/jira-software/4-ways-get-jira-keyboard-shortcuts


Gostou do post? Compartilhe e siga nossas Redes Sociais 


  

  


Não é segredo que a  transparência, mais comumente expressa como “Open company, no BS”,  é um dos valores mais importantes da Atlassian  . Longe de ser uma palavra da diretoria, operar com integridade dentro e entre as equipes é uma parte vital do sucesso de sua equipe e da empresa. De acordo com a TinyPulse, uma empresa de pesquisa de funcionários do B2B SaaS, a transparência é  o  principal fator que  contribui para a  felicidade dos funcionários .

5 maneiras de criar transparência no trabalho

Transparência no trabalho, ou transparência nos negócios, significa comunicar-se aberta e honestamente com os membros de sua equipe e cultivar uma cultura onde a informação possa fluir livremente entre as pessoas e as equipes. Embora a transparência seja muitas vezes encoberta em termos vagos, seus benefícios são tangíveis. Aqui estão  cinco   maneiras  simples de criar uma cultura transparente em seu trabalho :

   1.  Seja honesto. 

Pense na honestidade de apoio que você esperaria de um mentor. Sentir que você pode dar e receber feedback com segurança é uma característica marcante da transparência. A comunicação aberta cria confiança, incentiva a inovação e cultiva um ambiente de trabalho saudável.

Expressar informações importantes para todos os seus colegas cria uma plataforma positiva e produtiva para o trabalho em equipe. Por outro lado, a retenção de informações importantes de seus colegas de equipe pode prejudicar os projetos de sua equipe e quebrar a confiança entre os membros da equipe. Quando todos sentem que entendem o que está acontecendo em sua equipe e por quê, você verá um envolvimento maior com o trabalho e uma solução de problemas mais criativa que se alinha às necessidades do seu negócio.

Um excelente exemplo de transparência radical é a  Buffer,  uma empresa projetada para ajudar os usuários a prosperar nas mídias sociais. A Buffer tomou a decisão  de compartilhar os salários dos funcionários publicamente. Ao fazer isso, o nível de confiança entre os membros da equipe no Buffer aumentou drasticamente , o que ajudou a criar um ambiente de trabalho saudável e sustentável. A transparência salarial até ajudou nos esforços de recrutamento. Depois que a Buffer publicou seus salários e fórmulas salariais no final de 2013, os pedidos de emprego aumentaram 230% no mês seguinte.

Como fazer isso:  comece a fazer levantamentos em sua equipe. Ter um único lugar onde todos possam ouvir sobre o trabalho que está sendo feito e as atualizações relevantes criam um senso de transparência na comunicação da equipe.

   2.  Compartilhe seus resultados .

Uma das melhores maneiras de criar transparência e criar impulso no seu negócio é compartilhar suas vitórias, perdas e desafios. Compartilhar vitórias é a parte fácil. O mais difícil é admitir que as coisas não correram como planejado, mas aumenta a confiança e a maior união de uma equipe.

Jeff Bezos, CEO da Amazon, tem uma grande apreciação do fracasso. Em uma recente carta de acionistas, ele disse:  “Para inventar você tem que experimentar, e se você sabe de antemão que isso vai funcionar, não é um experimento. A maioria das grandes organizações adota a ideia de invenção, mas não está disposta a sofrer a série de experimentos fracassados necessários para chegar lá. ”

Como fazer isso:  Ao fornecer atualizações sobre o status de seus projetos, resista à tentação de revestir os negativos. Seja honesto com os fracassos, compartilhando com sua equipe o que você aprendeu e como planeja seguir em frente. Aprender com nossos fracassos é uma das coisas mais inteligentes que podemos fazer.

   3.  Quebre os silos. 

De acordo com um estudo da McKinsey, quase 80% dos executivos seniores  disseram que a comunicação é crucial para o crescimento, mas apenas um quarto deles achava que suas empresas eram boas em compartilhar conhecimento em toda a empresa . Fazer um standup diário dentro de sua equipe é ótimo, mas garantir que o conhecimento esteja disponível e aberto em todos os departamentos criará uma cultura corporativa verdadeiramente transparente.

Tornar a transparência uma prioridade torna muito mais fácil achatar sua organização e evitar a burocracia e um ambiente de trabalho político. Os líderes podem implementar uma estratégia de portas abertas, utilizar reuniões da prefeitura ou até reorganizar o escritório de maneira a promover a expressão. Considere um piso plano aberto com paredes que funcionem como quadros brancos, e não esqueça os divertidos locais da equipe que ajudam a criar laços de confiança e amizade. Na Atlassian, isso significa uma assembleia semanal que reúne todas as nossas equipes em todo o mundo, de Sydney a São Francisco.

Como fazer isso: não há necessidade de (fisicamente) derrubar as paredes. Você pode começar a construir relacionamentos entre várias equipes pedindo a um colega de outra equipe para almoçar ou agendar uma reunião para discutir como suas prioridades se alinham.

   4.  Contrate pessoas que se importam com transparência. 

No final do dia, nenhum programa sobre transparência funcionará, a menos que seu pessoal também se preocupe com a transparência. E que melhor maneira de promover uma cultura transparente do que recrutar pessoas que valorizam a transparência?

A boa notícia é que  87% das pessoas querem trabalhar para empresas transparentes, então, ao criar transparência em seu processo de recrutamento e entrevista, você atrairá muitos candidatos excelentes.

Na Atlassian, fazemos isso  discutindo nossos valores e transparência durante o processo de entrevista e, em seguida, perguntando aos nossos candidatos como eles se relacionam com eles.

Como fazer isso:  qualquer pessoa tem o poder de introduzir transparência no processo de contratação. Escreva uma descrição do trabalho que mencione a filosofia da sua empresa sobre transparência, ou se entrevistar um candidato faça uma pergunta sobre como trabalhar em um ambiente aberto.

   5.  Escolha ferramentas que suportem transparência. 

Quantas horas você perdeu pesquisando por um documento em um email, solicitando permissão para um arquivo ou editando (e esperemos que não perdendo!) Várias versões de rascunhos? O funcionário médio gasta 20% de sua semana procurando informações internas e procurando ajuda de colegas. E isso é uma grande perda de tempo! Todos na sua empresa precisam saber para onde recorrer para encontrar as informações certas, entrar em contato com a pessoa certa e resolver rapidamente os problemas.

Ferramentas que apoiam e organizam o fluxo de informações quebram barreiras que atrapalham o progresso dentro de um negócio. Você vai querer procurar algo que possa ser compartilhado e encontrado em toda a sua equipe, departamento e empresa inteira - e rapidamente. Você vai querer um lugar onde os membros da sua equipe possam dar feedback e oferecer insights e ajuda. Por fim, verifique se ele está acessível online para que todos tenham sempre as informações mais atualizadas .

Para a  Mercy Ships, uma organização internacional sem fins lucrativos que administra o maior navio hospitalar privado do mundo, o  Confluence  tem sido “o componente chave da expansão da organização.” Ajudando-os a conectar suas equipes em espaços geográficos e operacionais, eles “trouxeram transparência para diferentes aspectos da organização ”, ajudando os escritórios de suporte em todo o mundo e as equipes a bordo do navio permanecem conectadas.

Transparência significa trabalho significativo

A transparência pode afetar sua lucratividade? Em uma palavra, sim. Mas é muito mais que isso. A transparência permite que cada indivíduo da sua empresa se sinta parte de algo maior. É sobre construir confiança. Trata-se de ajudar os membros de sua equipe a criar um trabalho que seja significativo e faça uma diferença tangível.

Que é exatamente como deveria ser.

Fonte: https://www.atlassian.com/blog/confluence/5-ways-create-transparency-at-work


Gostou do post? Compartilhe e siga nossas Redes Sociais