HOME A Breakthrough Development Products - O poder da cultura ágil no desenvolvimento de produtos

A Breakthrough Development Products - O poder da cultura ágil no desenvolvimento de produtos

O mundo está em constante evolução. O desenvolvimento de produtos está, a cada dia, ocorrendo mais rápido “A Breakthrough Development Products”, resultado do aparecimento de tantas startups ao redor do mundo em diferentes mercados. Mais de 1/3 dos produtos das empresas listadas pela Fortune 500 têm menos de 3 anos. Nas startups, os produtos têm menos de 1 ano. As startups já nasceram com essa cultura, o que as tornam ainda mais competitivas e, também, complexas na visão tradicional.

O gerenciamento ágil de projetos tem papel relevante na criação e atualização de produtos.
Empresas que utilizam essa rapidez na abordagem têm 80% mais chance de manter seus produtos atualizados e competitivos do que empresas que utilizam o processo tradicional ou waterfall.

A agilidade que gera conhecimento: por trás da cultura ágil tem algo a mais do que entregar projetos e produtos. A cultura ágil tem características que levam à competitividade. Entre as mais importantes estão:

  • • Possibilidade de inovar, pois na cultura ágil o objetivo pode ser ampliado;
  • • Auto-organização de equipes, permitindo que o time estabeleça métodos próprios de trabalho e com a possibilidade de correr alguns riscos;
  • • Sobreposição de fases que, diferentemente do processo tradicional, cria uma dinâmica com maior iteração;
  • • Transferência de conhecimento e autoconhecimento, onde as equipes são encorajadas a buscar soluções para os problemas apresentados em cada fase (iteração) através da autoaprendizagem, inclusive, com formalização do tempo que cada indivíduo da equipe deva dedicar-se para esse desenvolvimento.

São características como estas que podem levar uma equipe a desenvolver-se muito mais rapidamente, pois todos os elementos participam e conhecem muito bem todos os objetivos a serem alcançados, durante todo o tempo.

Fundamentos do Scrum: o Scrum é um exemplo de prática ágil. É simples e foi inspirado em uma jogada do rugby, onde apenas 8 jogadores de cada time podem participar de cada jogada. O objetivo é retirar os obstáculos e avançar o quanto possível. Scrum não é um acrônimo. O substantivo Scrum tem origem no nome Scrummage que é a falta do jogo e reinício, no rugby.
O Scrum (pense no rugby) se baseia em PVM (Produto Viável Mínimo) ou MVP (Minimum Viable Product – em inglês), que significa ter um produto mínimo para ser utilizado ou comercializado o quanto antes possível. A figura abaixo, mostra muito bem o pensamento da cultura ágil.

Scrum Eg Product

O PO (Product Owner ou responsável pelo produto) é a pessoa que irá direcionar como os esforços são empregados. O papel do PO vai além de definir o produto, pois também atua como uma interface entre a equipe e os stakeholders.

Contando histórias: vamos pensar em um aplicativo de celular onde o usuário pode comprar ingressos de cinema. Na visão do PO, o produto deve permitir fazer um cadastro com nome, e-mail, endereço e telefone; incluir e alterar senha; realizar pedido de tickets; escolher o filme, a sala, a cadeira, o horário e realizar o pagamento. Cada grupo ou cada função é uma história de usuário e o PO é o responsável por montar as histórias.
As histórias devem ser independentes, negociáveis, valiosas (agregando valor ao produto), estimáveis, sucintas e testáveis. Cada uma deve ter seu próprio critério de aceitação. Por exemplo, cadastrar a senha com letras e números ou e-mail válido. A história pode ser funcional ou técnica. A história funcional é a que usamos para cadastrar a senha. Já a história técnica é a que usamos para manter o produto atualizado, como em uma nova versão do produto, por exemplo.

