Engenharia de Projetos – não apenas Projetos de Engenharia – Abordagem com uso de Gestão Ágil

Por: Ivsen Platcheck, MsC. Eng.

Atualizado em 27/02/2024

1.    Motivação

Neste texto, apresento o ponto atual da evolução de meu trabalho, na condução de grupos de desenvolvimento de projetos, usando princípios de Engenharia e Gestão Ágil. Este é um processo em constante aperfeiçoamento, visando sempre entregar os melhores resultados, valores e produtos.

Uma vez que não tenho como prever quem irá ler este texto, estou começando do básico. Mas, se o leitor já tiver conhecimento, formação, experiência em desenvolvimento de projetos, encorajo a pular estas primeiras partes e partir diretamente para a descrição dos processos.

O que é um projeto? Antes de falarmos em desenvolvimento de projetos, devemos alinhar o entendimento sobre o que é um projeto. E como vou lidar com este conceito.

Buscando uma convergência das definições de projeto, posso definir projeto como o processo de reunir uma equipe de pessoas, recursos e conhecimento, para planejar, estimar, acompanhar e controlar a execução de tarefas inter-relacionadas, com objetivo de produzir algo único, seja produto, serviço, ou processo, não repetitivo, com prazo determinado, e com um mínimo de organização das ações e resultados. [SM04]

Antes do advento do pensamento ágil, baseado nos manifestos ágeis [ABC01] e [AMO01], as metodologias pregavam a definição completa de escopo e objetivo. Porém, após as definições promovidas, difundidas e largamente aceitas, referentes à Gestão Ágil de projetos, estes conceitos foram relativizados. Estas alterações serão abordadas ao longo deste texto.

Os processos de desenvolvimento de projetos possibilitam a inovação, evolução, e a criação de soluções para problemas atuas, além da realização de sonhos.

Os projetos possuem características:

  • Temporário: Um projeto tem um tempo finito de desenvolvimento. Ele começa e termina, quando o valor desenvolvido se torna operacional.
  • Singularidade: Os projetos são únicos, geram resultados e valores únicos.
  • Resultados podem ser medido: Os resultados devem ser tangíveis, medidos, e avaliados com relação ao seu sucesso.
  • Projetos são realizados por pessoas para pessoas.

Nas metodologias mais tradicionais, baseadas em planejamento e controle, os projetos possuem mais algumas características: Recursos e objetivos totalmente definidos previamente.

Porém, com a disseminação do pensamento ágil, com suas premissas, princípios e pilares, estas características deixam de ser úteis, quando se trata de desenvolvimento de projetos usando gestão ágil. Agilidade fala em ciclos curtos, incrementos funcionais e testáveis, avaliação, e correções quando forem necessárias, entre um ciclo de criação de incremento e o seguinte.

A evolução da sociedade mundial, os desenvolvimentos científicos e tecnológicos, aliados à aceleração da vida cotidiana, trouxe como consequência um mundo muito mais complexo. Tudo evolui numa velocidade cada vez maior. Necessidades hoje, podem não ser mais necessidades amanhã. A quantidade e a intensidade das inovações são aumentam cada vez mais rápido e a sociedade humana, como um todo, muda a realidade a cada dia.

Existem duas nomenclaturas usadas: inicialmente se usou o termo mundo VUCA, sigla em inglês que significa “Volatility, Uncertainty, Complexity e Ambiguity” (volatilidade, incerteza, complexidade e ambiguidade).

Mais recentemente, tem-se falado muito em mundo BANI, sigla também em inglês que significa “Brittle, Anxious, Nonlinear e Incomprehensible” (fragilidade, ansiedade, não linear e incompreensível).

Todas estas definições traduzem como o mundo fica cada vez mais complexo, com a velocidade das mudanças cada vez maiores. A gestão ágil traz uma possibilidade de reduzir os erros, usando os princípios de alterar o caminho sem perder o foco. Encorajo o leitor na busca por mais detalhes referentes ao pensamento ágil [ABC01] e [AMO01].

Atualmente, os dois principais caminhos usados atualmente usam a metodologia em cascata (ou waterfall), bastante identificada com o PMI (Project Management Institute) [PMI06], e os princípios ágeis, já citados anteriormente, e que foram adotados por grandes empresas de tecnologia.

