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.
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:
- O que você fez ontem?
- O que vai fazer hoje?
- 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:
- O que deu certo?
- O que não deu certo?
- 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