O que é Prova de Conceito?

A Prova de Conceito (Proof of Concept – PoC) se caracteriza como um teste  que tem como objetivo mapear a viabilidade de uma solução (produto, processo, ferramenta) que uma determinada organização pretende implementar.

A PoC é realizada em um ambiente controlado e em baixa escala (com conjunto pequeno de amostras). A ideia é verificar a viabilidade do investimento na produção em escala de uma solução.

A PoC pode ser considerada como uma abordagem estratégica que provê à empresa subsídios para perceber se é comercialmente viável transformar uma ideia em realidade. Este tipo de prova é amplamente utilizado nas áreas de: TI, Engenharia, Medicina, Marketing, Negócios e Inovação.

É importante ressaltar que após passar pela PoC, várias soluções são descartadas ou modificadas, evitando assim o risco de se ter uma ideia, partir para o seu desenvolvimento imediato, produzir em grande escala e o produto gerado não emplacar.

Etapas para realização da PoC

  1. Defina os requisitos do Produto
  2. Especifique os requisitos.
  3. Construa um protótipo.
  4. Especifique o que será testado na PoC.
  5. Defina um cronograma com a equipe.
  6. Mapeie os riscos, recursos financeiros e envolvidos no processo de teste.
  7. Colecione os resultados.
  8. Faça uma análise se vale a pena investir no projeto.

Enfim, uma ideia pode ter tudo para dar certo, mas enquanto ela não for testada, é apenas uma ideia. Por isso, implementar a PoC é de fundamental importância no desenvolvimento de novos produtos.

por José Augusto Fabri

fabri@utfpr.edu.br

Você já ouviu falar de SCAMPER?

SCAMPER é o acrônimo de Substituir, Combinar, Adaptar, Modificar, Propor, Eliminar e Reorganizar.

A metodologia foi desenvolvida na década de 1970 por Bob Eberle inspirado nas ideias de Alex Osborn, um publicitário e autor que cunhou o termo “brainstorming

Bob percebeu a importância de estimular a criatividade e a imaginação, principalmente em contextos educacionais. O SCAMPER pode ser caracterizado como um processo prático para ajudar as pessoas a trabalhar com problemas e desafios de forma inovadora. O processo que permite que as empresas criem, aprimorem ou desenvolvam produtos e serviços.

As tarefas do processo SCAMPER

Substituir: Essa é uma tarefa que se constitui em analisar o processo de desenvolvimento do produto ou serviço. Direcionamento para a tarefa Substituir: Durante o desenvolvimento do produto ou na prestação do serviço existe algo que possa a ser substituído com intuito de proporcionar uma melhoria contínua.

Combinar: Na segunda tarefa você deve levantar a possibilidade de ocorrer uma combinação entre artefatos, competências, ferramentas, etc. com o objetivo de buscar novas possibilidades ligadas ao desenvolvimento de produtos ou serviços. Toda a sua equipe é incentivada a pensar em junções fora dos padrões com o intuito de buscar a inovação.

Adaptar: Essa é uma tarefa que direciona você a pensar em outros contextos para seu produto ou serviço. O próprio SCAMPER é um exemplo, ele surgiu dentro do contexto educacional e o mesmo foi adaptado para a área de inovação em diversas empresas de vários setores de mercado.

Modificar: Questão direcionadora desta tarefa: Quais aspectos do seu produto ou serviço pode ser reduzido,  intensificado ou alterado? Exemplos: Cor, aroma, formato e até mesmo o significado dentro do segmento de mercado. As Sandálias Havaianas é um caso clássico de um reposicionamento de mercado.

Propor: A 5° tarefa consiste em questionar se todo o potencial do produto (ou serviço) está sendo explorado. Existe outro público-alvo que pode fazer uso do seu produto ou serviço? Pense fora da caixa. 

Eliminar: O objetivo desta fase é encontrar aspectos que estão majorados no desenvolvimento no processo para desenvolvimento do serviço ou do produto. O que pode ser simplificado?  Se o meu produto (ou serviço) deixasse de existir, faria falta para a empresa?

