Artefatos de gerência de projetos 2018.2

Plano de projeto - Gerência de Projetos de J. Eurique C. Ribeiro Junior

Plano de projeto - Anexos de J. Eurique C. Ribeiro Junior

Slideshow - Metodologias ágeis de J. Eurique C. Ribeiro Junior

Seminário - Agilidade e Gerência de Projetos

Tá pensando que agilidade é bagunça? Parte 1: Planejamento no Contexto Ágil

Olá pessoal,

O meme foi intencional, pois este assunto é extenso, por isso irei dividir em algumas partes para não ficar tão cansativo.

Em um pouco de experiência com agilidade que tive, somado a inúmeras conversas com amigos que estão inseridos no contexto ágil, e com alguns que acham que estão, mas não, percebi que existe essa pequena confusão, em que dentro do contexto ágil temos que entregar o que dá, e não há a necessidade de parar o desenvolvimento para fazer o planejamento desse projeto.  

Sabemos que no manifesto ágil, em seus "versículo 2 e 3" nos diz: 

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Porém, isso em hipótese nenhuma significa ausência de documentação, e muito menos a falta de planejamento... Observando a metodologia Scrum percebemos que existe documentação, como também uma negociação com o cliente. Essa negociação é explicitada na priorização do backlog do produto, e o planejamento na "Reunião de Planejamento da Sprint", sem respeitar tais premissas, os projetos estão fadados a entrar no que carinhosamente chamo de limbo (projetos intermináveis, projetos que estouram prazos e/ou custos, e aqueles que sequer são utilizados pelo cliente), mesmo a organização mudando, ou tentando, mudar de paradigma. 

Porém, para realizar um planejamento que de fato possa ser exeutado, é necessário antes de tudo a escolha de métricas que aplicadas irão ajudar o time Scrum a entender por exemplo, qual é a sua capacidade de atendimento, de forma que em toda Sprint haja a entrega de algo que traga valor ao cliente... Mais quais métricas são utilizadas na agilidade? Isso é para o próximo post.

Até mais!


Referências:
http://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em 22 de janeiro de 2019.
https://www.desenvolvimentoagil.com.br/scrum/. Acesso em 22 de janeiro de 2019.

Lean Thinking: uma breve introdução

O século XX foi marcado por sangue, duas grandes guerras ocorreram na primeira metade, deixando corpos e destruição onde houve batalha. A segunda guerra mundial, a mais recente entre as duas, causou, após seu término oficial, muitas mudanças na forma de pensar das nações envolvidas, tanto as vencedoras, mas principalmente as perdedoras do conflito, precisaram se adaptar ao período de reconstrução. O Japão, um dos principais participantes da guerra, lutando do lado do Terceiro Eixo, precisava adaptar seu sistema de produção, influenciado pelo fordismo americano, para uma algo mais flexível e que mantivesse o padrão de qualidade dos produtos. Após Little Boy e Fat Man serem explodidas em território japonês e, sem qualquer resistência possível, destruir dois de seus maiores parques industriais, fez-se necessário um sistema de produção que fosse mais adequado à carência de recursos característica da realidade japonesa no pós-guerra, neste cenário surgiu o sistema toyota de produção.

O sistema toyota de produção é oriundo da própria Toyota e tem como principais valores a eficiência e o aumento da produtividade. Nesse sistema, objetiva-se evitar o desperdício, o tempo de espera, a superprodução, os gargalos de transporte, inventário desnecessário, entre outras coisas. Fortemente baseado na filosofia do Just-In-Time, que consiste, em poucas letras, em atender a demanda por um produto no exato momento em que ela deve ser atendida, o produto ou matéria prima deve chegar ao local de utilização somente no momento exato em que é necessário.

A forma de pensar do Toyotismo influenciou muitas outras ideias, entre elas, e de principal valor nesta postagem de blog, é o Lean Thinking. O Lean Thinking ganhou vida oficialmente apenas nos anos 80, no MIT (Massachusetts Institute of Technology), e vem influenciando a gestão de projetos desde então. O Lean Thinking, assim como outros métodos ágeis, é fortemente baseado em valores que precisam ser respeitados pela equipe, são eles a confiança, o respeito, a prestação de contas e a honestidade. O Lean Thinking, uma filosofia de como encarar o sistema de produtivo, é fortemente influenciado pelo conceito japonês de “shinsetsu”, que num paralelo grosseiro com as idéias do ocidente, pode ser entendido como moral. Isto significa que os valores devem ser internalizados pelos praticantes do Lean de tal maneira que eles não precisem de mais nada além de sua própria consciência para dizê-los como devem agir durante seu trabalho.