Existe muita radicalização na defesa de cada um dos caminhos a serem tomados. Eu acredito que as coisas não precisam ser assim tão definitivas. Recentemente, o próprio PMI está buscando uma forma de incorporar os princípios da agilidade ao seu modelo. Eu tenho background em Engenharia Elétrica, com uma ênfase grande em telefonia e telecomunicações. Depois, concluí meu Mestrado especializando em Arquitetura de Computadores, quando também, me especializei em simulação de sistemas.

Durante toda a minha formação aprendi e entendi que um Engenheiro acaba por ter uma visão mais sistêmica, mais global a respeito das atividades e, com certeza, na condução de ciclos de processos para desenvolvimento de projetos. Uma outra lição importante é que sempre devemos buscar a utilização das melhores ferramentas para cada projeto. Numa visão simplista, cito por exemplo que cada tipo de parafuso vai ter aquelas chaves de fenda que funcionam melhor para lidar com ele.

Este conceito eu uso para tudo. Em cada fase do processo de desenvolvimento de um projeto, procuro analisar e buscar as melhores ferramentas que me possibilitem chegar ao final do ciclo com algum valor funcional e testável.

Cada atuação pode ter algumas opções de ferramentas certas, e cabe ao profissional responsável escolher aquela ou aquelas que melhor se adequem ao serviço a ser executado.

Muitas vezes, se há indisponibilidade de alguma ferramenta, o profissional responsável deve criá-la, seja a partir de materiais disponíveis, seja por adaptar alguma ferramenta que possa se tornar adequada, ou buscar ferramentas destinadas a outras áreas que possam suprir a necessidade atual.

Desde o momento que comecei a trabalhar com projetos, procurei tratar o processo do projeto, o ciclo de desenvolvimento, como uma caixa de ferramenta para alcançar um ou mais objetivos.

Desde o princípio, alguns dos eventos, artefatos, ou ritos recentemente difundidos pela Gestão Ágil, eu já havia identificado como boas práticas para as minhas iniciativas de projetos, tanto aqueles projetos que eu apenas desenvolvi, como os aqueles que eu gerenciei os processos.

Ao longo de todo este texto, pretendo trazer as minhas práticas quando participei de times de projetos. Especialmente, quando eu estive na liderança dos grupos. Vou descrever algumas das minhas atividades, os passos que considero como os mais lógicos para o desenvolvimento de projetos, usando uma visão de Engenheiro. Não que esta visão seja melhor ou pior. Tudo depende de quem comanda, gerencia, e conduz o processo.

O que vou descrever é como eu enxergo os caminhos a serem tomados e as sequências de ações, de acordo com cada situação, contexto, natureza e a organização patrocinadora do projeto. É o caminho que uso, toda vez que me engajo em algum processo de desenvolvimento de projetos. A forma que eu me sinto mais confortável e que vejo entregar melhores resultados

Eu comecei a trabalhar muito cedo, e participei de alguns grupos de projetos, para gerar peças publicitárias para indústria do cinema. Durante minha adolescência, estudando e trabalhando, fui aprendendo como fazer projetos que gerassem resultados tangíveis e valores funcionais.

Quando entrei na faculdade de Engenharia, procurei aprender tudo o que poderia com referência à minha carreira, dentre os assuntos tive especial interesse em como desenvolver projetos com maior equilíbrio entre eficiência e eficácia, gerando resultados e valores palpáveis e relevantes.

Ao longo de meus anos de experiência, fui desenvolvendo meus próprios frameworks, minhas ferramentas, meus princípios e meus fluxos de trabalho. Ritos, ferramentas, artefatos, tudo o que precisei, para organizar e gerenciar os meus ciclos.

Em meados da primeira década do século XXI, tive contato formal e me aprofundei nos conhecimentos da gestão ágil, princípios, valores, pilares e caminhos propostos, com uso do pensamento Lean (enxuto) e das técnicas desenvolvidas e documentadas como Kaizen, melhoramento contínuo, que foram fundamentais para o ressurgimento do Japão, pós-guerra, e a ascensão de empresas como Google, por exemplo.

