Responda a Pesquisa sobre Comunicação nos Projetos

Já vi em muitos textos por aí afirmações sobre como a comunicação é isso e aquilo nos projetos. Quem já leu o guia PMBOK deve ter se deparado com algo como: “o gerente de projetos gasta 90% do seu tempo em comunicação com as partes interessadas”. Minha experiência, nos mais de 35 anos de desafios enfrentados nas organizações em que trabalhei, me mostrou por diferentes ângulos porque tanta gente decidiu escrever e falar sobre a comunicação. 

Outra coisa que a experiência me ensinou é que não sei tudo, longe disso, e que seria interessante juntar a experiência de tantos que trabalham com projetos e conhecer suas ideias e percepções sobre o tema. Esse esforço de juntar a experiência de tantos vale muito mais do que o saber individual e não deixa de ser uma boa oportunidade de aprendizado. Por isso, estou trabalhando em uma nova pesquisa sobre a comunicação nos projetos.

Essa pesquisa ficará disponível para acesso até o início de abril de 2021, e eu gostaria muito que você, leitor que me acompanha, respondesse ao questionário com apenas 16 perguntas sobre a comunicação nos projetos! Não é necessário dar seu nome e se identificar para participar dessa pesquisa.

A pesquisa foi carregada no Google Forms e cada respondente só poderá participar uma vez. Você pode enviar o link da pesquisa (que está logo aí em baixo) para seus colegas e amigos, desde que eles (e elas) também trabalhem ou tenham trabalhado em projetos nos últimos 12 meses.

Qualquer um que tenha participado de um projeto está apto a responder a pesquisa, não havendo restrições quanto ao tipo, o porte, o valor do investimento e a duração do projeto. Estão valendo projetos direcionados às áreas de construção civil, educação, bancos, agronegócio, indústria automobilística, indústria mecânica, petróleo, energia elétrica, eletrônica, processos industriais, logística, química, telecomunicações, aeronáutica, robótica, automação, desenvolvimento de aplicativos, inteligência artificial, etc. Isso porque o FOCO é a comunicação nos projetos!

Responder ao questionário da pesquisa não vai tomar mais do que 5 minutos do seu tempo. Quanto mais pessoas puderem responder as questões da pesquisa melhor será para o resultado.

 

Clique nessa frase para acessar o link da pesquisa!

 

Se você estava considerando usar uma plataforma de pesquisa na Internet, preferencialmente gratuita, onde você pudesse carregar o seu questionário de perguntas, com o objetivo de turbinar o seu TCC (Trabalho de Conclusão de Curso), o Google Forms é uma excelente sugestão. Você poderá ver como isso funciona respondendo a nossa pesquisa.

Sim, é claro que os resultados serão divulgados e comentados no blog após a coleta e análise dos dados. E para aqueles que desejarem estou disponível para responder perguntas e fazer esclarecimentos.

Desde já agradeço a todos que participarem! Muito obrigado! 

Pré Venda do Guia PMBOK - 7a. Edição

 

Anunciado para primeiro de maio de 2021, o Guia PMBOK - 7ª. edição encontra-se em pré-venda no site da Amazon.

 

O Guia PMBOK® - 7ª. edição, apresentado como o recurso ideal para os profissionais de gerenciamento de projetos, enumera 12 princípios de gerenciamento de projetos e é estruturado em torno de 8 domínios de desempenho do projeto, tendo sido projetado para atender às necessidades atuais e futuras dos profissionais e ajudá-los a ser mais pró-ativos, inovadores e ágeis em possibilitar os resultados desejados do projeto.

Mesmo com tudo isso, é praticamente certo que o PMI (Project Management Institute) lance no futuro um novo guia PMBOK atualizado, como tem ocorrido em intervalos de aproximadamente dois anos, desde que a primeira edição foi lançada. Afinal de contas, nada permanece novo para sempre.

Esta edição do Guia PMBOK® reflete toda a gama de abordagens de desenvolvimento (preditiva, adaptativa e híbrida) e se integra com o PMIstandards plus, para informações sobre padrões com base no tipo de projeto, abordagem de desenvolvimento e setor da indústria. O PMIstandards plus é uma plataforma que pode ser acessada apenas por membros que podem se registrar (e entrar) no site do PMI.

Link de acesso que solicitará login e senha (apenas para membros do PMI)  >

   PMIstandards plus 

É isso aí, até a próxima!

A História do Nó Górdio e da Espada de Alexandre

 

