Normalmente algumas preocupações se destacam: como conseguiremos coordenar o trabalho estando o time distribuído? Como conseguiremos trabalhar sem a mesma interação social que tínhamos no ambiente de trabalho único? E o impacto para as pessoas?

A agilidade, especialmente o Scrum, que recomenda que os times trabalhem juntos, em um mesmo local, pode obviamente ser adaptada para que esse local seja “construído” virtualmente. Bastam algumas ferramentas e acordos entre o time, para que tudo funcione bem, até melhor do que antes, no que diz respeito à produtividade.

Recentemente, em uma edição do Agile Beer, levantamos esse debate e foram muitos feedbacks de profissionais de empresas espalhadas pelo mundo. Procuramos organizar tudo e juntando com outros relatos apresentados em artigos que acessamos, preparamos um compêndio de sugestões para te ajudar a tratar com facilidade essa novidade. Nem tudo precisa ser implementado. Aliás, algumas soluções se sobrepõem. Selecione e adapte as que melhor ajudarem suas equipes.

Faça reuniões virtuais, mas limite a quantidade

Muitos profissionais reclamam do aumento de reuniões no trabalho remoto. Natural, pois algumas reuniões que eram presenciais e o profissional nem passava perto, agora vão direto para o seu desktop. Ficou mais difícil dizer que não vai poder ir, pois agora a reunião vem. Além disso, ficou mais fácil marcar reunião, pois não precisa sala, recurso audiovisual ou providenciar água e café. Cada um que se vire.

Reuniões demais cansam o time e afetam negativamente a produtividade. Um bom caminho é combinar com o time o que demanda reunião, estabelecer limites para a duração das necessárias, e até fixar um dia/período específico para reuniões que não sejam já previstas no processo de trabalho adotado.

Estabeleça um horário confortável e comum

O trabalho remoto na residência acaba por mudar tanto a rotina do indivíduo como a do seu lar. Adaptações nos horários e interações familiares acabam sendo necessárias. Porém, nem todas as famílias são iguais e tem as mesmas demandas. Não dá para ficar marcando reuniões ou tentando trabalhar junto sempre no horário que te agrada. Pode ser que esse horário não agrade aos demais do seu time.

Uma boa prática é estabelecer um horário diário em que todos do time devem estar disponíveis para o trabalho, um horário comum, que facilite a troca de informações, mas não incomode demais a rotina das pessoas. Afinal de contas, agora a casa é a empresa e a empresa é a casa. Reúna seu time e acorde esse horário. Defina um horário para trabalho, mesmo que reduzido, mas onde todos possam interagir à vontade. Defina intervalos bondosos para refeições, de modo que atenda aos diversos lares.  Isso vai diminuir a ansiedade do seu time e permitir que todos consigam organizar melhor as suas vidas.

Crie ambientes comuns

Algumas empresas fazem com que os seus colaboradores todos se conectem do início ao fim da jornada de trabalho utilizando uma ferramenta de comunicação. As vezes até utilizando vídeo. Isso pode acabar sendo um pouco over, e passar um sentimento de desconfiança e tentativa de controle muito ruim para todos. Se alguns se sentirem incomodados dessa forma, e isso despertar uma polêmica que pode ir da concepção do Pan-óptico ao efeito Hawtorne, algumas alternativas podem ser tentadas.

A existência de ambientes comuns para trabalho e descompressão pode ajudar. Algumas empresas têm adotado algumas soluções nesse sentido como:

• Criação de uma sala comum de trabalho, sem obrigatoriedade de conexão, simplesmente provendo um espaço virtual que as pessoas podem utilizar quando julgarem interessante;
• Realização de uma reunião diária, a exemplo do Scrum, em sala virtual comum a todos. Isso dá a oportunidade para as pessoas participarem de uma breve interação, combinarem encontros virtuais posteriores se necessário, e coordenarem seus esforços, sem tornar a reunião algo invasivo, visto a sua brevidade;
• Criação de uma sala de café virtual, onde os membros da equipe se conectam quando querem tomar um café e relaxar um pouco. Isso tenta substituir o “cafezinho”, tão comum no nosso ambiente de trabalho, aonde assuntos diversos são conversados.

Disponibilize os equipamentos e ferramentas necessários