Neste texto discorro sobre como vejo e pratico a gestão de processo de desenvolvimento de projetos, usando gestão ágil, junto com todos os recursos que possam auxiliar na condução de um processo equilibrado, que gere resultados de forma transparente, através das ações, medições, aprendizado contínuo, desenvolvimento iterativo e incremental, com intuito de gerar os resultados e valores. Fazer a diferença em termos de evolução de organizações, aumento de produtividade, faturamento e, consequentemente, lucro.

Eu não vou me ater em descrever, em detalhes, cada passo, ferramenta, ou evento, neste texto. O objetivo aqui é apresentar os possíveis caminhos pelos quais eu posso conduzir o processo.

Os processos de desenvolvimento de projetos não são iguais. Cada contexto, cada tipo de resultado, e cada tipos de organização e pessoas podem e irão levar a adaptações de caminho, eventualmente, até criar um caminho próprio.

Este estudo não é uma obra completa, e deverá ser alterada, atualizada, melhorada, corrigida e complementada ao longo do tempo. Aceito todas as sugestões e contribuições, para analisar e, se for o caso, incorporar a este texto e ao framework.

Para aqueles que têm alguma dificuldade em compreender ou ainda não conhecem o que é a tal da Gestão Ágil, sugiro leituras complementares. Mas, ainda assim, coloco que eu não sou radical no uso do pensamento ágil, ou seus princípios e ferramentas. Eu acredito que uma abordagem ágil pode trazer melhores resultados, mas o projeto em si pode compreender o uso de ferramentas, frameworks, workflows ou passos não indicados ou definidos como ágeis. Como eu coloquei anteriormente, busco as melhores ferramentas para alcançar os objetivos finais, a cada ciclo iterativo de criação dos incrementos.

A partir desta introdução, vou começar a descrever os passos, e como administrar cada evento, e decidir pelos próximos passos a serem tomados, de acordo com todas as variáveis envolvidas. Sempre tendo em vista que o principal objetivo geral é gerar resultados e criar valor para os clientes. O objetivo de um projeto, como colocado anteriormente, também, é o de atender às expectativas de pessoas: pessoas criando valores para pessoas.

Com relação às indicações dos papéis a serem desenvolvidos, usarei muito as nomenclaturas comuns à gestão ágil, e ao principal método ágil em uso atualmente, o SCRUM. Mesmo que eu adapte, altere o caminho em relação ao proposto pelo pensamento Ágil em seu manifesto [ABC01] e [AMO01], procuro manter aderência aos princípios do SCRUM.

Como já coloquei, a intenção não é a de escrever detalhadamente a respeito de cada passo, ferramenta, ou ritos e artefatos, ou outros aspectos que por si só exigem textos específicos para mostrar, explicar e ensinar sobre a definição, como é definido e como eu uso cada um deles. A intenção aqui é mostrar um caminho para o desenvolvimento de projetos. Todas as técnicas, ferramentas, e outros recursos terão a indicação de referências para estudo e aprofundamento.

Eventualmente, escrevo sobre cada aspecto individual, onde eu discorro mais detalhadamente, quando pertinente, e indicações de como enxergo as formas de uso, de acordo com cada contexto. Normalmente, eu procuro adaptar os meus procedimentos ao contexto se for o caso, mexendo no contexto de forma não-disruptiva, evitando que as pessoas envolvidas percam o engajamento, por causa de mudanças drásticas em suas rotinas de trabalho. Qualquer alteração deve ser conduzida de forma que as pessoas envolvidas no processo possam encarar mudanças como uma forma de melhorar o seu trabalho e sua vida.

Mais uma vez, coloco que devido às incertezas, volatilidades, complexidades e a velocidade com que as exigências de mercado demandam, mesmo as minhas abordagens podem ser alteradas, de acordo com o projeto. Eu, pessoalmente, encorajo que cada profissional, time, ou organização busque adequar as definições às suas realidades e necessidades.