Em 333 AC, enquanto Alexandre (O Grande) liderava seus exércitos pela Ásia, ele alcançou a cidade de Gordian, na Frígia. Lá, lhe mostraram a carruagem do antigo fundador da cidade, com seu mastro amarrado a equipagem por meio de um nó intrincado. Segundo a tradição, esse nó deveria ser desatado apenas pelo futuro conquistador da Ásia. Muitos tentaram e todos falharam ...

 

Diz a lenda que Alexandre olhou para o nó, desembanhou a espada e cortou o nó com um único golpe. Pouco depois, sob seu governo, a Ásia foi unida pela primeira vez. Moral da história: às vezes é melhor não ficar muito preso a um problema. Busque uma solução ousada!

Para desatar o nó de um projeto muitas coisas são necessárias. Tais coisas são, por natureza, inter-relacionadas. Todas essas coisas juntas formam uma espécie de “espada de Alexandre” que precisa ser usada com ousadia, mas também com sabedoria.

Para ser ousado é preciso ter confiança e estar emponderado. No projeto, o emponderamento significa proporcionar autonomia e, ao mesmo tempo, determinar os limites que o gerente de projetos terá sobre os recursos, o cronograma e a coordenação do projeto.

Para ser ousado é preciso estar preparado para correr riscos. Toda oportunidade tem um risco implícito. Da mesma forma que todo risco tem uma oportunidade implícita. Gerenciar os riscos é vital para conseguir uma execução do projeto bem sucedida.

Mas, olhando um pouco mais adiante, sabemos que correr riscos sem ter um plano é como voar as cegas. Os projetos gerenciados de forma tradicional são baseados em planos detalhados que incluem o escopo, o cronograma, o orçamento, os recursos, a qualidade, as compras, a comunicação, as partes interessadas, os riscos e a integração de tudo isso. No plano de riscos, é feita a identificação, a análise qualitativa e quantitativa, e a definição de ações de tratamento dos riscos. Por sua vez, em projetos em que prevalecem abordagens ágeis, os planos também existem, mas são de curto prazo, geralmente do tamanho das rodadas de trabalho de algumas semanas, chamadas de sprints ou iterações, dependendo o método ágil utilizado. Trabalhar em rodadas de trabalho mais curtas é um fator que também reduz os riscos. De uma forma ou de outra, os projetos precisam de gente ousada, que pise firme, trabalhando calçadas em planos, e capazes de criar soluções inovadoras. Um projeto não necessita de cegos que não enxergam o caminho, de mudos que não sabem se comunicar e de surdos que não ouvem o cliente. 

E aí entra uma grande qualidade de saber aproveitar o tempo precioso com o cliente. Isso significa estar envolvido, sabendo ouvir e se comunicar. O envolvimento do cliente no projeto facilita a tarefa de obter informações, conhecer necessidades, preferências e expectativas. Afinal de contas, tudo gira em torno do cliente.

Deve-se considerar também que muitas vezes os clientes tem dificuldade para dizer exatamente o que desejam e até mesmo saber exatamente o que precisam. Então, o escopo de um projeto que parece muito bem definido no início pode, a qualquer momento, precisar seguir um rumo diferente. Em um projeto os clientes podem fazer solicitações de mudança, assim como outras partes interessadas podem também solicitar mudanças. Quanto mais longo é um cronograma (de vários meses, por exemplo), maior será a probabilidade de alguém descobrir que não era bem isso que ele (ou ela) queria e, em consequência, uma mudança ser solicitada. Mudanças têm impactos no cronograma, nos custos, na qualidade e afetam os planos com maior ou menor intensidade. Se as mudanças forem muitas e forem grandes, poderão matar um projeto.  Os projetos tradicionais (que costumam ser longos) sofrem com esse problema e essa é a principal razão dos cuidados tomados para que se faça um levantamento de requisitos bastante detalhado e se leve a sério as lições aprendidas em projetos anteriores. Mesmo assim, as mudanças de escopo costumam ser a principal razão de fracasso de um projeto tradicional.

Por sua vez, nos projetos ágeis as rodadas de trabalho mais curtas são adequadas para a execução de partes menores de um projeto, escolhidas – com a participação do cliente - do ponto de vista do que é mais prioritário a agrega mais valor para esse mesmo cliente. O projeto completo será concluído após a execução de certo número de rodadas de trabalho, que acontecem uma após a outra. O risco de errar em uma rodada é menor. Se houver erro, o custo do erro em uma rodada será igualmente menor. Mesmo assim, há situações em que mudanças são solicitadas e necessitam ser analisadas quanto ao seu impacto no projeto. Se uma mudança causa um impacto grande o suficiente que afete de forma negativa a rodada que foi planejada, essa mudança poderá ser levada para uma próxima rodada de trabalho.  