Nem todos do seu time tem os recursos adequados para trabalhar de casa. Alguns precisam de uma cadeira melhor, outros de uma câmera, alguns até de uma mesa ou uma conexão Internet melhor. Verifique com o seu time o que lhes falta para o trabalho remoto e tome as possíveis devidas providências. Para muitas empresas o custo de manutenção dos locais de trabalho tradicionais reduziu bastante, permitindo um apoio maior aos seus times. Adicionalmente, os indivíduos passaram a ter custos que eventualmente não tinham. A empresa podendo, deve ajudar. Se não puder, converse com o time e faça os devidos acordos.

Nesse novo cenário, algumas ferramentas podem ajudar bastante na coordenação e organização. O ScrumHalf, p.ex., possui todos os recursos para apoiar o trabalho remoto, desde Backlog, Quadro Kanban virtual, facilidades para conduzir reuniões de Revisão e Retrospectiva, recursos para fazer o planejamento de entregas remotamente, e até salas de chat restritas aos projetos – War Rooms – para a interação da equipe e registro das conversas. O trabalho remoto acaba exigindo uma maior documentação das decisões e recursos como esse podem facilitar muito a vida do seu time.  Softwares adicionais de comunicação, principalmente de videoconferência, certamente serão necessários.

Atenção à Documentação

A interação do time agora será um pouco mais caótica, mesmo você tendo tomado alguns cuidados como descrito acima. Como visto, nem sempre as pessoas estarão disponíveis integralmente no seu horário de trabalho e a ausência de alguma informação pode criar um impedimento desnecessário. O melhor nessa nova realidade é dar um pouco mais de atenção à documentação, sempre lembrando que alguém mais do time poderá precisar trabalhar no que você está trabalhando agora. Sempre se pergunte o que você precisaria saber se fosse trabalhar naquela tarefa sem conhecer profundamente o problema. Que informações você precisaria? Elas estariam registradas em algum lugar já? Se positivo, indique. Caso negativo, registre-as.

Priorize Histórias Técnicas

É claro que você está construindo um produto ou executando um serviço para o seu cliente e você precisa entregar valor tangível para ele. Mas todos sabemos que qualquer projeto acaba acumulando histórias técnicas, que mesmo não sendo de percepção direta para o cliente também estão produzindo valor para ele. Se possível e não for comprometer as entregas a serem feitas, procure colocar na frente histórias técnicas. Pelo menos até a sua equipe se sentir mais à vontade com o trabalho remoto e com a interação remota com o cliente. Histórias técnicas demandam menos interação e podem inclusive ajudar o time a ganhar confiança no novo modelo de trabalho.

Esteja Presente para o seu Time

Deixe claro para o seu time que você está sempre pronto para ajudá-los. Independentemente dos horários acordados, combine que, se houver alguma emergência ou algo que prejudique realmente o andamento do trabalho, e que você possa ajudar a resolver de alguma forma, o acordo pode ser rompido e podem te chamar.

Se necessário, estabeleça no acordo um código de cores. No horário verde a chamada é livre, no amarelo somente se houver impacto sensível no resultado e no vermelho somente se for uma emergência mesmo. Dê exemplo de cada um dos casos, para ajudar o seu grupo a entender como se comportar. É importante para todos saberem que há suporte e que o fato de estarem fisicamente isolados não significa que estão largados e precisam resolver tudo sem auxílio de ninguém.

A realidade que vivemos demanda resiliência e criatividade. Mais do que manter a produtividade da nossa equipe, devemos contribuir para seu bem-estar e satisfação. Em um momento de dificuldades é que as verdadeiras oportunidades se revelam. Aproveite para melhorar a qualidade de vida no trabalho, mesmo sendo remoto. Sua ajuda e interesse podem fazer toda a diferença com o seu time.

E você que já está remoto, que prática você utiliza para tornar esse trabalho remoto agradável e interessante? Conte para a gente nos comentários.

The post Trabalho Remoto – 7 Dicas para Ajudar o seu Time appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto, esses problemas nunca devem passar despercebidos e o Burndown é um grande auxílio nesse aspecto, sinalizando que algo pode não estar indo como previsto. Ele serve como uma alerta, para que o time analise o quadro atual e o que será necessário fazer para entregar o combinado, ou até para adicionar novas atividades, entregando mais do que o combinado.