Os caminhos que pretendo apresentar, para ciclos de desenvolvimento de projetos, pode ser usado em qualquer projeto, independente da natureza. Eu já usei estes métodos no desenvolvimento de projetos de circuitos eletrônicos, equipamentos de telefonia, desenvolvimento de software, projetos de infraestrutura elétrica e eletrônica, e procedimentos e protocolos de atendimento técnico em campo e laboratório.

2.    Início do processo

Todo projeto a ser desenvolvido começa por uma ou mais das razões abaixo, principalmente, mas não exclusivamente:

  • Inovação
  • Novo produto ou procedimento
  • Atualização de algum produto ou procedimento
  • Resolver problemas
  • Melhorar produtos, serviços ou processos
  • Aumentar resultados financeiros, faturamento e lucro
  • Conquistar novos clientes
  • Manter a fidelidade dos clientes atuais
  • Atender desejos pessoais
  • Etc.

Todo ciclo de projeto começa a partir de uma ideia, ou um conjunto de ideias. Estas ideias devem ser documentadas, inicialmente, de forma não estruturada. Sempre lembrando que as ideias podem ser detalhadas ou não. Seguindo o pensamento ágil, de acordo com a complexidade do mundo atual, estas ideias podem e deverão ser alteradas, refinadas, melhoradas, de acordo com a evolução das iterações, da análise dos resultados incrementais, testes e avaliações, aprendizados que podem vir a demandar adaptações, alteração, ou até mesmo uma redefinição das ideias.

Nestes movimentos iniciais, torna-se necessário definir alguns papéis que podem ser performados por uma pessoa ou por um time coordenado. Porém, para o melhor gerenciamento dos processos, cada time de pessoas com o mesmo papel deve ter um líder, aquela pessoa que que será responsável pela condução dos trabalhos, e garantir a busca dos resultados, a cada ciclo.

No estágio da ideação, é importante ter uma pessoa que lidere, compile e otimize as ideias apresentadas, priorizando, com a participação das pessoas que propuseram ou apoiaram as ideias. Mais uma vez, de acordo com minhas experiências e observações do mercado, acredito que esta pessoa deveria ser um consultor externo, com capacidade de liderar de forma servidora, e atuar como coach, apoiando a ideação, sem interferir nas ideias apresentadas, em relação ao seu teor.

O uso de um profissional externo, contratado para este serviço, deve trazer uma maior impessoalidade às ideias. Apenas o teor das ideias seja analisado e não que criou, ou o cargo hierárquico da pessoa, na organização. Neste processo, o pensamento ágil incentiva que todas as pessoas que participem dos processos, eventos sejam colocadas no mesmo patamar hierárquico, com relação aos ciclos do projeto.

Esta pessoa deverá conduzir o processo a partir da ideação, liderando de forma servidora, conduzindo as pessoas envolvidas no processo inicial, para que cheguem aos acordos necessários à sequência do processo, organizando as ideias, discutindo-as e separando aquelas que realmente fizerem sentido para todos. Sempre lembrando que, usando gestão ágil, as adaptações podem ocorrer na forma e profundidade necessárias para que o resultado final entregue os valores que atendam aos anseios das pessoas.

Esta pessoa pode ser chamada de Agile Master, ou ainda Agile Coach, dependendo do envolvimento em relação à organização e sua atuação na condução do processo. Deverá conduzir os processos, garantir o engajamento das pessoas que tenham condições de agregar conhecimento, e motivá-las a participar do processo, sair de sua zona de conforto, aprender e ensinar o que seja relevante para que o processo seja conduzido ao sucesso. E remover todos os obstáculos e bloqueios que possam impactar no processo.

Nesta etapa, deve ser elaborado o primeiro artefato, ou documento. Este documento deverá listar as ideias geradas neste ciclo, priorizando e ajustando até que haja concordância de todos os participantes. A elaboração deste documento deve ser coordenada pelo líder servidor já citado, o qual deve facilitar as discussões, e orientar as pessoas a buscarem os denominadores em comum, às suas aspirações. Porém, a coordenação não pode tender para nenhum dos lados, em uma discussão. Sempre buscar os pontos em comum e acomodar as diferenças. Pode funcionar questionando as pessoas, buscando diminuir as diferenças e acomodar as ideias. Mas as decisões devem ser tomadas pelas pessoas lideradas, e apoiar as ideias selecionadas e listadas, cobrando comprometimento de todos.

