Nos últimos anos, na área de TI, muito tem se ouvido falar em DevOps.

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 (Português) 3 Motivadores para a Cultura DevOps appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post (Português) 3 Razões para o Coaching em Equipes Ágeis appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post (Português) 3 Razões para usar BPMN appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Estamos vivendo a era do conhecimento, onde as organizações estão cada vez mais empenhadas em conhecer e entender tudo o que está relacionado ao seu negócio, com o objetivo de elaborar estratégias mais eficientes, prevendo riscos e reduzindo custos. Um artifício muito utilizado nesta tarefa é a modelagem de processos.

Muitas são as organizações que investem na gestão de processos com o intuito de conhecer, documentar, sistematizar, utilizar e retroalimentar o seu processo de negócio. Porém, existem alguns erros muito comuns na gestão de processos que podem torná-la uma ferramenta ineficiente e custosa.

No post de hoje apresentamos 3 dicas do que NÃO fazer na modelagem de processos.

O que é modelagem de processos?

De uma forma bem breve, podemos descrever um processo como aquilo que ocorre em uma sequência de etapas. Por exemplo, o processo de compra em uma loja virtual pode se dar pela sequência de etapas:

1. Acessar a loja virtual
2. Busca pelo produto
3. Visualização do Produto
4. Inserção do produto no carrinho de compras
5. Finalização da compra
6. Preenchimento de dados cadastrais
7. Escolha da forma de pagamento
8. Confirmação da compra

Este é um exemplo simples e representa apenas uma possibilidade de processo de compra em uma loja virtual. Muitas são as variações que este processo pode ter de acordo com o tipo de produto, de acordo com a loja, entre outros fatores.

A modelagem de processos trata exatamente de representar um processo em diferentes níveis de acordo com o que se deseja com a modelagem. De acordo com o objetivo, uma modelagem mais superficial pode ser suficiente. Por outro lado, podem ter objetivos que tornem necessária uma modelagem em nível mais detalhado.

Por que modelar processos?

Conhecer os pontos fortes e fracos de uma organização é necessário para que uma organização possa tomar ações no sentido de melhorar o que pode ser melhorado e garantir a manutenção do que funciona bem. A modelagem de processos é uma ferramenta que permite à organização visualizar a situação atual do seu processo de negócio, ajudando a identificar gargalos, pontos de falha, problemas de interface, dentre outros itens. Além disso, a partir de uma modelagem de processos fica mais fácil identificar possibilidades de melhoria mesmo em pontos que não sejam um problema, mas que podem ser melhorados.

Notação

A modelagem de processos utiliza uma notação (ou linguagem) para representar o comportamento de uma organização. Redes de Petri, SPEM e BPMN são exemplos de notações utilizadas na modelagem de processos. Por terem sido desenvolvidas em épocas diferentes e com objetivos diferentes, as notações podem apresentar diferenças. Assim, de acordo com o objetivo da modelagem, uma notação pode ser mais vantajosa do que outra. Em futuros posts discutiremos as principais diferenças entre as notações mais utilizadas na modelagem de processos e apresentaremos dicas de como conduzir a escolha de uma notação.

3 erros comuns na modelagem de processos

Alguns erros são muito comuns na construção da modelagem de processos nas organizações. Neste post apresento 3 deles:

1-Tentar modelar todo o processo em um único nível

Seja em grandes organizações, seja em pequenas, muito dificilmente o processo poderá ser representado completamente em um único nível. Os modelos devem ser construídos em diferentes níveis de abstração, que correspondem aos diferentes graus de abstração da realidade. Por mais difícil que pareça, é comum encontrarmos organizações onde os responsáveis pela gestão de processos tentam construír um modelo do processo inteiro em um único nível. Quando isto ocorre, o modelo tende a ser mais complicado de entender, dificultado a visualização do processo e a comunicação entre as partes envolvidas através do modelo.

2- Confundir um expert em ferramentas de gestão de processos com um gestor de processos

Outro erro comum é a confusão que se faz entre um bom usuário de ferramentas de modelagem de processos e um bom gestor de processos. Saber usar uma determinada ferramenta ou conhecer a fundo uma notação são muito importantes na modelagem de processos. Porém, é muito importante também que o responsável pela modelagem esteja qualificado para construir modelos adequados. Aprender uma notação, ou ser expert em uma ferramenta de modelagem não são garantia de que o processo será bem modelado. É preciso qualificação para construir bons modelos independente de notação ou ferramenta.

3- Não deixe a modelagem de processos somente com o pessoal de sistemas

Uma prática comum nas organizações atualmente é envolver cada vez mais o pessoal de TI na modelagem de processos de negócio da organização. De fato, é interessante que o pessoal de sistemas esteja envolvido na modelagem, afinal são eles quem vão construir os sistemas que podem tornar o processo mais automatizado e garantir que, na prática, as etapas previstas na modelagem sejam cumpridas. Porém é preciso cuidado para não deixar a modelagem do processos toda na mão da TI. Em geral o pessoal de TI participa da modelagem de processos de negócio com o objetivo de definir o escopo de sistema e seus requisitos. Quando a modelagem fica toda sob responsabilidade dos responsáveis pelo sistema, a tendência é que o modelo construído seja mais um modelo do sistema que vai ser construído ao invés de ser o modelo do processo de negócio da organização.