Se a resposta for positiva, para de fabricá-lo, reorganize seus colaboradores para outros segmentos.

Reorganizar: Na tarefa do SCAMPER, as soluções para os problemas identificados já foram materializadas, neste caso é necessário repensar a cadeia de produção e levantar hipóteses das consequências dessa reordenação.

Por questões ligadas a minha função de professor, vou exemplificar a aplicação do SCAMPER no contexto educacional.

Na área de educação o SCAMPER pode ser utilizado na:

  1. Substituição de  métodos tradicionais de avaliação por abordagens mais inovadoras. Exemplo: baseadas em projetos ou portfólios.
  2. Combinação de métodos no processo de ensino e aprendizado dentro de uma sala de aula. Exemplo: utilizar sala de aula invertida em alguns momentos e aprendizagem baseada em problemas em outros.
  3. Adaptação do currículo para atender às necessidades específicas de um grupo de estudantes. Melhorar materiais para torná-los mais acessíveis.
  4. Modificação da aula para incorporar métodos mais ativos e práticos. Exemplo: Ampliação de recursos tecnológicos para o enriquecimento das experiências de aprendizado.
  5. Proposição espaços físicos alternativos para promover ambientes de aprendizado dinâmicos. Exemplo: aplicação da disciplina em um contexto real.
  6. Eliminação das práticas pedagógicas desatualizadas que não contribuem efetivamente para o aprendizado. Exemplo: a aula não deve ser somente centrada no professor.
  7. Reorganização da abordagem de ensino, permitindo que os alunos liderem discussões e projetos. Exemplo: A programação da disciplina pode incluir períodos mais longos de foco em projetos e atividades práticas.

Os exemplos de 1 a 7 podem variar de acordo com as necessidades específicas dos professores e das instituições de ensino.

Por fim surge a pergunta: O Scamper é eficaz?

Certamente alguns gestores ficam inseguros de aplicar o SCAMPER nas organizações, afinal, não é um método tão conhecido assim.

A vantagem da utilização desse processo  é a sua duração. Ele é muito rápido, pois é um processo de geração de ideias, e não aplicação delas. Também é possível destacar que não é necessário a realização de altos investimentos para aplicação do processo. 

No cenário do mercado atual, tomar decisões assertivas e rápidas tornou-se fundamental para a sobrevivência de qualquer organização. O Scamper possibilita essa realidade.

Para saber mais sobre o SCAMPER:

SCAMPER: Creative Games and Activities for Imagination Development. Bob Eberle (1971).

Thinkertoys: A Handbook of Creative-Thinking Techniques. Michael Michalko (1991).

Cracking Creativity: The Secrets of Creative Genius. Michael Michalko (1998).

O Papel do PO

O Papel do PO

O Product Owner se caracteriza como um dos principais papéis dentro do processo Scrum. O PO tem a responsabilidade de representar os interesses dos stakeholders e maximizar o  valor do produto. O Product Owner pode ser o responsável por definir e priorizar as funcionalidades do produto, com base nas necessidades e objetivos do cliente e do negócio.

Responsabilidades do PO:

  • Definir e manter o Product Backlog;
  • Priorizar o Product Backlog de acordo com o valor e a necessidade de cada funcionalidade;
  • Descrever as funcionalidades do produto de forma clara e detalhada;
  • Trabalhar em colaboração com a equipe de desenvolvimento;
  • Participar das reuniões diárias de acompanhamento do progresso do projeto;
  • Participar das reuniões de planejamento de Sprint; 
  • Participar das reuniões de revisão de Sprint;
  • Garantir que o produto esteja sendo desenvolvido de forma eficiente e eficaz.

O papel do Product Owner é fundamental para o sucesso do projeto, pois ele é responsável por garantir que o produto final atenda às necessidades e expectativas dos stakeholders e gere valor para o negócio.

Perceba que PO é caracterizado como um papel, esse papel pode ser assumido por vários colaboradores dentro de um projeto. Isso facilita o balanceamento da carga frente a complexidade de um modelo de negócio. 