Aconselho e pratico solicitar a assinatura de todos os envolvidos na organização das ideias selecionadas. Este ato oficializa a aceitação de todos e permite uma cobrança forte pelo engajamento e participação.

A etapa da ideação pode e provavelmente será repetida, sempre que for necessário, para alterar caminhos, adaptar ideias, e mais uma vez, engajar todos os envolvidos no processo.

Este artefato criado eu chamo de Estórias Textuais de Usuários. Um texto que pode ou não ter alguma estruturação, ou organização específica, e pode ser alterado ao final de cada ciclo, após os testes serem concluídos e novos aprendizados apontem para adaptações, ou alterações no caminho do projeto.

A partir das ideias, devem ser definidos os próximos objetivos e a forma de lidar com eles, para que as ações sejam definidas no intuito de alcançar estes objetivos selecionados.

3.    Os Objetivos

Uma vez que as ideias estão listadas, e com alguma organização, os próximos passos são para planejar o que será feito para que as ideias se tornem realidade, um produto, serviço, procedimento, ou qualquer outro valor que atenda às pessoas a eles destinados.

Neste ponto do processo, eu índio que a inclusão no time de uma pessoa responsável pelo produto a ser desenvolvido, seja incorporado o papel de Gestor do Produto, ou, usando a nomenclatura do Scrum, o Product Owner (Dono do Produto), ou apenas conhecido como PO.

Este papel deve ter apenas um responsável por ciclo de projeto, mas pode ser usado o concurso de um time para assessorar o PO que será o responsável pelas decisões e pareceres. Estes serão responsáveis pelo modelamento do produto, analisar o valor a ser criado e, a partir deste entendimento, decidir a ordem de trabalho das ideias, a priorização das atividades e a avaliação dos resultados.

Nos meus trabalhos, eu sempre procuro usar como PO uma pessoa, ou grupo de pessoas, com vínculo junta à organização. O detentor deste papel deverá ter conhecimento, autoridade, discernimento e liderança necessários para que saiba como manter o processo e os valores produzidos aderentes ao que a direção da organização define como visão e missão, além de ter que ter disponibilidade de tempo para atender às obrigações que o ciclo de projeto irá exigir, o comprometimento para realmente exercer este papel.

Existem alguns caminhos que podem ser tomados, a partir daqui. Normalmente, eu separo de 2 a 3 objetivos por ciclo iterativo. Objetivos que possam levar a produção de incrementos funcionais, testáveis e que levem mais próximo de produzir valores palpáveis, tangíveis, e possam realmente trazer resultados reais.

Para cada objetivo, devem ser definidos quais os resultados que se deseja atingir, para garantir a realização do objetivo. Estes resultados podem ser medidos em números ou em resultados que não se adequem à medição mais objetiva. Por exemplo:

  1. Objetivo: Aumentar as vendas de um certo produto; Resultado esperado: Aumentar em 30% a quantidade de itens vendidos deste produto. – Este resultado é muito fácil de verificar que o objetivo seja alcançado.
  2. Melhorar a acessibilidade da tela de um aplicativo; Resultado esperado: trazer mais conforto e possibilidade para pessoas com algum tipo de limitação consigam acessar o aplicativo. – Este resultado já é um pouco mais subjetivo, pois qualquer medida de aceitação por parte dos usuários pode ser pouco conclusiva.

Para os objetivos com resultados numéricos, mensuráveis e com uma grande dose de objetividade, a ferramenta OKR[1] (Objective and Key Results, ou Objetivo e resultados chave) tem sido emprega largamente. Os resultados chave são a forma de verificar que o seu objetivo seja alcançado. Mais uma vez, remeto à literatura para a descrição mais detalhada dos OKRs. O meu objetivo neste texto é dar uma direção e os passos que posso dar, no desenvolvimento de projetos.

O objetivo pode contar com mais de um resultado chave, que somados, levarão ao objetivo. A definição de OKR sugere que um objetivo não tenha mais do que 5 resultados. Pessoalmente, eu prefiro não passar de 3 e se precisar mais aprofundamento, os resultados chave podem representar novos OKRs numa análise top-down.

