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, instalar, configurar, atualizar e personalizar os produtos Atlassian e fazer configuração do servidor. 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 2 anos de experiência em consultoria a clientes;
  • 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;
  • Capacidade de trabalhar em vários projetos ao mesmo tempo proporcionando alta satisfação ao cliente;
  • Familiaridade com bases de dados e experiência SQL comprovada;
  • Familiaridade com outros sistemas de controle de origem GIT, SVN.

Exigimos para oportunidade

  • ACP-400 Jira Service Desk Administration
  • ACP-200 Atlassian Certified Confluence Administrator
  • 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

  • Outras certificações (se ainda não possuir, estar disposto a fazer pelo menos duas em 2019):
    • 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

Nossa empresa utiliza o Processo 3PUP para o chão de fábrica, o qual é fortemente baseado na FDD e Scrum. Toda a nossa gestão de projetos é feita em plataforma web com suporte wiki para colaboração online e gestão do conhecimento.

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;
  • Ótimo ambiente de trabalho com equipe receptiva e descontraída;
  • Disponibilidade semanal para atividades de P&D;
  • Programa de indicação premiada;
  • Incentivo e bônus por certificação;
  • Auxílio idiomas/cursos/treinamentos/Universidade.

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)

  

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 


 

Analisar as estatísticas de performance da sua equipe, hoje é um passo fundamental para ajudá-los a desenvolverem melhores projetos e produtos. Nessa série nós vamos entrar nos detalhes para ajudá-lo a interpretar os relatórios ágeis do JIRA Software. Vamos iniciar a série entendendo como interpretar o Version Report.

  

Entrando de cabeça no JIRA Version Report

Após muitas horas de estudo sobre o Version Report, muitas dúvidas sobre como interpretar os seus dados e previsões plainaram sobre minha mente. Saber como que esses dados são realmente afetados, e como projetar as previsões de formas realistas baseado no desempenho da minha equipe. Muitas investigações depois, trago esse blog post para compartilhar tudo o que aprendi sobre o JIRA Version Report.

Como que a velocidade do time é calculada

Uma das partes fundamentais para poder entender as projeções de entrega da versão nesse relatório, é o entendimento de como calcular a velocidade desempenha pelo time até a data corrente da versão. Esse cálculo considera o número de dias úteis trabalhados e o total de story points (ou outra estatística de estimativa) para poder determinar a velocidade média do time por dia. Importante se atentar que esse leva em consideração o número de dias baseado na data de início da versão (Start date da versão), e não de uma sprint.


Explicando a estratégia de projeções

