Workshop Inception to Go na Everymind – 01/02(sábado) – 09:00 as 18:00

Olá!

Era dia primeiro de fevereiro de 2020, mais um sábado …

Estávamos nós, (Alexandre, Emerson e eu) na EveryMind em Sampa para ministrar o workshop Inception to Go  mão na massa.

Vou fazer um parênteses aqui – 100% recomendaria para um amigo o workshop (informação atualizada em 06/02/2020 as 10:00 – após o fechamento da avaliação – média geral do treinamento: 9.26 ) – veja os depoimentos abaixo, e tire suas conclusões

Iniciamos com a apresentação das pessoas, tínhamos um verdadeiro caldeirão de cargos/papéis:

  • Scrum Masters e Agile coachs
  • Analistas de requisitos
  • Analista funcional
  • Gerentes de projetos
  • Analistas de negócios
  • Analistas de testes/QA

Somente para citar alguns exemplos. Imaginem as experiências destas pessoas com projetos e/ou produtos?

Realizada as apresentações, começamos a explicar a abordagem em si. Inception to Go, é uma abordagem para definir o MVP de produto digital (software) em conjunto com a funcionalidade principal, através da participação efetiva de dois atores importantes: Usuário final e o desenvolvedor. Estes atores, permitem que ao final da Inception to Go, tenhamos insumos para iniciar a construção o mais breve possível (de 2 a 5 dias após o termino da itoGo)

Abordagem explicada em poucos slides, partimos direto para a prática.

Fizemos uma dinâmica onde cada grupo, faria a fase de preparação da Inception to Go (que pode ser realizada online na vida real):

  • Definir o problema a ser resolvido
  • Pessoas chaves que participarão da Inception to Go
  • Logística/Regras
  • Artefatos a serem entregues após a Inception to Go

Cada dinâmica, mais atividades, discussões, networking e entusiasmo.

Quando nós percebemos, tinha acabado o período da manhã.

Partimos para almoço, retornando as 13:30.

Voltamos a tarde com a corda toda – mais dinâmicas em grupo:

  1. Product Vision Board
  2. Interação dos sonhos
  3. M.V.P.
  4. Funcionalidade core
  5. Etapas/protótipos
  6. Checkpoints
  7. P.O.C.
  8. Estamos prontos

Encerramos por volta das 18:15/18:20.

Para nós instrutores, foi motivo de muita alegria, aprendizado, compartilhamento e ótimas histórias da vida real.


Veja alguns depoimentos:

“Sabe aquele treinamento que quando você termina você se sente confiante e preparado para executar? Esse é um deles.
É tudo o que precisamos.
Sermos capaz de reproduzir em nosso dia a dia algo eficiente e eficaz.
Fico feliz em ter participado desse encontro.”

Selma Rodrigues – SM Coach DevOps

“A dinâmica do curso permite aprender fazendo atividades, o que faz a turma ficar muito envolvida e ‘acesa’, o tempo todo. E permite a troca de experience entre o grupo. “

Rogério Ilton Arita – Scrum Master

“Inception to Go! É a forma muito prática e objetiva de se fazer uma Inception e tirar o seu produto do papel e ou cabeça. Recomendo a todos a participar deste curso, sem dúvida muito exclarecedor e cheio de ferramentas para lhe auxiliar em seu dia a dia.”

Marcelo Gomes Ferreira – Analista de testes QA

“Sensacional pode aprender e nos fazer repensar um pouco mais sobre as etapas iniciais do projeto, muito bom mesmo, é vida real !”

Andreia Regina Paulini – Analista funcional Salesforce

“O Workshop é muito interessante e aborda o tema da Inception enfatizando a importância das duas pontas tão impactadas no resultado de uma Inception, mas tão esquecidas ou menosprezadas nesta etapa do processo de desenvolvimento, que são os desenvolvedores e usuários finais. Super recomendo o Workshop e outros conteúdos deste time incrível!”

Debora Bronzoni Aguiar – Analista de Negócios Líder

“Gostei muito da segurança/conhecimento que os palestrantes demonstram em relação às práticas da inception, e da disponibilidade em ajudar e tirar dúvidas de aplicação dessas práticas, nos mais diversos cenários”.

Sergio Roberto Xavier dos Santos Junior – Scrum Master