Por tudo isso, seja em um método tradicional de gerenciamento de projetos ou em um método ágil, é evidente que o gerenciamento das mudanças no projeto é muito importante. A sabedoria adquirida com a experiência nos mostra que apesar do planejamento, mudanças geralmente ocorrem durante a execução do projeto, sendo necessário analisar, de todas as formas possíveis, os impactos dessas mudanças no projeto, antes de aceitá-las.

Outro ponto que a experiência nos ensina é que o suporte da alta direção da empresa é vital para que tudo funcione bem nos projetos. É a alta direção que disponibilizará os recursos necessários para o projeto, que exigirá que esses recursos sejam usados com eficiência e eficácia e, sem a menor sombra de dúvida, que cobrará os resultados esperados para o projeto.

Conseguir todas as coisas de que se precisa para formar a tal “espada de Alexandre” pode ser bastante difícil. Isso, como tudo na vida, mostra algo que é ruim e bom ao mesmo tempo. Mas, será que a espada de Alexandre teria feito tudo sem a ação daquele que a usava? Se fosse fácil, qualquer um conseguiria. Bem, é isso aí, até a próxima.

**********************************************

Uma Visão Geral de Diferentes Métodos Ágeis

 

Nesse artigo vamos apresentar uma visão geral de alguns métodos ágeis de gestão de projetos de desenvolvimento de software. O leitor poderá notar que praticamente todos esses métodos usam rodadas (sprints, ciclos, iterações) de trabalho para criar partes menores de um produto maior e completo. A escolha e priorização dessas partes menores – criadas em cada rodada - leva sempre em consideração o que é mais útil, prioritário e gera mais valor para os clientes.

As abordagens ágeis aqui tratadas e descritas nesse artigo em suas linhas gerais, parecem provar que existe uma diversidade de ideias e preferências presentes no campo da engenharia de software e do gerenciamento de projetos. Mas, como na frase de Bob Marley, essas diferenças não derrubam o ágil, ao invés disso, ajudam a levantá-lo.

 

“Seja diferente:

Não derrube.

Ajude a levantar...”

(Bob Marley)

Scrum – Dentro desse método ágil, um projeto é divido em ciclos chamados de Sprints. Um Sprint representa um Time Box (período de tempo, tipicamente de 2 a 4 semanas) dentro do qual um conjunto de atividades deve ser executado. Tudo que vai ser implementado em um projeto é mantido em uma lista de itens chamada de Product Backlog. No início de cada Sprint, faz-se uma Sprint Planning Meeting (reunião de planejamento do Sprint), em que o Product Owner prioriza os itens do Product Backlog e a equipe seleciona os itens que serão implementados durante o Sprint que se inicia.

Os itens alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. Para tratar do que foi feito no dia anterior, identificar gargalos e priorizar o trabalho do dia que se inicia, a equipe realiza uma reunião chamada Daily Scrum Meeting. Ao final de um Sprint é realizada uma reunião de revisão chamada de Sprint Review Meeting, na qual a equipe apresenta os itens implementados e o projeto é avaliado com relação aos seus objetivos. Finalmente, é também realizada uma reunião de retrospectiva, chamada de Sprint Retrospective Meeting, para avaliar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

Os principais papéis no Scrum são o Product owner, que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings, o Scrum Master, que é o responsável por facilitar o trabalho de toda a equipe, principalmente no que diz respeito à compreensão dos conceitos do Scrum, e a equipe (Scrum Team) que trabalha com os itens priorizados do  Product Backlog  e se compromete a entregá-los ao final de um Sprint.

XP (eXtreme Programming) – É um método ágil no qual o desenvolvimento de software é feito em iterações de curto período de tempo (1 ou 2 semanas) onde a equipe desenvolve um conjunto de funcionalidades. No início da iteração os desenvolvedores e clientes se reúnem para priorizar as funcionalidades. Essa reunião chama-se jogo de planejamento e nela já devem estar criadas as User Stories (Estórias de Usuário). Se uma estória for muito grande, deverá ser dividida em tarefas com menor duração. O planejamento é importante para que sempre se faça o que é mais importante e prioritário. O XP segue um conjunto de práticas que auxiliam no alcance de um projeto bem sucedido e incluem, por exemplo, o cliente sempre presente, programação em par, metáforas, TDD, refatoração, código coletivo, padronização de código, design simples, integração contínua e releases curtos. No XP também são adotadas reuniões diárias de curta duração, feitas com as pessoas de pé, para alinhamento do projeto e discussão de problemas, chamadas de Stand Up Meetings (Reunões de Pé).