A modelagem de processos permite às organizações descreverem o seu processo de negócio e identificar pontos de falha e oportunidades de melhorias. A construção de um modelo do processo de negócio organizacional não é uma tarefa trivial e exige cuidados para que os objetivos pretendidos com a modelagem não sejam prejudicados.

No post de hoje apresentamos 3 erros comuns na modelagem de processos de uma organização. E vimos como cada um deles pode prejudicar a organização quanto aos objetivos pretendidos pela organização.

E você? Como trata da modelagem de processos na sua organização?

Deixe um comentário! Até o próximo post!

The post (Português) 3 Grandes Erros na Modelagem de Processos appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Muitas organizações encontram dificuldades para adotar metodologias ágeis, como o Scrum. Em muitos casos apenas algumas técnicas de agilidade são adotadas na prática, levando o time a não obter as principais vantagens do uso de metodologias ágeis. Na tentativa de usufruir de alguns benefícios do Scrum, algumas organizações realizam adaptações no framework a fim de adequá-lo a sua realidade. Estas adaptações, também conhecidas como ScrumButs tem se tornado muito comuns nas organizações.

No post de hoje compartilho com vocês alguns ScrumButs que tenho encontrado por aí.

O formato básico do ScrumBut é:

Nós usamos Scrum, mas <por alguma alguma razão>, <fazemos um certo workaround>.

A razão, em geral, é alguma dificuldade ou fruto da falta de entendimento sobre o framework Scrum. O workaround pode ser visto como a saída escolhida pelo time para tratar uma determinada dificuldade.

Muitos podem ser os ScrumButs. A seguir destacamos alguns bem comuns:

ScrumBut 1: “Nós usamos Scrum, MAS a reunião diária é muito longa, então nós fazemos reunião diária uma vez na semana.”

A reunião diária deve ser um breve resumo do status da Sprint. Apresentações técnicas, discussões, etc, devem ser feitas em outros momentos. Algumas equipes deixam de fazer a reunião todos os dias porque quando o fazem, levam muito tempo. O que deveria ser feito neste caso é buscar reduzir o tempo da reunião para que ela possa ser realizada diariamente, ao invés de deixar de fazê-la porque está sendo demorada.

 ScrumBut 2: “Nós usamos Scrum, MAS não gostamos de todas as práticas, então adotamos apenas as práticas mais atraentes”.

Segundo Kent Beck, engenheiro americano, criador do Extreme Programming (XP) e TDD, nenhuma prática isolada funciona bem por si só. Uma prática precisa da outra para manter o equilíbrio de todas. Usar apenas alguma(s) práticas(s) propostas pelo Scrum pode levar o time a não poder usufruir dos benefícios da agilidade, uma vez que pode não haver equilíbrio entre as práticas propostas pelo Scrum.

ScrumBut 3: “Nós usamos Scrum, MAS não estamos confiantes quanto ao nosso planejamento, então aumentamos o tempo do nosso planejamento.”

O planejamento de um projeto pode se tornar uma tarefa difícil e demorada quando o Product Backlog não está preparado. Em muitos casos, pela falta de histórias preparadas e priorizadas, a tarefa de planejar a Sprint pode ser prejudicada, ou até inviabilizada. Portanto, é preciso cuidar do Product Backlog para que o planejamento possa ser feito de forma eficiente. Este exemplo reflete a questão do equilíbrio entre as práticas do Scrum, mostrando como uma prática interfere na outra.

ScrumBut 4: “Nós usamos Scrum, MAS nós não conseguimos desenvolver uma história dentro de uma Sprint, então, aumentamos o tempo da Sprint para podermos implementar esta demanda.”

Scrum é TimeBox. Logo deve-se alterar o escopo da Sprint ao invés de se alterar a sua duração. Caso uma história seja muito grande, é recomendado que ela seja fragmentada em histórias menores que possam ser acomodadas dentro de uma Sprint sem que o tempo da Sprint tenha que ser modificado.

Alguns ScrumButs podem não ter workaround envolvidos, como o exemplo a seguir.

ScrumBut 5: “Nós usamos Scrum, MAS não gostamos, pois tornou nossa vida mais difícil.”

Em muitos casos, a transparência que se alcança pela adoção do Scrum, evidencia possíveis problemas no projeto em questão. Porém, ao invés de solucionar o problema, buscando primeiramente conhecer a sua real causa, algumas organizações culpam a metodologia, como se esta fosse a responsável pelos problemas que já existiam, porém só se tornaram conhecidos após o uso de técnicas ágeis. É preciso muito cuidado para avaliar a verdadeira causa dos problemas e não “culpar o carteiro pela má notícia da carta que ele apenas entregou”.

Apesar de atuarem como um grande obstáculo para o sucesso do uso Scrum, os ScrumButs são muito comuns.

No post de hoje apresentei alguns exemplos pelos quais já passei em uma organização que vem tentando adotar o Scrum. Podemos perceber que dentre outras dificuldades, as modificações no framework Scrum impedem que os benefícios do seu uso possam ser alcançados. Portanto é necessário que o framework seja utilizado adequadamente, sem alterações nos seus elementos básicos.

Você se identificou com algum destes ScrumButs? Conhece outros? Compartilhe conosco nos comentários! Até o próximo post!

The post (Português) Qual a sua desculpa? Conheça os 5 ScrumButs mais comuns por aí appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.