Além dos valores supracitados, o Lean Thinking pode ser caracterizado, e deve ser compreendido, através dos seus 5 (cinco) princípios básicos, são eles a identificação e definição do que é “valor” para o cliente, a investigação e busca da compreensão do fluxo do “valor” ao longo do processo produtivo (mapeamento dos processos), a manutenção de um fluxo sem interrupções e minimização dos atrasos durante a troca de contexto no processo produtivo, o trabalho puxado, ou seja, uma postura ativa na determinação de qual será a próxima demanda a ser atendida, e por último, mas não menos importante, a busca pela perfeição, também chamada de melhoria contínua, que consiste em buscar incessantemente agregar qualidade aos produtos e aos processos. A principal ideia por trás do Lean é a maximização do valor para o cliente e a minimização dos custos envolvidos na produção, uma organização Lean compreende bem o que agrega valor ao cliente e foca neste ponto especificamente para buscar satisfazê-lo cada vez mais.

Percebe-se, portanto, que o Lean Thinking possui uma sinergia natural com os valores postulados pelo manifesto ágil, objetivando a satisfação do cliente, e do fornecedor, com o produto mais que atolamento em burocracias e regras que atrasam o trabalho e o torna penoso. O Lean Thinking é uma ferramenta essencial para os times ágeis de desenvolvimento de software e pode ser aplicado sem complicações em conjunto com outras metodologias como Scrum e Kanban. Isso é tudo e até a próxima!

Referências
Toyotismo - Wikipédia, a Enciclopédia Livre
Just-in-time, Wikipédia, a Enciclopédia Livre
Princípios Lean
Lean Thinking, Wikipédia, a Enciclopédia Livre
O que é Lean Thinking
Todos os acessos em 18 de Dezembro de 2018

Kanban em 5 minutos e nada mais que isso

Eu sei, parece maluco explicar várias definições de autores clássicos e métodos criados em cima uma bagagem teórica gigante. Mas meu intuito com essa postagem é localizar alguns perdidos nesse assunto e quem sabe despertar o interesse por essa técnica de desenvolvimento, assim como o Scrum, ágil.

Origem de Kanba

Vem do Japonês que significa "sinal visual" e surgiu lá dentro da Toyota, fazendo referência a linha de trabalho dos funcionários. O que é muito justo porque a empresa é muito famosa pelo seu processo de produção "milimétrico" e foi pioneira em Kanban para desenvolvimento de software.

Kanban promotes continuous collaboration and encourages active, ongoing learning and improving by defining the best possible team workflow.

É muito comum ver equipes errando sempre na mesma coisa: usando simplesmente para organizar cartõeszinhos de "a fazer" para "feito" mas não é somente isso, na verdade é muito mais.

Scrum é outra coisa

O Kanban é baseado em 3 princípios bem simples: Visualizar seu fluxo, limitar sua quantidade de trabalho e melhorar seu fluxo.

Note que de cara, se você sabe o que é Scrum, percebe que o kanban e scrum prega coisas diferentes, ou quase. Vamos destrinchar um pouquinho.

Visualizar seu fluxo

Exatamente o que você leu, nele você poderá ver todo o trabalho que você vai fazer durante seu dia, assim mesmo: simples e rápido. E ajuda bastante convenhamos.

Limite sua quantidade de trabalho

Sim, como você precisa visualizar bem seu fluxo de trabalho é necessário limitá-lo, para a equipe não se enbananar com uma enxurrada de trabalho de uma vez só. Note que no Scrum é diferente, lá diz que você deve escrever todo seu Product Backlog e distribuir em sprints.

Melhore seu fluxo

Bem, é uma evolução: se você nota um problema no fluxo, porque não melhorá-lo? Ao contrário do Scrum podemos sim fazer alteração no meio do processo, ou seja, se algo é finalizado, o próximo  backlog que está dando trabalho é posto na mesa.

E por onde começo?

Calma, isso já é assunto pra outro post, segura aí que jajá tem outro. Já trabalhou ou teve contato  com Kanban? E com Scrum? Quais suas impressões sobre algum deles? Fala aqui em baixo na área de comentários. ;)

See you soon!