Users Stories (Estórias de Usuário) são escritas pelos clientes com “coisas que o software precisa fazer”, substituindo documentos detalhados de requisitos e são usadas para criar estimativas de tempo para a reunião de planejamento além de auxiliar na criação dos critérios de testes de aceitação.

Spike Solutions se refere ao uso do programa mais simples possível para explorar soluções potenciais. É usado para determinar quanto trabalho será necessário para resolver ou contornar um problema de software.

Programação em par – Dois programadores fazendo o trabalho juntos em um único computador para revisão do código, redução de falhas e melhoria da qualidade.

Metáforas – São elementos usados no computador que simulam “coisas” que existem no mundo físico (lixeira, porta, janela, pasta, etc). As metáforas melhoram a comunicação e o entendimento de partes do código que executam determinadas funções representadas por elementos do mundo físico com os quais os desenvolvedores e clientes estão familiarizados.

TDD (Test Driven Development ou Desenvolvimento Orientado à Testes) – Primeiro se escrevem os testes, antes de implementar o sistema (conjunto de componentes integrados). Cada componente é testado individualmente para garantir sua correta operação. Depois disso, os componentes são integrados para formar o sistema e então testados, buscando-se encontrar erros que resultem de interações não previstas nos testes individuais.

Refatoração – Uma técnica usada pelas equipes para melhorar continuamente a estrutura do código quando uma nova funcionalidade é introduzida, tornando-o mais claro e fácil de ser compreendido, mas sem mudar o comportamento das funcionalidades.

Código coletivo – Isso significa que o código fonte não tem dono e ninguém na equipe de desenvolvedores precisa solicitar permissão para modificar o mesmo.

Padronização de código – Isso significa que existe um jeito certo de fazer as coisas no projeto e todos na equipe devem seguir essas regras definidas para desenvolver o software.

Integração contínua – Isso significa que não se deve esperar muito tempo (1 semana ou mais) para integrar uma nova funcionalidade com a versão atual do sistema.

Releases curtos – Isso significa que os releases são pequenos pedaços do produto que está sendo desenvolvido no projeto.

DSDM (Dynamic Systems Development Method) – É uma metodologia ágil de desenvolvimento de software iterativa e incremental que enfatiza o envolvimento constante do usuário. Assim sendo, em cada rodada no método, partes do software (funcionalidades ou componentes funcionais do sistema) vão sendo entregues.

É importante ter a compreensão que para iniciar o ciclo de desenvolvimento iterativo no DSDM o projeto precisa estar construído em uma base sólida, com fundamentos que incluem, por exemplo, um estudo de viabilidade e um plano geral de desenvolvimento.

A estrutura de trabalho do DSDM possui fases que são descritas a seguir:

Pré-Projeto: Essa fase deve garantir que os projetos estejam prontos para começar com base no objetivo e nas metas de negócios.

Antes de iniciar a construção das funcionalidades, o projeto no DSDM considera que deve ser feita uma análise de viabilidade e também deve ser elaborada uma análise do negócio. Como resultado se obtém o relatório de viabilidade, a lista de requisitos do sistema e o plano geral de desenvolvimento.

Após a conclusão destas duas fases, o sistema é desenvolvido iterativamente e incrementalmente, em um modelo evolucionário que considera o seguinte:

Iteração do modelo funcional: Tem foco na criação, a partir dos requisitos identificados no estágio anterior, de protótipos funcionais que determinam as funcionalidades a serem implementadas, que resultarão desta iteração. Isso feito, a lista de requisitos é atualizada, removendo-se os itens entregues e refazendo a lista de prioridades dos requisitos remanescentes.

O sistema é construído exatamente de acordo com o design e as funções consolidadas e integradas nos protótipos.

Na fase de implantação, ocorre a entrega das funcionalidades (ou componentes funcionais do sistema) desenvolvidas, devidamente prontas e funcionando para utilização pelos usuários finais. Inclui também o treinamento dos usuários e a entrega da documentação do projeto relacionada às funcionalidades que estão sendo entregues.