No entanto, infelizmente, muitas vezes esse gráfico tão simples e útil, é mal empregado e acaba trazendo prejuízos ao invés de benefícios para o time. Vamos dar uma olhada nos 3 principais vícios na utilização do gráfico de Burndown.

Controlar o Time

Não é vigiando o Burndown para avaliar o trabalho do time que as coisas vão mudar. Na verdade, esse tipo de atitude atrapalha muito o funcionamento da agilidade. Na agilidade todos trabalham com comprometimento absoluto. As pessoas são empoderadas para resolverem problemas e atuarem da melhor forma possível.  O controle indevido acaba se tornando um estopim para o início de uma crise na equipe. Acaba gerando contrariedade entre PO e time, com acusações mútuas que podem desencadear crises muito mais sérias. O gráfico de Burndown não deve ser utilizado com uma ferramenta para exercer o Comando e Controle.

Comparar Times

O Burndown também não é ferramenta para comparar times. Aliás, na Cultura Ágil, a preocupação deve ser muito maior em motivar do que comparar desempenho. O objetivo não é dar “pressão” no time, mas trabalhar junto com o time, buscando pontos de melhoria, para cada vez mais aumentar a eficácia e eficiência. O próprio sistema de pontuação de histórias, velocidade, e planning poker, utilizados na maioria dos times Scrum, não permite comparações entre equipes. É um sistema de pontuação sem uma referência única, onde cada time estabelece suas referências e seus valores de acordo com as suas percepções e capacidades, dentro de seus respectivos cenários. A utilização do Burndown para comparação de times além de inapropriada e sem nexo, é improdutiva.

Medir Performance

A performance do time de forma ampla é avaliada pelo cumprimento do combinado. Isso de uma forma geral acaba sendo feito conjuntamente durante a Retrospectiva, em função do resultado da Revisão. Acontece que, em alguns casos, membros do time, ou mesmo participantes externos, acham que podem utilizar o Burndown para avaliar o desempenho do time durante a Sprint. Ficar medindo performance através de indicadores como o Burndown, além de não ser adequado, cria um clima de desconfiança prejudicial, e acaba levando ao primeiro vício que citamos, o de tentar controlar o time, utilizando o modelo de Comando e Controle.

É importante que todos os envolvidos com o Scrum entendam que o Burndown é um mecanismos de transparência, de awareness, e não uma ferramenta de medição de desempenho para uso numa estrutura de Comando e Controle. O propósito do Burndown é dar visibilidade à evolução dos trabalhos, para permitir que o time faça a devida análise do mesmo, considerando o cenário e o momento que se encontram. Existem outras métricas bem interessantes que podem ajudar o time. Entretanto o Burndown deve, e precisa, ser usado de forma útil e frequente para ajudar o time a dar o seu melhor.

Como vocês estão usando o Burndown no seu time? O Burndown tem ajudado? Conta para a gente.

The post Burndown Chart – As 3 Principais Confusões appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O movimento, se assim podemos chamar, #noestimates tem como fundamento básico a afirmação que “estimativas não geram valor”. Baseado nisso, prega que devamos evitar a todo modo estimar, reduzindo tal atividade ou mesmo a extinguindo. Advoga que devemos bolar métodos alternativos à estimação. Será? Esse caminho serve para a gente?

Vamos começar falando um pouco sobre estimativas. Estimativas são por natureza incertas, i.e., apresentam o valor aproximado de algo que ainda não conhecemos, não dominamos ou não temos como medir. Estimativas são comumente usadas para previsão. E porque precisamos prever algo? Simples: para podermos planejar.

A ideia com o planejamento de uma forma geral é permitir que nos preparemos para o futuro, especialmente no que diz respeito a tomarmos decisões que promovam a eficácia e eficiência do nosso projeto. Nesse artigo Planejando a Sprint: Velocidade e Estimativa, p.ex., falamos do planejamento da Sprint.