Fontes:
<https://resources.collab.net/agile-101/what-is-kanban>
Acesso em 4 de Dezembro de 2018

Gestão de riscos: O que você precisa saber para começar

O risco, no contexto de um projeto, diz respeito à uma possibilidade de perda ou prejuízo, que, via de regra, é indesejado. O risco é uma ameaça, de alguma forma mensurável, à concretização do projeto, ou, em outros termos, um risco deve ser entendido como a probabilidade de um resultado indesejável no curso do projeto.

A ISO, International Organization for Standardization, formalizou a gestão de riscos através da ISO 31000, nesta norma, é possível encontrar uma variedade de diretrizes que orientam o gestor na hora de proteger o projeto de ameaças, além de promover uma padronização internacional na gestão de riscos, o que permite que o tema seja tratado de maneira uniforme em países diferentes, permitindo, desta forma, perseguir e, eventualmente, alcançar padrões de qualidade internacionais. A ISO 31000 define risco como influências, ou fatores, internas(os) ou externas(os) à organização que tornam incerta a concretização de um projeto e, ou, o prazo predefinido para execução dele. Quando essa incerteza não pode ser mitigada, dá-se a ela o nome de risco. A ISO 31000 também condensa muitos dos conceitos relacionados ao tema e se apresenta como uma leitura indispensável para interessados na gestão da incerteza, além de possibilitar, quando implementada e mantida, aumentar a probabilidade de atingir os objetivos, encorajar uma gestão pró-ativa, estar atento para a necessidade de identificar e tratar os riscos através de toda organização, melhorar a governança, minimizar perdas, aumentar a resiliência da organização entre outros benefícios.

Riscos podem vir das mais variadas fontes, como a incerteza em mercados financeiros, ameaças de falhas de projeto ou a instabilidade econômica e política do cenário em que o projeto está sendo desenvolvido, por exemplo. Entre as estratégias para lidar com riscos, é importante salientar a capacidade de estimar a incerteza e isso pode ser feito através de uma escala para refletir a probabilidade percebida do risco, da definição das consequências do risco e da medição do impacto do risco no projeto e no produto.

Quando existir um risco, ele ameaçará o projeto independentemente se for detectado ou não. Neste contexto, vale aplicar a sabedoria preconizada pela popular “Lei de Murphy”, que consiste num adágio que postula que qualquer coisa que possa ocorrer mal, ocorrerá mal, no pior momento possível. Esse raciocínio é comumente aplicado por forças militares, e estrategistas profissionais, para solapar a possibilidade de falha e buscar minimizar a exposição ao risco através de um criterioso exercício estratégico que objetiva identificar, analisar e superar todos os elementos capazes de afetar negativamente os planos estabelecidos. A gerência de riscos permite uma consideração mais formal da “Lei de Murphy”, permitindo o gerenciamento mais criterioso e profissional dos riscos a que o projeto está exposto.

Gerenciar riscos, portanto, permite aplicar inteligência para lidar com as ameaças e negligenciar essa atividade é equivalente a navegar em alto mar em dia de tempestade sem o auxílio de uma bússola, ou seja, a possibilidade de sucesso pode até existir, mas é muito mais provável que os resultados alcançados sejam muito diferentes daquilo que foi inicialmente estabelecido como ótimo.

No contexto do desenvolvimento de software, é possível apresentar um roteiro simples que pode ajudar o gestor a identificar e mitigar os risco a que seu projeto está exposto. O roteiro consiste em analisar o tamanho do produto, calcular o impacto no negócio, capturar e analisar as características do cliente, definir o processo, configurar o ambiente de desenvolvimento, selecionar as tecnologias a serem utilizadas e estabelecer uma arquitetura, além fazer uma criteriosa análise e seleção dos recursos humanos que formarão a equipe.

Riscos nem sempre são evidentes, análises diferentes podem acabar considerando riscos diferentes, ou seja, a qualidade dos levantamentos de riscos dependem daqueles que os fazem e dos cenários analisados, desta forma, é possível que riscos diferentes sejam considerados por analistas distintos. O medo de que algo possa dar errado e uma postura defensiva diante da imprevisibilidade podem ser utilizados como mecanismos naturais de motivação para identificação, análise e superação de riscos.