O PO não pode ser considerado o ser onisciente dentro da equipe, isto não é bom para ele nem para demais membros do time. O PO tem que exercer a liderança dentro da equipe, essa liderança não pode ser autocrática, liberal, democrática, situacional. O PO deve potencializar as qualidades, conhecimentos, experiências e trabalhar os gaps dos liderados.

Por fim, é importante que o PO tenha uma relação de confiança com toda equipe, incluído da alta gerência. Caso o PO não tenha uma liderança sólida, não possui a confiança de toda a gerência ele não pode ser PO.

Reflita, o PO é um papel, esse papel pode ser constituído por várias pessoas que possuem liderança e conhecimento.

por José Augusto Fabri

Projeto, processo e Adaptabilidade do Framework Scrum

Olá pessoal, recebi a pergunta abaixo de um aluno do curso de pós-graduação em Engenharia de Software, nosso MBA da UTFPR-CP.

Como iniciar um projeto SCRUM? Ou seja, o que seria o “Termo de Abertura do Projeto” em um projeto SCRUM?

Para responder a questão vamos primeiramente definir SCRUM

O Scrum se caracteriza como um framework ágil que possibilita a customização de um processo e que visa a entrega de produtos de forma iterativa e incremental. É baseado em três pilares principais: transparência, inspeção e adaptação.

O Scrum é composto por diversos papéis, incluindo o Product Owner, Scrum Master e a equipe de desenvolvimento, que trabalham juntos para criar um plano detalhado para cada iteração do projeto. Essas iterações são conhecidas como Sprints, que geralmente duram de 2 a 4 semanas.

O Scrum é altamente adaptável e pode ser aplicado a projetos de diferentes tamanhos e complexidades. É amplamente utilizado na indústria de desenvolvimento de software, mas também pode ser aplicado a outras áreas de negócios que envolvem a entrega de produtos ou serviços complexos.

Perceba que o Scrum não é caracterizado como um projeto, Scrum é um Framework adaptável e aplicável a qualquer projeto.

Vamos as questões

Como iniciar o desenvolvimento de um projeto dentro de uma empresa que utiliza Scrum? O que seria o “Termo de Abertura do Projeto” em um projeto SCRUM?

Tendo como base que a empresa possui um processo institucionalizado a partir do Framework Scrum, você pode realizar uma primeira reunião aplicando a técnica de brainstorming e compilar todas as ideias do projeto em mapa mental (aqui temos o mapeamento de escopo). Posteriormente você também pode delimitar usuários chaves e realizar diversos refinamentos sobre as características do projeto. Neste contexto estamos falando sobre os aspectos ligados a levantamento de requisitos, delineados por várias áreas da engenharia, inclusive a de software. Você pode trabalhar com um termo de abertura de projetos como ponto de partida de um projeto, não existe impedimento para isso.

Eu apresentei uma das formas de delimitar as fronteiras de um projeto (com Mapas Mentais ou com o Termo de Abertura do Projeto). Não iremos, em hipótese alguma, abandonar as práticas da engenharia de software ligadas ao levantamento de requisitos.

Scrum é um framework. Diante deste fato destacar um dos pilares do Scrum, a adaptação. Analise as características do projeto e implemente o work no seu frame. Reflita sobre a amplitude destas palavras. 

O Scrum por si só não é a tábua da salvação, ele necessita de customizações.

Por José Augusto Fabri

FrameWork

Pessoal, vários interlocutores deste blog sempre me questionam: Fabri como você enxerga o conceito de FrameWork?

Vou separar a expressão FrameWork em duas palavras.

Frame e Work 

Entendo que a palavra Frame pode ser caracterizada como as paredes de uma casa levantada. Estas paredes aguardam o Work, ou seja a massa corrida, pintura da casa ou o assentamento do piso.

Quando você utiliza um FrameWork, você instancia a casa toda sem ela estar customizada. Cabe a você customizá-la Ao instanciar a casa toda, você pratica aquilo que chamamos reuso

Você também pode delinear no seu FrameWork quais partes da casa podem ser customizadas, por exemplo: 

  • Algumas paredes já vem com massa corrida e pintura.
  • A cozinha já está com piso assentado.