O processo seria o seguinte:

  • Conte o número de dias desde que a versão foi iniciada até a data atual (obs: Data de início da versão, não da sprint)
  • Identifique a quantidade de pontos completados até a data corrente
  • Agora é só dividir o total de pontos completados / pelo número de dias úteis trabalhados na versão até a data corrente, e você terá a velocidade estimada por dia (estimativa(pontos/horas, etc).
  • Para projetar, basta continuar adicionando esse número da velocidade média por dia, até chegar no total de estimativa restante para completar toda a versão.

(info) Se todas as semanas tiverem o mesmo número de dias úteis, essa projeção será linear.

Qual a importância de ter configurada a data de início da versão ?

Se o Fix Version no JIRA não tiver sido configurada a data de início da versão, então o gráfico começará a partir da data em que a Fix Version foi associado a uma tarefa. Se isso levar algum tempo antes do início do trabalho na versão, a data de início da versão deverá ser definida como a data de início da primeira sprint, na qual os problemas associados a essa versão de correção foram executados.

Abaixo segue um exemplo, em que o Product Owner definiu logo no começo a data de inicio da versão, enquanto ele planejava um novo conjunto de funcionalidades para equipe trabalhar. Perceba que demorou algum tempo até que a equipe realmente começasse a desenvolver qualquer uma das atividades em um sprint. Com isso o calculo de previsão de entrega dessa versão ficou previsto para o dia 27 de Outubro.


O gráfico acima estava usando para a data de início da versão o padrão em que o Fix Version foi associado com a primeira story. No gráfico abaixo, quando essa data de início da versão foi modificada para a data em que a equipe iniciou o desenvolvimento das story na primeira sprint, o gráfico se modificou, dando uma nova projeção de conclusão da versão para o dia 24 de Agosto.


Isso ocorre porque o primeiro gráfico incluía a velocidade de fevereiro a abril, embora a equipe não estivesse progredindo em nenhuma das stories. Como resultado, a previsão foi muito mais distante porque o Jira estava incluindo várias semanas de velocidade zero da equipe para a versão. Quando a data de início foi definida corretamente no início do primeiro sprint que incluiu essa versão, a previsão foi ajustada corretamente.

O que faz o gráfico curvar ?

Geralmente, a linha de previsão do gráfico tende a ser reta. No entanto, em algumas circunstâncias, a linha será curvada a partir da data corrente. Isso pode acontecer em qualquer direção, para cima ou para baixo, dependendo do evento que a causou. A seguir, vou explicar um pouco dos eventos simulados que podem causar essa curva no gráfico.

  1. Non-Working days

    Se houver mais dias não úteis definidos em um lado considerando a data corrente do que no outro, o gráfico será curvado de acordo, pois levaria um número diferente de dias no segundo plano para alcançar o mesmo número de pontos concluídos no plano anterior.

    Por exemplo, o gráfico irá curvar ligeiramente quando houver mais 'dias não úteis' no primeiro semestre, antes da data corrente, do que no segundo semestre.

  2. Fechando e reabrindo uma tarefa

    Este é um ponto em que existe um bug aberto na Atlassian (SWSERVER-11735) onde, em vez de subtrair os pontos das stories de um problema reaberto, ele continua adicionando-os. O que resulta na projeção incorreta, onde a velocidade assume que a equipe irá acelerar nas próximas semanas e atingir a meta mais rapidamente. Isso significa que as tarefas fechadas que são reabertas fazem com que a linha se curve para cima.

  3. Removendo o fix version de uma tarefa fechada

    Remover a versão de correção de um problema que já está fechado faz com que a linha seja curvada para cima. (Isso não acontece com problemas que estão abertos, apenas com aqueles que já estão fechados quando a alteração é feita.)

    Vale a pena ser muito cauteloso sobre esses eventos, já que a curva no gráfico geralmente não é reversível. Para exemplificar, abaixo segue um gráfico proveniente do resultado da remoção da versão de correção de várias stories fechadas.


Como as mudanças de escopo são tratadas?

As mudanças no escopo, além daquelas descritas acima, parecem ser tratadas de maneira consistente e esperada. Isso inclui o seguinte:

  • Aumentar / reduzir os pontos de uma story
  • Adicionando uma tarefa à versão de correção ou removendo a versão de correção de um tarefa aberta

Quando tal alteração é feita, isso altera o escopo de destino no lado direito do gráfico, de forma que a linha de previsão se intercepta em um ponto anterior ou posterior, fornecendo assim uma data de previsão atualizada. Veja o exemplo a seguir, em que o escopo foi reduzido, fornecendo uma previsão anterior para conclusão:

Conclusão

O version report, é um relatório muito útil para poder obter previsões a cerca de como sua equipe esta progredindo, e realizar projeções a cerca da entrega de uma versão. Por isso é muito importante entender de forma consistente como que esse relatório é construído. Espero que esse blog possa ajuda-lo nas suas previsões de lançamento das suas versões.


Fonte: https://community.alfresco.com/community/ecm/blog/2015/07/29/inside-the-jira-version-report


Gostou do post? Compartilhe e siga nossas Redes Sociais 


  

Você tem encontrado dificuldades em fazer uso dos produtos Atlassian com o seu time? Planejou conteúdos e tarefas e quer colocar em prática mas não tem apoio? Sabemos das dificuldades de convencer sua equipe a fazer uso do Data Center e estamos aqui para ajudá-lo a convencer seus colegas.

É importante que você saliente a importância de evoluir para o Data Center, e os benefícios e ganhos que a sua equipe terá. Ressalte que já passou da hora de mudar proativamente suas ferramentas para o Data Center, e diminuir as horas de trabalho perdidas. O número de vantagens e melhorias aparecem no número de horas economizadas resultam em produtividade da sua equipe.

Você encontra essas e muitas outras informações no nosso guia abaixo.



Fonte: 3layer/Atlassian


Gostou do post? Compartilhe e siga nossas Redes Sociais 



A 3Layer Tecnologia participou do evento "Atlassian for Teams", que ocorreu no dia 17 de Maio de 2018, no espaço de eventos Amcham Business Center, em São Paulo. O evento contou com o patrocínio da 3Layer, pois temos o compromisso de promover o conhecimento das possibilidades que o universo Atlassian oferece aos nossos clientes e parceiros.

  

Saiba tudo que ocorreu no Atlassian for Teams e DevOps Simulation

A evolução da tecnologia nos negócios e as novidades da Atlassian nas soluções em DevOps, ITSM e Enterprise, foram os principais assuntos do "Atlassian for Teams", cases de negócios, ferramentas, usos e processos dos produtos Atlassian também foram pauta do evento que abordou diferentes áreas de atuação, e contou com um painel com perguntas dos usuários e respostas de especialistas do universo Atlassian. Os palestrantes Archana Menon, Julio Chez, Kelvin Yap, entre outros, estiveram presentes para conduzir as conversas do acontecimento.

Neste dia também disponibilizamos aos nossos parceiros e clientes o workshop "DevOps Simulation", onde foi possível conhecer e aplicar técnicas, processos de implantação e melhorias para aqueles que já fazem uso de DevOps, ou estão objetivando fazê-lo. A 3Layer disponibilizou brindes e informações dos produtos Atlassian e, oportunizou para aqueles que participaram do evento, além de diversas palestras, e outras  atividades.

Nos dias 15 e 16 de Maio de 2018, nosso grupo de colaboradores, que esteve presente no evento, participou do treinamento sobre uso e implantação de DevOps nas empresas. A 3Layer apoiou a participação de sua equipe, afim de prepará-los e habilitá-los para oferecer aos nossos clientes as melhores práticas ágeis e integradoras que existem atualmente no mercado, e, que buscam facilitar o êxito e crescimento das empresas parceiras que buscam desenvolvimento, eficiência, entrega de softwares, projetos e demais serviços e produtos para fortalecer equipes.

DevOps é uma cultura e prática de engenharia de software que visa unificar o desenvolvimento de software (Dev) e o operacional de software (Ops), onde cada equipe é responsável por entregar um bom trabalho para o cliente de forma integrada, com foco na abordagem colaborativa, feedback e experiência unificada de novas técnicas e ferramentas. DevOps é uma receita para o sucesso, onde os times trabalham juntos para atingir equilíbrio, afim de alcançar os objetivos e entregar resultados positivos.

Para saber mais sobre a metodologia e implantação de DevOps entre em contato conosco.






Fonte: 3Layer Tecnologia


Gostou do post? Compartilhe e siga nossas Redes Sociais 



A 3layer está de cara nova na internet! Temos agora um site enxuto, clean, cheio de novidades! Explore o site e saiba mais sobre a nossa empresa.

  

Novo site, ótimos blogposts!

A 3layer trabalhou bastante para colocar no ar o novo site, e com uma grande equipe de envolvidos, concluímos a missão com sucesso! Deixamos tudo aqui mais organizado, mais clean, com um ar de inovação, você já deve ter percebido. Achamos importante manter nosso site atual e com informações atualizadas sobre nossos serviços e atividades, assim nos aproximamos dos nossos clientes e criamos um grande vínculo profissional.

Falando um pouco sobre cada seção do nosso novo site, temos os seguintes links no menu: Serviços, Empresa, Parceiros, Novidades e Contato.

Na página de Serviços, você ficará por dentro dos principais serviços que a 3layer oferece, como Consultoria, Gestão Compartilhada, Produtos e Cloud (sendo este uma novidade da 3layer que em breve você terá mais informações, num próximo blogpost).

Seguindo os itens, em Empresa, você saberá mais sobre a nossa Missão, Visão e Valores.

Em Parceiros, você verá todos os parceiros da 3layer e poderá saber mais sobre as ferramentas que cada um tem no mercado, bem como suas funcionalidades.

Na página de Novidades, estão dispostos todos os blogposts postados.

E em Contato, caso você tenha interesse em algum serviço nosso, ou quiser saber mais sobre algum parceiro ou ferramenta, pode entrar em contato conosco que ficaremos muito felizes em lhe ajudar com qualquer dúvida!

Voltando para a página inicial, acabamos por utilizar um pouco do conceito "One Page", que basicamente agrupa todo o conteúdo do site na página central do site, contendo informações necessárias para você saber tudo sobre nós! Desde nossa missão como empresa, parceiros, até os nossos últimos blogposts postados...

E falando em blogposts, também temos algumas novidades por aqui. Confira comigo o que mudou (pra melhor) sobre os blogposts:

Agora é possível visualizar 2 colunas ao final da página inicial, à esquerda está nosso blogpost destaque! Aquele que achamos super importante, como eventos realizados pela empresa, eventos que a empresa participa, e também blogposts sobre coisas novas sendo criadas ou melhoradas (como este blog sobre o novo site (big grin) ). E à direita, estão os nossos blogposts semanais, onde cada colaborador dedica um período de tempo postando coisas novas sobre o mundo Atlassian!


Espero que você tenha gostado do novo visual que aderimos para nosso site! Nosso foco é garantir uma melhor experiência do usuário final conosco, bem como trazer novidades para você desfrutar das últimas novidades do nosso grande parceiro Atlassian.

Até a próxima!


Ah!... você achou que havia finalizado né?! O nosso novo site foi feito no Confluence da Atlassian e teremos um blogpost novinho em seguida explicando mais sobre isso, aguarde!



Gostou do post? Compartilhe e siga nossas Redes Sociais 



Parece que a base de código em que você trabalha (ou suas principais dependências) pode mudar em um piscar de olhos? Assim que você mudar para a versão mais recente, uma nova versão estável será lançada. É ainda mais frustrante quando isso acontece dentro de sua empresa. Claro, ele pode aparecer durante o standup diário... mas isso nem sempre captura o impacto a jusante.

Agora, você pode assistir a repositórios para obter uma atualização de e-mail com as atualizações mais recentes. 

Mantendo-se atualizado com os repositórios

Manter-se a par das últimas alterações em vários repositórios pode ser angustiante para os desenvolvedores mais experientes. Os aplicativos monolíticos podem receber centenas de solicitações pull em uma semana e uma equipe em todo o mundo pode fazer uma alteração em uma dependência compartilhada. Tem de haver uma maneira melhor para os desenvolvedores e gerentes obterem as atualizações mais recentes sem ter que vasculhar as páginas de solicitações de pull ou commits, certo?



Com a nova funcionalidade de acompanhar repositórios, você pode receber notificações por e-mail sobre os repositórios nos quais está interessado (e somente para eles). A maioria dos desenvolvedores está familiarizada com as variações desse recurso, mas queremos oferecer controle refinado para os tipos de atualizações de e-mail que você pode receber.

Os e-mails de observação do Bitbucket Server podem ser personalizados para incluir confirmações somente na ramificação padrão ou em todas as ramificações, bem como alterações de estado de solicitação pull ou todas as atividades de solicitação pull. Essas atualizações podem ser agrupadas ou enviadas imediatamente. Cada opção ajuda os desenvolvedores a otimizar objetivos diferentes. Os e-mails em lote reduzem a desordem na caixa de entrada, enquanto as atualizações por e-mail imediatas garantem que você saiba o que está acontecendo assim que isso acontece.

Um novo visual para o Bitbucket Server

Lançamos  nossa nova e ousada marca em  setembro e hoje apresentamos uma nova aparência para o Bitbucket Server e o Data Center. Você pode já ter encontrado isso no servidor do Confluence. É o mesmo fluxo de trabalho do Bitbucket que você conhece com  uma interface de usuário nítida e bonita . Nosso novo visual é baseado na  linguagem de design Atlassian  e inclui cores atualizadas, tipografia e ícones.


Melhorar a produtividade do desenvolvedor está próximo e caro para nós na Atlassian - especialmente desde que adotamos dogfood em todos os nossos produtos. Nossos desenvolvedores estão amando como as atualizações do repositório do Bitbucket Server 5.10 de uma forma mais intuitiva, para que elas nunca percam uma batida, e esperamos que você também goste.

Aliás, se você quiser adicionar um pouco de diversão à sua análise de código, também adicionamos  suporte para o emoji de unicórnio  ( )! Porque você sabe ... unicórnios.

Fonte: Watch this! New look, watch repos, and unicorns in Bitbucket 5.10


Gostou do Post? Compartilhe e siga nossas Redes Sociais