Projetos de software, como vários outros tipos de projeto, podem estar expostos a uma variedade de tipos de riscos. Entre os riscos comuns neste tipo de projeto, estão a rotação de pessoal que forma a equipe, ou seja, a demissão e contratação de recursos humanos, a descontinuação das tecnologias selecionadas na definição da arquitetura, a seleção de um modelo de processo inadequado, a presença de erros não previstos no produto depois de entregue e, principalmente, erros no processo de concepção e análise do produto a ser construído. Para minimizar alguns desses riscos, é possível aplicar uma simples heurística de divisão de tempo para a execução do projeto, esta heurística é conhecida como regra 4-2-4, que consiste em dedicar 40% do tempo do projeto à concepção e análise, 20% à construção, e 40% à transição e manutenção do produto.

É possível formalizar matematicamente a exposição de um projeto a um risco iminente. Isto é feito através da aplicação métodos estatísticos e do uso do raciocínio probabilístico. Através da análise de dados históricos e da aplicação de métricas, é possível estimar o quão provável e danoso é uma determinada ameaça. Essa estimativa é dada na forma de um percentual e é considerada alta quando atinge 50% de probabilidade de ocorrência. Quando o sucesso de um projeto é tão provável quanto o acaso de cair um determinado lado de uma moeda, diz-se que o risco que a que ele está é exposto é alto o suficiente para exigir uma tomada de decisão crítica, devendo implicar, inclusive, no cancelamento do projeto. É necessário objetivar taxas de exposição menores que 50%, uma vez que é mais prudente e profissional assumir projetos que sejam mais prováveis de sucesso que de fracasso.

A exposição um risco individualmente pode ser calculada considerando duas variáveis primordiais, são elas a probabilidade do evento ocorrer, que pode ser obtido através de dados históricos, e da perda causada caso ele ocorra, que pode ser definida de maneira arbitrária pelo analista. A seguinte fórmula expressa o conceito descrito:

Seja R a exposição ao risco,

Esta mesma ideia pode ser generalizada para calcular o risco a que todo o projeto está exposto, isso pode ser feito considerando todos os riscos levantados e é expresso na fórmula a seguir:

Seja R a exposição ao risco,

Desta forma, é importante almejar trabalhar em projetos que apresentem um valor de R inferior a 50%.

As tomadas de decisão para mitigar os riscos devem seguir a abstração da estrutura de dados conhecida como heap, ou fila de prioridades, de forma decrescente, de tal maneira que o risco com maior valor de R seja mitigado antes daqueles que possuem valores de R menores a ele, está abstração é conhecida como heap de máximo, ou max heap. Desta forma, será sempre combatido primeiramente o risco que apresenta maior dano para o projeto, uma vez que é considerado o quão provável é sua ocorrência e quanta perda ele causa para o projeto.

Além disso, é possível combater altas taxas de exposição ao risco através da elaboração de planos de contingência, que são os famosos “Planos B” da cultura popular, um plano de contingência é uma solução alternativa, por vezes menos valorosa que a solução principal selecionada, mas que é suficiente para alcançar resultados satisfatórios a um menor custo. Um plano de contingência deve ser elaborado quando a exposição a um risco for muito alta e mesmo assim o gestor estiver disposto a correr o risco de falha, neste caso, o plano de contingência pode ser posto em prática quando os resultados desejados mostrarem ser inviáveis de serem alcançados através do planejamento inicial.

Por fim, caro leitor, esperamos que seu próximo projeto esteja preparado para lidar com as ameaças que podem minar seu o sucesso, ao lidar com riscos é importante desenvolver um certo tipo de sabedoria como “cautela e caldo de galinha não fazem mal a ninguém” ou “a melhor defesa é o ataque”. Não subestime as dificuldades que você terá que enfrentar e aplique a inteligência para combater ativamente as ameaças.

Referências
Verbete "Risk" em Wikipedia, The Free Encyclopedia - Risk
Verbete "Project Risk Management" em Wikipedia, The Free Encyclopedia - Project Risk Management
Verbete "Lei de Murphy" em Wikipedia, The Free Encyclopedia - Lei de Murphy
Verbete "Heap" em Wikipedia, The Free Encyclopedia - Heap
ISO 31000, disponível em ISO 31000.PDF

Todos acessos em 04 de dezembro de 2018

Metodologia clássica ou metodologia ágil no gerenciamento de projetos: qual escolher?