Entretanto, adicionalmente, devemos também entender que o processo de estimar envolve a procura de conhecimento sobre o que se deseja estimar. Em projetos de desenvolvimento, seja de software ou de qualquer outro produto ou serviço, isso representa discutir o assunto com o cliente/usuário. Buscar e investigar produtos ou serviços semelhantes ou de concorrentes. Muitas vezes até promover discussões com especialistas. E essa busca por conhecimento traz como efeito colateral um melhor entendimento do que se deseja estimar. Quanto mais sabemos mais acertamos, como discutimos nesse post Histórias bem Descritas, Estimativas mais Precisas.

Assim, chegamos ao primeiro aspecto importante, abordado de certa forma pelo #noestimates. Só devemos estimar se isso for necessário para alguma coisa que nos traga valor. Seja para prever custos, prazos, planejar capacidade, definir escopo de projeto, entender dependências entre requisitos e/ou melhorar o entendimento sobre algo que deveremos fazer.

Por outro lado, sabemos que estimativas são intrinsecamente imprecisas, especialmente se elaboradas pelas pessoas erradas, no momento errado. A literatura relacionada a projetos de software deixa isso bem claro, como apresentado por Robert Glass, aqui sintetizado:

1.  A maioria das estimativas de software é feita no início do ciclo de vida, quando tem-se pouco entendimento do problema.
2. A maioria das estimativas é feita pela gerência ou pelo marketing, não por quem irá efetivamente construir o software.
3. Raramente estimativas são refeitas.

Considerando tais observações, podemos também deduzir para que estimativas não devem ser usadas.

1. Determinar algo com precisão.
2. Estabelecer desafios.
3. Basear cobranças.
4. Premiar desempenho.
5. Curar falta de comprometimento.
6. Estabelecer confiança.

Sabemos que estimativas são muitas vezes utilizadas de forma errada e isso precisa sim ser combatido. Porém estimativas são parte indispensável de um processo de planejamento que, como vimos acima, serve pelo menos para organizarmos esforços para o atingimento de algum objetivo.

Como fazer então? Falamos para o cliente que é impossível planejar, porque não podemos ou devemos estimar nada? Planejamos com detalhes tudo que vamos fazer?

Bem, inicialmente devemos entender que o movimento ágil percebeu esse problema nos processos tradicionais de desenvolvimento e estabeleceu algumas diretivas que ajudam a reduzir os efeitos colaterais negativos de estimativas. Destaco a mais relacionada, ao meu ver, a estimativas: “Responder a mudanças mais que seguir um plano”.  Isso significa, por exemplo, que ao planejarmos algo entendemos que nosso conhecimento sobre o planejado irá mudar e que precisaremos rever nosso planejamento. Tudo a ver com o que discutimos acima.

De uma forma geral, o movimento #noestimates, ou as recomendações do mesmo, segue o mesmo caminho de muitos outros que tem surgido na agilidade: traz diversos insights interessantes, mas não pode ser aplicado de forma absoluta ou em qualquer caso.

Muitos projetos e organizações com  as quais temos contato já, de certa forma, ao utilizar o Scrum, trabalham com #noestimates. Em sua maioria, os times estimam histórias usando pontos de história. Entretanto, a maioria não estima tarefas, limitando-se a estabelecer um timebox para estas. É comum os times  quebrarem suas histórias em tarefas procurando limitar o tamanho de suas tarefas para que possam ser realizadas em um dia, no máximo em dois.

Concluindo, #noestimates é muito válido, mas não significa que deva ou possa ser aplicado indiscriminadamente. Se agrega valor, estimar é preciso. O mais importante é lembrar que estimar por estimar só atrapalha o time.

Como tem sido sua experiência em projetos Scrum? Sua equipe estima ou não? Vocês vêem valor em estimar?

The post Estimar ou #NoEstimates? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O SEMAT (Software Engineering Method and Theory) foi fundado em 2009 para ajudar a resolver diversos problemas que a indústria vem enfrentando. Seu primeiro passo foi fornecer uma fundação (chamada de Kernel) que irá suportar todo o pensamento de software daqui em diante, independentemente das práticas e ferramentas utilizadas. Com esse kernel, é possível entender se o processo, seja ele ágil, cascata ou qualquer outro, está atendendo as áreas consideradas pelo grupo como essenciais: Os chamados Alphas. Esses Alphas são divididos em temas e se relacionam entre si das mais variadas formas, como podemos ver na figura a seguir.