Os resultados chave também levam a definição das tarefas a serem executadas para que sejam atendidos e os objetivos alcançados. Esta etapa será analisada mais à frente.

Para aqueles objetivos que não permitem uma medida numérica para aferição, usar resultados chave, ou OKR, não faz sentido. A definição de OKR fala claramente em medida objetiva. A definição das tarefas pode ser mais complexa, mas terá que ser feita e os envolvidos deverão buscar formas de atingir o objetivo da melhor forma, no menor espaço de tempo, com a máxime qualidade e dedicação.

É aqui que o PO deve assumir as suas tarefas, orientado e apoiado pelo líder servidor. O PO sim tem o poder de decidir sobre o que fazer, enquanto o líder servidor garante que todos façam as suas tarefas com comprometimento, como disse anteriormente, trabalha na remoção de bloqueios ou barreiras que formem ao longo do processo, interagindo com a organização e suas lideranças.

As próximas etapas são as que irão definir as atividades a serem desenvolvidas para que os resultados chave finais sejam alcançados e os objetivos sejam atingidos.  

4.    As tarefas

Nesta etapa começam a ser determinadas e definidas as tarefas que deverão ser executadas para que os resultados contribuam na aproximação dos objetivos. Estas tarefas são também chamadas de estórias a serem desenvolvidas.

Para definir as tarefas, podem ser usadas várias técnicas e ferramentas. Dependendo da natureza dos resultados a serem atingidos, podemos buscar qual das técnicas será a mais adequada para cada produto ou valor a ser desenvolvido no ciclo do projeto.

Eu advogo pelo uso de duas técnicas associadas: o Design Thinking[2] e um artefato desenvolvido e definido, com a UML[3] (Unified Modelling Language), muito difundida no paradigma do desenvolvimento de software orientado a objeto. Mas que tem se mostrado muito útil nas etapas de deixar as atividades o mais detalhadas possível.

Mais uma vez, neste texto, não vou explicar muito sobre as técnicas e ferramentas e encorajo a leitura de alguns dos livros que coloco como referência.

Apenas vou falar um pouco sobre o porquê de usar Caso de Uso. Eu uso e recomendo este artefato para que as tarefas e ações sejam mais bem detalhadas, permitindo uma descrição mais completa sobre o que se deseja fazer. Percebi, também, os Casos de Uso são muito úteis em projetos de outras áreas, como projetos de eletrônica, procedimentos administrativos, além dos softwares.

Cabe aos líderes servidores e aos POs, o conhecimento necessário para discernir sobre o uso ou não de alguma ferramenta.

Nesta etapa, é necessário que o time, ou os times de desenvolvimento sejam definidos, usando as prerrogativas do Framework que será utilizado.

Estas tarefas podem começar grandes, complexas e, então, refinadas usando alguma técnica pertinente como o refinamento, Grooming, Inception, ou qualquer outra ferramenta ou técnica que melhor se aderir ao time de desenvolvimento e à organização. Independentemente da técnica usada, eu sugiro e uso muito, mais uma vez, a ferramenta de Caso de Uso, da UML, para clarear todas as possibilidades de refinamento das tarefas. A técnica apresentada por Alistair COCKBURN [Ca01] de usar níveis de detalhamento tem me ajudado muito a chegar o mais próximo de tarefas elementares e de desenvolvimento mais rápido e certeiro.

Deste refinamento, devem ser feitas as estimativas de cada tarefa, para que possam ser definidos quantos grupos de desenvolvimento serão necessários, se for possível ter mais de um, a seleção de tarefas que produzam incrementos funcionais e testáveis, a cada ciclo, o MVP (Minimmum Viable Product = Mínimo produto viável) do ciclo

A lista destas tarefas, ou estórias, será chamada de Backlog do Produto, ou Product Backlog, também referido por PB. Esta lista não é imutável. A cada ciclo o PO pode alterar a lista. Podem ser incluídas novas estórias, podem ser ajustadas estórias, podem ser eliminadas estórias. O PO é o responsável pela administração desta lista, com apoio do Líder Servidor e do time.