Pós-Projeto: Esta fase garante a eficiência e eficácia do projeto, através de manutenções, melhorias e ajustes.

FDD (Feature Driven-Development) – é um método ágil e iterativo para desenvolvimento de software que combina gestão de projetos com boas práticas de engenharia de software. No FDD o projeto é dividido em “features” (funcionalidades) definidas como pequenas partes de um projeto completo.

No FDD é feito um mapeamento sobre que partes do software os desenvolvedores serão capazes de criar, dividindo as solicitações maiores e complexas em uma série de conjuntos menores e, em seguida, é elaborado um plano que estabelece como concluir cada um desses conjuntos menores ao longo do tempo.

Os principais papéis do FDD são os seguintes:

Gerente de Projetos (Project Manager) – É o administrador do projeto, que faz os relatórios de progresso e gerencia o orçamento, os equipamentos, os recursos, etc.

Arquiteto Chefe (Chief Architect) – É o responsável pelo design geral do sistema.

Gerente de Desenvolvimento (Development Manager) – É o membro da equipe que lidera as atividades de desenvolvimento do dia-a-dia.

Programador Chefe (Chief Programmer) – É um programador experiente que já passou algumas vezes por todo o ciclo de vida de desenvolvimento de software.

Proprietários de classe (Class Owners) - São desenvolvedores que estão trabalhando como membros de pequenas equipes de desenvolvimento sob a orientação de um Programador Chefe.

Especialistas em Domínio (Domain Experts) - São usuários, patrocinadores, analistas de negócios, ou todos esses especialistas combinados, conhecidos por possuir a base de conhecimento na qual os desenvolvedores dependem e confiam para entregar o sistema correto.

O FDD é multifuncional, iterativo e altamente colaborativo e possui cinco (5) etapas básicas:

Desenvolver um modelo geral – Com orientação do Arquiteto Chefe, a equipe desenvolve um modelo geral que serve de base para a criação da lista de funcionalidades a ser desenvolvida no projeto.

Construindo a lista de funcionalidades - Usando o modelo da etapa anterior, a equipe ou o Programador Chefe constrói uma lista de funcionalidades considerando o que será útil para os usuários e poderá ser concluído ao longo de um cronograma de liberação de funcionalidades.

Planejamento por funcionalidade - Os planos são colocados na ordem em que as funcionalidades serão implementadas. As equipes são então selecionadas para desenvolver cada conjunto de funcionalidades.

Design por funcionalidade - Nesse estágio, o Programador Chefe escolhe as funcionalidades para o desenvolvimento e faz a alocação destas para as equipes. Geralmente, uma equipe deve contar com as seguintes funções/papéis: Gerente de Projeto, Arquiteto Chefe, Gerente de Desenvolvimento, Especialista de Domínio, Proprietário de Classe e Programador Chefe.

Construindo por funcionalidade - As equipes trabalham para fazer a codificação das funcionalidades, os testes e a documentação completas de cada funcionalidade. As funcionalidades concluídas pela equipe e avaliadas pelo cliente são liberadas.

Embora os métodos sejam diferentes, há muitas semelhanças entre eles.

É perfeitamente possível notar que nos métodos estudados existe a ideia da rodada de trabalho, em que partes menores vão sendo feitas e incorporadas para formar um todo. Os nomes dessas rodadas de trabalho (Sprint, ciclo, iteração) podem variar de método para método, mas a filosofia é nitidamente comum à todos.

A duração dos Sprints, ciclos ou iterações é de poucas semanas. Além disso, a maior parte dos métodos ágeis foi idealizada para o trabalho com equipes pequenas.

Há uma etapa de avaliação inicial que tem como propósito a tarefa de responder as seguintes perguntas: - O que vamos fazer? Como vamos dividir esse problema grande em partes menores? As respostas ajudam a criar a lista de funcionalidades do software que será desenvolvida.

Outro aspecto presente em quase todos os métodos aqui apresentados é que, ao invés de elaborar um plano completo e que abranja todo o projeto, o planejamento é feito para cada rodada de trabalho. Se analisarmos em linhas gerais, será possível notar que no Scrum esse plano é o planejamento do Sprint (Sprint Planning). No XP existe o chamado jogo de planejamento que utiliza as estórias de usuário, os critérios dos testes de aceitação e elabora o plano da iteração. No FDD o planejamento é feito por funcionalidade, uma vez que os planos são colocados na ordem em que as funcionalidades serão implementadas.