“Acredito que a prática proposta com o Inception To go é mais uma ferramenta voltada à colaboração e integração das equipes. É uma ferramenta que permeia o todo da cadeia de concepção de um produto criando um senso comum de pertencimento e entendimento de esforço x expectativa que proporciona ambientes favoráveis.”

Cesar Augusto Tomaz – Scrum Master

“Treinamento excelente e com muitas atividades práticas, o que facilita o entendimento e aplicação no dia a dia.”

Ricardo Batista Miluzzi – Agile Coach

“Treinamento muito legal, descontraído e produtivo. A equipe está de parabéns”

Diógenes Antônio – Gerente de Projetos

“Gostei da técnica, e com certeza irei aplicar na próxima oportunidade “

Margarete Bispo dos Santos Silva – Scrum Master


Muito obrigado a todos.

Agradecemos a EveryMind por ter gentilmente cedido o espaço, o coffee break e permitir que pessoas de fora da organização participassem.

Ao Ricardo Miluzzi por toda organização, comprometimento, parceria e ações.

Ao Marcelo Gomes, por ter doado dois livros físicos para sorteio  – Jornada Ágil e Digital

Devido a todo este apoio, foi possível realizar este workshop presencial 100% gratuito.

#InceptionToGo

Softwares, impactam vidas

Inception_to_Go_Imagem

Algumas fotos do Workshop de Inception to Go – 01/02(sábado) – 09:00 as 18:00 – SP – Escritório da EveryMind

AwMONs7QxOWZAY98

Hx53G1eAlT5ROgRwoLU0Z8awRR2EXvL3Wj_9z8cLwpw6ffTS

 

 

 

 

 

 

 

Inception to Go – Uma abordagem centrada no usuário e no desenvolvedor

Olá!

Vamos falar de projetos.

Projetos de softwares. Até parece assunto dos profissionais de Tecnologia da Informação, gestão de projetos, governança e outros, mas não é, é um tema que impacta diretamente as pessoas no cotidiano. Duvida?

Em nosso dia a dia utilizamos dezenas de aplicativos, para as mais variadas finalidades: pedir comida, deslocar, pagar contas, etc.

Mas e se, você fizesse parte de um time de uma empresa, no papel de Product Owner, analista de negócios, desenvolvedor, gerente de projeto e outros correlatos, como mapearia as reais necessidades dos seus clientes?

Os clientes podem ser internos (áreas de negócios) ou externos, isto não importa.

O que realmente importa é construir(rapidamente) software de acordo com as reais necessidades deste cliente, e gerar impacto no cotidiano do seu cliente, ou seja, a partir de uma demanda, você vai discutir colaborativamente, o que é o produto digital, qual o impacto, quem são as personas, definir o MVP e a funcionalidade core, tudo isto “dentro” da Inception to Go (que normalmente tem duração de 2 ou 3 dias).  Foco extremo!

Você esta fazendo isso?

E se eu te falar que Inception to Go, é uma abordagem para definir produtos digitais (softwares) considerando dois personagens centrais: O usuário final e o desenvolvedor. Mas sem esquecer dos objetivos de negócio.

Nada mais justo do que considerar relevante, quem vai utilizar o produto no dia a dia (usuário final) e o desenvolvedor que irá construir. E o Product Owner, onde entra nesta história? Simples, trabalha lado a lado com usuário final e desenvolvedor.

Pareceu confuso?

Então baixe este material e saiba mais sobre Inception to Go

Se o seu cliente é importante, então você vai levar em consideração o usuário final e o desenvolvedor.

Ao acessar nosso material inicial, entenda:

  • O que é Inception to Go?
  • Qual aplicação?
  • Quais benefícios?
  • Visão macro

Inception to Go

Softwares, impactam vidas.

Inception_to_Go_Imagem

Qual o problema das coisas simples?

Olá!

Não sei se é uma impressão minha, mas tenho observado algumas pessoas questionando as coisas simples.

Sinceramente, não entendo qual o motivo.

Eu tenho buscando cada vez mais a simplicidade, quanto mais simples, melhor (pra mim é claro).

O fato de eu aprender algo, simples, significa que será fácil? Eu acredito que não. Vamos aos exemplos:

Treinar 4 vezes por semana numa academia, é simples? Sim.

Mas você consegue fazer isso? É fácil manter este ritmo? Não exige esforço? é fácil? E os aprendizados em cada treino?