A partir deste momento, será decidido qual o framework a ser utilizado para desenvolver os incrementos deste ciclo.

5.    Decidindo os caminhos – SCRUM e KANBAN

Dentre os frameworks existentes, o mais usado é o SCRUM, para gerenciar todo o processo. E esta é a minha escolha pessoal, quando comando times de projetos. Porém, para organizar o fluxo de trabalho durante os SPRINTS, eu uso quadros KANBAN.

Para minha introdução formal a SCRUM e KANBAN, usei os guias da SCRUM.ORG [SS01] [So2021], além dos cursos que frequentei, junto a empresa MindMaster [MMGa], e ao instrutor Roberto Brasileiro (MÉTODOAGIL.COM) [FACE].

Existem diversos livros que versam sobre SCRUM, KANBAN e seus desdobramentos. Encorajo a todos que busquem maiores informações na vasta literatura existente. Cada aspecto do SCRUM e do KANBAN pode merecer um capítulo específico para sua descrição, uso, exemplos e implementação.

Apesar de que alguns autores serem contrários ao ajuste dos métodos, eu pessoalmente faço minhas próprias adaptações, de acordo com natureza do projeto, do contexto em que será desenvolvido e os valores serão utilizados. Como Engenheiro, sempre procuro o melhor caminho, para desenvolver o melhor produto. Sempre usando uma frase comum aos médicos, mas que em Engenharia também tem seu valor: “Cada caso é um caso”, e merece ser tratado individualmente.

O que eu posso falar, ainda, sobre minha experiência, no uso destas duas ferramentas, é que, mesmo antes de estudar formalmente, a respeito, eu já utilizava várias das técnicas, pilares, caminhos e artefatos.

Por exemplo, eu sempre usei fazer uma reunião prévia de planejamento, para decidir o que fazer no próximo ciclo. Sempre usei as reuniões diárias para avaliar o que foi feito, anteriormente, o que deve ser feito e se há algum impedimento que eu necessitasse remover, do nosso caminho. Por fim, uma reunião de análise e testes do valor produzido, assim como os métodos de trabalho empregados no desenvolvimento.

Após o ciclo de SPRINT, cabe ao líder servidor e ao PO, a definição dos próximos passos. De acordo com os resultados do SPRINT, da inspeção e do aprendizado, decidir qual etapa retornar, se o valor não tiver sido totalmente desenvolvido, de acordo com o PO e demais interessados. Sempre lembrando que um projeto é desenvolvido em ciclos, produzindo incrementos testáveis, e adaptando quando necessário.

Como colocado acima, o ciclo iterativo se repete, até que o valor final seja completado, de acordo com as expectativas daqueles que usarem estes resultados.

No próximo item, mostro um diagrama com os principais passos possíveis do processo que descrevi até agora. Usei o aplicativo Bisagi, para montar um esquema que retratasse, o mais fiel possível, o que penso a respeito de um processo de desenvolvimento de projetos usando gestão ágil.

Esta imagem é apenas uma primeira versão e, com a evolução dos processos, dos métodos e dos trabalhos, pode haver modificações, alterações ou adaptações.

6.    Diagrama básico proposto

Srumban image: Artemis Agile Consulting, “Tales from the trenches », at https://www.youtube.com/watch?v=Ht4S3Fs6COQ

7.    Conclusão

Os primeiros artigos que publiquei foram apenas uma preparação para que chegássemos a este momento, quando começo a apresentar minha proposta de trabalho, às organizações, empresas e entidades no seu caminho para desenvolver projetos, inovações ou soluções para problemas existentes.

Senhores Gestores, Dirigentes, Líderes, ofereço meu trabalho como Agile/Scrum Master, quando aplico toda minha experiência de quem já fez, faz e, certamente, fará a diferença na condução de ciclos de Desenvolvimento de Projetos, entregando o principal resultado, o valor, o produto, o objetivo, a cada ciclo e iteração. O framework que estou desenvolvendo tem apresentado, ao longo de sua evolução com inovação, soluções e resultados palpáveis. Tenho formação e experiência na condução de times técnicos e, normalmente, agrego atividades de Coaching, Mentoria, Tutoria e treinamento, visando alcançar os melhores resultados e fomentar a melhoria contínua com motivação e foco de todos os envolvidos nos times que conduzo com vistas à Liderança Servidora. Em meu artigo “Relação dos Principais Projetos dos quais Participei” [Pi16] apresento os principais projetos em que participei, e os resultados entregues, os valores e objetivos atingidos.