Outro ponto que merece ser destacado é que cada método, a sua maneira, permite que seja criado um fluxo contínuo de desenvolvimento de software.

Espero que você leitor que me acompanha tenha gostado desse conteúdo. Deixe seu comentário. Bem, é isso aí. Até a próxima!

As 12 Descobertas de Reifer

Será que a foto que vemos logo abaixo prova que o Scrum, em particular, e o Agile, em geral, não são isso tudo? Não é bem assim. 

No início da falação e intensa divulgação sobre os métodos ágeis todos queriam ser ágeis e mostrar que estavam a favor da novidade. Ninguém queria ficar para trás e isso levou as pessoas a fazer vista grossa para certos exageros. A frase na capa do livro de Jeff Sutherland, lançado em 2014, é uma prova disso. A frase dizia o seguinte: “Scrum, the art of doing twice the work in half the time.” (Scrum, a arte de fazer o dobro do trabalho na metade do tempo).

Mais recentemente o Disciplined Agile Consortium (Consórcio do Ágil Disciplinado) em uma de suas apresentações divulgou o slide acima, que diz o seguinte:

.............................................

You are promised: Scrum, the art of doing twice the work in half the time. (Jeff Sutherland)

You actually get: 

Recent study of 3,000+ teams within 155 organizations found:

Teams adopting agile (mostly Scrum) saw productivity increases of 7 to 12 % in average.

Teams adopting prescriptive scaling frameworks, the most popular of which is SAFe, saw productivity increases 3 to 5% in average.

.............................................

Te prometeram: Scrum, a arte de fazer o dobro do trabalho na metade do tempo. (Jeff Sutherland)

Você realmente obteve:

Um estudo recente com mais de 3.000 equipes em 155 organizações descobriu:

As equipes que adotaram o Agile (principalmente o Scrum) tiveram aumentos de produtividade de 7 a 12% em média.

As equipes que adotam estruturas de trabalho prescritivas ágeis em escala, a mais popular das quais é o SAFe, viram a produtividade aumentar de 3 a 5% em média.

.............................................

Não vejo isso como uma crítica aos métodos ágeis em geral e ao Scrum em particular, mas sim um alerta ao exagero que as novidades costumam causar nas pessoas.

Mas então quais foram os benefícios obtidos pelas organizações que adotaram métodos ágeis de gerenciamento de projetos? É o que o trabalho de Donald Reifer procurou responder.

O texto a seguir teve como base o artigo de Reifer, publicado no website Infoq.com, com o título “Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings” (Um estudo da Análise Quantitativa de Métodos Ágeis (2017): Doze Principais Achados), que pode ser encontrado acessando o link no final desse artigo.

De qualquer modo, é evidente que os métodos ágeis trouxeram benefícios para os projetos e para as empresas que os adotaram, como é tratado no próprio artigo de Reifer, na descrição das suas 12 descobertas, que tiveram como base uma extensa pesquisa que envolveu a análise dos resultados de 1.500 projetos concluídos que usaram métodos ágeis e outros 1.500 que usaram abordagens tradicionais.  Vejamos, então, um resumo sobre as 12 descobertas de Reifer relacionadas aos métodos ágeis aplicados aos projetos:

Descoberta no. 1 – Os métodos ágeis continuam a ser a abordagem predominante usada para desenvolvimento de software. Mais de 70% das organizações pesquisadas reportaram que têm usado métodos ágeis operacionalmente por períodos que vão de três a treze anos.

Descoberta no. 2 – O método ágil mais popular usado atualmente continua a ser o Scrum ou um derivado do Scrum chamado LeSS (Large Scale Scrum). Outros métodos ágeis empregados, mas encontrados em porcentagens muito menores na população da pesquisa, incluem o AUP (Agile Unified Process), o XP (Extreme Programming) e o FDD (Feature-Driven Development).

Descoberta no. 3 – Trabalhar com métodos ágeis em grandes projetos não é uma tarefa fácil. As organizações que buscam esses grandes desenvolvimentos estão usando uma metodologia ágil em escala (48%) ou uma metodologia híbrida (52%). Isso representa uma mudança em relação ao cenário de dois anos atrás, quando o uso do ágil em escala era cerca de metade do que é hoje.

Descoberta no. 4 – A taxa de reversão do Agile diminuiu. Apenas 10% daqueles que abandonaram os métodos ágeis reverteram (ou seja, decidiram voltar) para os métodos tradicionais. Os outros 90% de organizações que abandoram os métodos ágeis passaram a usar abordagens híbridas ou mesmo caseiras para preencher o vazio.