Perceba que neste caso você minimiza o nível de customização e maximiza o conceito de reuso. O delineamento das ações que serão customizadas (cômodos, paredes) depende do nível de padronização que você pretende ter dentro de sua organização.

por José Augusto Fabri

fabri@utfpr.edu.br

Vamos conversar um pouco sobre Lifelong Learning

Vamos conversar um pouco sobre Lifelong Learning. Vocês já ouviram falar sobre este termo?

É possível definir Lifelong Learning como uma modalidade de formação voluntária e ocorre na maior parte das vezes dentro de um contexto extracurricular. Um dos objetivos do Lifelong Learning é o desenvolvimento pessoal e na maioria das vezes esse desenvolvimento também é capitalizado pelas empresas. É possível traduzir Lifelong Learning como uma Aprendizagem Contínua dentro de domínio de conhecimento específico, por exemplo  a gestão. 

Alguns autores definem Lifelong Learning da seguinte forma: 

“O Lifelong learning se baseia no princípio fundamental de que sempre há algo novo para se aprender”

Geralmente a Aprendizagem Contínua ocorre fora das instituições de ensino, esta técnica de formação vem crescendo dentro das empresas.

As empresas podem implementar o Lifelong Learning de várias formas com o objetivo de proporcionar o aprendizado constante de seus colaboradores, vamos a uma proposta.

1 – Conceber ou adquirir uma base de conhecimento composta de objetos de aprendizado. Durante o processo de concepção você pode utilizar os conhecimentos de seus colaboradores com o objetivo de efetuar um processo de equalização das habilidades e competências dentro do ambiente empresarial. Uma outra técnica é termos o Lifelong Learning Motor, ou seja, o Motor da Aprendizagem Contínua. Um grupo de colaboradores que “inputam” o conhecimento na base. Em ambas as estratégias é necessária que tenhamos muito bem consolidado no ambiente questões inerentes sobre a materialização do conhecimento (aqui abrimos uma outra frente de discussão).

2 – Provocar, constantemente os seus colaboradores que eles busquem o conhecimento materializado na base e fora dela. A ideia é que os colaboradores percebam um valor agregado na sua perspectiva pessoal quando eles incorporam o objeto de aprendizagem.

3 – Compartilhar o conhecimento internalizado pelos colaboradores na solução de problemas dentro do ambiente empresarial.

  • Desenvolvimento de cursos e treinamento;
  • Desenvolvimento de webinar;
  • Participação em conferências especializadas.

Lembre-se que o compartilhamento de conhecimento poderá realimentar a base.

Por fim, é importante salientar também que a implementação do Lifelong Learning provê uma sensação de pertencimento do colaborador ao ambiente. Garantir a constante qualificação da equipe, expandir oportunidades de negócio, aumentar a Employer Branding (Marca Empregadora) são benefícios gerados pelo Lifelong Learning.

Um abraço a todos e até a próxima.

Por José Augusto Fabri – fabri@utfpr.edu.br

Aplicando métricas e estimativas de software no framework Scrum – parte III

Olá Pessoal. 

Tudo bem com vocês?  

No mês passado, Iniciamos uma discussão sobre as métricas e estimativas de software e os processos ágeis. Acessem os posts 1, 2 e 3 para se inteirar de nossa proposta.

  • No post 1 diferenciamos fortemente métricas e ágil.
  • No post 2 posicionamos o eixo da gestão junto ao framework scrum, eixo que provê os dados que irão compor as métricas e estimativas em um projeto de software.
  • No post 3 especificamos o eixo da gestão utilizando uma estrutura de dados implementável para que os envolvidos no projeto possam responder às seguintes questões:
  • Quem?
  • Está fazendo o que?
  • Para quem?
  • Em quanto tempo?
  • Com qual valor?
  • Com qual grau de qualidade?

Neste post vamos inserir atributos que configuram as métricas de software junto a entidades (vide figura abaixo).

