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

 

 

 

 

Ingredientes para prototipagem de requisitos de softwares

Olá!

A prototipagem ou prototipação de requisitos de softwares tem a finalidade de obter grande quantidade de informações sobre um problema, permitindo uma coleta de requisitos muito ágil e fluída. Possibilitando ao usuário final atuar como cocriador.

Diante do desafio de coletar requisitos de softwares, utilizar abordagens colaborativas e construção incremental de partes do produto, permite um melhor resultado devido a dois fatores:

  1. Participação do usuário final
  2. Utilização de ciclos curtos de feedback para correção e ajustes, contribuindo com a construção de produtos com foco nas REAIS necessidades dos clientes e/ou usuários

Antes de propor um sessão de prototipagem para coletar requisitos, sugiro alguns ingredientes básicos:

  1. Entendimento do problema a ser resolvido
  2. Quais os resultados esperados
  3. Definição do time multidisciplinar
  4. Escolha de uma funcionalidade chave que resolverá o problema de forma plena
  5. Definição de agenda para realizar a sessão
  6. Apoio de um sponsor

Dependendo do cenário, mais ingredientes poderiam ser necessários, mas vamos começar com estes.

1. Entendimento do problema a ser resolvido

Como assim o problema a ser resolvido? Explico.

Um desafio de negócio que hoje causa impacto negativo no processo atual, ou que poderia ser evoluído ou criado.

Vamos citar alguns exemplos:

  • Um novo processo de aviso de férias para facilitar a vida do RH, colaborador e gestor
  • Um relatório gerencial para área de compras visando apresentar as maiores compras por departamento e economia realizada
  • Uma tela de pedido de venda simplificada para ser utilizado por representantes na visita a clientes
  • Um aplicativo ou portal que permita acompanhar os custos dos projetos através de diversos indicadores para área de PMO

Todos estes problemas acima, precisarão da criação ou evolução de softwares com foco em melhoria de processo, automatização, redução de custos ou outros pontos.

Entender o problema e como as pessoas são impactadas é o primeiro passo.


2. Quais os resultados esperados

Tendo em vista que já sei qual o problema a ser resolvido, fica muito mais fácil estabelecer os resultados esperados.

Supondo que o nosso problema fosse:

Um novo processo de aviso de férias para facilitar a vida do RH, colaborador e gestor

  • Processo muito manual e sujeito a erros
  • Envio de planilhas entre os envolvidos
  • Falta de controle eficiente

Resultados Esperados:

  • Automação do processo e eliminação de erros
  • Visibilidade do processo para todos os envolvidos
  • Diminuição do custo operação para gestão do processo de férias

3. Definição do time multidisciplinar

Consiste num time que se complementa e as diferenças de visões contribuem para um produto mais aderente as reais necessidades

Apesar de ser um time, “Um por todos e todos por um” tenho dois perfis bem distintos: Técnico e de negócios

Técnico: Programadores, arquitetos, DBAs, Profissionais de UX/UI, Lider Técnico e testador

Negócios: Cliente, usuário final, gestores, Product Owner, analista de requisitos/negócios e partes interessadas.

O foco deste time deve ser a entrega do produto em ciclos curtos, muita comunicação e colaboração. Parece até ser fácil!

Acrescente um facilitador, e escolha um dos presentes para ser o escrivão da sessão de prototipagem, para registro e documentação dos requisitos discutidos.


4. Escolha de uma funcionalidade chave que resolverá o problema de forma plena

Imagine um produto contendo inúmeras funcionalidades, porém tem uma (ou conjunto delas) que é chave, aquela que “resolve a dor do cliente”

Vamos pensar no Uber, qual seria esta funcionalidade matadora?

Solicitar corrida.

Ok, alguns estão bravos comigo porque chamei de funcionalidade, e não de tema ou épico. Mas se realmente você esta preocupado com a terminologia utilizada, você não entendeu nada do que estou falando.

Chame do que você quiser: Épico, tema, macro funcionalidade, funcionalidade…

O importante é entender o conceito.Ok?

Escolhida a funcionalidade chave.

Em nosso exemplo do problema das férias do RH, vamos chamar a funcionalidade chave de: Solicitação de férias através do colaborador


5. Definição de agenda para realizar a sessão

Avise antecipadamente(normalmente utilizo uma semana de prazo) todos os envolvidos.

Informe:

  • tema
  • data
  • horário
  • duração da sessão em horas, deixe claro os intervalos
  • regras para interrupções/uso de smartphone/internet
  • local
  • nome da sala
  • fone/email/whatsapp para contato rápido

E dois dias antes do sessão, envie um lembrete a todos. Invista na comunicação intensa de seus projetos!


6. Apoio de um sponsor

Conselho básico, muitas vezes esquecido.

Proximidade com este sponsor, venda a ideia pra ele, forme uma parceria no sentido mais amplo da palavra.

Que este sponsor seja politicamente forte, afinal nem tudo se resume a utilização de abordagens ou lindos post-its coloridos, precisamos de resultados reais e mensuráveis!

O apoio deste sponsor é fundamental para iniciação do projeto, e durante a caminhada, os possíveis problemas que surgirão.

Mantenha um dialogo constante e franco.

Ao final da sessão de prototipagem, devemos ter um entendimento claro sobre a funcionalidade e o alinhamento entre todos os envolvidos.


Dica Extra

Não adianta nada utilizar todas estas dicas, e não construir o produto de forma incremental o mais breve possível com uso intenso de feedback.

#boraprototipar

#foconousuariofinal

#prototipandorequisitos

Scrum Day Brazil 2019 – Sempre aprendendo

Olá!

Participei no dia 15/06/2019 no espaço de Convenções Frei Caneca, do Scrum Day Brazil 2019, um evento bem bacana da Scrum.org.

Além de aproveitar o evento para aprender, é sempre bom rever amigos, ouvir histórias e tomar um bom café – indivíduos e interações entre eles, lembra?

Quando a gente entende, que podemos aprender com todos, ativamos um dispositivo mental, passamos a prestar mais atenção nas (ricas) histórias dos colegas.

Não assisti, toda a grade de palestras, devido ao reencontro com amigos e outros fatores.

No final da tarde, assisti a palestra do Alexandre Magno, realmente algo que nos faz refletir.

Começa com a abertura por parte da organização sobre a palestra do Alexandre Magno.

Mesmo sendo um evento da Scrum.org, Alexandre Magno(Scrum Alliance), estava lá sem preocupar-se com este detalhe. Isto achei sensacional!

Importa se é Scrum.org, Scrum Alliance ou Exin? Ou o que REALMENTE importa é buscarmos um ambiente de trabalho colaborativo com foco no cliente e produzindo resultados com ciclos curtos?

Nunca entendi esta “briguinha chata” por parte de alguns! Mas tudo bem, faz parte.

Placar: Pontos para Alexandre Magno!

Além disso, Alexandre Magno brilhantemente(no meu ponto de vista), demonstrou onde surgiram diversas práticas que são aplicadas por todos nós… Mas ele trouxe o contexto em que cada uma era aplicada… Nossa!

Como é fácil esquecer o contexto, e tentar reproduzir algo que aprendemos em outra realidade. Uau!

A ficha caiu(para mim) de um jeito estarrecedor! Obrigado Mestre

Placar: Mais Pontos para Alexandre Magno!

Parabéns ao Organizadores, palestrantes, apoiadores e participantes pelo evento.

Que venha o Scrum Day 2020 com mais lições simples e poderosas!

Todos, podem aprender com todos!