Descoberta no. 5 – Os ganhos de produtividade ágil foram estabilizados. Com base em dados de 1.500 projetos tradicionais concluídos e outros 1.500 projetos ágeis também concluídos, os ganhos médios de produtividade alcançados durante o desenvolvimento por equipes que usam métodos ágeis foram de 7 a 12% melhores do que para as equipes que usam métodos tradicionais. Essas melhorias ainda são notáveis, especialmente em grandes organizações, onde esses ganhos se traduzem em economia de milhares de horas por pessoa.

Descoberta no. 6 – As economias de custo do Agile também se estabilizaram. Os custos ágeis, medidos em termos de $/unidade produzida, continuam a ser entre 5 a 12% menores do que os custos medidos da mesma forma em um projeto tradicional. Os dados revelam que as reduções de custo obtidas com o uso de métodos ágeis durante os últimos três anos se estabilizaram à medida que as empresas espalharam o uso desses métodos por toda a organização.

Descoberta no. 7 – A maneira como o tempo e o esforço são distribuídos durante o desenvolvimento de software usando métodos ágeis difere daquela experimentada em projetos tradicionais. A principal razão para essa diferença é que as equipes que usam métodos ágeis concentram seus esforços na criação de um produto funcional em curto espaço de tempo, em vez de, por exemplo, gastar tempo na criação de documentação. Os desenvolvedores ágeis criam e revisam o código de trabalho com o usuário, em vez de – como nos métodos tradicionais - dedicar 50% do esforço e 40% do tempo à geração de requisitos e especificações de design antes do início da codificação. Em vez de tentar obter as especificações certas antes de começar a codificar, os desenvolvedores ágeis gastam até 80 por cento de seu tempo e esforço desenvolvendo um software funcional que possam demonstrar para os clientes.

Descoberta no. 8 – O Agile melhora a capacidade de cumprir os prazos do cronograma. A análise dos dados pesquisados mostrou que o Agile fornece às empresas a capacidade de cumprir prazos apertados em 75 a 90% do tempo, em comparação com o desempenho médio de 40 a 60% que as empresas experimentam em projetos similares gerenciados por métodos tradicionais. No entanto, é importante entender que o conteúdo típico entregue em desenvolvimentos ágeis (ou seja, a porcentagem de funcionalidades que foram prometidas e realmente entregues) varia de 80 a 90% contra 95 a 100% para desenvolvimentos orientados a planos ou tradicionais. Nos projetos pode acontecer a situação da não entrega de todas as funcionalidades prometidas. Nos projetos ágeis isso é esperado porque as equipes oferecem as funcionalidades que o cliente considera mais importantes. Quando prazos ou mudanças de escopo se tornam um problema, as funcionalidades de prioridade mais baixa são acumuladas (voltam para o backlog) e aquelas de prioridade mais alta são desenvolvidas e entregues. Em contraste, os desenvolvimentos tradicionais seguem uma filosofia do “tudo ou nada”, em que os atrasos são a norma.

Descoberta no. 9 – A qualidade é melhor nos métodos ágeis do que nos métodos tradicionais. Nos próximos 3 anos espera-se que a qualidade ágil exceda a qualidade obtida nos métodos tradicionais em um fator de 6 a 12%. A qualidade do software melhora tanto durante o desenvolvimento quanto no pós-lançamento, porque é trabalhada pela equipe à medida que o software funcional é gerado.

Descoberta no. 10 – O valor ágil continua sendo difícil de quantificar. Os métodos ágeis enfatizam o fornecimento de valor a seus usuários/clientes, fornecendo continuamente produtos de software funcionais ao longo do ciclo de vida de desenvolvimento. O valor é comumente medido em termos do benefício financeiro e/ou competitivo que as organizações recebem por seus esforços e investimento. Embora haja alguma orientação disponível para o planejamento de valor, pouca ajuda é oferecida sobre como quantificar o valor derivado desses esforços. Em vez disso, o termo às vezes é usado para transmitir moral e outras medidas de valor importantes, mas não facilmente quantificáveis.

Descoberta no. 11 – O Àgil continua a fornecer vantagem competitiva aos seus usuários. Muitas organizações parecem acreditar que os métodos ágeis podem representar uma vantagem competitiva quando aproveitam ao máximo seus pontos fortes e contrabalanceiam seus pontos fracos. Os métodos ágeis não apenas fornecem recompensas de produtividade, custo e tempo de colocação do software no mercado, mas também fornecem aos usuários a capacidade de atrair e reter talentos.