Será que é simples mesmo? Sim, basta você pagar, e treinar nos dias definidos e conquistar o “shape perfeito”.

Simples, mas exige esforço, dedicação, disciplina e treinos frequentes.

E o framework Scrum, é simples?

Sim, segundo a definição do Scrum Guide.

Vai tentar “aplicar” em seus projetos?

E “executar perfeitamente” cada cerimônia dentro do objetivo esperado…

A definição do Sprint é bem simples, mas…

A definição de pronto é simples…

Observe o número de artigo, livros e eventos falando sobre o tema.

E as certificações?

Então, sim o Scrum é simples de entender.

ScrumEhSimples

 

Eu prefiro as coisas simples, mas nem por isso significa que são fáceis,  ou não exigem esforço, aprendizados, discussões e praticar constantemente.

Achar algo simples de entender, não praticar no seu dia a dia, e não enxergar o poder da simplicidade, é um erro comum, no meu modesto entendimento. Simples assim!

E por falar em coisas simples…

ScrumEhSimplesPesquisagoogle

A ideia da pesquisa do Google é super simples, mas e a engenharia/esforço necessária para criar algo tão fantástico.

Esta é somente a minha humilde opinião.

 

 

 

 

 

 

 

 

Quantas Sprints para construir um M.V.P.?

Olá!

Vamos contextualizar primeiro.

M.V.P. (Minimum Viable Product) – produto mínimo viável, ou seja uma versão muito enxuta do seu produto que entrega valor para o seu cliente, e permite aprendizados, validar o mercado, o público ou ainda viabilidade técnica.

O conceito M.V.P. foi popularizado no Livro Startup Enxuta do Eric Ries, a ideia consiste trabalhar com poucos recursos, e buscar validar ou não a hipótese do MVP.

MVP não é:

  • Produto ruim
  • Protótipo
  • Foco na parte técnica

Vamos imaginar o seguinte exemplo:

Pense que você quer aplicativo para unir cuidadores de idosos e famílias que tenham idosos, e demandem um cuidador. Este seria o objetivo do seu produto completo, que teria inúmeras funcionalidades para cuidar de toda a jornada do cuidador, do contratante, da plataforma e assim por diante.

A ideia do MVP, seria construir algo muito simples, de valor para ambos os públicos e proporcionar alto aprendizado com períodos curtos de tempo.

O MVP neste caso poderia ser:

  • Uma pesquisa(por exemplo no Google forms) em grupos de Whatsapp perguntando se você contrataria este serviço?
  • Uma Landing page para você se oferecer como cuidador com seus dados de contato, ou a  família, e alguém fazendo o contato entre as pontas.
  • Um vídeo no Youtube explicando como funcionaria o serviço

Acho que ficou claro o que é M.V.P, senão veja os links abaixo no final deste post.

E Sprint, neste caso estamos falado das Sprints do Scrum, que é um período de tempo(de 1 a 4 semanas), onde o Time Scrum trabalha para realizar uma entrega de valor para o cliente. Na sprint, o time faz planejamento, inspeções diárias e trabalho árduo, até acabar o período de tempo acordado para o tamanho da Sprint.

No final deste post colocaremos alguns links para que você possa estudar sobre o Scrum.

Agora, voltando ao tema do post.

Vamos imaginar que nosso aplicativo ligando cuidadores de idosos a famílias tivesse as seguintes funcionalidades – produto “completo”:

  1. Pesquisar cuidadores
  2. Pesquisar famílias
  3. Match cuidador X Família
  4. Perfil do cuidador
  5. Perfil da família
  6. Agendamento da primeira visita
  7. Fechamento de contrato
  8. Envio de documentação do cuidador
  9. Avaliação da documentação do cuidador
  10. Aprovação do cuidador
  11. Reprovação do cuidador
  12. Avaliação do cuidador por parte da fámilia
  13. Avaliação da família por parte do cuidador
  14. Ranking dos melhores cuidadores
  15. Ranking dos melhores famílias

Estas seriam as funcionalidades do produto “completo”, e M.V.P, seria as funcionalidades abaixo:

  1. Pesquisar cuidadores
  2. Pesquisar famílias
  3. Match cuidador X Família

MVpCuidadorFamilia

Então neste caso, estamos escolhendo as 3(três) funcionalidades que vão compor o nosso MVP. Imagine que nosso time desenvolvimento estimou que para desenvolver este MVP, seriam necessários 5 sprints de 2 semanas cada.