Comparando o processo ágil X tradicional: imagine a criação de um livro. O autor busca a inspiração e realiza a pesquisa de campo, escreve todo o conteúdo, inclusive as notas. Ele então remete ao editor, que lê e sugere alguma alteração. Depois, o texto é formatado, incorporado, impresso e distribuído e, nesse caso, mais uma vez, temos um processo tradicional. Imagine esse mesmo livro sendo elaborado em processo ágil: o autor busca inspiração e a valida com o editor. Depois ele escreve capítulos que são revisados e experimentados (público-alvo é convidado a experimentar) e só então, o livro é incorporado, impresso e distribuído.
Na sua opinião qual dos dois processos é mais efetivo? Como consultor a resposta é: depende. Se for um romance, pode ser que o primeiro método seja mais efetivo, mas se for um livro técnico / didático pode ser que o segundo método seja o melhor. Sempre depende das circunstancias existentes. De qualquer forma é possível perceber que o processo ágil cria mais envolvimento que o processo tradicional, se espalhando pela organização como um vírus do bem, quebrando as estruturas hierárquicas mais rígidas e permeando a cultura de colaboração.

Bom, se você chegou até esta parte do artigo já deve ter entendido como o Scrum trabalha. Deve ter percebido que a abordagem ágil é, de fato, bastante “dinâmica e envolvente”. Por exemplo, construir uma nova fábrica onde o produto final só pode ser testado no fim da última fase, ou implementar um software de gestão financeira que necessita de fases para que o produto seja totalmente incorporado (instalação, migração de dados, testes unitários, testes integrados, treinamento e go live) e, assim, apresentar um resultado final. Daí é fácil entender que o processo ágil não se aplica em todas as situações, sendo que o processo tradicional ainda é uma alternativa muito valiosa, basta ver o número crescente de profissionais de gestão de projetos em PMI/PMBOK para atuar em PMO, com ampla demanda pelas empresas.

As equipes: no Scrum, o tamanho da equipe ideal é parecido com o tamanho da equipe do rugby. Recomenda-se de 5 a 8 profissionais, sendo que em alguns casos, um profissional poderá desempenhar mais de um papel.

Desenvolvimento iterativo: o Scrum trabalha com histórias e pontos por história. No Scrum, o desenvolvimento do produto é iterativo e cada iteração dura entre uma a 4 semanas. Pode-se dividir as histórias de forma que se tenha uma estimativa de quantas iterações serão necessárias para o lançamento da PVM (Produto Viável Mínimo) e do produto total.
O Planejamento das iterações é feito pelo PO, pelo Scrum Master e equipe. O PO prioriza as histórias mais importantes e atua em conjunto com a equipe para determinar o tamanho de cada uma delas, verifica os CA (Critérios de Aceitação) e todas as dúvidas sobre as histórias são esclarecidas.
Diferentemente de outros processos iterativos, como o RUP ou tradicionais, o Scrum não utiliza artefatos padronizados para descrição de papéis, requisitos funcionais, requisitos técnicos e diagramas, mas se utiliza de artefatos definidos pela própria equipe. Ao final do planejamento das iterações a equipe precisa dizer “sim”, comprometendo-se com o que foi definido. Lembre-se, o processo no Scrum é colaborativo e não deve ser imposto.

O monitoramento no Scrum: assim como em qualquer outra prática de controle de projetos, o Scrum necessita de controle e utiliza quadros para mostrar as histórias da iteração atual, a situação de cada história e as tarefas concluídas. Pode-se se utilizar um quadro, de preferência visível a todos, mostrando as tarefas atuais, as não iniciadas e as concluídas.
A segunda ferramenta de controle é um gráfico, chamado de burndown que mostra duas linhas: uma com as tarefas programadas ao longo do tempo e outra linha, com as tarefas executadas. Seja como for, esses dois quadros têm como objetivo mostrar a situação das iterações da equipe e servem para que a equipe se reúna em torno deles para verificar a situação atual e discutir alternativas de correção, se necessário.

O Scrum Master: o papel do Scrum Master é o de facilitador da equipe. É considerado o Coach do time, dando ao time a melhor condição possível para realização do trabalho.