Mais informações sobre o modelo, os estados e os Alphas podem ser obtidas no guia de referência, mas farei uma breve descrição de cada um deles a seguir:

Cliente:

Área que se preocupa em saber se o time entende os stakeholders e a oportunidade que está sendo endereçada

• Oportunidade: As circunstâncias que fazem apropriado a criação ou alteração do sistema em questão.
• Stakeholders: As pessoas, grupos ou organizações que afetam ou são afetadas pelo sistema.

Solução:

Área que se preocupa  em saber se o time estabeleceu um entendimento conjunto dos requisitos e implementou um sistema capaz de atender os mesmos.

• Requisitos: As restrições que o sistema deve atender para endereçar a oportunidade e satisfazer os stakeholders
• Sistema de Software: O sistema como um todo, composto de software, hardware e dados

Endeavor (Traduzido livremente para esforço):

Área que se preocupa com o time, sua maneira de trabalhar e com o trabalho a ser feito.

• Trabalho: As atividades envolvendo esforço (mental ou físico) com objetivo de alcançar o objetivo
• Time: O grupo de pessoas engajado no desenvolvimento, suporte e gerência do projeto
• Maneira de Trabalhar: O conjunto de práticas selecionado que guiará o time e ajudará no trabalho

Cada um desses alphas possuem um estado a ser determinado pela equipe, utilizando a técnica denominada de Progress Poker. Esse método foi criado para ser rápido de ser executado e prover valiosa informação sobre o projeto de uma forma geral. O objetivo é que a equipe avalie cada Alpha, os estados que o mesmo possuem e entre em um consenso da situação atual naquele quesito.

É importante avaliar os itens que não foram atendidos porque são eles os pontos a serem atacados para a melhoria do processo.

Para verificar na prática essa técnica, utilizamos em um dos nossos projetos e obtivemos o seguinte resultado:

Como podemos ver, estamos bem posicionados em relação a Cliente (Oportunidade e Stakeholders) e Solução (Requisitos e Sistema de Software) mas pecando um pouco na área de Esforço (Time, Trabalho e Maneira de Trabalhar).

Sabemos que a causa dessa situação se deu pela entrada de diversos membros novos na equipe que ainda não haviam internalizado as práticas e atividades que a empresa executa. Esse foi o foco de maior trabalho para que o cenário identificado fosse revertido.

Em relação as outras duas áreas, é satisfatório perceber que bons resultados estão sendo obtidos e as práticas adotadas continuam sendo mantidas.

Faça você também a avaliação do seu projeto e deixe um comentário com a sua impressão!

The post SEMAT – Como Anda a Engenharia de Software do Seu Projeto? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Esta cultura tem tornado cada vez menos rígida a fronteira entre o desenvolvimento e as operações de TI necessárias para manter os sistemas no ar.

Diante dos muitos benefícios trazidos pela adoção das práticas de DevOps, principalmente em times ágeis, quais seriam as razões para que esta cultura tenha ganhado força somente num passado recente? Que fatores motivam as práticas de DevOps? Que fatores permitiram que o DevOps se tornasse uma realidade?

No post de hoje vamos elicitar 3 grandes motivadores da cultura DevOps na atualidade.

O conflito histórico entre equipe de infra e equipe de desenvolvimento parece estar com os dias contados. As práticas de DevOps vem com o objetivo de facilitar a integração entre atividades de desenvolvimento, como criar novas features, resolver bugs, etc, e as operações de infra para manter o sistema no ar como manutenção dos servidores, sincronização e deploy do código, etc.

Realizar estes dois tipos de tarefas de forma coordenada pode trazer diversos benefícios através da colaboração entre os profissionais que criam e testam as aplicações e as equipes que mantém todo o ambiente de produção no ar. Para mais informações sobre DevOps, leio o post "Já Ouviu Falar em DevOps?".

Como falei no início do post, os processos de DevOps começaram a marcar presença mais fortemente nos times de TI somente nos últimos anos. Principalmente pela constante necessidade de mudanças e, consequentemente, pela maior necessidade de agilidade nas entregas, o cenário que encontrado em muitos times de desenvolvimento praticamente "pedia" a aplicação dos processos de DevOps.