Descoberta no. 12 – Os impactos do Agile nas práticas de contratação governamentais podem ser importantes. O impacto dos métodos ágeis não se limita às práticas de desenvolvimento. Quando o ágil é usado no contrato, o impacto do método se reflete na forma como o trabalho é planejado, cronogramas e orçamentos são alocados, requisitos são capturados e gerenciados, o progresso é revisado e o desempenho geral do contrato é determinado. Se o governo e os fornecedores estabelecerem uma estrutura de gerenciamento colaborativo para o desenvolvimento, ambos podem trabalhar de acordo com os planos acordados para atingir as metas compartilhadas com um mínimo de atraso e atrito. Quando tal estrutura não é criada, conflitos ocorrem devido às diferenças na forma como cada um conduz seus negócios. Essas incompatibilidades geralmente resultam em gargalos, atrasos e desconfiança devido a seus desalinhamentos.

Para mais detalhes acesse:

Reifer, D. J. (2017) Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings. Available at: https://www.infoq.com/articles/reifer-agile-study-2017/  Accessed: 10 February 2021.  

.............................................

As “Inocentes Mentiras" do Marketing

   

O professor Rafael Sampaio, em seu livro “Propaganda de A a Z”, publicado pela editora Campus em 1996, afirma que “a melhor política é ser absolutamente honesto em tudo o que se diz e se mostra ao consumidor. Um consumidor frustrado com uma promessa exagerada, decepcionado pelo não atendimento das expectativas criadas por um comercial ou revoltado com a mentira contada por um anúncio, não apenas deixa de comprar ou repetir a compra do produto/serviço, como forma uma imagem negativa da marca e tende a fazer comentários negativos a respeito delas para um grande número de pessoas”.  

Eu concordo plenamente. Todavia, observando o mundo a minha volta, essa afirmação do professor Sampaio parece que ficou pertencendo aos velhos manuais enferrujados de boas maneiras. Mas, afinal de contas, a propaganda e o marketing estão cheios de mentiras?   

Os mais antigos devem se lembrar de propagandas que mentiam na maior cara de pau. “Esse modelo fará de você uma miss” é um exemplo desse tipo de propaganda aplicado a roupas femininas. Esse tipo de expediente acabou sendo proibido e condenado pelas regras de ética e conduta profissional dos publicitários. Apesar disso, ainda podemos nos deparar com vários exemplos de propagandas enganosas, que não deixam de ser mentirosas, como, por exemplo aquelas que costumam propalar os efeitos milagrosos de determinadas químicas, como produtos para emagrecimento ou crescimento capilar, sem mencionar seus efeitos colaterais prejudiciais à saúde das pessoas que delas se utilizam. Há muitos outros casos e essas tentativas de convencimento a qualquer custo e sem maiores preocupações estão presentes em muitas situações.

“Com o Scrum você faz o dobro do trabalho na metade do tempo”. Nossa, um verdadeiro milagre! Essa foi mais uma típica mentira de marketing aceita pelas pessoas. O Scrum foi vendido da mesma forma como se vendem remédios para calvície e emagrecimento. Parece que, por alguma razão, as pessoas queriam acreditar nesse milagre. Da mesma forma que as pessoas desejam muito recuperar seus cabelos e emagrecer, existe o desejo de conseguir ser mais eficiente no trabalho, fazendo o dobro na metade do tempo.

Mas, o tempo passa e a dura realidade acaba mostrando sua face, o que significa que em algum momento essas mentiras podem ser desmascaradas. Mesmo assim, não é tão simples para um indivíduo admitir que foi enganado. Por causa disso, muitas vezes as pessoas fingem que as tais mentiras nunca existiram e que foram apenas mensagens motivacionais sobre uma novidade. Mensagens apressadas, aparentemente inocentes e despreocupadas, que não passariam de pequenos deslizes da natureza humana. Pobres de nós, ansiosos por uma mentira conveniente e temerosos pelas inconvenientes verdades. Pelo menos, sabendo disso, que fiquemos atentos para as próximas!

Vamos voltar à foto acima em nosso próximo artigo: “As 12 Descobertas de Reifer” tendo como base uma análise quantitativa de métodos ágeis. Então, é isso aí, até a próxima.

Orientação de TCC Online