As reuniões no Scrum: diariamente ocorrem reuniões entre o Scrum Master e a equipe. Essas reuniões (chamadas de stand-up meetings ou reuniões em pé) têm como objetivo verificar se as coisas estão ocorrendo dentro do planejado. Todos estarão na reunião: testadores, desenvolvedores, PO e Scrum Master. Nesse encontro as tarefas são movimentadas pelo quadro de histórias. O Scrum diário é de, no máximo, 15 minutos. O motivo da reunião ser realizada com os participantes em pé é para que tudo seja rápido e eficiente. São feitas três perguntas:

  1. O que você fez ontem?
  2. O que vai fazer hoje?
  3. Tem alguma coisa impedindo seu progresso?

Caso exista algum empecilho, o mesmo deve ser resolvido, em um dia, pela equipe, pelo Scrum Master, pelo PO ou por outra pessoa comprometida com o projeto. O Scrum diário é a cadência de comunicação e colaboração da forma, pois no Scrum, as equipes se comunicam o dia todo.

Detalhando um pouco mais como o Scrum funciona: o PO é o responsável por se reunir com os stakeholders para definir o que deve ser feito. Novos recursos e histórias podem ser identificados e adicionados, sendo o PO o responsável por detalhar as novas histórias e o CA de cada uma. Apesar disso, no Scrum, a iteração não muda. As pendências e novas histórias só podem ser inseridas em iterações futuras, com prioridade definida pelo PO. A história só pode fazer parte de uma iteração se estiver totalmente entendida, ou seja, se houver dúvida sobre a história, a mesma não pode ser inserida na nova iteração, e ficará pendente. A cada nova iteração a equipe se reúne, por até 60 minutos, para entendê-la e avaliar a iteração passada.

Vale lembrar que o Scrum se baseia em colaboração. Em cada iteração deve-se entregar uma PVM e que uma história pode ser desmembrada em várias outras a serem inseridas em iterações futuras, dependendo de sua complexidade e de sua dificuldade. De toda forma, é o PO que define quando as histórias desmembradas devem ser realizadas.

Ganhando o stakeholder e a equipe: é bastante frustrante quando um investidor pergunta como estão as coisas e não recebe feedback de quando o produto vai ficar pronto e quando será lançado, ou trabalhar em uma equipe que fica sem feedback do que está acontecendo. No Scrum, é utilizada a demonstração para mostrar o PVM para os stakeholders. É um evento importante onde a equipe, o Scrum Master, o PO e os stakeholders se reúnem para mostrar as realizações, recomendar alterações e realizar feedback para a equipe. Isso gera maior integração e melhora o relacionamento, abrindo a perspectiva dos stakeholders sobre a equipe e o produto. No Scrum, isso fortalece o relacionamento e a confiança da equipe e dos stakeholders.

Pensando no que foi feito: no Scrum existe um processo que é a retrospectiva, realizada ao final de cada iteração, sendo o Scrum Master o agente facilitador dessa avaliação. Somente os membros da equipe irão participar da retrospectiva. São feitas três perguntas:

  1. O que deu certo?
  2. O que não deu certo?
  3. O que precisamos melhorar?

As respostas defensivas dever ser evitadas. O reconhecimento deve ser utilizado para criar um ambiente positivo para a equipe. As melhorias identificadas devem ser inseridas nas próximas iterações, sendo o Scrum Master o responsável por gerar as condições para que isso ocorra.

Por: Antonio Romano


Está por dentro das alterações no e-Social?

Diversas alterações já serão implantadas desde logo, antecipando as mudanças. A principal delas é a alteração de diversos grupos e campos de “OC” (Obrigatórios na Condição) para “F” (Facultativos).

Fique por dentro das principais alterações da EFD Contribuições

Com o início da obrigatoriedade da EFD-Reinf, que inclui as informações relativas à Contribuição Previdenciária sobre a Receita Bruta, a CPRB deixa de ser informada no bloco P da EFD-Contribuições.

Conheça as diferenças entre a ECD e a ECF

Apesar das declarações estarem correlacionadas, a ECD e a ECF possuem algumas diferenças importantes. Sobretudo em relação às informações fornecidas para a Receita Federal.

Sete passos para uma delegação de tarefas eficaz

Uma das inseguranças mais encontradas em quem tem papel de líder nas organizações é a delegação de tarefas.