Entender os motivos que levaram a ascensão destas práticas pode ajudar na aplicação das mesmas de forma a extrair o máximo dos benefícios trazidos com as técnicas de DevOps. Abaixo, enumeramos 3 grandes fatores que ajudam a entender o porquê da adoção e valorização das práticas de DevOps atualmente:

1. Cultura Ágil

Dentre tantas melhorias, como os avanços nos meios nos setores de telecomunicação e tecnologia da informação tornaram a realidade das organizações cada vez mais dinâmicas.

Com ambientes mais dinâmicos surge a necessidade de maior flexibilidade e respostas mais rápidas às mudanças. Mais especificamente na área de TI, é preciso que os sistemas sejam desenvolvidos e mantidos de maneira que mudanças possam ser aplicadas com agilidade.

É necessário estar continuamente entregando valor. Para que isso seja possível é preciso que, uma vez desenvolvido, um sistema possa ir para produção rapidamente e com qualidade. Um gargalo que pode ser comumente encontrado é na burocracia muitas vezes imposta pelas equipes que mantém os sistemas no ar. Para estas equipes, a priori, mudanças não são bem vindas e estão sempre associadas a riscos. Porém, para o negócio as mudanças tem se tornado cada vez mais necessárias.

O tempo entre o desenvolvimento de um recurso e o deploy em produção pode ser um fator determinante para o sucesso ou fracasso de uma iniciativa de uma organização. Diante deste cenário é possível notar os processos de DevOps surgem como uma prática interessante na medida em que permitem que as mudanças sejam levadas rapidamente para produção de forma coordenada e com qualidade, reduzindo o time to market.

As práticas de DevOps tratam de tornar mais eficientes e, quando possível, automatizar todas as operações necessárias para que um código saia do desenvolvimento e chegue em produção com rapidez e qualidade, que é o que se pretende dentro da cultura ágil.

2. Tecnologia

Operações como realizar deploy de forma bem controlada, gerar de pacotes, executar testes, automatizar scripts para sincronização de pacotes, dentre outras operações não são desejos recentes na TI.

Antes mesmo do crescimento da cultura ágil e da necessidade de entregas contínuas, a automatização de operações de TI já era um desejo em muitos times. Podemos nos perguntar: Então por que estas operações ganharam maior atenção agora com as práticas de DevOps?

O primeiro ponto que me vem em mente é o fator financeiro. Antigamente, responder rápido a mudanças era algo não tão "lucrativo" quanto hoje. Primeiro porque o custo para automatizar estas operações era mais alto.

Segundo, por que a necessidade por respostas rápidas a mudanças não era tão grande quanto hoje.

Outro ponto é a tecnologia. Atualmente com a virtualização e computação na nuvem, além da alta capacidade de processamento das máquinas, ficou facilitada a construção de ferramentas voltadas para o apoio às operações de TI, como automatização de testes e gerência de configuração,por exemplo. Além disso, os crescentes investimentos em aplicativos para dispositivos móveis tem impulsionado criações e atualizações que precisam ser lançados frequentemente com agilidade e qualidade.

3. Infra estrutura mais complexa

Manter os sistemas de uma organização no ar tem se tornado uma tarefa cada vez mais complexa. Atualmente, muitas são as formas de disponibilizar as aplicações no ar. A manutenção, que antes era feita somente sobre as máquinas físicas, hoje é feita sobre máquinas físicas, máquinas virtuais, além da nuvem.

Estes novos recursos permitem que as equipes responsáveis por manter os sistemas no ar tenham maior previsibilidade, garantias e SLA bem definidos na manutenção de seus sistemas.

Por outro lado, a complexidade decorrente destes serviços requer que as operações de TI estejam bem definidas e automatizadas na medida do possível, para garantir que os benefícios alcançados com estes serviços sejam alcançados.

A partir destes 3 grandes fatores fica fácil perceber a necessidade e os benefícios que o DevOps pode trazer às organizações atuais.

Para o desenvolvimento ágil é importante que as operações sejam feitas com a colaboração de todo o time, conferindo mais rapidez nas entregas, e economizando nas burocracias.

Métricas importantes como o Time to market são afetadas diretamente com a implantação das práticas de DevOps, que pode reduzir significativamente o tempo necessário para que um produto seja disponibilizado no mercado.

The post 3 Motivadores para a Cultura DevOps appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.