Ofereço aos senhores a cortesia de uma conversa inicial, para que possamos analisar juntos a situação corrente e possíveis caminhos a serem seguidos para que os objetivos da organização, empresa ou entidade sejam alcançáveis. Basta me contactar pelo e-mail: yoelgrego@yoelgrego.blog, e marcamos uma conversa usando meu canal do Google Meetings.

[1] Ver [De01]; [HMf01]; [HMf02]; [K21]; [Sf01]; [VP10].

[2] Ver [Dd18]; [Lm18]; [MMDT]; [MrC18].

[3] Ver. [Ca01].

Referências

ABC01 – “The Agile Manifesto”, The Agile Business Consortium.

AMO01 – “Agile Manifesto”, agilemanifesto.org

Ca01 – COCKBURN, Alistair, “WRITING EFFECTIVE USE CASES”, Addison-Wesley, USA, 2001, English.

Ct10 – Coutinho, Thiago; “Você sabe o que é um Projeto? Conheça os seus tipos e características!”; Voitto; at https://www.voitto.com.br/blog/artigo/o-que-e-um-projeto; 2023.

Dd18 – DUNNE, DAVID; “DESIGN THINKING AT WORK”, UNIVERSITY OF TORONTO; CANADA; 2018; 168

De01 – Daher, Elias. “OKR: O guia definitivo desde os fundamentos, a implementação até a gestão da ferramenta”, Brasil, Brasília, DF, 2020, Edição do Kindle.

FACE – BRASILEIRO, Roberto, “FACE – Formação Agile Coach Especialista”; Curso online, 2023.

HMf01 – Homem de Mello, Francisco Souza, “The Definitive Guide to OKRs”, Qulture.Rocks, 2016.

HMf02 – Homem de Mello, Francisco Souza, “OKRs – da Missão às Métricas”, Qulture.Rocks, 2018.

K21 – “Facilitação check-ins de OKRs”, K21, 2022.

Lm18 – LEWRICK, MICHAEL et Alli; “The design thinking playbook”; JOHN WILEY & SONS, INC.; ESTADOS UNIDOS DA AMÉRICA; 2018; 347 pg.

MMDT – “Curso “Design Thinking Online”; Mind Master Treinamentos; 2022.

MMGa – “Curso Gestão Ágil 2.0”, Mind Master, 2022, Portuguese and English.

MrC18 – Müller-Roterberg, Christian; “Handbook of Design Thinking”; ESTADOS UNIDOS DA AMÉRICA; 2018; 44

Pi16 – PLATCHECK, Ivsen; “Relação dos Principais Projetos dos quais Participei”; https://yoelgrego.blog; 10/02/2024.

PMI06 – “Guia do CONHECIMENTO EM GERENCIAMENTO DE PROJETOS”, 6ª Edição; Project Management Institute; USA; 2017.

Sf01 – Da Silva Junior, Francisco de Assis, “OBJECTIVE AND KEY RESULTS: CRIANDO SINERGIA, ALINHAMENTO E ENGAJAMENTO COM OKR”, Brasil, 2022.

SM04 – SILVA, Sergio Mylius da & MARODIN, Helio E.; “Planejamento e Gerência de Projetos”; Mylius & Marodin – Gestão de Projetos. Porto Alegre, RS, Brasil; 2004.

So2021 – “The Kanban Guide for Scrum Teams”, SCRUM.ORG, 2021.

SS01 – SCHWABER, Ken & SUTHERLAND, Jeff, “The Scrum Guide”, Scrum Org, 2020.

VP10 – VIEIRA, Denisson & PEDRO, Denis, “Do Conceito à Prática – OKR”, MindMaster Educação Profissional, Brasil, São Paulo, SP, 2022.