Percebe que os atributos ligados às métricas estão circulados em amarelo. 

  • pf: pontos por função.
  • pcu: pontos por caso de uso.
  • ponto: métrica inserida nos cartões de estórias.
  • métrica: qualquer métrica que você queira utilizar, ou seja busque a mais lhe agrade.
  • linguagem: linguagem de programação que o software foi desenvolvido.

Perceba que você possui um leque de atributos, você escolhe aquele que mais se adeque ao seu projeto. Por exemplo, se sua empresa trabalha com análise de pontos por função como métricas, então o atributo utilizado será pf.

Os atributos podem ser inseridos na tabela de projetos ou na tabela de produtos ou na tabela de produção.

Se você optar por inserir os atributos na tabela de produção, você terá um dado mais refinado, sabendo a produtividade no âmbito da produção. 

Caso opte por inserir os atributos na tabela de projetos, teremos dados menos refinado, mapeamento a produtividade no âmbito da do projeto, você não terás as métricas em relação a produção de um determinado produto.

As estimativas são caracterizadas com o tempo necessário para implementar 1 ponto por função, 1 ponto por caso de uso ou 1 ponto.

Ao mapear a linguagem de programação como atributo, você poderá levantar a quantidade de linhas de código, o total de pontos por função delineado no projeto e gerar mais uma métrica de suma importância – line of code (loc).

Para finaliza. Verifique o nível de refinamento que você deseja e inseri um atributo ligado a métricas (pf ou pcu ou métricas) e o atributo linguagem na estrutura de dados.

Acredito que fechamos o ciclo de texto sobre métricas e aglidade.

por José Augusto Fabri – fabri@utfpr.edu.br 

Aplicando métricas e estimativas de software no framework Scrum – parte II

Olá Pessoal. 

Tudo bem com vocês?  

Nesta semana continuaremos nossas discussões sobre as métricas e estimativas de software e os processos ágeis. Acessem o post 1 e o post 2 para se inteirar de nossa proposta.

No último post defendemos a ideia que o framework scrum possui um eixo oculto. Isso mesmo, o eixo de gestão. Esse eixo tem como objetivo mapear:

Quem?

Está fazendo o que?

Para quem?

Em quanto tempo?

Com qual valor?

Com qual grau de qualidade?

A pergunta agora passa a ser: O que tem dentro deste eixo? 

No meu ponto de vista esse eixo internaliza uma estrutura de dados que possibilita que você realize o planejamento, a execução e controle de seu processo de produção de software.Na figura abaixo você verifica qual é o formato da referida estrutura de dados.

Perceba que estrutura proposta possui 6 tabelas:

  • Projetos;
  • Produtos;
  • Atividades;
  • Produções: Tabela que interliga as atividades do processo aos produtos;
  • Colaboradores;
  • Colaborações: Tabela que interliga as produções aos colaboradores.

Alimentar de forma automática e dinâmica essa tabela pode facilitar ao máximo a gestão de seu processo.

Por fim, perceba que alguns campos das tabela de produções já realizam uma certa intersecção com o conceito de estimativas e métricas, o campo tempo é um exemplo.

No próximo post iremos inserir as métricas na estrutura de dados e posteriormente, para que possamos realizar estimativas consistentes.

Até a próxima

por José Augusto Fabri – fabri@utfpr.edu.br 

Aplicando métricas e estimativas de software no framework Scrum (1)

Olá Pessoal. 

Tudo bem com vocês?  

Ontem iniciamos uma discussão sobre Agile e Métricas de Software. No post deixei claro que não me sinto confortável em conjuntar o termo Métrica Ágeis. Minha proposta é aplicar as métricas e estimativas dentro do processos/frameworks ágeis. Este texto tem como objetivo iniciar a referida aplicação.

Vamos retomar a figura clássica dos Scrum. 

Ao analisar a referida figura é possível perceber que presença da

  • product backlog
  • sprint backlog
  • sprint
  • Reuniões diárias

Nas consultorias, cursos, treinamentos e palestras sempre defendi que existe um eixo oculto junto ao Framework Scrum – O EIXO DA GESTÃO (grafado em vermelho na figura). Este eixo encontra-se paralelo à execução da Sprint, ele tem como objetivo mapear:

Quem?

Está fazendo o que?

Para quem?

Em quanto tempo?

Com qual valor?

Com qual grau de qualidade?

Perceba que as 3 últimas perguntas, grafadas em negrito, estão intimamente ligadas ao conceito de métricas e estimativas. Correto?

É a partir do eixo da gestão que aplicaremos as métricas e estimativas dentro do framework Scrum.

No próximo post caminharemos mais um pouco neste sentido.

por José Augusto Fabri – fabri@utfpr.edu.br 

Métricas Software Ágeis?

Olá Pessoal. 

Tudo bem com vocês?  

Vários alunos e interlocutores do blog Engenharia de Software sempre me questionam:

Professor, você não vai abordar as Métricas Ágeis nos textos e nos cursos ligados a Engenharia de Software?

Para responder a questão, vou apresentar algumas definições importantes?

1 – Métricas

2 – Paradigma Ágil

3 – Scrum 

1 – Métricas

As métricas são caracterizadas como medidas quantificáveis. As métricas são essenciais para toda e qualquer empresa, pois possibilitam o seu crescimento e melhoria.  As métricas estão relacionadas ao tamanho de algo. Podemos citar alguns exemplos:

  • Retorno sobre investimento (ROI) – Tamanho do seu retorno após a aplicação de seu investimento;
  • Taxa de venda – Tamanho da sua venda.
  • Taxa de rejeição – Tamanho da sua rejeição.
  • Quantidade de cliques;
  • Quantidade de visualizações;
  • Quantidade de downloads;
  • Life value, o quanto que uma empresa pode ganhar com um cliente;
  • Ticket médio, divisão do valor total de vendas pelo número de vendas realizadas;
  • Índice de satisfação do cliente;
  • Linha de código;
  • Pontos por função;
  • Pontos por caso de uso.

2 – Paradigma Ágil

A agilidade pode se caracterizar como um paradigma. Etimologicamente, o termo paradigma vem do grego parádeigma e significa modelo, padrão, algo a ser seguido em situações distintas.

A agilidade não pode ser confundida com velocidade. Lembre-se, você pode dirigir um carro em uma rodovia a 200 km/hora e nunca chegar ao seu destino. E se chegar, o tempo que você economizou no percurso, não vale o risco que correu. A velocidade utilizada de forma incorreta pode te levar a construir algo que não tenha valor agregado algum. A velocidade pode ser importante em alguns momentos, mas não é essencial.

A assertividade é essencial. Ter foco, firmeza, capacidade de comunicação direta e elegante são conceitos assertivos. Agilidade e assertividade andam de mãos dadas. A agilidade está ligada à ideia de ser eficaz e efetivo. Agilidade deve despertar o sentimento da confiança e da empatia nas pessoas. A agilidade gera Resultado, com R maiúsculo, para todas as pessoas de uma equipe (o cliente é o principal ator da equipe). Colaboração, feedback, flexibilidade são características ágeis de um bom time.

3 – Scrum 

O Scrum pode ser encarado como um framework com objetivo de organizar um conjunto de tarefas a ser realizadas objetivando a execução de um projeto.

Respondendo a questão: Por que não abordar as Métricas Ágeis nos textos e nos cursos ligados a Engenharia de Software?

Porque métrica é conceito que pode ser aplicado a qualquer projeto independente do processo ou framework utilizado. As métricas podem ser aplicadas aos processos tradicionais assim como aos processos ágeis.  Métricas ágeis é um termo que não me sinto confortável em conjugar. O que existe são as métricas, cabe a nós customizá-las dentro de nosso ambiente de produção, respeitando nossos processos.

Nos próximos posts iniciaremos uma discussão de como trabalhar as métricas dentro dos frameworks ágeis. Perceba o grifo na palavra dentro. Escolha uma métrica, ou um conjunto delas, e trabalhe dentro de seus frameworks.

Até a próxima.

por José Augusto Fabri – fabri@utfpr.edu.br