Então neste caso, nosso MVP seria construído em 10 semanas. Logo, um MVP  pode consumir várias sprints. E este é o cenário mais comum.

Desta forma, quanto mais funcionalidades, mais recursos exigirá.

Vamos pensar Lean, este é o desafio!

Alguns links

O que é um MVP?

Sprint: O coração do Scrum

Audiobook(português) do Scrum Guide 2017 do André Gomes

Dica de livro: Lean Inception

Dica de livro: Comece sua Startup Enxuta

MVPQuantasSprints

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

E-book(GRATUITO) Por quê Prototipar requisitos de softwares

Olá!

Baixe o E-book(GRATUITO) sobre Por quê Prototipar Requisitos de Softwares:

http://prototipandorequisitos.com.br/ebook-prototipando

Quais os motivos para colocar o usuário final no centro da discussão, como um co criador? Em um mundo onde softwares estão em nosso dia a dia, compreender este simples fundamento, permitirá conceber, construir e entregar produtos digitais com aderência as REAIS necessidades e que faça a diferença no dia a dia do seu cliente.

Produtos digitais deveriam facilitar a vida das pessoas!

#prototipandorequisitos

Abraços

Fernandes Lima

Agilenow.com.br

 

ebook_mockup-img-1417738-20190826190430

 

 

 

Conteúdos sobre Histórias de Usuário – Agile

Olá!

Resolvemos reunir vários conteúdos sobre Histórias de Usuário, para facilitar sua vida.

Vamos colocar o link direto para o fonte original.

Além de conhecer mais sobre o tema, você aprenderá técnicas que podem lhe ajudar no dia a dia.

Histórias de Usuário na Wikipedia

E-book gratuito – Histórias de Usuário – Rafael Helm

7 dimensões do produto – Blog Café com Scrum

Como escrever uma user story Fantástica – Analisederequisitos.com.br

Escrevendo Histórias Eficazes – André Vidal

8 dicas para escrever boas Historia de usuários -Metodoagil.com

Histórias de usuarios INVEST – Agilemomentum.com

Backlog DEEP, Histórias INVEST e Tarefas SMART – LuizTools

O trabalho de F.D.P. do Product Owner

Dica Extra: User History Mapping 

#somaresforcos

Histórias de usuário

 

 

 

 

Conceber e entregar software como antigamente

Olá!

Em pleno domingão, temperatura agradável em Londrina/PR, ao baixar a edição do dia 11/08/2019 no Estadão Digital, seleciono alguns conteúdos e um me chama muito a atenção:

Seguro, despachante, aluguel e desmanche já são feitos por celular

A matéria do estadão fala de mobilidade urbana e a onda de startups com foco no setor automotivo.

“Se não assistimos televisão como antigamente, não usamos banco como antigamente, não nos deslocamos pela cidade como antigamente, precisamos questionar também outras relações de negócios ainda engessadas”, ressalta Ricardo Bernandes, presidente da Onsurance

Lendo o texto integralmente, a gente identifica umas opções bem diferentes e com foco na dor do cliente.

Diante disto, pensei, Por quê a gente ainda esta fazendo software como antigamente?

Explico.

Ainda perdemos uma infinidade de tempo tentando detalhar todo o escopo de um projeto de software, todas as possibilidades, exceções e fluxos.

Perdendo tempo, em identificar e/ou mitigar todos os riscos.

Muitas vezes, ignorando as REAIS necessidades do usuário final.

Perdendo tempo, construindo o produto errado.

Processos de construção morosos!

Eu gosto muito das seguintes práticas:

  1. Identificar a dor a ser resolvida – Lean Startup
  2. Envolvimento do usuário final como co criador
  3. Time de negócios e técnico trabalhando juntos
  4. Ter uma visão macro da dor a ser resolvida
  5. Participação ativa da área de negócios na priorização e detalhamento
  6. Uso de prototipação como ferramenta de comunicação ágil entre todos
  7. Iniciar a construção por uma pequena parte
  8. Entregas incrementais com ciclo curto, aliada a muito feedback e colaboração na veia

Já pensou se nossos projetos de softwares, pudessem adotar as práticas acima?

Parece simples, né?

#prototipandorequisitos

dinossauroAntigamente