Antes de se pensar em desenvolvimento ágil, diversas empresas e gerentes de projeto utilizavam uma abordagem clássica para gerenciar seus projetos. É fato que essa abordagem ainda funciona hoje em dia para uma ampla gama de empresas. Mas na área de TI, mais especificamente em desenvolvimento de softwares, diversos conceitos passaram por drásticas transformações.

Muitas empresas utilizavam o Project Management Body of Knowledge, ou PMBOK, (na verdade muitas empresas ainda utilizam!) para gerenciar seus projetos. Esse guia de gerenciamento de projetos de software apresenta diversas vantagens como a coordenação e alinhamento bem definido dos projetos, uma gestão de riscos mais eficaz, mas, ainda assim a metodologia para gerenciamento não estava acompanhando a velocidade e mudanças necessárias no desenvolvimento dos projetos.

Justamente por essa necessidade de mudança que surgiu o manifesto ágil: um documento apresentado por 17 membros influentes da comunidade de desenvolvimento de projetos, onde eles reuniram neste trabalho boas práticas que devem ser seguidas pelos profissionais a fim de mantê-los focados no que realmente gera valor não só para o projeto, mas também para a empresa e principalmente, o cliente.

Foram salientadas 4 premissas gerais no manifesto ágil:

- Indivíduos e interações são mais importantes que processos e ferramentas;

- Software funcionando é mais importante que documentação abrangente;

- Colaboração com o cliente é mais importante que negociação de contrato;

- Respostas às mudanças são mais importantes que seguir um plano.

A publicação e adoção das práticas presentes neste documento causou um verdadeiro rebuliço no desenvolvimento: as empresas estavam percebendo que o atual modelo de desenvolvimento em cascata não estava sendo eficaz: era preciso priorizar mais a colaboração, os indivíduos das equipes e as interações com o cliente para responder às mudanças de forma rápida e assim entregar o certo e o importante para o cliente de forma gradativa e contínua.

Opa! Depois desse monólogo histórico, você caro leitor está munido de informações a respeito da metodologia ágil e chega a conclusão de que: sim! Utilizar metodologia ágil vai ser a melhor forma de gerir os projetos da minha empresa!

Na verdade, a resposta é: depende. Depende não somente dos tipos de projetos que você está desenvolvendo, mas também do endosso dos seus colaboradores: A metodologia ágil não deve ser imposta na empresa, ela deve ser abraçada e aceita.

Mas como assim aceita? Por exemplo: caso você trabalhe em um ambiente com certa resistência a mudanças,  com projetos que possuem um ciclo de desenvolvimento bastante consolidado ou em projetos em que seja necessária uma melhor gerência de riscos, a metodologia ágil pode não ser uma opção tão viável assim; logo, a metodologia clássica para o gerenciamento do projeto deve ser levada em conta como uma sólida opção.

Por outro lado, caso a equipe que você esteja envolvido:

- For adepta à mudanças e experimentação de novas tecnologias e frameworks;

- O cliente também está disposto a experimentar essa abordagem;

- Os projetos gerenciados necessitam de feedbacks constantes e alterações a fim de atingir uma melhor qualidade de produto e satisfação dos clientes.

Abraçar a metodologia ágil na gerência e desenvolvimento dos seus projetos é fortemente indicada para você e a sua equipe.

Para finalizar, deixo a seguinte pergunta: Para você, quais as vantagens em adotar a metodologia clássica ou a metodologia ágil na gerência dos projetos de uma equipe de desenvolvimento?

Referências: 

- A guide to the PMBOK:

http://www.cs.bilkent.edu.tr/~cagatay/cs413/PMBOK.pdf

- Agile Manifesto:

https://assets.uits.iu.edu/pdf/Agile-Manifesto.pdf

- Benefícios da adoção do modelo PMBOK:

https://www.devmedia.com.br/beneficios-da-adocao-do-modelo-pmbok/29208

- Conheça como o Manifesto Ágil aprimorou a gestão de projetos:

https://robsoncamargo.com.br/blog/Conheca-como-o-Manifesto-Agil-aprimorou-a-gestao-de-projetos

- Gerenciamento de Projeto com Metodologias Agéis:

https://blog.mandic.com.br/artigos/metodologias-ageis-de-gerenciamento-de-projetos/

- Hard skills no gerenciamento de projetos agile

https://www.codigofonte.com.br/artigos/hard-skills-no-gerenciamento-de-projetos-agile

- Por que vale a pena usar o PMBOK?

https://artia.com/blog/por-que-vale-a-pena-usar-o-pmbok/